Paul's Various Languages for the X16

[rje]

I went looking for his 6502 version of BCPL, and stumbled upon a gold mine of little languages he wrote for the 6502 and relatives.  And I want to know what you guys think about them... and which ones should be considered candidates for the X16 ROM?   (I'm not an official vote-taker; I'm just asking for opinions).

 

https://github.com/paulscottrobson/rpl-c   "RPL for the X16".  

reference: https://portcommodore.com/dokuwiki/lib/exe/fetch.php?media=larry:comp:flash_attack:fa-rplmaual.pdf

RPL claims to be "like Forth, but friendlier and more efficient" re:

• 
  not threaded
  


• 
  memory efficiency via p-code
  


• 
  easier to debug (again, p-code and no threads)
  


• 
  designed to leverage Commodore BASIC, screen editor, I/O etc.
  


• 
  compiled; no interpreter.
  

 

 

https://github.com/paulscottrobson/xcpl   "BCPL-like language for the 6502"

My favorite, but it appears to have no useful purpose:

Quote

XCPL is a 6502 based cross-compiled programming language. It runs code in a virtual machine called “Sour 16”. This is a virtual machine not dissimilar to Sweet 16, but it is largely unusable for general programming. 6502 code routines are supported.

 

https://github.com/paulscottrobson/lean   "The 3rd, and hopefully final, version of a terse like language for the 65C02"

Lean appears to be a bizarre utility for handling 16 bit integers in local compilation.  Or something.  Quote:

Quote

Lean is the third version of my structured shorthand macroassembler concept, and hopefully the final one.



...Lean is at heart a simple pattern matching code generator. Lines of code are compared against a dictionary of such, and each of those lines has a code generator attached to them. Some ‘code generators’ are code themselves, executed to do specific actions, most just copy the code out.



...The 6502 has a basic problem with code generation for compilers, especially if you want to build it into the machine – not have it cross developed on a more powerful machine (lean can do this, but it’s actually assembled on the machine). It is bad at 16 bit arithmetic. Adding 16 bit values takes a lot of code. 8 bit values are too limiting. Bytecode is one alternative, but this produces a slowdown of at least x 10.



...One can make an argument that this is just syntactic sugar on 6502 assembly ; it is slightly more than that, in that it provides 16 bit instructions.  But yes, that’s pretty much it.

 

And here's most of his BASIC interpreters:

https://github.com/paulscottrobson/Basic65.   "Open Source Integer 6502/65816 Basic interpreter"

https://github.com/paulscottrobson/basic-65    "A free open source BASIC for 65C02/65816 processors. Close to MS compatibility"

Apparently, both of these are intended for the MEGA65.

https://github.com/paulscottrobson/mega-basic    "Portable-ish 65C02/65C816/4510 BASIC"

https://github.com/paulscottrobson/mega65-basic

 

 

[paulscottrobson]

XCPL is effectively done, in that it's complete and it works. There's no easy mechanism to link assembler, that's the main problem, though it could be added to the Sour16 Runtime easily enough.

Some are complete, some aren't, some are experiments, some I decided not to do for other reasons. Some are private and some aren't, pretty arbitrary really. Even Sour16/RPL-C aren't really efficient enough for development on the CX16, even with the hacks ; the mad instruction set and the borrowing of 65C02 Forth's fast execute code you still get a big performance hit on the runtime. Really, the best thing is to have something easier to do the skeleton and the stuff that isn't done very often and write the rest in Assembler.

Eris which is a similar sort of machine with about the same effective MIPS  I wrote as a retrocomputer own design thing as many others have. I wrote an assortment of games in BASIC (it's about 50% quicker than the CX16 equivalent), old things like Frogger, Space Invaders, Atic Atac.  It did have much more specific commands than the CX16 does.

The only one which couldn't cope was Asteroids, simply because it's moving and collide testing too many things if you blow up lots of asteroids. It has a sort of quasi assembler which looks rather like FORTH , you had things like

check.collide.one = rpl(#p 6 + @ #q 6 + @ + 2 * 3 / 256 * ^radius 0 check.range 1 check.range and if #qn ^h then)

rpl() is a unary function like str$() which compiles the code inside it and returns the address of the routine. It is roughly equivalent to FORTHs.

:check.collide.one p : 6 + @ q ! 6 + @ + 2 * 3 / 256 * radius @ 0 check.range 1 check.range and if qn @ h ! then ;

#var and ^var are required because it used the standard variable store to store addresses (a full stop is part of an identifier, not a record or member) so it can't distinguish between whether an address stored in a variable represents a variable or a routine - #count is the same as the BASIC variable count. The main problem with doing it on the CX16, except for the obvious variable name readability issue, is that a 6502 just isn't very efficient at doing anything not 8 bit ; you can have compactness or speed but you can't have both.

https://github.com/paulscottrobson/eris/blob/master/code.basic/asteroids/asteroids.bas

https://github.com/paulscottrobson/eris/blob/master/code.basic/pacman/pacman.bas

It's remarkable what you can do in little space ; Asteroids is about 250 lines,  Pacman was about 300 with a *lot* of spaces, and comments but you have to have the right language and system.

 

[paulscottrobson]

Lean is a macroassembler without macros. It pattern matches things like A=300 against A=<constant> and generates appropriate code for that ; e.g. ldx #1 lda #44 (300 = $0144).

There's some code to hack structures and procedures, so you get this weird pseudoassembler, without any actual 6502 assembler. The idea came from here http://www.terse.com which is an x86 implementation of the same idea, though I have a memory of a very similar thing for the Z80 years ago. What makes it unreadable is only have 24 bits of storage inside the 6502. The 6502 has one purpose in life ; to be cheap.

It looks like this https://github.com/paulscottrobson/lean/blob/master/testing/balls.src it's not that readable, but it's *very* fast compared to anything other than raw assembler. The mario demo (test1.src) goes like stink ?. The balls demo has to be slowed down otherwise it's just a blur.

You pays your money. Really the answer is probably a compiler that compiles pseudo-code when it suits or 6502 assembler when it suits ; the 90/10 rule.  Your pcode interpreter doesn't care about speed efficiency and your 6502 code doesn't care about space efficiency.

I had a language which was syntactically closer to XCPL but had no assignment statement that I wrote for the Z80 (which can do 16 bit stuff straight off), but more readable than Lean.

 

[paulscottrobson]

Now this one works with the 90/10 rule. Switch between p-code and 6502 as you like. https://github.com/paulscottrobson/amoral

 

[desertfish]

interesting stuff, I'm going to try to rewrite those various demos into Prog8 to see how it compares

[paulscottrobson]

Very different really. It's a baby (5 days occasional work), single type, 16 bit. No optimisation. You almost optimise it yourself with the ~ operator, and by using the p-code for bits where speed doesn't matter.

There are a few bits I'd like to tidy up, but that's mainly * and divide powers of two becoming shift routines.

[desertfish]

I understand. I like mini languages they can explore interesting concepts. (and going completely bonkers if you want, see: Esotheric languages)

With 'compare' I actually meant how an equivalent program would have to be written in Prog8 and how it performs, to learn about possible bottlenecks in Prog8 I might be able to address later

[paulscottrobson]

Looks like two very different designs ; you've designed a language you want, I've designed one I can have ?

The bottlenecks are the ones every language, even FORTH, has. 6502 code is too long winded, P-Code is too slow. This gets round it by allowing you to do both, and simplifying the language to make the code generators pretty consistent and stable. Though actually all routines are 6502 m/c, so you could use it to write routines you called from BASIC.

[rje]

How slow IS P-Code?

 

[paulscottrobson]

Well, obviously it varies but I reckon it reduces the running speed by a factor of 10 or so. So optimistically if you run it on the X16 you're back at C64 assembler speed.