[ColorForth] code sharing

[John Drake <jmdrake_98@xxxxxxxxx>]

--- Mark Slicker <maslicke@xxxxxxxxxxx> wrote:
> 
> 
> On Thu, 25 Jul 2002, Bob Shafer wrote:
> 
> > 
> > I happen to have "Project Oberon" sitting on my
> desk (borrowed from a
> > library the other day). It contains all (or nearly
> all) the source code
> > to the (first) Oberon System. But the book is much
> more than that: it
> > explains the System. (Since that time (late-80s),
> the System has continued
> > to evolve, and I don't really follow the latest
> incarnations much).
> > 
> 
> I think it was you who sugested looking a Native
> Oberon for device
> code. When I checked, the kernel was closed source,
> only available to
> other academics.

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.)
 
> > ColorForth is partly about _not_ abstracting from
> the hardware, isn't
> > it?
> 
> Right.

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.
 
> > That was what I was trying to get at. Because of
> that, colorForth
> > code is inherently non-sharable, unless you take
> the time to truly
> > understand it, and then re-implement the bits you
> need to, to port it
> > to your hardware.

I'm not sure I follow you (Bob) here, but if 
you're saying what I THINK you're saying I disagree.
ColorForth is still an abstract machine model just
like Forth.  But some neat things are added like
an address register.  Such things were available
in MachineForth.  It ain't Pentium specific folks.
 
> But remember, machines are a commodity now. Code
> that works on one
> 32-bit intel will work another (cpu code, not device
> code). There are
> esentially two classes of commodity hardware. One is
> intel the other is
> powerpc, ignore workstations since they are a small
> minority. As Chuck
> wrote on his site, macros do factor the machine
> specific code, so his
> helps in porting the machine specific code.

Excactly.

> Glad to hear, that was the intent of my first
> message, to provide a
> platform for people with different methods.
> Unfortunately it was taken as
> hostile. I'm not hostile toward ASCII just wanted to
> hear the opinion of
> those that have good amount of experience with it (I
> have no ASCII forth
> experience). 
> 
> Mark

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!)  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.

Regards,

John M. Drake

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
------------------------

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