Eric,
I've just had a nosy at the Fastspin sources looking for encoding details of LOC instruction.
I just checked in a fix that I think corrects LOC, or at least makes it produce an explicable and consistent output. The change is in backends/dat/outdat.c:
I have no understanding of these but I would have expected OPC_GENERIC_BRANCH would apply to both "calla" and "callb" equally. And presumably the OPC_CALL would go with the "call".
PS: Fastspin v3.9.21
The OPC_xxx field describes how the instruction is used internally in the code generator. In P2 fastspin uses ptra as the stack and makes subroutine calls (of all kinds) with "calla", so that's why that instruction is marked as OPC_CALL. Internally we never use "call" or "callb", but they might appear in user inline assembly, so they're marked as OPC_GENERIC_BRANCH to warn the optimizer that control flow will change across them.
There have been some significant bug fixes since fastspin 3.9.21. If you're interested in working with the source I recommend grabbing the most recent version from github (it's up to 3.9.25-beta now)
If you're inclinded to keep that source, just after you'd downloaded that one I'd updated the forum download with a small bug fix to display correct program counter value.
EDIT: Doh! I've got the updated PC value showing the address of the LOC instruction. Which doesn't quite suit relative sum for comparison with PA value. I think I'll leave it this way though.
#Define dirab dira
#Define inab ina
#Define outab outa
I put this at top of PASM .spin2 file and doesn't complain about the define statements but get:
"unknown symbol dirab"
etc. erros
The preprocessor is case sensitive, so it doesn't recognize "#Define" (only "#define"). It also ignores any directives it doesn't recognize; I think this was for compatibility with some other tools.
This is obviously unexpected, so I'll see what I can do to ameliorate it. In the meantime, use "#define" instead of "#Define" and it should work.
I've created new binary releases of spin2gui and fastspin. The changelog for fastspin is posted below. Besides the usual bug fixes, there are some significant additions to BASIC (support for two dimensional arrays and ON x GOTO) to make porting BASIC code easier. There's a new header file, "classic.bi", to assist with getting old style BASIC games running.
Also of note is a new warning for jumps without "#". This warning is only triggered for a branch to a simple label where that label contains code, but there is no "#". You can avoid the warning by changing the label to an expression like "label+0". So for example:
jmp foo ' no warning, foo is followed by long 0 so is probably a computed goto
jmp bar ' warning, possibly missing #
jmp bar+0 ' no warning, not a simple label
...
foo long 0
bar
add $, #1
Changelog:
- Unrolled LMM loop some more, for about a 10% performance improvement on code outside of fcache.
- Added --lmm=xxx flag to change LMM interpreter (for test purposes only, really; the default (`orig`) LMM is the best one)
- Changed runtime support code to avoid using CNT shadow register (for GEAR emulator compatibility)
- Added warnings for missing # on jumps
- Fixed scaling of LOC instruction when running in COG mode
- Put spaces between bytes in .lst files.
- Made preprocessor directives like "#define" case-insensitive in Spin and BASIC
- Allow multi-dimensional dim in BASIC
- Add ON x GOTO to BASIC
- Change BASIC number reading code to ignore leading spaces
- Added include/classic.bi, a header file to make porting classic basic games easier.
- Fixed using string initializers for arrays.
- Accept old-style C function declarations
- Accept .a as an extension for C code; this allows us to create a "library" containing a bunch of C declarations with __fromfile() notation to find the implementations.
I think i found a bug in the fastspin compiler. Version 3.9.25 Compiled on: Apr 14 2019
I haven't read all the previous pages, if it is on there, sorry!
I use the DAT section for 'lookup' and strings and... (also a lot of assembly...)
modus1
long RAM_CMD+WRbit
long (modus1_end-2-modus1)*4
long NUMBER
word modus1_x , modus1_d_y*0+modus1_1_y , modus1_font , 0
word modus1_x , modus1_d_y*1+modus1_1_y , modus1_font , 0
word modus1_x , modus1_d_y*2+modus1_1_y , modus1_font , 0
word modus1_x , modus1_d_y*3+modus1_1_y , modus1_font , 0
long 0
modus1_end
modus2
long RAM_CMD+WRbit
long (modus2_end-2-modus2)*4
long NUMBER
word modus2_x , modus2_d_y*0+modus2_1_y , modus2_font , 0
word modus2_x , modus2_d_y*1+modus2_1_y , modus2_font , 0
word modus2_x , modus2_d_y*2+modus2_1_y , modus2_font , 0
word modus2_x , modus2_d_y*3+modus2_1_y , modus2_font , 0
long 0
modus2_end
but after 2048 bytes of a lot of these 'lookups' it gives me this error:
error: label modus1_end in COG memory not on longword boundary
error: label modus2_end in COG memory not on longword boundary
This error is gone if i dont use the second label to auto calculate the size of the 'lookup' block of data.
I use this a lot on prop 1. this error let me scratch my head for longer than i admit.
Are you able to post your complete code? I'm not able to reproduce the problem, and I'd like to figure out what is going on. I'm quite surprised that it would complain about "modus1_end" not being aligned but not about "modus1", since both should have the same alignment.
Are you able to post your complete code? I'm not able to reproduce the problem, and I'd like to figure out what is going on. I'm quite surprised that it would complain about "modus1_end" not being aligned but not about "modus1", since both should have the same alignment.
ok. the problem exist between chair and keyboard. I overlooked some crucial info without fact checking. sorry!
i can't post the code, but i can reproduce the problem in a smaller form.
I also have some strings in it: bytes.
the following code won't compile.
dat
modus1
long (modus1_end-2-modus1)*4
long 37
word 0,1,2,3,4,5,6,7,8,9
byte "strings"
long 0
modus1_end
I understand there are 7 bytes in the string. is it possible to auto fill up the remaining bytes with 0 until the next long? (like on P1 with bst)
That you were compilig for P2 rather than P1 is another crucial piece of the puzzle .
There are two ways to get rid of the error on P2:
(1) Insert an "orgh" directive before your data. In that case you'll probably also want to remove the "*4" in your calculation of the size, because the labels will the HUB labels (byte addresses rather than long addresses).
(2) The other alternative is to insert an "alignl" directive after the string. This will explicitly align the following code/data to a long word boundary.
A set of tables bigger than all of cogram might have something to do with it. The ORGH placed ahead should fix it. The tables are going to be in hubram then though.
Presumably the specific error is a side effect of the order of checks.
orgh works like a charm!
I find the propeller a very nice controller to program. BUT dubble check every char, number, comma,... the compiler compiles it and you can start the endless search.
It's something you can have with every controller, but I find this especially true with propeller.
Thank you for the solution!
Hi
Well at last I thought I MUST give this a try.
I only have P1 and I have only used PropBasic and it has done all I want but with P2 getting ever closer AND I am a happy user of freeBasic its time to investigate. So I downloaded spin2gui zip and ran spin2gui.exe and... my AVG antivirus took a keen interest- whipped it out from under my nose to inspect and it tells me it will let me know what it finds in about an hour or so.
Ok its in the previous zip, but not the one before that. Thanks
I downloaded the zip file from that link just to make that screenshot.
What settings and what executable program are you using to unzip the file? Try a different unzip program.
Hi
Well at last I thought I MUST give this a try.
I only have P1 and I have only used PropBasic and it has done all I want but with P2 getting ever closer AND I am a happy user of freeBasic its time to investigate. So I downloaded spin2gui zip and ran spin2gui.exe and... my AVG antivirus took a keen interest- whipped it out from under my nose to inspect and it tells me it will let me know what it finds in about an hour or so.
Dave
Someone else reported that AVG was upset about the file. I'm quite sure that it's a false positive -- I built the executables myself on my Linux machine (with a cross compiler) so it is *highly* unlikely that there's a Windows virus in any of them.
Saw something in another thread that made me wonder...
Is it possible to compile things like assembly VGA driver, USB driver, etc. and then bring them into top level program (PASM or Spin) using the "File" directive on the ".binary" output?
Seems like it might work...
Or, maybe better... Can a Spin file include assembly drivers from a separate file with separate namespace?
Is it possible to compile things like assembly VGA driver, USB driver, etc. and then bring them into top level program (PASM or Spin) using the "File" directive on the ".binary" output?
If you're very careful to make the code position independent then it should work. If the code is not position independent then you'd have to compile it to a specific address.
Or, maybe better... Can a Spin file include assembly drivers from a separate file with separate namespace?
Objects automatically have their own namespaces, so that's the best way to do things (make each driver its own object).
Do you have an example where a Spin2 file (Spin, not PASM) includes an assembly driver from another file?
Objects work the same way in Spin2 as in Spin, or at least they do in fastspin (and I assume that in Chip's Spin2 they will at least be very similar). You use an OBJ directive and give the name of the file.
Can this be done where the main file is PASM only?
No.
I guess it'd also be interesting if this can be done with your C compiler...
Kind of; the "struct __using" declaration lets you include a Spin or BASIC object into a C file.
Comments
--- a/backends/dat/outdat.c +++ b/backends/dat/outdat.c @@ -1238,6 +1238,9 @@ decode_instr: isrc *= 4; } isrc = isrc - (curpc+4); + if (instr->ops == P2_LOC && !inHub) { + isrc = isrc >> 2; + } src = isrc & 0xfffff; val = val | (1<<20); } else {With this change your test program produces: which at least gets the PA-data right in all 3 cases.
Thanks for your bug report!
Eric
The OPC_xxx field describes how the instruction is used internally in the code generator. In P2 fastspin uses ptra as the stack and makes subroutine calls (of all kinds) with "calla", so that's why that instruction is marked as OPC_CALL. Internally we never use "call" or "callb", but they might appear in user inline assembly, so they're marked as OPC_GENERIC_BRANCH to warn the optimizer that control flow will change across them.
There have been some significant bug fixes since fastspin 3.9.21. If you're interested in working with the source I recommend grabbing the most recent version from github (it's up to 3.9.25-beta now)
Good stuff. Looks perfect. I'll go grab the update ... confirmed same good results for me. Thanks.
EDIT: Doh! I've got the updated PC value showing the address of the LOC instruction. Which doesn't quite suit relative sum for comparison with PA value. I think I'll leave it this way though.
I put this at top of PASM .spin2 file and doesn't complain about the define statements but get:
"unknown symbol dirab"
etc. erros
The preprocessor is case sensitive, so it doesn't recognize "#Define" (only "#define"). It also ignores any directives it doesn't recognize; I think this was for compatibility with some other tools.
This is obviously unexpected, so I'll see what I can do to ameliorate it. In the meantime, use "#define" instead of "#Define" and it should work.
Thanks,
Eric
Also of note is a new warning for jumps without "#". This warning is only triggered for a branch to a simple label where that label contains code, but there is no "#". You can avoid the warning by changing the label to an expression like "label+0". So for example:
jmp foo ' no warning, foo is followed by long 0 so is probably a computed goto jmp bar ' warning, possibly missing # jmp bar+0 ' no warning, not a simple label ... foo long 0 bar add $, #1Changelog:
- Unrolled LMM loop some more, for about a 10% performance improvement on code outside of fcache.
- Added --lmm=xxx flag to change LMM interpreter (for test purposes only, really; the default (`orig`) LMM is the best one)
- Changed runtime support code to avoid using CNT shadow register (for GEAR emulator compatibility)
- Added warnings for missing # on jumps
- Fixed scaling of LOC instruction when running in COG mode
- Put spaces between bytes in .lst files.
- Made preprocessor directives like "#define" case-insensitive in Spin and BASIC
- Allow multi-dimensional dim in BASIC
- Add ON x GOTO to BASIC
- Change BASIC number reading code to ignore leading spaces
- Added include/classic.bi, a header file to make porting classic basic games easier.
- Fixed using string initializers for arrays.
- Accept old-style C function declarations
- Accept .a as an extension for C code; this allows us to create a "library" containing a bunch of C declarations with __fromfile() notation to find the implementations.
I'd make it always give a warning, personally...
Maybe you can have a command line warning option to override.. Like "-W2" or something...
I like the simple label+0 to prevent the warning
I have had to place comments when the # was specifically not required. I think +0 makes sense here.
I haven't read all the previous pages, if it is on there, sorry!
I use the DAT section for 'lookup' and strings and... (also a lot of assembly...)
modus1 long RAM_CMD+WRbit long (modus1_end-2-modus1)*4 long NUMBER word modus1_x , modus1_d_y*0+modus1_1_y , modus1_font , 0 word modus1_x , modus1_d_y*1+modus1_1_y , modus1_font , 0 word modus1_x , modus1_d_y*2+modus1_1_y , modus1_font , 0 word modus1_x , modus1_d_y*3+modus1_1_y , modus1_font , 0 long 0 modus1_end modus2 long RAM_CMD+WRbit long (modus2_end-2-modus2)*4 long NUMBER word modus2_x , modus2_d_y*0+modus2_1_y , modus2_font , 0 word modus2_x , modus2_d_y*1+modus2_1_y , modus2_font , 0 word modus2_x , modus2_d_y*2+modus2_1_y , modus2_font , 0 word modus2_x , modus2_d_y*3+modus2_1_y , modus2_font , 0 long 0 modus2_endbut after 2048 bytes of a lot of these 'lookups' it gives me this error:
This error is gone if i dont use the second label to auto calculate the size of the 'lookup' block of data.
I use this a lot on prop 1. this error let me scratch my head for longer than i admit.
Are you able to post your complete code? I'm not able to reproduce the problem, and I'd like to figure out what is going on. I'm quite surprised that it would complain about "modus1_end" not being aligned but not about "modus1", since both should have the same alignment.
ok. the problem exist between chair and keyboard. I overlooked some crucial info without fact checking. sorry!
i can't post the code, but i can reproduce the problem in a smaller form.
I also have some strings in it: bytes.
the following code won't compile.
dat modus1 long (modus1_end-2-modus1)*4 long 37 word 0,1,2,3,4,5,6,7,8,9 byte "strings" long 0 modus1_endI understand there are 7 bytes in the string. is it possible to auto fill up the remaining bytes with 0 until the next long? (like on P1 with bst)There are two ways to get rid of the error on P2:
(1) Insert an "orgh" directive before your data. In that case you'll probably also want to remove the "*4" in your calculation of the size, because the labels will the HUB labels (byte addresses rather than long addresses).
(2) The other alternative is to insert an "alignl" directive after the string. This will explicitly align the following code/data to a long word boundary.
Presumably the specific error is a side effect of the order of checks.
I find the propeller a very nice controller to program. BUT dubble check every char, number, comma,... the compiler compiles it and you can start the endless search.
It's something you can have with every controller, but I find this especially true with propeller.
Thank you for the solution!
Is there a built loadp2.exe windows version somewhere for download?
No \bin directory in the spin2gui download
https://github.com/totalspectrum/spin2gui/releases
Ok its in the previous zip, but not the one before that. Thanks
Well at last I thought I MUST give this a try.
I only have P1 and I have only used PropBasic and it has done all I want but with P2 getting ever closer AND I am a happy user of freeBasic its time to investigate. So I downloaded spin2gui zip and ran spin2gui.exe and... my AVG antivirus took a keen interest- whipped it out from under my nose to inspect and it tells me it will let me know what it finds in about an hour or so.
Dave
What settings and what executable program are you using to unzip the file? Try a different unzip program.
Someone else reported that AVG was upset about the file. I'm quite sure that it's a false positive -- I built the executables myself on my Linux machine (with a cross compiler) so it is *highly* unlikely that there's a Windows virus in any of them.
But this is a 'normal' windows behavior if you use other then MS compilers.
Enjoy!
Mike
Is it possible to compile things like assembly VGA driver, USB driver, etc. and then bring them into top level program (PASM or Spin) using the "File" directive on the ".binary" output?
Seems like it might work...
Or, maybe better... Can a Spin file include assembly drivers from a separate file with separate namespace?
Objects automatically have their own namespaces, so that's the best way to do things (make each driver its own object).
Can this be done where the main file is PASM only?
I guess it'd also be interesting if this can be done with your C compiler...
No.
Kind of; the "struct __using" declaration lets you include a Spin or BASIC object into a C file.
Sounds like you're saying to just do it the same way as with P1...