PLASMA virtual machine

[shifters74]

HI Steve,

From your experience, can you create an array of structures such as

Code: Select all

const MAX_NUMBER_SESSIONS = 10

struc t_session
  byte stationid
  byte state
  word avatarid
end

//
// Global Variables
//

res[t_session] sessions[MAX_NUMBER_SESSIONS + 1]

How would you then access each structure e.g. sessions[1].stationid = 1 to set stationid in structure 1 etc, and recall it as puti(sessions[1].stationid)

I have tried the above but I am getting corrupt data when i read all the structures back.

Attach is an example .pla which tries to look for empty records (as indicated by the stationid == 0)

It prints out the while structure array, one structure per row with 3 values before storing anything and 3 values after data is stored.

Note that when setting up the first structure the second row has 01 00 0 in it when it should be 00 00 0 (as thats structure 2 and isnt used)

Sorry another day of being a noob

cheers

shifters

[shifters74]

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.)

Thanks will change it!

Shifters

[SteveF]

Code: Select all

res[t_session] sessions[MAX_NUMBER_SESSIONS + 1]

How would you then access each structure e.g. sessions[1].stationid = 1 to set stationid in structure 1 etc, and recall it as puti(sessions[1].stationid)

I have tried the above but I am getting corrupt data when i read all the structures back.

Hi shifters,

Good question! I have had a play with this and I think that although the definition works like this to allocate space, the compiler does *not* "remember" that the elements of sessions are t_session bytes long; it is just a simple byte array as far as any subsequent code is concerned. So you need to use "n * t_session" as the array index, not just "n". I could be wrong here, but that's how it looks to me like it works. This is a bit of a shame, and coming from a C background it's definitely a gotcha, but my best guess is this is done to keep the compiler simple.

For what it's worth, I investigated this by looking at the bytecode generated by the compiler (using -O, as it was easier to interpret after optimisation). The initial loop assigning the 0 values does:

Code: Select all

; <stdin>: 0020: // clear each of the structures
; <stdin>: 0021: for index = 0 to MAX_NUMBER_SESSIONS
_SUBSEG                                 ; BYTECODE STARTS
_INIT
        !BYTE   $14                     ; CN    10
        !BYTE   $00                     ; CN    0
_B002
        !BYTE   $7C                     ; DAB   _D029+0
_F000   !WORD   _D029+0         
; <stdin>: 0022:     // set the session structure details
; <stdin>: 0023:     sessions[index].stationid    = 0
; <stdin>: 0024:     sessions[index].state        = 0
; <stdin>: 0025:     sessions[index].avatarid     = 0
; <stdin>: 0026: next
        !BYTE   $00                     ; CN    0
        !BYTE   $26                     ; LA    _D028+0
_F001   !WORD   _D028+0         
        !BYTE   $B4                     ; ADDAB _D029+0
_F002   !WORD   _D029+0         
        !BYTE   $70                     ; SB

_D028 is the 44 byte "sessions" array and _D029 is the loop index. "LA _D028+0" puts the address of _D028 on the stack and "ADDAB _D029+0" adds the byte value at _D029 to the value on the stack. "SB" then stores the 0 pushed earlier by "CN 0" as a byte at the address on top of stack. So we're using the raw value at _D029 as the offset from _D028 without multiplying it by t_session.

I'm 99% sure this analysis is correct and shows *why* your code isn't doing what we'd expect it to, but this doesn't say anything about whether by tweaking the source code slightly the compiler would start doing the multiplication by the element size automatically. Looking quickly at the compiler source code, in toolsrc/parse.c, parse_struc() seems to be the code which parses these definitions - note that "res" is just a synonym for "byte", so we will have a BYTE_TOKEN when parsing this. The code recognises the open brackets and sets basesize and size and subsequently multiplies size by basesize, but it doesn't appear to store size/basesize anywhere for future reference when indexing. Oops, that's wrong - it's almost certainly in the BYTE_TOKEN case in parse_vars() where we get the base size in cfnvals and pass it to parse_var() instead, although I still don't think I can see the element size being stored for future reference. So I *think* this means there's currently no way to get the implicit multiplication by the element size, but I am not certain.

Incidentally I think you have accidentally used a "." instead of a ":" in the line:

Code: Select all

    sessions[index].avatarid     = 0                                 

(You've used a colon elsewhere, so this looks like just a slip. I only mention it as I happened to notice it and it may save hair pulling on your side later.)

Assuming I'm right and there's no way to have the compiler handle the indexing for you, there are three rough approaches you can take:

• Instead of writing "sessions[index]", write "sessions[index * t_session]" - STEST.pla in attached zip shows this
• Have a new word variable "session" which you initialise to "@sessions" (for 0-based loops) or "@sessions + t_session" (for 1-based loops) and add t_session to it each time round the loop, then use session as a base pointer to access the current element - the first two loops in STEST2.pla show this
• Have a new word variable "session" and do "session = @sessions + index * t_session" at the start of each loop body, then use session as a base pointer to access the current element - the last loop in STEST2.pla shows this

I've given the attached variants a quick test but it's not impossible I've done something wrong, so please take this with a pinch of salt. If you try something and it doesn't work let me know and I'll take a look!

Sorry another day of being a noob

No problem. And far from being a noob, you're probably in the top 100 PLASMA programmers on the planet!

[shifters74]

Thanks Steve.

I have been thinking about this and was coming to the same conclusion - i had modified the source for that and thought it looked a little messy so thought i would ask the guru (thats you!!) before making things more complicated. I do like your third option though!

Basically its just large byte array then.

Interestingly i assumed it was a multidimensional array and according to the docs that would make it an array of array's and they can be non-contiguous in memory. So when i did memset on the @sessions, 0, t_session * number of em thinking i was setting it all to 0, it was wrong (another gotcha!).

thanks

shifters

[SteveF]

I'm glad that made sense! Perhaps going off at a bit of a tangent...

Interestingly i assumed it was a multidimensional array and according to the docs that would make it an array of array's and they can be non-contiguous in memory. So when i did memset on the @sessions, 0, t_session * number of em thinking i was setting it all to 0, it was wrong (another gotcha!).

I'm far from super confident about this myself, but I think the key thing in the documentation about multi-dimensional arrays is the line:

Every array dimension except the last is a pointer to another array of pointers, thus the type is word.

I think this is talking about *how the programmer sets the array up*, not a C-style kind of pointer decay.

Looking at the example in the documentation:

Code: Select all

//
// Hi-Res scanline addresses
//
word hgrscan = $2000,$2400,$2800,$2C00,$3000,$3400,$3800,$3C00
word         = $2080,$2480,$2880,$2C80,$3080,$3480,$3880,$3C80

hgrscan is an array of pointers with explicit initialisation, and you can then write (e.g.) hgrscan[2][4] to refer to address $2804. But without setting up these "intermediate" addresses yourself, you can't define a multidimensional array as "word foo[3][5]" and expect to be able to access "foo[1][3]".

[SteveF]

I'm glad that made sense! Perhaps going off at a bit of a tangent...

Interestingly i assumed it was a multidimensional array and according to the docs that would make it an array of array's and they can be non-contiguous in memory. So when i did memset on the @sessions, 0, t_session * number of em thinking i was setting it all to 0, it was wrong (another gotcha!).

I actually kind of missed this before - FWIW: I think you *should* be able to use memset to zero out the array, as it is just a contiguous stretch of 44 bytes. If you try this (although perhaps you'd prefer to use an explicit loop anyway, of course) and it doesn't work, please let me have a copy of the code and I'll take a look.

[shifters74]

Hi Steve,

yes memset works fine on a whole byte array fine.

I have modified my code to work correctly now - thanks for the examples!

cheers

shifters

[shifters74]

Hi Steve,

After a brief break and me hols i am back coding in PLASMA on my mud.

Instead of working with sideways ram for cache storage as i previously suggested, I am using JIM RAM on a underkeyboard Pi1MHz. I have written a quick PLASMA module to control the paging of JIM and its all fairly fast.

For some reason i can't seem to include the source though (attachments not working in firefox?)!??

cheers

Shifters

[SteveF]

Hi Shifters,

I'm glad you're carrying on with the project! This sounds pretty nifty, I'm glad it's working out for you; I see you've been discussing JIM RAM in another thread too. It would be interesting to see the code at some point when you can get attachments to work.

Cheers.

Steve

[shifters74]

Trying with a different browser!

Its not complete - more a proof on concept as this stage.

Shifters

[SteveF]

Looks like a pretty nice interface so far anyway! I appreciate this is just a proof of concept, but is there any reason you can't replace:

Code: Select all

    // 16M JIM check                                                             
    if (jim_size == 1 and page_id_ff >= $1)                                      
        page_error = 1                                                           
    fin                                                                          
    // 480M JIM check                                                            
    if (jim_size == 30 and page_id_ff >= $1E)                                    
        page_error = 1                                                           
    fin                                                                          
    // 992M JIM check                                                            
    if (jim_size == 62 and page_id_ff >= $3E)                                    
        page_error = 1                                                           
    fin                                                                          

with

Code: Select all

    if (page_id_ff >= jim_size)
        page_error = 1

and handle an arbitrary jim_size into the bargain?

[shifters74]

No reason!

They were added as i worked out the page size for Pi Zero (30) and Pi3 (62) - those sizes are fed in from constants in the main program when it knows what the Pi being used is!

The JIM functions are so key to handling memory that they will be stripped to the bear minimum as i work out how to split the work load in to 256 byte pages and it may only be the DIAG build that has any checking in it.

Shifters

[shifters74]

Found another 'gotcha'!

Obvious in hindsight but if you 'forget' to add the number of returns values to the end of the function definition in the .plh file you trash your stack!

(took me 3 hours to figure that one out!)

Shifters

[SteveF]

I'm glad you figured it out, although I'm sure it wasn't a fun three hours!

I think if/when issue https://github.com/dschmenk/PLASMA/issues/65 is resolved, it might be possible for the compiler to detect this mismatch - at the moment it will never see both the declaration and definition at the same time so it doesn't get a chance to complain.

I have knocked up a super-hacky "lint" utility which compares function signatures (expressed in form "a#b", where a is the number of input parameters and b is the number of return values) across .plh and .pla files and complains if it sees something it doesn't like. The parsing is entirely ad-hoc and this has scarcely been tested, but feel to give it a try and let me know how you get on if you're interested. You need to call it with "all" the files for your project, both .pla and .plh, as arguments.

There's an example in the attached zip file:

Code: Select all

$ cat x1.plh
import x1
    predef foo
    predef bar(baz)#4
    predef quux()#1
    predef wibble(wobble)
    predef fooble()#0
end
$ cat x1.pla
asm foo#0
    rts
end

def bar(baz)
    return 3
end

def quux(arg)
    return 0
end

def wibble()
    return 4
end

def fooble()
    return 3
end
$ python lint.py x1.plh x1.pla
Function x1.wibble has inconsistent signatures:
    Signature 1#1:
        x1.plh
    Signature 0#1:
        x1.pla
Function x1.fooble has inconsistent signatures:
    Signature 0#0:
        x1.plh
    Signature 0#1:
        x1.pla
Function x1.foo has inconsistent signatures:
    Signature 0#0:
        x1.pla
    Signature 0#1:
        x1.plh
Function x1.bar has inconsistent signatures:
    Signature 1#1:
        x1.pla
    Signature 1#4:
        x1.plh
Function x1.quux has inconsistent signatures:
    Signature 1#1:
        x1.pla
    Signature 0#1:
        x1.plh

[shifters74]

Ooh nice!

Will give that ago and probably integrate it in to my build script - its an easy mistake me to make while prototyping!

I shall give it a whirl!

thanks

Shifters

[shifters74]

HI Steve,

lol you just 'knocked it up' - a nice piece of code and not really trivial!!

Rebuilt my compile scripts with it in and works a treat!

I introduced deliberate errors and it picked them up nicely!

The only change i had to make was to remove converting the file names to lower case (as all mine are uppercase).

Many thanks

shifters

[SteveF]

Thanks Shifters, I'm glad it's working for you!

My thinking was a bit confused when I wrote the script, I thought I had to force the filenames to lower case for consistency, but all that really matters is that module names use a consistent case so definitions can be matched between .plh and .pla files. I've attached a tweaked lint.py which may be better at preserving case in filenames, although if your hack of the previous one works well for you there's no need to try this.

Cheers.

Steve

[shifters74]

HI Steve,

are there any PLASMA examples i can crib using fileio to read a file?

I have my messages in a binary file now to load into JIM and i was going to see if i could read 256 bytes at a time directly from file into JIM memory and then switch pages.

If not then i will fall back to using the acorn OS file calls but thought i would try fileio as its built in!

thanks

shifters

[SteveF]

There is an example of using the Acorn fileio in samplesrc/acorn/bench2.pla - have a look at loadfileio() and storefileio(). By all means give it a go, just be aware that the Acorn fileio implementation is a little bit half-baked. It will probably work fine in practice though and feel free to ask if you get stuck.

The same file has storegbpb() which do the same sort of job with OSGBPB (there's no loadgbpb() for whatever reason), although TBH you're probably better off writing the code from scratch as I probably got the subtleties of the OSGBPB interface wrong in storegbpb()...

[shifters74]

HI Steve,

Yup got that all working with help from the example

thanks!

shifters

[shifters74]

Hi Steve,

I have tried the following simple code

Code: Select all

// Import standard library functions
include "inc/cmdsys.plh"
include "inc/conio.plh"

// clear the screen
home()
//putc(12)

puts("Hello clear screen!")

done

and it crashes when running from *PLASMA and *PLAS128

however

Code: Select all

// Import standard library functions
include "inc/cmdsys.plh"
include "inc/conio.plh"

// clear the screen
// home()
putc(12)

puts("Hello clear screen!")

done

works!

As home is such a simple function what is going wrong there?

thanks

shifters

PS This is with the ROM branch of PLASMA

PPS conio:home() does work but don't understand why home() does not when its directly included!

[shifters74]

Hi Steve,

the same is happening when calling keypressed() i.e. the function call just hangs!

I had started to write the client side of the mud (so i can test the server) but i can't seem to check if a key is pressed or not i.e. is there a key in the buffer

thanks

Shifters

[SteveF]

Hi Shifters! Glad to hear work on your MUD is progressing!

Sorry for the delay getting back to you, I've been fiddling with my PC and it's been out of action.

This had me scratching my head for a bit! (Edit: if only I'd paid more attention to your PPS! ) I think the problem is that you need to write "conio:home()" instead of just "home()", and similarly for keypressed. This version of your first test works for me in the PLASMA VM:

Code: Select all

// Import standard library functions
include "inc/cmdsys.plh"
include "inc/conio.plh"

// clear the screen
puth(home)
//home()
conio:home()
//putc(12)

puts("Hello clear screen!")

done

The puth() call is how I figured out what was going on - it prints "0006", which obviously isn't a valid address to transfer control to, but is instead the offset of the pointer to the home() function in the conio function table. I'm obviously a bit rusty, but what I think happens here is that:

• An imported module ("conio" here) has an associated symbol at runtime, which is the address of the module's global data area. In other words, if you do "puth(conio)" you should see the address of conio's global data area.
• All the different versions of conio start with a table of words (see the "// Exported function table" comment in libsrc/apple/conio.pla, for example) which are initialised with pointers to the actual functions.
• Writing "conio:home()" effectively says "call the function pointer at element 'home' of the conio table of words". Edit: This looks a bit like a C++ namespace, but it doesn't really work the same - in C++ if you just wrote "home()" you would probably get an error about "home" not being found.
• Writing "home()" effectively says "call address &0006", which isn't an address with valid code, hence the crash. This is a bit of a gotcha but it's just how it is, I'm afraid - conio is a standard library and it works this way on all platforms.
• Edit: "home" has the value 6 because the struc definition in conio.plh assigns it that value - it is element 3 in 0-based numbering and each element is a two byte word, so it's 2*3=6.
• Edit: As you probably know, but just following on from the previous point: because PLASMA doesn't have types in the same way C does, the "members" of a struct are just global constants showing the offset of the member within the struct, because there's no associated type for them to belong to. In C "struct foo { int home; } struct bar { int foo; int home; }" would be fine, because any use of "home" is in the context of a specific type, but in PLASMA this will (probably) go wrong if these are both visible at the same time, because the former struct wants home=0 and the second wants home=2.

Off the top of my head I am not certain why the functions are not just directly exported as normal by each different version of the conio module. My best guess would be that doing it this way:

• Might improve load times by reducing the number of symbols the run-time linking has to resolve (we just have "conio" not home(), keypressed(), etc)
• Might allow the init code in the conio module to test the machine it's running on and change the function pointed to to suit that machine, without any runtime performance overhead. (Doing this would have a memory overhead, as the code for all versions of the same function would be resident.)

The ROM linking tool linktool.py didn't recognise imported module names as creating a symbol referring to the module's data area, but I have just pushed a very quick and lightly tested change to it (on the "rom" branch in github) which should make this work. Please let me know how you get on if you try it!

[shifters74]

Thanks Steve!

I was reading the source and wondering why they set conio function table the way they did as having to call them that way is a bit inconsistent with how normal functions are called but then i was looking through the rogue source and saw you using conio:function. It did strike me as almost like a name space for a module to avoid conflicts.

So i did get it working but thanks for the clarity of explanation - that mostly makes sense now!

I also found an error in the econet advanced user guide documentation (calls it an OSWORD but its actually OSBYTE call) when trying to delete econet receive blocks (tidying them up after a previous ctrl-break)!! That had me swearing for a while when trying to work out why it didnt work and i was running out of receiving blocks while testing!

I am making slow progress but progress none the less. I am using a private github repo to store the code as i get to defined working stages, so if you want a nose let me know and i can give you access.

cheers

shifters

[SteveF]

Thanks, it would be cool to see your code. Please make sure you only give me read access just to avoid any possible accidents though!

[shifters74]

Hi Steve,

i THINK i have given you access to it as ZornsLemma but not that familiar with what access i have given

Let me know if you can access it here https://github.com/shifters67/ECOMUD

cheers

shifters

[SteveF]

Thanks! I just accepted, I got a notification at the top of the browser window saying I have push access, so I could probably commit changes to your code. Obviously I don't *plan* to do that but if there is some way you can downgrade me to read-only access that would be safer. If that seems tricky don't worry about it, in the absolute worst case if I did somehow push a random commit to your repo there would be a git history showing it which would make it possible to undo it.

Edit: I've had a quick browse around the source, looks very nicely organised!

[shifters74]

I added you as a collaborator - if thats not the right way - i dont know what is and there seems no finer control on private repo unless you know otherwise!

shifters

[SteveF]

Thanks - I'm no expert on github permissions, but I think this will be fine. I'm not going to do anything malicious and since I'll probably either browse the repo via the web interface or clone it via http, which I think doesn't allow "git push" anyway, the chances of me accidentally breaking things for you should be close to zero.

And the last thing I want to do is eat into time you could be writing code in by asking you to fiddle around with github permissions.

[shifters74]

Hi Steve,

i will of course open the repo to public read in the future when its at the point of doing something useful - its still a bit to primitive at the moment.

Once you can login (you can!) and move around locations (work in progress) and interact with objects via commands (working on that next) then that may be the point for version 0.1 release - more as an extended example of PLASMA rather than a playable game of course.

While i have ideas for the game engine and what i want it to do, I am still debating about the type of game to implement i.e. what the theme would be - not just another dungeon crawler.

I am thinking of separating 'the game' itself from the 'engine' running on the server such that the same server engine could run multiple different games - just pick your game file when starting the server.

For the implementation of the game, i will need to implement a scripting language which the game is written in and is then converted/compiled to byte code (but not PLASMA byte code - my own) to run on the server game engine VM with that written in PLASMA running on the PLASMA VM

The main hardware i use at the moment for the server is an integraB (KenLowes with shadow and sideways ram) and JIM via 1MHz for RAM (lots and lots of ram ) and econet of course. The client runs on a stock B but the server runs with PLAS128 fine (not bothered with the co-pro yet and may not - undecided).

cheers

Shifters