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
