[ColorForth] code sharing

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Fri, 26 Jul 2002, John Drake wrote:
> 
> Check again.  The kernel source may be closed but
> the device driver code is open.  They even have
> a section on the web-page on how to write device
> drivers.  The only device code that's not freely
> available is code that's based on information from
> vendors who required them to sign NDAs.  And even
> that is handled on a by request basis.  (Hint, you
> don't absolutely positively have to be an 
> accademic.)
>

Will check, when looking at device code I like to see it written
directly for the hardware. Will see how useful abstract device code is.
  
> 
> I think it's possible to make a bigger deal
> abstraction
> then it really is.  ColorForth IS an abstraction of
> the hardware.  Not as big as an abstraction as some
> other languages perhaps, but an abstraction 
> nonetheless.  The wordset was pretty much set before
> Chuck coded it for the Pentium.  It would probably
> be pretty much the same if it was ported to the
> PowerPC.  Remember, ColorForth is an evolution of
> machine Forth which was basically Chuck's chip's 
> instruction set.  So what does that mean in 
> real terms?  If I code an algorithm that 
> isn't hardware specific, like CRC-32 for 
> instance, and moved my code from ColorForthOS 
> to Flux or even PowerPC ColorForth I should 
> expect it to work pretty much the same.
> However if I'm doing something like graphics or
> sound that's a whole different can of worms.  
> Chuck implementation of ColorForth as Pentium macros
> keeps the implementation low level, but it could
> be implemented different ways (as a simulation of
> c18 hardware for instance).  Don't forget, Lisp
> was orginally coded directly to a specific machine.
> CAR and CDR originally stood for Contents of Address
> Register and Contents of Data Register.
>

Never heard that about Lisp. Interesting. Agreed about the
abstraction.

In my jpeg code, I have four machine macros. This code should be very easy
to port to other machines. The local powerpc colorForth guru will have no
trouble with it.

Portability people will not be satisfied until my code works on every
machine made, every operating system created, ect. There is really no
sense in accommodating these people, they will already reject the code
since it is not in a standard character set, not in the C language, ect.

> 
> I didn't take your statements as "hostile towards
> ASCII".  In fact I would agree (I think I already
> did) that for colorForthOS to colorForthOS code
> sharing blocks are probably the best way to go.
> That is provided that there's a good way to
> extract/insert blocks for us non-Linux folks.
> (Is there?  If so I missed it.  Someone please
> repost!)

For someone who knows windows I/O, a block reader/writer would probably
not be too dificult. But, I'm not sure what method is used by the windows
folks.

The point of Terry's message was (I think), what form of source would you
choose, perhaps if colorForth didn't even exist. For me it is preparsed,
even before I discovered colorForth, I was experimenting with editing an
in memory parsed representation of the source code. colorForth has all the
things to make the preparsed idea work, and more efficiently than ASCII.

>  Beyond that if ASCII is necessary for
> ColorForth strongly depends upon what ColorForth
> grows into or more specifically what projects
> people decide to tackle with ColorForth.  iTV
> (which Chuck and Jeff were both involved in)
> of course had to use ASCII for 4os because 4os
> by definition needed to be able to handle HTML.
> I'd love to see something like 4os built using
> ColorForth and ultimately running on something
> like the 25x!  But that would require a whole
> different set of assumptions than what's required
> for OKAD II.
> 

Still you don't need ASCII to deal with HTML. If you need to write e-mail
headers, or write HTTP headers hex will work, but it is very cryptic for
something that is human readable.

Alternatively, you could use one of the unused tags as a ascii string
tag. Richard Collins on his c4w page describes using blue words for such a
purpose. Seems very appropriate if your application needs to write ASCII
data.

25x is also of interest to me, I agree you need a different set of
assuptions. The on chip memory is very small, so need to factor the
problem very differently than the single chip large address space pentium
machines.

Mark

------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com
Wiki page http://kristopherjohnson.net/wiki/ColorForth
ColorForth index http://www.users.qwest.net/~loveall/c4index.htm