PLASMA virtual machine

[shifters74]

Just tried running the same PLAS128 on my BBC which has an integraB with 6 banks of SW ram and the same co-pro

PLAS128 just returns to the command prompt - no output, nothing.

PLASMA starts up and says $D793 free memory.

Disabling the co-pro:

PLAS128 now runs and says $4C28 free and $FFF6 free

PLASMA starts and says $4DEE free

cheers

shifters

[shifters74]

Hi SteveF,

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

I dont use make files to build my code but a shell script that calls plasmac.py.

Is it possible to perform the above preprocessing when using plasmac.py as looking at the code in plasmac.py I am not spotting anything obvious that would allow that

shifters

[SteveF]

Just tried running the same PLAS128 on my BBC which has an integraB with 6 banks of SW ram and the same co-pro

PLAS128 just returns to the command prompt - no output, nothing.

Thanks for this and the screen shots - I did believe you, but the photo is certainly nice!

The fact this hangs on the BBC is oddly reassuring. My current theory is that the PLAS128 code to disable the second processor is either buggy and/or doesn't work well with your copro/Econet. PLAS128 then starts up with some corrupt/incorrect idea of where HIMEM is, and on the Master it kinda-sorta works because it's trampling on part of the sideways RAM workspace at &C000-&DBFF and just happens to get away with it. On the BBC there's no RAM there so it doesn't get away with it.

Sadly I haven't done anything clever to allow copro and sideways RAM to be used simultaneously.

How do you feel about continuing to investigate this? You won't get extra usable RAM out of it, all we'd really be doing is figuring out exactly why this goes wrong exactly as it does. As I say, my inclination is that in the end even if we figure it out, PLAS128 would just be modified to refuse to run on a second processor (as BAS128 does, IIRC), but we might have learned something useful. Probably all we'd have learned is that I did something stupid in the code that's going to be removed anyway, but there's a slim chance we'd discover an obscure but genuine quirk related to the Pi copro and/or Econet.

If you're interested in doing further tests I will see if I can produce a cut down version of the PLAS128 code which does something like (with luck):

• disable copro
• call OSBYTE to read HIMEM
• prints it and gets a "wrong" value given we disabled the copro on some systems, but works on others

If we can get to that point I can post it in a more visible place and let the experts deliver their verdict. As I say, this would be mostly for interest, rather than practical benefits. If you'd rather leave this that's fine by me, because the "real" fix will just be dropping the automatic disabling of the copro anyway.

[shifters74]

HI SteveF,

sure i am happy to help investigating it further if you need me to do anything - just let me know!

cheers

Shifters

[SteveF]

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

I dont use make files to build my code but a shell script that calls plasmac.py.

Is it possible to perform the above preprocessing when using plasmac.py as looking at the code in plasmac.py I am not spotting anything obvious that would allow that

plasmac.py won't allow it directly (although I could potentially extend it to do this), but if you're already using a shell script, can't you just make the cc call in your shell script? So if for example it currently does:

Code: Select all

#!/bin/sh
python plasmac.py foo.pla

you can change that to:

Code: Select all

#!/bin/sh
cc -DFOO -DBAR -E -P < foo.pla > foo2.pla
python plasmac.py foo2.pla

[SteveF]

sure i am happy to help investigating it further if you need me to do anything - just let me know!

Thanks! As a starting point, can you please try to run the attached TEST program (i.e. do *TEST) from the attached SSD with your copro active? Please try both from your Econet and from another filing system if possible.

The code (in beebasm format) is also in the zip file for future reference. All this does is check to see if the tube is present, disable it if it is, then use OSBYTE $82 to read the high-order address and prints the high byte of the high-order address in hex. This should always be FF in the host, and since we have just disabled the copro we should always see FF, but I am "hoping" that when you run it you will sometimes see something else.

It deliberately hangs after printing the two hex digits, so you'll need to press BREAK to get control back.

Edit: Just as an extra sanity check (I doubt this is the problem), can you also please try "PRINT ?&27A" before running TEST and let me know what value you get? Ignore this, it's a silly thing to do when tube is active...

[jgharston]

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.

You can make calls and catch BRKs similar to doing SWI X_NAME with the code here.

[jgharston]

• disable copro

The code here shows how to disable the Tube Host and take over the I/O processor.

[jgharston]

The code (in beebasm format) is also in the zip file for future reference. All this does is check to see if the tube is present, disable it if it is, then use OSBYTE $82 to read the high-order address and prints the high byte of the high-order address in hex. This should always be FF in the host, and since we have just disabled the copro we should always see FF, but I am "hoping" that when you run it you will sometimes see something else.

If code running on the I/O processor calles OSBYTE &82 it will /always/ get &FFFF, as OSBYTE &82 gives you the high order address of the caller. Similarly, OSBYTE &84 always gives you the top of memory for the caller, so if code on the I/O processor calls OSBYTE &84 it will always return whatever the top of memory on the I/O processor is, because that's the processor the caller is running on.

[shifters74]

Just for any one else following this

Code: Select all

#!/bin/sh
cc -DFOO -DBAR -E -P - < foo.pla > foo2.pla
python plasmac.py foo2.pla

This works fine but NEEDS the - before the input files!

shifters

[shifters74]

sure i am happy to help investigating it further if you need me to do anything - just let me know!

Thanks! As a starting point, can you please try to run the attached TEST program (i.e. do *TEST) from the attached SSD with your copro active? Please try both from your Econet and from another filing system if possible.

The code (in beebasm format) is also in the zip file for future reference. All this does is check to see if the tube is present, disable it if it is, then use OSBYTE $82 to read the high-order address and prints the high byte of the high-order address in hex. This should always be FF in the host, and since we have just disabled the copro we should always see FF, but I am "hoping" that when you run it you will sometimes see something else.

It deliberately hangs after printing the two hex digits, so you'll need to press BREAK to get control back.

Edit: Just as an extra sanity check (I doubt this is the problem), can you also please try "PRINT ?&27A" before running TEST and let me know what value you get? Ignore this, it's a silly thing to do when tube is active...

Right:

BBC Master - Copro and econet active and loading from econet - $00
BBC Master - Copro and MMFS active and loading from ssd - $FF

Let me know if you want me to check on the BBC B also

Shifters

[shifters74]

HI SteveF,

See the attached which contains the NETLIB code i have written in plasma for talking over econet.

This is functionally working in PLASMA fine, but there possibly could be additions to it in the future as dev progresses.

Please let me know any comments on my PLASMA foo!

PLASMA does lend itself to compact and clear source code compared to basic!

cheers

Shifters

[SteveF]

BBC Master - Copro and econet active and loading from econet - $00
BBC Master - Copro and MMFS active and loading from ssd - $FF

Thanks shifters! That's good, as it shows something is going wrong, probably with my tube-disabling code. I will have to compare the code I'm using with the code Jonathan posted and see if it's different or if his code works better. I'll try to post a new test later on, and I'll take a look at your Econet code as well.

Let me know if you want me to check on the BBC B also

It wouldn't hurt but I don't think it's strictly necessary, so it's up to you. Maybe wait until I create a new version of the test code anyway?

[SteveF]

Please let me know any comments on my PLASMA foo!

I've had a look over this, it looks pretty nice code on the whole! I see you're taking advantage of multiple return values and structures, which I think definitely aids readability.

The main comments I have are about coding style and that's inevitably something very personal (and I think you're also following Dave's PLASMA style in a lot of cases, which is probably no bad thing), so please don't take any of this too seriously, but just FWIW:

• The header comments on econet_rx_check and econet_rx_read say "param 1: none" which seems a bit odd to me, as there is no param 1. I would be inclined to say "parameters: none" or just not say anything - if there are no parameters, there's nothing to document.
• Although it's optional in PLASMA, I prefer to use "()" when calling a function with no arguments. When I saw your line:

  Code: Select all

  num_bytes_received, station_id = econet_rx_read
  

  at first I thought it looked odd, because you were assigning a single value to two variables - then I realised the right hand side was actually a function call and it made sense.

Apart from that, looking at TIME.pla, if you haven't already seen them you might be interested in the isuge/isugt/isule/isult 16-bit unsigned comparison functions (the names are shorthand for things like is-unsigned-greater-or-equal) in cmdsys.plh, which might be useful. You could also use the 32-bit arithmetic support in int32.plh, which might make it more practical to write the PLASMA equivalent of the BASIC "T%=TIME+delay:REPEAT UNTIL TIME>=T%". But if what you have does what you need then obviously it's fine as it is!

[shifters74]

HI SteveF,

thanks for the feedback!

Yes i agree with all that - especially the () on functions, its just i saw it used that way (but i dont like it!) - too many years of writing c (some 35 at this point!).

cheers

Shifters

[SteveF]

Thanks shifters! That's good, as it shows something is going wrong, probably with my tube-disabling code. I will have to compare the code I'm using with the code Jonathan posted and see if it's different or if his code works better.

Right, I've tweaked the test program to use a fragment of code from the link Jonathan posted. I think this is pretty much equivalent to what I had before (not surprising as I found how to disable the tube somewhere on mdfs.net anyway), but maybe it will work.

Please run it from both Econet and non-Econet filing systems with the copro initially enabled and report the hex digits it produces. Since it (tries to) disable the copro and then queries the high order address, it *should* in theory always print "FF", but I predict that when you run it from Econet it won't. (I don't know *why* it behaves differently on Econet, but the fact the previous version did this makes me predict the same here.)

I'm sure you're getting it right, because for one thing I doubt it would work at all if you didn't, but if you could please do "*INFO TEST" when running from Econet to confirm the load/exec addresses are set correctly that would be reassuring.

The source code is in the zip file for future reference.

thanks for the feedback!

Yes i agree with all that - especially the () on functions, its just i saw it used that way (but i dont like it!) - too many years of writing c (some 35 at this point!).

You're welcome! I'm guessing all that C experience is making it fairly easy to pick up PLASMA? Albeit with the odd "argh, this would be so easy in C" moment.

[shifters74]

Thanks shifters! That's good, as it shows something is going wrong, probably with my tube-disabling code. I will have to compare the code I'm using with the code Jonathan posted and see if it's different or if his code works better.

Right, I've tweaked the test program to use a fragment of code from the link Jonathan posted. I think this is pretty much equivalent to what I had before (not surprising as I found how to disable the tube somewhere on mdfs.net anyway), but maybe it will work.

Please run it from both Econet and non-Econet filing systems with the copro initially enabled and report the hex digits it produces. Since it (tries to) disable the copro and then queries the high order address, it *should* in theory always print "FF", but I predict that when you run it from Econet it won't. (I don't know *why* it behaves differently on Econet, but the fact the previous version did this makes me predict the same here.)

I'm sure you're getting it right, because for one thing I doubt it would work at all if you didn't, but if you could please do "*INFO TEST" when running from Econet to confirm the load/exec addresses are set correctly that would be reassuring.

The source code is in the zip file for future reference.

thanks for the feedback!

Yes i agree with all that - especially the () on functions, its just i saw it used that way (but i dont like it!) - too many years of writing c (some 35 at this point!).

You're welcome! I'm guessing all that C experience is making it fairly easy to pick up PLASMA? Albeit with the odd "argh, this would be so easy in C" moment.

Hi SteveF,

Ran on a BBCMaster with econet (ANFS) and Pi3A Copro (HognoseR6) - $00
Ran on a BBCMaster with MMFS (1.45) and Pi3A Copro (as above) - $FF

*Info TEST of TEST on econet file server

I like the way you can return multiple values (like you can in tuples in elixir/elang) with PLASMA!

I find it odd that words are signed by default but i have used the functions you pointed out (thanks!) and just need to test it again. Its a shame more of the built in functions are not documented better as there seems to be a whole useful number of them but short of 'knowing' they are there you wouldn't without checking all the .plh files then the .pla files for implementation (and its not easy to always find where they are implemented, as the .plh file says one thing then the .pla file has nothing at all in it about those functions!). Even if the .plh files were commented for the functions it would help - but just my $0.02 for newbies (including me!) picking up the language.

I think coding in PLASMA (once your getting a bit familiar with it) is fast and more compact (but clear!) than BASIC and certainly assembler!

Now we just need a line stepping debugger!!

As far as switching off tube for PLASMA, if its less code in the run time, why not just put a message 'tube on' like EXMONII does and leave it to the user to sort it out?

cheers

Shifters

[shifters74]

Hi SteveF,

sorry to have to pick your brain but ....

I have made some minor changes to the ECOMUD.pla server to start incorporating the management of sessions - really just function calls to functions which return a default value, so not really doing anything. It compiles fine, but when trying to run it with *PLASMA or *PLAS128 (no-copro), i keep getting the error that the functions can not be found despite including them in the SESSION.plh and including the SESSION.plh in the ECOMUD.pla

Unable to find functions

Files in current folder - SESSION is there!

I have included the .pla, .plh and byte codes below. I have spent about 5 hours tearing my hair out over this, I am sure its trivial but i have tried all kinds of import the .plh, predef the functions in ECOMUD.pla etc etc and nothing seems to want them to load.

I am assuming the .plh files do not need to be on the server with the bytecode (as its not for TIME or NETLIB!)

Help me obi-wan Steve, your my only hope of sanity!

shifters

[SteveF]

Ran on a BBCMaster with econet (ANFS) and Pi3A Copro (HognoseR6) - $00
Ran on a BBCMaster with MMFS (1.45) and Pi3A Copro (as above) - $FF

That's brilliant, thanks! This doesn't make sense, but it at least doesn't make sense in a small, easy-to-understand program. I'll probably post this in another thread where it will be more visible and ask for advice on why it's going wrong. (Edit: Done, see here)

I find it odd that words are signed by default but i have used the functions you pointed out (thanks!) and just need to test it again. Its a shame more of the built in functions are not documented better as there seems to be a whole useful number of them but short of 'knowing' they are there you wouldn't without checking all the .plh files then the .pla files for implementation (and its not easy to always find where they are implemented, as the .plh file says one thing then the .pla file has nothing at all in it about those functions!). Even if the .plh files were commented for the functions it would help - but just my $0.02 for newbies (including me!) picking up the language.

I think the signed/unsigned behaviour is just something that comes with the BCPL-ish nature of the language where there are no types beyond byte/word. I guess Dave decided it's less confusing for the "default" behaviour to be signed, which does seem safer in the context of things like loops which count down and terminate "after" hitting 0.

More documentation would definitely be good. I might see if I can knock up a patch to the README.md file which outlines some of the standard library functions and send a pull request upstream.

I think coding in PLASMA (once your getting a bit familiar with it) is fast and more compact (but clear!) than BASIC and certainly assembler!

Having been tinkering a bit with (8-bit) BBC BASIC in the course of a few projects, and wearing my spoiled modern head and not my 1980s head, what I really miss in BBC BASIC is the ability to write if-else-endif and nest complex-ish if statements without worrying about it. I know there are workarounds (such as factoring things out into procedures) but it feels a bit painful.

Now we just need a line stepping debugger!!

That would be nice, but I suspect it would be pretty hard to implement. I'd love for someone to prove me wrong though!

As far as switching off tube for PLASMA, if its less code in the run time, why not just put a message 'tube on' like EXMONII does and leave it to the user to sort it out?

I think that's what I will do, although the code to turn the tube off doesn't really cost any runtime memory as it is executed once on startup and then gets overwritten by the PLASMA heap anyway, so it just takes up a bit of space on disc and fractionally increases the time taken to load the VM. I was trying to be helpful by not just refusing to run, but even if the weird glitch you've discovered can be fixed, I think it's just confusing to seem to run on the copro when it isn't.

I have made some minor changes to the ECOMUD.pla server to start incorporating the management of sessions - really just function calls to functions which return a default value, so not really doing anything. It compiles fine, but when trying to run it with *PLASMA or *PLAS128 (no-copro), i keep getting the error that the functions can not be found despite including them in the SESSION.plh and including the SESSION.plh in the ECOMUD.pla

I am assuming the .plh files do not need to be on the server with the bytecode (as its not for TIME or NETLIB!)

Help me obi-wan Steve, your my only hope of sanity!

You're right about the .plh files, all you need at runtime are the compiled bytecode modules.

You're running up against the limit of 16 characters in exported function names. I need to think about this a bit more, but I *think* the comment in README.md that only the first 16 characters are matched isn't quite right - taken as written, I believe what you've done would work, but in practice you need to ensure exported function names are <=16 characters. My gut feeling is that the compiler should generate an error if you try to import or export a function with more than 16 characters in its name, as it looks like even the Apple VM would potentially suffer from internal corruption if it comes across such a name.

If you try cutting the names of these functions down to <=16 characters I think it will work. (To be scrupulously honest, in experimenting with this I did seem to get into a position where a name of 14 characters *didn't* work and a name of 13 characters *did*. However, I couldn't reproduce that later and I'm putting it down to old versions of files lying around and so forth. I suggest you work on the assumption 16 characters is OK, and if that doesn't work please let me know and I'll investigate further.)

[shifters74]

Hi SteveF,

Yup that fixed it - make the function names less than 16 characters.

I had read about it but my understanding was it would truncate them down to 16 (but more was fine) - guess not!

The other gotcha i had today was putting the constants of SESSION.pla into SESSION.plh and including SESSION.plh into SESSION.pla. (bit like you do with .h and .c files) but it causes the bytecode to bomb out in all weird ways with 'no room', error $00 etc etc.

The only way to sort it was to put the constants in both .pla and .plh and NOT include the .plh in the SESSION.pla - only in the modules that call the functions.

cheers for the help!

shifters

PS Knew it would be trivial to you!! Still enjoying PLASMA though, just these little gotcha's as you learn the language!

[SteveF]

Yup that fixed it - make the function names less than 16 characters.

Phew! I'm glad it worked, please don't hesitate to ask if you encounter problems with names <=16 characters - I am still a bit nervous after that unreproducible problem I had with a 14 character name.

I had read about it but my understanding was it would truncate them down to 16 (but more was fine) - guess not!

I think your reading is correct and this is a small glitch in the documentation. Or the Acorn port is accidentally incompatible with the Apple VM in this respect, but I don't think it is. I've raised an issue upstream to see what Dave thinks about this: https://github.com/dschmenk/PLASMA/issues/66 My inclination is to tweak the compiler to refuse to compile imports/exports with such long names, but I'd rather avoid making the Acorn port gratuitously different.

The other gotcha i had today was putting the constants of SESSION.pla into SESSION.plh and including SESSION.plh into SESSION.pla. (bit like you do with .h and .c files) but it causes the bytecode to bomb out in all weird ways with 'no room', error $00 etc etc.

I've been bitten by this myself before. I've raised an issue upstream to get Dave's opinion on this: https://github.com/dschmenk/PLASMA/issues/65

cheers for the help!

Any time! It's really cool to have someone actually using the Acorn port for something serious! (Well, maybe not serious. But you know what I mean. )

[SteveF]

Hi shifters74,

Would you mind trying the test again with copro+MMFS and copro+ANFS with the attached test3? Jonathan spotted a bug in the test2 code.

Thanks.

Steve

[shifters74]

Hi SteveF,

Still the same - $00 with Master Copro and Econet, $FF with Master Copro and MMFS

I checked the file times to ensure i had the correct TEST exe's.

cheers

shifters

[SteveF]

Brilliant, thanks! That confirms my silly mistake isn't the cause of the strange behaviour. It might be a *different* mistake on my part though. I might have another version for you to try later on but I'll post this result over in the other thread for now.

Edit: You might be reading it anyway, but would you mind joining the other thread so we can keep all this information in one place? And could you confirm which version of ANFS you're using please, just in case it matters? sweh has reported this isn't happening for him so I'm now clutching at straws such as the precise version of ANFS making a difference.

[shifters74]

Hi Steve,

yes posted in other thread!

shifters

[BeebMaster]

Does it make any difference that the test code is shown on the Econet file server to load & run at 00FF2000 instead of FFFF2000?

[shifters74]

Guess it does!!!

Changing it to that and it works. Ignorance on my part

shifters

[SteveF]

If code running on the I/O processor calles OSBYTE &82 it will /always/ get &FFFF, as OSBYTE &82 gives you the high order address of the caller.

Thanks Jonathan, I *thought* I understood what you were saying here when I first read your post, but only in hindsight do I realise you had actually explained the problem perfectly - it "couldn't" be a bug in the tube disabling code, because if the code really was running in the I/O processor disabling the tube wouldn't even be necessary to get &FFFF returned from OSBYTE &82, and therefore (again, in hindsight for me!) we could infer the code was actually running in the second processor because of load/exec address problems.

Guess it does!!!

Changing it to that and it works. Ignorance on my part

Excellent, thanks for confirming that. It's an easy thing to get tripped up by, I feel a bit embarrassed I didn't catch this earlier, particularly when you had posted the *INFO result I asked for and I had this clue from Jonathan. Oh well.

I'm still going to get rid of this code from PLASMA shortly, as we've discussed before. And just for the record, once I do that, PLAS128 will have the high bits of the load/exec address as 0 instead of &FF, so you won't need to do anything special when copying from DFS/MMFS to Econet. Edit: I've now made PLAS128/P128JIT just refuse to run on a second processor on the "rom" branch. I haven't tagged the code but if you do a "git pull" on this branch you should pick it up.

I see you have some questions over in the other thread, I'll let BeebMaster reply to your latest but if you need any extra information I'm happy to help too.

[shifters74]

Hi Steve,

I will change PLASMA to 0000xxxx LOAD/EXEC address on my PiFS and PLAS128 to FFFFxxxx on my PiFS

This should mean that PLASMA can run on the tube but will run on the host if no tube

PLAS128 will only run on the host (even if tube active).

I will then retest PLAS128 to see if its giving me the correct amount of memory free!

Learn something every day (although every day seems a BBC noob day at the moment!)

cheers

Shifters

[SteveF]

Thanks shifters, that sounds good - but please note that's only correct for the version of PLAS128 you already have. If you build the latest version on my branch as discussed in my last post, you need &0000xxxx addresses for both PLASMA and PLAS128. That's because the new PLAS128 expects to load and run in the second processor, if one is active, and it then detects if it's running in the second processor and generates an error telling the user to turn it off. Whereas the old PLAS128 is intended to be loaded in the host even if there is a second processor, and it then detects and disables any second processor so it can run properly in the host.

(I'm not trying to discourage you from experimenting with the version of PLAS128 you already have to see that it all works as expected, I just want you to be aware the "correct" load/exec addresses are changing as a result of making PLAS128 complain about second processors rather than disable them automatically.)