PLASMA virtual machine

[shifters74]

HI SteveF,

above you said

The standard "fileio" module won't work in ROM

There are various reasons for this, and it's not quite production-ready even when used with the normal PLASMA VM anyway. If anyone is particularly interested in this let me know and I'll see what I can do, or at least explain why it isn't practical. Anyone writing a language ROM in PLASMA should probably just use the standard Acorn OS filing system calls for I/O, though; there is some support for this in the acornos module, and you can use the standard PLASMA call() function to call any OS routine.

I am thinking of using PLASMA for a project - creating a MUD running over econet (one server many clients kind of thing) and one of the things i do need to do is to of course read/write data to files with PLASMA. Above you mentioned there are issues with this - what are they?

I am just trying to get a feel if PLASMA would be appropriate for such a project.

thanks

Shifters

[SteveF]

This sounds quite exciting!

There are two main problems with the "fileio" module:

• Its functions are supposed to indicate errors (e.g. "file not found", "disc error") by their return value and/or setting the global variable "perr", because that's how the Apple implementation works and the Acorn one should be compatible. The Acorn OS/filing system will sometimes report errors by executing a BRK and transferring control into the PLASMA BRKV handler. In order to hide this behaviour, the Acorn fileio module should internally wrap OS calls using except() so it can retain control if a BRK occurs and turn the error into a suitable return code/perr update. Unfortunately except() is quite a heavyweight function and so far I've been reluctant to add the overhead of doing this. Since the code you're writing is probably going to be Acorn-specific anyway, you might be willing to accept this behaviour.
• The current Acorn implementation uses global variables, which are read-only when used to build a language ROM with PLASMA. If you're writing code which won't be built into a language ROM, this isn't a problem. It could be changed to work around this, but even if the previous bullet point were addressed, we'd still have a problem because "update the global perr variable to indicate what went wrong" is part of the API, and we can't change that, but in a ROM perr isn't writable.

More generally, it has not been extensively tested, but I believe it does work fairly well and I'm happy to try to fix any bugs if you find them.

The alternative is for you to just make the OS calls to do whatever filing you want directly, using the standard PLASMA call() function and the helper functions in the acornos module. If your code is Acorn-specific anyway you're not losing out on much by doing this, and it does give you full control over what's going on.

Ignoring portability, the only real advantage of the "fileio" module over direct OS filing system calls is that it adds its own layer of buffering on top of the OS/filing system, so you can efficiently read (say) 5 bytes at a time without incurring the overhead of an OSGBPB call for every 5 bytes. Of course, if you want/need to use the OS/filing system calls directly, you can implement your own buffering on top of them.

It's worth noting that the fileio API is oriented around sequential reads/writes. If you plan to do random access within files it's not really suitable for your purposes anyway and this all becomes moot. (Of course we could extend the fileio API to handle this, but that wouldn't be a standard PLASMA feature, so you're almost at the point where you might as well just go back to making OS calls directly again.)

Edit: Just for reference, were you thinking of using the ROM-building feature for this? Depending on what you're trying to achieve, you might want to consider using a "normal" PLASMA VM for the server, as you could then potentially benefit from the speed/extra memory benefits of the JIT/tube/sideways RAM versions. This might also side-step the "using fileio from ROM" issue, as I'd guess all your file access would be in the server code?

[shifters74]

Hi SteveF,

No i am not intending this to run from ROM - it will be with PLASMA or PLAS128 or second co-pro depending on how i progress.

As its econet specific, I am not concerned about apple support so will probably use the acorn API directly to access files. All file access is intended to be on the server and sent to the client but thats an intent - we shall see how we progress.

Thanks for the clarifications! At the moment I am at the 'can i do this' phase and doing little proof of concept programs in basic for the communications etc. If they go well (so far so good) then i will start converting them to plasma and see how i go.

cheers

Shifters

PS Of course the number of people interested in a MUD on econet can probably be counted on one hand (1 finger???)

[SteveF]

Thanks! I look forward to hearing how you get on.

I suppose with all the Econet developments lately it's not utterly inconceivable stardot members could connect to your MUD via Econet over the internet these days.

[shifters74]

Yes your probably right - didnt think of that!

shifters

[shifters74]

Hi SteveF,

I am now trying to convert my basic econet tests which work fine into PLASMA code

When i try putb(value) where value is a byte value between 0 and 12, it compiles ok (using plasmac.py) but when run on the PC i get the following error at the command line

Code: Select all

Unimplemented call code:$09

Using puth and puti works fine in its place but putb gives the above error.

I am probably just miss understanding something simple - anything strike you as strange?

This is on stardot9 branch.

thanks

shifters

[SteveF]

It looks like the C implementation of the VM (plvm) was missing support for the putb() library function. I've pushed a change to the "rom" branch which should fix this, so if you pull that and rebuild it you should be OK. You can check you have the right code by looking at src/vmsrc/plvm.c and seeing that it contains:

Code: Select all

        case 9: // LIBRARY STDLIB::PUTB
            i = UPOP;
            printf("%02X", i);
            break;

Please let me know how you get on and if this works for you I'll send a pull request to upstream to include this change.

[shifters74]

HI SteveF,

wow fast fix!

Downloaded the rom branch, rebuilt and tested on BBC and PC and that works fine!!

thanks

shifters

[SteveF]

Thanks, I'm glad it was an easy one!

[shifters74]

Hi Steve,

with a machine with more than 4 banks of 16K SW RAM e.g. a integraB can have up to 10x 16K banks, and using PLAS128, what banks are used for the 64K of byte code i.e. are they selected from bank 15 down or 0 up or random?

I would like to use the other SW RAM banks not used by PLASMA to hold data that could be swapped in and out of the main memory space as required by the program - probably using ASM in PLASMA rather than PLASMA itself. i.e. i would allocate a cache area (say 2K) in main memory and then copy data in to that area for updating then write it back to the SWRAM.

By using multiple caches in main memory, i could then hold the most recent data for access by PLASMA in main memory from a larger set in the SWRAM not directly accessible from PLASMA.

thanks

shifters

[SteveF]

Hi! These are good questions.

Your plan to use other sideways RAM banks as cache sounds neat.

Currently the PLASMA VM checks all banks from 0 upwards, and it takes the first four it finds which contain sideways RAM and don't have an entry in the OS ROM table at &2A1+bank number; the latter check is intended to prevent ROM images running from sideways RAM being clobbered. (This is imperfect; if you've disabled a ROM image in sideways RAM using some kind of ROM manager, PLASMA will feel free to clobber it.)

There is currently no "official" way (unless it's slipped my memory) for code running under the VM to check whether it's being run under "PLASMA" or "PLAS128", or to control/detect which/how many RAM banks PLAS128 will use instead of just auto-detecting. This could and perhaps should change, of course.

For the moment, it's probably helpful for you to know that *if* you assume you're running under PLAS128, &40A will contain the number of RAM banks PLASMA is using (max 4) and the RAM bank numbers will be at &40B-E. You can query these from within PLASMA using the ^ operator, but please don't change them or things are likely to go wrong! Please define some sort of constant for this address so if it moves later your code can be fixed up easily; as I said above, there should probably be an "official" stable API for getting this information, but there isn't yet.

I think that will let you do what you want - if you know/have auto-detected which banks contain RAM on your machine, you can remove the ones PLASMA is using by querying that data at &40x and then you can do what you like with the others. Or of course you might want to just assume PLASMA will use the lowest four banks and that the higher ones are free.

If you're using real hardware (as opposed to an emulator), please note that I wrote the sideways RAM detection code in PLASMA myself without being aware of hardware mysteries like bus capacitance and so forth which make it trickier than it seems at first to detect real sideways RAM. I need to change PLASMA to use the same code (Wouter Scholten's, not mine) I am using in Ozmoo to do this job properly. If it's working for you, that's great, but if you see strange behaviour please let me know.

[shifters74]

HI SteveF,

thanks for your usual detailed and clear explanation!

I am still in the design stage at the moment for the server and client basics and doing lots of thinking of how i would like things to work. This helps provide a base layer design upon which to build the game engine and the memory handling and deciding on the hardware to use is part of that.

I do all my testing on real BBC B (client) and Master (server) over real econet so if i run into any issues I will sqwark for help

I have my PLASMA build environment for the MUD running now with auto deploy to my econet file server for rapid prototyping!

Currently working to get to grips with PLASMA which is similar to C but with enough differences to make me go huh! some times.

One of the first things I am writing is an econet module library for the communications which i would like to share with you (or include in PLASMA as an acorn module if you wish) to ensure i am understanding the PLASMA idiom.

cheers

shifters

[SteveF]

Hi shifters, you're welcome! I'm glad you're making progress, if you want to post any code (here or on github) for "review" I'm happy to take a look. Once it stabilises I'd be happy to include your Econet library in my repo for other people to re-use, or of course you could host it on your own github page and I can include a link to it.

[shifters74]

Hi SteveF,

I use VSCode - do you know of any colour syntax plugin for it?

cheers

Shifters

[SteveF]

Sorry, no. Is there any chance you could create one by tinkering with an existing plugin for C or Pascal or something like that? I can't help thinking PLASMA looks (from a rough syntax highlighting point of view) a bit like Pascal with C(++)-style comments; the lack of braces in PLASMA is what makes me think a Pascal-style language might be a better starting point.

(I use vim/Doom Emacs myself, but I find the plugin aspect of both so convoluted I haven't even dared try to create my own. I just make do without syntax highlighting for PLASMA, although it would be nice to have it.)

[shifters74]

That sounds like a whole other project then!

I think i have more than enough going on with my project without this for now but thanks for the clarity - i thought it was unlikely even from the apple guys but worth the ask.

Shifters

[shifters74]

Hi SteveF,

I am trying to do the following

Code: Select all

        recv_val = call(osbyte, $33, cblock_rx.block_number, 0, 0)->xreg

Now in the docs it says you can do a call, and get the return values which are A, X, Y and S in a single 4 byte return value

I can't find the def call function in the source to see what it returns, but other examples in the documentation say you can ->xreg on the call return value but the compiler is saying (with a ^ pointing at ->xreg)

Code: Select all

<stdin>   84:         recv_val = call(osbyte, $33, cblock_rx.block_number, 0, 0)->xreg
                                                                                                                             ^
Error: Undeclared identifier

Any ideas?

Shifters

[shifters74]

HI SteveF,

sorry more questions!

Is it possible to do conditional compilation i.e. only have certain code in debug build etc?

When running PLAS128 on a Master with a 6502 co-pro, it returns

Code: Select all

MEM FREE: $DFC9, AUX FREE: $FFF6

Does this mean that on the co-pro there is $DFC9 free memory for user data and $FFF6 is free memory for byte code in the Master SW rams?

cheers

Shifters

[SteveF]

I can't find the def call function in the source to see what it returns, but other examples in the documentation say you can ->xreg on the call return value but the compiler is saying (with a ^ pointing at ->xreg)

Code: Select all

<stdin>   84:         recv_val = call(osbyte, $33, cblock_rx.block_number, 0, 0)->xreg
                                                                                                                             ^
Error: Undeclared identifier

My best guess is that you haven't included the:

Code: Select all

const xreg = 1

constant definition; looking at the example in README.md, xreg is defined there as part of the example code, it is not a standard constant in the same header that defines the call() function. For better or worse, it doesn't look like the constants to help interpret the call() result structure are part of any standard header. You can of course add them to a custom header for your own project if that will simplify things.

If this doesn't fix it for you please let me know and I can take another look.

Cheers.

Steve

PS I knocked up the following test program while investigating this, and it seems to work. It also shows that you can use either ".xreg" or "->xreg" - the generated bytecode is the same - which I don't pretend to fully understand. Although I seem to have been using "." in most of my code, I suggest you stick with "->" since that's presumably more "officially correct".

Code: Select all

include "inc/cmdsys.plh"
include "inc/acornc.plh"

const osbyte_identify_host = 0
const xreg = 1

def test()
    byte host
    puts("Test 1: ")
    host = call(osbyte, osbyte_identify_host, 1, 0, 0).xreg
    puti(host); putln()
    puts("Test 2: ")
    host = call(osbyte, osbyte_identify_host, 1, 0, 0)->xreg
    puti(host); putln()
end

test()
done

[SteveF]

HI SteveF,

sorry more questions!

Hi shifters, no problem! I'm glad you're persevering with this!

Is it possible to do conditional compilation i.e. only have certain code in debug build etc?

There's no "standard" support for this in PLASMA itself. What I've done in my code is abuse the C preprocessor, which in practice works fairly well but obviously could go wrong as it's not designed for PLASMA. You can see some examples of this in the makefile, such as:

Code: Select all

        cc -DJIT -E -P - < vmsrc/acorn/cmd.pla > vmsrc/acorn/32cmdjit.pla
        ./$(PLASM) -AOW < vmsrc/acorn/32cmdjit.pla > vmsrc/acorn/32cmdjit.a

The first line transforms cmd.pla into 32cmdjit.pla with "JIT" defined, and the second line then compiles the resulting PLASMA code.

It's probably best to stick to using the C preprocessor for #define/#if/etc; if you start trying to use #include the C preprocessor will probably start emitting #line directives which will trip up the PLASMA compiler.

If you are doing very small "within function" tweaks for conditional compilation, you *may* be able to rely on the optimiser to eliminate dead code of the form:

Code: Select all

const debug_output = FALSE

if debug_output
    puts("debug output here!\n")
fin

but I haven't tested this - if you want to use this approach, please double-check the bytecode output to see if the code is indeed being removed. It's probably better to just use the C preprocessor.

At the risk of stating the obvious you are also free to create your own ad-hoc preprocessor in whatever language you want, e.g. something clunky but customised to your personal requirements could probably be written in a few lines of Python. I would still personally recommend the C preprocessor unless there's some specific problem with doing that.

When running PLAS128 on a Master with a 6502 co-pro, it returns

Code: Select all

MEM FREE: $DFC9, AUX FREE: $FFF6

Does this mean that on the co-pro there is $DFC9 free memory for user data and $FFF6 is free memory for byte code in the Master SW rams?

You are interpreting the values correctly, but those specific values look wrong to me.

On PLAS128, "MEM FREE" is the main RAM free for assembly language code and user data (local variables, the heap), and "AUX FREE" is free memory for bytecode functions in sideways RAM, as you say.

However, PLAS128 isn't really second processor compatible. I increasingly think I need to change this, but in order to avoid just saying "sorry, turn off your second processor" when you run it, PLAS128 disables the second processor itself and carries on running on the host, which gives a misleading impression that it is taking advantage of the second processor.

It therefore doesn't seem right you are seeing such a high MEM FREE value. When I try this on b-em, a Master with a 6502 co-pro says:

Code: Select all

MEM FREE: $5428, AUX FREE:$FFF6

There can't be $DFC9 bytes of (ordinary) "MEM FREE" when the second processor is disabled as the "MEM FREE" is a subset of the 32K of main RAM. If you just made those numbers up for the question that's fine, but if you're really seeing this can you please let me have a copy of the .ssd containing the PLAS128 which is saying this so I can investigate! (It would be good if you could confirm the branch/commit you built it from too, please.)

Changing the subject slightly to offer some unsolicited advice , it's probably quite hard to write a program which will seriously benefit from ~64K of bytecode space. Your plans to use sideways RAM as cache are probably better, and it may be worth taking steps of some kind to stop PLAS128 grabbing the maximum 64K of RAM for itself. One thing you could possibly do to take advantage of all this bytecode space is to store data in the form of constant strings, e.g. (contrived, not tested):

Code: Select all

def roomhandler(description)#0:
    puts(description)
    // do lots of cool stuff here
end

def room1desc()#0:
    roomhandler("This is a very verbose description of room 1, which will be stored in sideways RAM as bytecode and temporarily copied into main RAM while this function is executing.")
end

def room2desc()#0:
    roomhandler("Another very verbose description blah blah.")
end

[shifters74]

Hi SteveF,

ah thanks - i had assumed the way it was used it was defined part of call return structure - oops my bad!

For clarity, is it something like the following returned from call then?

Code: Select all

const areg = 0   // i.e. ->areg return
const xreg = 1   // i.e. ->xreg return
const yreg = 2   // i.e. ->yreg return
const sreg = 3   // i.e. ->sreg return

As i think i read call returns a pointer to 4 byte return value of all the registers?

cheers

Shifters

[shifters74]

HI SteveF,

thanks for usual excellent clarity of explanation.

Code: Select all

There can't be $DFC9 bytes of (ordinary) "MEM FREE" when the second processor is disabled as the "MEM FREE" is a subset of the 32K of main RAM. If you just made those numbers up for the question that's fine, but if you're really seeing this can you please let me have a copy of the .ssd containing the PLAS128 which is saying this so I can investigate! (It would be good if you could confirm the branch/commit you built it from too, please.)

The PLAS128 is from your rom branch (at least thats the branch i have on my machine) and i then built a script to build and push the necessary parts to my econet server over scp via ethernet (that included PLAS128). See the attached as this is what i have in my build environment.

I will give the C preprocessor a try and see how i get on - a smart way to do it that i did not think of at all!

cheers

shifters

[SteveF]

That looks right to me. FWIW you can see the call() implementation in vmsrc/acorn/cmd.pla and the last bit of it serves as an extra confirmation:

Code: Select all

        PHP ; push flags onto stack
        STA     REGVALS+0 ; save A at offset 0
        STX     REGVALS+1 ; save X at offset 1
        STY     REGVALS+2 ; save Y at offset 2
        PLA ; get flags into A
        STA     REGVALS+3 ; save A (flags) at offset 3
        LDX     ESP ; restore X (PLASMA frame stack pointer) after whatever the called routine did
        ; return the address of REGVALS as this function's return value
        LDA     #<REGVALS                                                        
        LDY     #>REGVALS                                                        
        STA     ESTKL,X                                                          
        STY     ESTKH,X                                                          
        PLP                                                                      
        RTS                                                                      

REGVALS is just an alias for SRC, so the returned registers are temporarily held in four bytes of zero page owned by the VM. To state the obvious just because the thought crossed my mind, you therefore shouldn't expect them to stay intact for very long and you should copy the individual values into variables if you need them long-term, rather than saving a copy of the address returned directly by call().

[SteveF]

HI SteveF,

thanks for usual excellent clarity of explanation.

You're welcome!

Code: Select all

There can't be $DFC9 bytes of (ordinary) "MEM FREE" when the second processor is disabled as the "MEM FREE" is a subset of the 32K of main RAM. If you just made those numbers up for the question that's fine, but if you're really seeing this can you please let me have a copy of the .ssd containing the PLAS128 which is saying this so I can investigate! (It would be good if you could confirm the branch/commit you built it from too, please.)

The PLAS128 is from your rom branch (at least thats the branch i have on my machine) and i then built a script to build and push the necessary parts to my econet server over scp via ethernet (that included PLAS128). See the attached as this is what i have in my build environment.

This is a bit worrying! Could you please let me have the top line of output from "git log", where it says "commit..."? Did you forget to attach something, by the way?

Does this PLAS128 actually work?! I would have expected it crash almost immediately!

[shifters74]

Yes that makes sense, hence why i was doing call(osword, x, y, 0)->xreg i.e. doing it immediately after the call was evaluated.

As its in assembler, that would explain why i could not find a define for it - still seems slightly weird that call does not have a structure defined for its return value so you can immediately do ->xreg or ->areg etc as its a neat and very clear way of doing it (and i am adding it to my code!!)

cheers

Shifters

[shifters74]

HI SteveF,

thanks for usual excellent clarity of explanation.

You're welcome!

Code: Select all

There can't be $DFC9 bytes of (ordinary) "MEM FREE" when the second processor is disabled as the "MEM FREE" is a subset of the 32K of main RAM. If you just made those numbers up for the question that's fine, but if you're really seeing this can you please let me have a copy of the .ssd containing the PLAS128 which is saying this so I can investigate! (It would be good if you could confirm the branch/commit you built it from too, please.)

The PLAS128 is from your rom branch (at least thats the branch i have on my machine) and i then built a script to build and push the necessary parts to my econet server over scp via ethernet (that included PLAS128). See the attached as this is what i have in my build environment.

This is a bit worrying! Could you please let me have the top line of output from "git log", where it says "commit..."? Did you forget to attach something, by the way?

Does this PLAS128 actually work?! I would have expected it crash almost immediately!

twri@twri-ROGB450F:~/Downloads/6.BBC/8.Languages/PLASMA-rom$ git log
commit aaf07f45a32b07102b6b370b6636e2c592386474 (HEAD -> rom, origin/rom)
Author: Steven Flintham <sgf@lemma.co.uk>
Date: Fri Jun 17 13:32:12 2022 +0100

Add putb() support to plvm

Thanks to shifters74 for reporting this!

commit 43a2bcf47906e0914b0f3a28067f7010f2eb88fc
Author: Steven Flintham <sgf@lemma.co.uk>
Date: Fri May 20 22:34:07 2022 +0100

Tweak comment

commit e27f6e80bf367ff6c77b6a9b755297fbeddde14c
Author: Steven Flintham <sgf@lemma.co.uk>
Date: Fri May 20 21:45:27 2022 +0100

Fix typo in comment

commit ee529cd60c30bf200ac2df6af6adab4f7304e4d2 (tag: stardot9)
Author: Steven Flintham <sgf@lemma.co.uk>
Date: Fri May 20 21:21:22 2022 +0100


PLAS128 works fine from what i can see - its running my current MUD Server in plasma which is dumping its econet received messages to the screen

shifters

PS I have attached what it on the econet server (not just what was built on my PC)

[SteveF]

See the attached as this is what i have in my build environment.

Thanks for those! When I run these on b-em with a Master 128 with either an internal or external co-pro, I get a MEM FREE of $5428. I wonder if this is some bizarre interaction with Econet?

Any advice would be appreciated here! If anyone else can reproduce PLAS128 showing MEM FREE of more than $6000 please let me know, as it might help to narrow down the problem.

twri@twri-ROGB450F:~/Downloads/6.BBC/8.Languages/PLASMA-rom$ git log
commit aaf07f45a32b07102b6b370b6636e2c592386474 (HEAD -> rom, origin/rom)

Thanks, that looks good to me, and the PLAS128 binary you posted is identical to the one I'm building for myself. So at least this isn't some sort of strange build error. (Edit: and the second copy of it you posted appears to be identical to the first, which is good.)

PLAS128 works fine from what i can see - its running my current MUD Server in plasma which is dumping its econet received messages to the screen

Well I guess that's the main thing! I really would have thought it would be falling over if it thinks it has all that extra memory free when it doesn't.

[shifters74]

I did think the amount of memory free was weird hence why i asked, as i didnt think it was possible to have so much main memory free unless running on the co-pro and yet is seemed to be saying the 64K srwam was available too!

I will keep an eye on PLAS128 and see how it goes as the program and its memory requirements get bigger just incase it working is a fluke.

shifters

[SteveF]

I did think the amount of memory free was weird hence why i asked, as i didnt think it was possible to have to much main memory free unless running on the co-pro and yet is seemed to be saying the 64K srwam was available too!

And you were right! It's so strange. I am hoping someone else will come along with an explanation. Currently my inclination is that the code I'm using to disable the second processor in PLAS128 is buggy in a way that doesn't manifest itself on my particular b-em setup (with no Econet, among other things) but does on your machine. But even so, I'd expect it to crash!

I am tempted to make PLAS128 simply refuse to run if a second processor is active (as I said before, I'm increasingly convinced this is more confusing than helpful, even if the code to do it isn't buggy), but I won't tinker with it just yet as it would be good to get to the bottom of this strange behaviour first.

I will keep an eye on PLAS128 and see how it goes as the program and its memory requirements get bigger just incase it working is a fluke.

Thanks, please do. If you experience problems please post, but please also try explicitly disabling the second processor and see if that helps.

[shifters74]

Hi SteveF,

the attached are what comes up on screen when running on my Master (which has econet and Pi3A co-pro)

Co-pro enabled with PLAS128

PLAS128 with co-pro enabled

Co-pro disabled with PLAS128

PLAS128 with co-pro disabled

Just to show i am not completely mad!!

Not that i am complaining about the extra memory - i was hoping you was doing something wizzard!!

cheers

shifters