Sunday 16 September 2018

Catching up

for next and i macro definitions
The current M8 has nearly caught up with the old version of M8. It's acquired structures, the code on the right is for for ... i .... next. Like ColorForth you can't nest them, so break up your code :)

Most of the standard vocabulary is there now (all ?) so I can compile some of the libraries I wrote previously, the Console I/O and memory dumper ran straight off. 

"M" is now fairly standardised.

By FORTH standards it's quite rapid ; for example for 10000 for next it compiles the following (you can probably see the pattern in the for and next words defined in the picture). It keeps the loop value on the top of the stack and also puts it in A at the start of every loop (this is an optimisation that became a language feature, fun when you write your own language ....)

 ex de,hl
 ld hl,10000
loop:
 dec hl
 push hl
 pop hl
 ld a,h
 or l
 jr nz,loop

which isn't amazingly efficient by pure Z80 stanrds, but isn't bad. As far as I can see once you get used to the slight oddities, it's much quicker than writing Z80 assembler and it's quicker than Z80 FORTHs, even the multitasking one which works in Z80 code.

So next up, the editor. It would probably port straight off, but I've decided to rewrite it. The major change to the language involves the use of register known as 'C' (actually Z80 BC register) (A is HL and B is DE), which is used as a temporary register, which should hopefully cut a lot of the pushing and pulling of stack values the original had.

Once the editor is working it's a short step to it working interactively.

The variables thing is quite like Color FORTHs but takes it a stage further ; declaring variable FRED creates three words FRED& (get address) FRED@ (get value) FRED! (store) which cuts out a lot of stack work and the work is handled by the compiler. I really wanted this because I thought limiting the 'stack' - e.g. workspace to 2 (now 3) registers would mean an explosion of variables. The odd thing is it hasn't ; you could make a pretty good case that the variables actually are cleaner code that faffing around trying to remember what is where on FORTHs stack, do I do OVER ROT or something, which always annoyed me.

No comments:

Post a Comment