home .. forth .. misc mail list archive ..

Re: Color Forth 2000 from a FIG FORTH FAN.


Jeff Fox wrote:

> I went from assembler to Forth source for two reasons,
> the first was I found the source much easier to read.
 
> But I also maintain that the original document on Forth
> stated that Forth was written in Forth and that this
> was one of the things it was very good for.  I couldn't
> agree more and don't see that his ever changed except
> for the people who tried to write their Forth in assembler
> or 'C' or Java or Cobol or whatever.

I agree but some times you just need to get at the bit level
of a program. Hmm at 54AC that needs to be F3 not E3, I must
have a bad memory chip.  

> Color Forth has not been released.  The only way to "get"
> it would be to implement one yourself.  Chuck would
> encourage people to try it and experiment since it isn't
> hard to do.

That is one thing I like about Forth.

> 
> Forth isn't 'C' and 'C' isn't Forth.  I am happy with that.
> I know other people would like to see Forth become 'C', not me.
> 
	C is nice but it is getting to be a bit bloated.
 Playing around with Small C I have come up with a nice general
purpose cpu design ( see Octal Computers ) and have thought
of adding ! and IF( relative ) and CALL( relative ) to make the
cpu able to run Forth more effectively but I can't think of a clean
way to do it.
Hmm I just thought of a clean way to add
CALL and IF. I think I may just add it to my cpu. On second
thought I will just add CALL. This only a few gates to add.
IF requires a few more TTL chips.
 
> I found the carry bit implementation to be interesting and liked
> using both IF and -IF.  Chuck found it less useful and dropped it.
> I think whether IF drops is pretty much a wash.  There are things
> about it that are nice about both versions.  One solution would
> be to offer both in the instruction set.  But one should
> remember that there are also tradeoffs involved in hardware.
> The number of instructions is limited

True.

> ... in the CAD system so he doesn't
> have a requirement that the source be editable with
> Emacs like many other people.

YUCK!  ( I am not a Emacs fan ).
t.com for MDOS was a text editor that was only 4096 bytes long.
64k text size but for autoexec.bat and config.sys it is great.
 
> The issue is hardware design more than software.  You have
> a right to your opinion.  What alternative would you prefer?
> How would it effect the hardware implementation and speed?
>
  With Forth you add a extra cycle to add to the PC for a branch
and call.Too slow for a dedicated Forth machine but not for 
a general purpose machine with Forth instructions added.

> But Blocks predated file systems in Forth. They are
> one of the "changes" that people have made to Forth.
> I thought you said you felt that the changes since
> FIG Forth were bad things.  FIG Forth used blocks
> although I adapted one version I was using to use
> native OS files.

I have found a copy of Forth 83 for 8080 and plan to
play with that. Since I don't have 8080 computer any
more I am running a CP/M emulator (Yaze) under linux.
I don't expect fast compile times. :)


> Sounds interesting, Color Forth sort of works that way.  If
> I do a complete transcription of the presentation you will
> see what I mean about cursor, menus, text, and graphics
> in this Color Forth.
Too bad many products seem to pushed out by Management
before they are ready. Color Forth ( No it does not run
on the 6809 Color computer yet .(grin)) looks to be a very
well polished and Classy piece of software.
Ben.
-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
"Octal Computers:Where a step backward is two steps forward!"
 http://www.jetnet.ab.ca/users/bfranchuk/index.html