Alternative Languages

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
Post Reply
Posts: 77
Joined: 17 May 2018, 07:17

Alternative Languages

Post by monsonite » 31 Mar 2020, 16:51

Hi All,

I have started this new topic so that alternative languages may be discussed without deviating or diluting the superb content of some of the existing threads.

Clearly there is some interest in Forth on this forum - which is excellent, bearing in mind that Chuck Moore was presented a Gigatron Kit around the time of his 81st birthday.

My own interests lie in minimal language implementations, and of course minimum hardware - of which the Gigatron excels at.

By minimal - I set an arbitrary limit of 1024 bytes of code.

Here are some notes I made back in August of 2018, before the Gigatron even had a keyboard interface - when I proposed my own minimum Forth-inspired language, which I call SIMPL.
Forth is 50 this year - recently some original 1968 assembly listings for the IBM 1130 came to light, with Charles Moore experimenting with an early Forth.

From the 50 year old listings, you see how Chuck builds up his Forth from the ground up using a few primitives, which exploit every feature of the machine architecture.

In the light of this new interest in Forth - I have experimented with a much reduced form of Forth, which requires no dictionary, and the interpreter fits into under 1k bytes of assembly language.

I call it SIMPL - serial interpreted minimal programming language.

Having implemented it on ATmega, ARM and MSP430 - I think that it could be ported to the Gigatron,
and run as an alternative 16-bit interpreter to vCPU - but still be compatible with the vCPU ROM coded routines.

It would in effect treat each vCPU as a primitive instruction on the 16-bit virtual machine - and allow a stack based,
Forthlike interactive language to be written from these primitives.

What it does bring is the interactive nature of Forth. Code typed at the keyboard can be executed immediately, or "compiled" into user definitions, which can be strung together to perform simple actions.

Flashing LEDs, toggling ports and playing musical notes - by keyboard interaction are just a few of the things I have used it for.

At it's heart, is a character interpreter running in a loop. The interpeter is pointed at an area of RAM containing the user's ascii text input.

Using single ASCII characters, every symbol is treated by the interpreter as a call to an assembly language routine to perform some action.

Tokenising the instructions this way allows for a more memorable language, and a lookup table is used to convert each ascii value into the start address of a function block of code.

For example the plus symbol +, when read by the interpreter, calls a block of code that adds the top two entries of the stack and leaves the sum on the stack.

For convenience, lower case characters and punctuation symbols are used to provide a call to "primitive" assembly routines. There are 59 symbols available for these primitives. They provide highly mnemonic access to the assembly routines running in the 16-bit machine from ROM.

Uppercase characters are used to define new words - created from combinations of primitives. This is analogous to the colon definition - as used in Forth. Clearly the user is restricted to just 26 of these user definable words - and this is the main limitation of this implementation. On encountering a capital letter, the interpreter is forced to jump to a fixed location in memory - where the code for the user routine is located. This effectively removes the additional complexity of a dictionary search - found in proper Forths.

The interpeter tests the text input buffer for number characters - and on finding a number or a string of numbers, converts that into a 16 bit integer that it puts on the stack.

I have used the space character as a means of separating numbers. When the space character is encountered it signals the interpreter that the next number should be placed on the arithmetic stack

Marcel's ROM consists of a series of assembly routines that can be called in this manner. It would be a simple task to link his ROM routines with an interpreter - to create a kind of pseudo-Forth.

But what is it good for? When bringing up a microcontroller for the first time you want to exercise ports, access memory and communicate with a serial terminal.

My cut down Forth, allows toggling of I/O ports, flashing LEDs, generating square wave signals (musical tones) and terminal communications - all in an interactive manner.

I think that it could be ported to the Gigatron fairly easily, having prototyped it already on an MSP430 in under 1024 bytes of assembly language - which is about 300 assembly instructions on the 16 bit MSP430.

The Gigatron would need as a minimum a serial terminal interface. At the moment it can shift 8 bit characters onto the databus. Adding an 8 bit output shift register would allow for a synchronous serial interface - which an Arduino could translate into a regular serial terminal interface.

Some examples - entered from a serial terminal:

h - set a port pin high
l - set a port pin low
hlhlhlhl - toggle a port pin to generate a square wave
1000 - put 1000 on the stack
1000 2000+p - add 1000 and 2000 and print them
1000m - a 1000mS delay
600u - a 600uS delay
h600ul600u - set port high for 600uS then low for 600uS

Now we introduce loops

10{kp} k is the loop variable that gets decremented each time around the loop, p prints the top of the stack - which is k

This prints the numbers 10 down to zero.

Now we can make musical tones

1000{h600ul600u} - 1000 cycles of 600uS high and 600uS low -> 1000 cycles of 833Hz tone

Like Forth, we can define new words using a colon definition - capital letters are used for htese new words.

:A1000{h600ul600u}; Define a word "A" that plays 1000 cycles of 833Hz

Every time A is entered - you get a short tone. All 26 capital letters can be assigned in this way.

It's definitely not Forth, but it shares a lot of similar ideas in a much smaller package.

I can supply more details for those that are interested.

Posts: 22
Joined: 16 Jul 2019, 09:19

Re: Alternative Languages

Post by qwertyface » 01 Apr 2020, 09:48

Here are a few strands of thought on virtual machine design. I don't know if they add up to anything - but if you were to design a new language with the Gigatron in mind, choosing an appropriate execution model seems half the battle.

I'm increasingly wondering if Forth isn't such a great fit for the Gigatron - Threaded code is fine (my implementation may not be) - in fact combined with a return stack I think it is the key to having code across both RAM and ROM. However my current impression is that you pay a rather sizeable penalty for the data stack on the Gigatron architecture. I know vCPU has recently gained interrupts - which makes reentrancy a concern, but that not withstanding, statically allocating all data as a BASIC would may be a better idea for many purposes. I recently saw a conversation on Twitter along these lines, and it really struck a chord.

I've been following a project by Whitequark called Boneless CPU. This is a 16-bit RISC designed to be cheap to synthesise on an FPGA, and it uses a memory-backed register window (which always moves by 8). Apparently the design goal is to be as close to a normal load-store architecture as possible in a small amount of logic, presumably with the goal of being easy to target with LLVM and similar. It's interesting to contrast with the Gigatron - because it's quite a different design with not-dissimilar goals. The difference between designing in 7400 series logic and designing for an FPGA gives rise to some differences, and then the matter of degree of what counts as a small amount of logic probably accounts for much of the rest.

A while back Marcel posted an interesting YouTube video about a virtual machine for the 6502 which also used a register window (in the zero-page) of which one register is temporarily chosen as a sort of accumulator. The instruction encoding employed some nice tricks to make it dense, and you couldn't do exactly the same thing on the Gigatron. This gave code density similar to Forth, and performance comparable to SWEET16.

I feel like my Forth is spending a lot of cycles copying data from the stack to zero-page variables, to have easy access to them, and then copying them back - and a future optimisation I'd be interested in would be to make this a bit more formal - build something more like that 6502 VM, underneath Forth, or at least implement "register"-oriented words and use those as the building-blocks for higher-level words.

I was browsing old threads on here recently, and I saw mention, (perhaps by you?) of TinyBasic being implemented on top of an abstract virtual machine - making porting easier. If you were to design a new VM - being a good target for BASIC and Forth, and perhaps GCL and even C might be worthy design-goals.

User avatar
Posts: 490
Joined: 13 May 2018, 08:26

Re: Alternative Languages

Post by marcelk » 01 Apr 2020, 12:10

For vCPU we purposely went for a model that encourages to put everything important on fixed locations in zero page. For small programs on small computers, that is perfectly fine. And that's why the GCL notation doesn't even bother with scoping. Still you can do recursion if you want, using LDWL, STWL and ALLOC. See Queens. But those aren't really needed for typical programs. We merely added those, days before releasing ROM v1, a bit for demonstration purposes and for some sense of completeness.

But Forth is Forth. It is still cool now because of its legacy. Not because it brings new applications to the Gigatron. At least, I can't come up with one. I just want type in a colon definition and execute it. I don't see speed optimisations as very relevant on this computer. To me, working programs are important, and to get them with low effort. The system is still just a toy, please don't take it too seriously. So that's why my personal Forth kick-off went for vCPU. I don't want to solve the same problems over again :-)

Posts: 22
Joined: 16 Jul 2019, 09:19

Re: Alternative Languages

Post by qwertyface » 01 Apr 2020, 14:11

Yes, that all makes perfect sense. I'm continuing to learn a lot from the Gigatron - especially about what is and isn't easy!

I'd like to see Forth become a viable alternative to C for writing larger programs on the Gigatron - but C on vCPU, will likely prove to work better in practice.

User avatar
Posts: 490
Joined: 13 May 2018, 08:26

Re: Alternative Languages

Post by marcelk » 01 Apr 2020, 14:37

qwertyface wrote:
01 Apr 2020, 14:11
Yes, that all makes perfect sense. I'm continuing to learn a lot from the Gigatron - especially about what is and isn't easy!

I'd like to see Forth become a viable alternative to C for writing larger programs on the Gigatron - but C on vCPU, will likely prove to work better in practice.
IMHO, C on vCPU has a pretty long road ahead of it before becoming useful. The initial LCC port is a gigantic step, but its current backend should really be seen as a concept. Also we've lost contact with the author. In the GitHub issues I've documented what I found. There are quite a few of them. I lumped everything related to speed and code density into 1 single issue, because those can come later and are not critical. I believe there is something amiss in the register allocation that takes some concentrated effort to resolve. This must be addressed before anything else. I tried last year, but I had to give up because personal issues took precedence. I don't see myself picking it up again soon. But the good news is, once the allocation problem is out of the way, all the rest is "just work".

Personally, I now see at67's BASIC compiler as the next prodigy in program/game development. The demos in his directory are very impressive (rotating cube...).

Post Reply