PLASMA virtual machine

Development tools discussion area.
SteveF
Posts: 510
Joined: Fri Aug 28, 2015 8:34 pm
Contact:

Re: PLASMA virtual machine

Post by SteveF » Fri Mar 02, 2018 11:48 pm

Hi all,

Before I start looking into merging the latest upstream and attempting to fit this port nicely into the new framework, I thought I'd post what I have at the moment. It's a little bit less polished than I'd like, but I think it's in reasonable shape all the same.

I've updated to a fairly recent version of the upstream code (1.00, yay!) so there are a number of upstream changes/improvements. The big one is the introduction of a self-hosted PLASMA compiler. I've ported this (really just the addition of basic filename munging to turn "HELLO.PLA" into "P.HELLO") and so you can now write PLASMA programs on the BBC without soiling your hands on one of these new-fangled modern PCs. Here's a screenshot showing how to use it:
Screenshot from 2018-03-02 22-42-20.png
It's not as fast as I'd like; I think the main problem is that the file I/O code is a quick and dirty version I threw together to get things working. I know what I want to do to improve this, I just haven't got round to doing it yet.

Currently the self-hosted compiler only works on a second processor due to the memory requirements (the extra CPU speed doesn't hurt either!). It may be possible to make this run using sideways RAM under PLAS128, but it doesn't work at the moment - the "PLASM" compiler module is 24K and PLAS128 can't load modules over 16K.

Dave has created a series of videos introducing PLASMA and put them up on Youtube: https://www.youtube.com/playlist?list=P ... f4SP2Gw3yU Obviously these cover the Apple version, but I think most of the content would apply equally well to this port. (Anything involving graphics won't work. The '+ed' editor used in those videos hasn't been ported, but you can use any of the usual Acorn text editors such as EDIT on the Master or the View or Wordwise word processors instead.)

Other upstream changes include:
  • New standard libraries for text I/O (conio) and file I/O (fileio). I have created Acorn implementations of these, although as noted above the fileio code is pretty hacky.
  • Increased use of #n on function declarations/definitions to indicate the number of return values from a function. This will improve the generated code in some cases and also helps the compiler to catch errors. I've added this in to most of the Acorn port stuff too.
  • Loaded modules no longer have their name prefixed with '#' in the symbol table.
  • Assembler (instead of PLASMA) code is used to perform symbol fixups when loading a module; these changes have been included in the Acorn port. This make a big difference to the startup time when loading large programs like the self-hosted compiler.
  • VM has been optimised; some (but not all, yet) of these have been included in the Acorn port.
  • New divmod() function to avoid repeating work when calculating a/b and a%b separately.
  • New strcat() and strpcy() functions, similar to the C library functions of the same name.
  • New sext() function to sign-extend a byte to a word.
Acorn port specific changes include:
  • PLASMA programs can now receive command line arguments (the upstream Apple code has supported this for a while); you can see an example of this in the invocation of the self-hosted compiler above.
  • setjmp() and longjmp() have been renamed except() and throw() respectively; upstream now has an implementation of these functions under these names, so I've renamed mine to be consistent. (The implementation is not quite the same, mainly due to the need to allow for the frame stack moving around on mode changes on the Acorn port.) There's an Acorn-only function except2() which will dynamically allocate a buffer of exactly the right size instead of requiring a worst-case sized buffer; dump.pla has an example use of this.
  • There's a partial port of David Given's "bounce" program from his Cowgol distribution.
  • Some files have been tidied up, some have become a lot messier and some have experienced both. :-)
  • ROGUE is temporarily not working; I just haven't got round to porting the changes yet.
  • The plasmac.py wrapper I created to simplify invoking the cross-compiler (give it a source file and it spits out an emulator-ready SSD) and which I described in an earlier post is probably broken; I haven't tested it but I suspect it is. I intend to fix this up later.
  • There's the option to install a user-defined module which gets a chance to rewrite the filename from which a module will be loaded. Type '+MODNAME' at the prompt to load the (mostly pointless) example module, then run something else (e.g. '+HELLO') to see the effect. This is experimental, but I thought it might be useful as a way to provide support for the equivalent of Windows/Unix PATH/LD_LIBRARY_PATH, particularly if you were running PLASMA on a hierarchical filing system.
  • Loaded modules now get their address in memory associated with them in the symbol table instead of the arbitrary value 1; this always happened on the Apple version, but it wasn't really used and it was slightly inconvenient to support with some of my other changes, so I didn't. As this is now used to provide access to a table of function pointers by some standard modules (such as conio and fileio), I had to start supporting this after all.
  • Some experimental optimisations have been added to the cross-compiler. (It's a while since I added them, but they weren't as useful as I'd initially hoped and I may remove them later.)
  • The VM used to contain an initial symbol table (for the built-in functions) which was copied into the real symbol table on startup; the symbol table in the binary is now used in-place, saving a bit of memory.
The source is in my github repository here: https://github.com/ZornsLemma/PLASMA/re ... g/stardot7

I've attached a zipped SSD built from that repository; you can use that if you want to play around with the self-hosted compiler yourself, though you'll probably need to delete some of the other files on there to free up space in the catalogue. Good files to delete would be: HANOI, SIEVE, SORT, SORT1, SORT2, STRPOOL
Attachments
plasma7.zip
(29.66 KiB) Downloaded 13 times

User avatar
BigEd
Posts: 1983
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: PLASMA virtual machine

Post by BigEd » Sat Mar 03, 2018 5:13 am

A great leap forward!

Post Reply