Tuesday 7 April 2020

More ideas.

While lounging in the bath this morning I remembered this language I'd found a while back ; it was called RPL, and it was for the Commodore PET. It was very similar to FORTH ; same basic idea, different syntax. It used the tokenising system as a sort of virtual machine code. Problem was the 6502 is great at one thing, being cheap, and not very good at many other things, so it was a bit limited.

Had the idea of doing a similar sort of thing here. I was going to do FORTH anyway, but I thought if I used an inlined FORTH I could take advantage of some of the things already there - for example variables and have a fixed dictionary. Then you could add quasi-FORTH using this sort of syntax

new.word = RPL(40 2 + dup . . )

So RPL would be a unary function that returned it's call address. Dup and + could either be in a fixed dictionary, or variables themselves. You could have immediate variables and so on as well. Implicit semicolon at the end. Once you've defined it you can just call it with sys new.word and it already knows about the variables. Arrays wouldn't work, but indirection would be fine a la structures in BCPL.

Now, to fix actual variables - there is a problem if you have a word in FORTH it 'knows' what it is. This doesn't. So the idea is something like - a variable compiles its address , so you could write

another.word = RPL(new.word new.word)

Variables would track the reference of the last compiled address, and use two operates to back patch. These couldn't be @ ! so I have used @@ and !! in the past e.g.

another.word = RPL(count @@)

would initially compile jsr #<whatever value count is> but in this case it would back patch and replace that with push r0 ; ldm r0,#<address of count>

I will give it more consideration.

No comments:

Post a Comment

Breaking change

We all make mistakes. One early mistake I made was copying (partly) the old thing in Microsoft BASIC where you didn't have to declare ...