A Forth for Gigatron?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
User avatar
ECL
Posts: 26
Joined: 01 Feb 2020, 17:56

seedForth - said to be real quick to port

Post by ECL » 04 Feb 2020, 15:54

https://fosdem.org/2020/schedule/event/ ... synthesis/

at the end of the talk, the lecturer makes the claim that seedForth can be ported to a new CPU within half a day, with the first half spent on reading the guide as a non-Forth programmer.

only like 30 simple instructions to implement in vCPU Gigatron machine code and you're done! :)

https://github.com/uho/preForth has i386 Assembler to be replaced by vcpu machine code. Mr Hoffman says he has AMD64 arch target but that is not on github ready-made like i386

the goal is to run this interesting App : https://github.com/uho/preForth/blob/ma ... h/hi.forth

pdr0663
Posts: 7
Joined: 13 Mar 2020, 10:26

Re: A Forth for Gigatron?

Post by pdr0663 » 13 Mar 2020, 10:57

Here's my wishlist for Forth features:

1) SPI -> SD card
2) Simple file IO to read and write sequential files to and from the SD card.

I applaud the efforts to implement Forth in the native assembly language, I think that's truly in the spirit of Forth and this machine.

Thanks for all of the Forth effort!

Paul

qwertyface
Posts: 18
Joined: 16 Jul 2019, 09:19

Re: A Forth for Gigatron?

Post by qwertyface » 14 Mar 2020, 13:42

Thanks. Perhaps it would be useful to let people know where I'm at with the Forth effort.

Right now the progress is hard to see - to date there isn't anything that is directly runnable on real hardware on an emulator. However I have quite a large part of the system implemented - including 34 of the 168 words in the core and core ext. lists, and many building blocks to support them (e.g branching). Many of these are themselves implemented in Forth as I have a sort of cross-compiler working. This has accelerated things very substantially!

My next step will be to get input and output working, by providing a means of wrapping the SYS functions built in to the Gigatron ROM as Forth words. Part of this is having a means of entering and re-entering Forth from vCPU, while making sure that all of the timings line up correctly.

I also need a means for loading an initial dictionary into RAM on start up, and words for working with the dictionary, and there are a few other things that I don't yet have a ROM-based encoding for yet like variables and strings.

Once I have these things, I should be close to having a working system. I intend to try to use this Forth 2012 test suite to guide me through bringing up the system.

In terms of SPI and SD card development, these things "should" be "just" a matter of programming at that point - the SYS functions are currently used from vCPU can be exposed to Forth, and the block and file word lists built on top of that.

I've been taking a little break from development for a few weeks, but I expect to get back into it soon. If anyone is interested in helping out, I'd be happy to provide some guidance - there's still some words that can be trivially implemented in Forth right now, and many more that will become unlocked once a bit more work is done.

pdr0663
Posts: 7
Joined: 13 Mar 2020, 10:26

Re: A Forth for Gigatron?

Post by pdr0663 » 15 Mar 2020, 07:31

Well done. I'll have a look at some of the Forth words to extend it further. Do you have a native assembler for the G?

Paul

monsonite
Posts: 70
Joined: 17 May 2018, 07:17

Re: A Forth for Gigatron?

Post by monsonite » 31 Mar 2020, 16:19

Hi, I have been following Ulrich Hoffman and Andrew Read's work for a couple of years.

There an interesting paper from the 2018 Euroforth conference that was held in Edinburgh

http://www.complang.tuwien.ac.at/anton/ ... ffmann.pdf


The Forth kernel is first dis-aggregated into two separate processes that can then be reconnected

The first is "preForth" that was mentioned by ECL above. This contains just 13 primitives which allows the virtual machine to be constructed using only the datastack and the return stack structures.

There is no random memory access at this stage (it is added later) - everything is processed on the stacks.

preForth does not permit the use of immediate words - so it relies on Forth source code that has already been compiled into a sequence of 16-bit addresses. (Or I suppose you could enter manually the address of the routine you wanted to execute - a bit like a monitor program) There is no interpreted mode or the need for a dictionary search or dictionary structure - at this low level - this is also added later.

Code: Select all

 preForth is a minimalistic non-interactive Forth kernel that can bootstrap itself and
can be used as an easy-to-port basis for a full Forth implementation.
preForth feels like Forth - it is mainly a sublanguage of ANS-Forth - but is
significantly reduced in its capabilities.
Features:
minimal control structures, no immediate words, strings on stack, few primitives
just
• stack
• return stack
• only ?EXIT and recursion as control structures
• colon definitions
• optional tail call optimization
• IO via KEY/EMIT
• signed single cell decimal numbers (0-9)+
• character constants via ’c’-notation
• output single cell decimal numbers
and
• no immediate words, i.e.
• no control structures IF ELSE THEN BEGIN WHILE REPEAT UNTIL
• no defining words
• no DOES>
• no memory @ ! CMOVE ALLOT ,
• no pictured numeric output
• no input stream
• no state
• no base
• no dictionary, no EXECUTE, not EVALUATE
• no CATCH and THROW
• no error handling
preForth is based on just 13 primitives: emit key dup swap drop 0< ?exit >r r> - nest
unnest lit which are defined in the host language.
The next layer is simpleForth :

Code: Select all

simpleForth is an extension to preForth built using preForth. It is still
non-interactive but adds
• control structures IF ELSE THEN BEGIN WHILE REPEAT UNTIL
• definitions with and without headers in generated code
• memory: @ ! c@ c! allot c, ,
• variable, constants
• [’] execute
• immediate definitions
Enough convenient words to formulate an interactive Forth

As with any Forth implementation it is important to get the inner loop (usually called NEXT) of the VM to execute as efficiently as possible - as this is where Forth gains or loses its speed advantage.

The inner loop picks up the 16-bit start address of the word (function) to be executed and then jumps to that address. At the end of the function, there is a jump back to the start of NEXT.

Sometimes Forth will make use of 8-bit tokens to identify its words, but this introduces an extra stage of look-up to get the code field address.

Post Reply