Last visit was: Sat Sep 07, 2024 12:21 pm
|
It is currently Sat Sep 07, 2024 12:21 pm
|
PLASMA virtual machine on the OPC6
| Author |
Message |
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
Here's an example to show what I'm talking about: Code: steven@riemann:~/src/PLASMA-opc6$ cat equexample.s
ORG 0x0200
UBYTE 0x00 # ZERO
EQU _SYSFLAGS, 0
steven@riemann:~/src/PLASMA-opc6$ python opc6byteasm.py equexample.s
0400 ORG 0x0200
0400 00 UBYTE 0x00 # ZERO
0401 EQU _SYSFLAGS, 0
Assembled 1 bytes of code with 2 errors and 0 warnings.
Symbol Table:
PC 0x0200 (000512)
_BPC_ 0x0400 (001024)
_SYSFLAGS 0x0000 (000000)
Error: found word label directive or instruction on unaligned byte ...
EQU _SYSFLAGS, 0
Error: found word label directive or instruction on unaligned byte ...
EQU _SYSFLAGS, 0
If I add an ALIGN before the EQU line it assembles fine. As I say, it isn't causing me any real problems, but I find this mildly counterintuitive, since that line as far as I know is just setting the variable (I perhaps shouldn't call it a label) _SYSFLAGS to 0 and doesn't use the current word position.
|
| Thu Aug 10, 2017 9:29 pm |
|
|
|
Revaldinho
Joined: Tue Apr 25, 2017 7:33 pm
Posts: 32
|
Aha. OK that is unexpected. Fixed now and the non-zero exit status on errors too.
R
|
| Thu Aug 10, 2017 9:45 pm |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
Both changes work, thanks!
|
| Thu Aug 10, 2017 9:48 pm |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
I've been implementing some more VM opcodes and I've been trying to use a modified version of Ed's cmpsigned() macro. I infer that the extra __ arguments to the macro are essentially a way of getting local labels; is that right? I'm hitting problems with redefinition of those labels - apologies if I've introduced a bug, but here's a cut-down test case demonstrating my problem: Code: steven@riemann:~/src/opc/opc6$ cat error.s
ORG 0x1000
MACRO zero(dest, __bar)
__bar:
mov dest, r0
ENDMACRO
zero(r1)
zero(r2)
steven@riemann:~/src/opc/opc6$ python opc6byteasm.py error.s mem
2000 ORG 0x1000
2000
2000 # MACRO zero(dest, __bar)
2000 # __bar:
2000 # mov dest, r0
2000 # ENDMACRO
2000
2000 # zero(r1)
2000 __bar:
2000 01 00 mov r1, r0
2002 # zero(r2)
2002 __bar:
2002 02 00 mov r2, r0
Assembled 4 bytes of code with 1 error and 0 warnings.
Symbol Table:
PC 0x1002 (004098)
_BPC_ 0x2002 (008194)
__bar 0x1001 (004097)
Error: Symbol __bar redefined in ...
__bar:
Is this supposed to work, and if not is there some other way to get the effect of local labels in a macro? Cheers. Steve
|
| Fri Aug 11, 2017 10:12 pm |
|
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1796
|
I think revaldinho may have broken something recently! He added an '@' suffix to make this kind of thing a bit easier, but it's not quite right yet.
Edit: oops! That's not quite it. See below.
|
| Sat Aug 12, 2017 7:50 am |
|
|
|
Revaldinho
Joined: Tue Apr 25, 2017 7:33 pm
Posts: 32
|
Steve, You're half way there. You've defined the local label as a parameter in the macro definition... Code: MACRO zero( dest, __bar)
...but then not supplied a parameter value in the macro instances. If you add unique tokens to your macro instances then this will work, ie Code: zero ( r1, L0001)
zero (r2,L0002)
This is the origninal 'free' local label implementation. As Ed says I am adding a better local labelling function where you don't need to track the labels yourself. This isn't working yet but it's not related to this issue. I have a testcase from Dave to look at but won't be at my computer 'til later today. It won't take long to fix so will probably push that change if not later today then early tomorrow. R
|
| Sat Aug 12, 2017 8:09 am |
|
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1796
|
Oops! Thanks for the correction.
|
| Sat Aug 12, 2017 8:14 am |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
Thanks, I've added some unique tokens to my macro instances and it works now. I'll change this when the enhancement is available but it's not a big deal either way.
Cheers.
Steve
|
| Sat Aug 12, 2017 11:03 am |
|
|
|
Revaldinho
Joined: Tue Apr 25, 2017 7:33 pm
Posts: 32
|
Just pushed a fix for Dave's testcase in both word and byte assemblers so the new local label scheme is working in the latest GitHub code. No need to declare any parameters on macros or track labels yourself now. Just put the '@' symbol in any local label and it will get replaced with the macroname and a counter value each time it's used. Nested macros are still allowed. Here's a simple example using a cut down version of Dave's testcase with the byte assembler Code: EQU __divu, 0x1234
EQU __modu, 0x5678
MACRO SW16 ( _sub_ )
pl.inc pc, l1_@ - PC
inc r5, 1
l1_@:
add r2, r0
pl.inc pc, l2_@ - PC
jsr r13,r0, _sub_
l2_@:
mov pc, r13
ENDMACRO
__div:
SW16(__divu)
__mod:
SW16(__modu)
assembles into ... Code: 0000
0000 EQU __divu, 0x1234
0000 EQU __modu, 0x5678
0000
0000 # MACRO SW16 ( _sub_ )
0000 # pl.inc pc, l1_@ - PC
0000 # inc r5, 1
0000 # l1_@:
0000 # add r2, r0
0000 # pl.inc pc, l2_@ - PC
0000 # jsr r13,r0, _sub_
0000 # l2_@:
0000 # mov pc, r13
0000 # ENDMACRO
0000
0000 __div:
0000 # SW16(__divu)
0000 1f ec pl.inc pc, l1_SW16_0 - PC
0002 15 0c inc r5, 1
0004 l1_SW16_0:
0004 02 04 add r2, r0
0006 2f ec pl.inc pc, l2_SW16_0 - PC
0008 0d 19 34 12 jsr r13,r0, __divu
000c l2_SW16_0:
000c df 00 mov pc, r13
000e
000e __mod:
000e # SW16(__modu)
000e 1f ec pl.inc pc, l1_SW16_1 - PC
0010 15 0c inc r5, 1
0012 l1_SW16_1:
0012 02 04 add r2, r0
0014 2f ec pl.inc pc, l2_SW16_1 - PC
0016 0d 19 78 56 jsr r13,r0, __modu
001a l2_SW16_1:
001a df 00 mov pc, r13
001c
Assembled 28 bytes of code with 0 errors and 0 warnings.
Symbol Table:
PC 0x0000E (000014)
_BPC_ 0x0001A (000026)
__div 0x00000 (000000)
__divu 0x01234 (004660)
__mod 0x00007 (000007)
__modu 0x05678 (022136)
l1_SW16_0 0x00002 (000002)
l1_SW16_1 0x00009 (000009)
l2_SW16_0 0x00006 (000006)
l2_SW16_1 0x0000D (000013)
|
| Sat Aug 12, 2017 5:58 pm |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
Thanks, I've updated my code to use that and it works!
|
| Sat Aug 12, 2017 6:04 pm |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
I'm continuing to implement more of the VM opcodes and I now need to do the MUL, DIV and MOD opcodes, which carry out signed 16-bit multiplication, division and remainder. I see there is a udiv16 and a mul16 in math16.s in the opc repository, so: - Is the author of that code (Revaldinho?) OK with me including it in the GPL3-licensed PLASMA repository?
- Does anyone have any signed 16-bit division/remainder code? I can probably modify the udiv16 routine but I'm not all that comfortable implementing these kind of things and it would be nice if there's already some tested code I can re-use.
Cheers. Steve
|
| Sun Aug 13, 2017 7:25 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
Steve, I've just pulled together such a set of routines for the C compiler: https://github.com/hoglet67/opc/blob/c_ ... ot-c/lib.sDave
|
| Sun Aug 13, 2017 8:02 pm |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
Thanks Dave, they look great - are you OK for me to include that code in my GPLv3-licensed repository?
|
| Sun Aug 13, 2017 8:05 pm |
|
|
|
hoglet
Joined: Tue Feb 10, 2015 7:07 am
Posts: 52
|
SteveF wrote: Thanks Dave, they look great - are you OK for me to include that code in my GPLv3-licensed repository? That's fine as far as I'm concerned. Dave
|
| Sun Aug 13, 2017 8:30 pm |
|
|
|
SteveF
Joined: Sat Aug 05, 2017 6:57 pm
Posts: 26
|
Further progress... The PLASMA VM now starts up, displays the usual banner message and then dies because I haven't implemented the gets() function it uses to accept user input yet... Code: steven@riemann:~/src/PLASMA-opc6$ ./doit2.sh
[...]
steven@riemann:~/src/PLASMA-opc6$ ls -l emuout.txt
-rw-rw-r-- 1 steven steven 15693204 Aug 15 21:55 emuout.txt
steven@riemann:~/src/PLASMA-opc6$ python output.py emuout.txt
PLASMA 00.99
MEM FREE:$E1DC, AUX FREE:$FFF6
output.py is just grabbing OUT instructions from the emulator output and assuming they are all attempts to print ASCII characters. I think there is a lurking issue around the handling of function addresses but this is actually probably 50-75% of the way to being a working port, if an inefficient one which is ripe for tuning. (But that's the really fun bit, right?  ) It might be worth pointing out here that a full PLASMA implementation is something that expects to have a filesystem from which it can load modules containing user code (and ideally a terminal to interact with the user on). It would certainly be possible to use the core PLASMA VM to build a standalone executable with a hard-coded PLASMA program (and that might be appropriate for an embedded use), and what I've implemented already more-or-less provides that. (Just use 'doit.sh myprog.pla' to compile and run, but note that as it stands the program has no access to any standard PLASMA functions - just the core language. Kind of like a freestanding C implementation, I guess.) I can certainly make further progress towards a full implementation with the Python command line emulator, but at this point it would be very nice if I had a version of b-em with the PiTubeDirect OPC6 co-pro available. Dave - I see you're busy with the C64 port and probably other stuff as well, would you be willing to have a go at creating such a version of b-em, please? If not I can have a go at it myself. I'm also quite happy to break off development of the OPC6 port temporarily if you're interested in doing this but not right now. I have had a quick look at the OPC6 co-pro client ROM in the repository and I suspect I'd also have some further questions/requests for implementation of more OS calls/advice on how to extend the client ROM to do those myself. I'd really like to have the following (plus some which already seem to be supported): - OSFIND (open file for input/close file)
- OSGBPB (read ignoring PTR#)
- OSARGS (read extent)
Cheers. Steve
|
| Tue Aug 15, 2017 9:12 pm |
|
Who is online |
Users browsing this forum: CCBot and 0 guests |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
|
|
