Have this error. Haven't traced my bug down but I thought i would post it before I overwrite it.
The error points to a wrong line and perhaps wrong module.
This is the problem. I have a set of constants defined for my ROM Monitor. The call is in hub (hubexec) and the call is too far away to do a relative call. I forgot to force it to use absolute addressing on this line.
call#_SerialInit ' initialise serial
BTW this is one of my bugbears that you shouldn't use the "\" absolute when in cog/lut for reasons I'm still unsure about.
C:\P2\Propeller_II_Latest\ClusoZ80>f420 test.spin2 -2 -l
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version4.2.0 Compiled on: May 292020test.spin2test.spin2MON_CONST.spin2:111: error: Operand for call is out of range
Done.
BTW this is one of my bugbears that you shouldn't use the "\" absolute when in cog/lut for reasons I'm still unsure about.
As far as I know you can always use "\" in any jump or LOC instruction. I've certainly used it in cog and lut in my code.
That is likely the same problem as I found above with the $ missing.
I think we (well at least me) need a definitive document as to precisely where you need to use "\", "@" and "@@" and where not to use them. I have to resort to a lot of trial and error, and to add to the mix IIRC there is still a problem with pnut although as you've probably realised I've abandoned it. Now that I've done so, I can use #include and #define and friends. This allows me to break down the code into re-usable objects nicely. I don't need to copy/paste code blocks into various pieces of code, and I only have to fix/modify/enhance once
Eric ,
This code when executed from hub (hubexec) it places the wrong address into the lmm_p register. I've checked the pasm listing and it is 1 long out. ie $4E0 is used and it should be $4DC.
mov lmm_p, ##str_progid ' must be in hub!
Does not matter whether I use with or without "@".
The same error applies for the ##str_p2d2 and ##str_p2eval a few lines back in the code. File is cog_startup.spin2 line 119.
What is interesting besides the string address being a long out (as in the previous post) is that by changing 1 line ## to # results in a long being lost in the ## code listing. But it's not the use of AUGS which isn't invoked. The long gets consumed later. I've included the listing for both for you to compare them.
I am not seeing any other errors in my code that could cause this but you never know
I'm really giving fastspin a workout now!
BTW it compiles my Z80 emulator and that's quite large. While it runs I don't have anything to compare it with. It does execute Z80 code (and 5000 instructions worth) but I don't currently have enough working to verify it.
... that by changing 1 line ## to # results in a long being lost in the ## code listing. But it's not the use of AUGS which isn't invoked. ...
It's utterly illegal to use ## on JMP. That should be an assembly error.
Yes. It's just like missing the # on a jmp which is almost always an error. But when you're coding lots of large constants it sort of becomes a habit and you let one slip thru. But what got me was not that it didn't work, nor that an error wasn't reported, but that in some obscure way the compiler lost a long further down the code. It just disappeared without a trace as the hub address jumped by 4 bytes right at the destination address of the failed JMP ##
0052f 0D 0A 00005320000 | alignl
00534 | '+=============================================================================+00534 | _USER_HUBEXEC_BEGIN ' users hubexec code begins here00534020000 FF
00538 0F C5 07 F6 | mov lmm_p, ##str_progid2 '\ <<<<<<<<<<<<<<<<<< your hubexec code goes here
0053c A4 CB AF FD | call #\_hubTxStr '/ <<<<<<<<<<<<<<<<<< your hubexec code goes here
It wasn't until I did a compare of the listing of both that I saw this. You can be sure there is a reason for this error manifesting this way, but it's a doosey!
Just twigged to this problem. The alignl is not working as it should when this jmp ## error is present. Knowing how many bytes were filled, I removed the alignl and inserted byte 0,0. The missing long in no longer missing. Something is causing the alignl to skip 4 bytes. It doesn't appear to be inserting them but just bumps the pc (program counter).
Eric, I bet this is the cause of the incorrect
mov lmm_p, ##str_progid
a couple of post back. The binary is missing the long causing the displacement error in the mov address. Probably causing a lot more problems too.
@Cluso99 : Thanks for the bug report, Ray. I had intended to support ## on jmp/call as an extension (treating it just like #) but some other part of the code always treats ## as indicating the code takes 2 instructions, hence the hub address mismatch. So I've changed the code to throw an error for ## used with jmp/call/loc.
Evan, in these cases I’m getting a listing and binary. The binary is shifted by 4 missing longs which is evident in displaying strings which are missing the first 4 bytes.
I think I’ve removed all the alignl by padding with trailing zeros. The last attachment has the listings too if you’re interested.
I’ll wait for the next fastspin release before I do anything further as I’ve plenty to continue with.
Also got to get my pcb made for those chips I ordered
Eric,
Is this supposed to work?
If the hub address is less than $400 then I want to pad with zeros.
But the compiler is then resetting the hub address back to $400.
Ray: I can't reproduce the byte 0[$400-$] problem you showed; when I try it I just get nothing output, although really it should report an error. Do you have an orgh somewhere before this? If not then "$" is probably not doing what you expect. In any case there should be an error about using a negative number in a byte declaration, and I'll add one.
What you're probably looking for is to do something like:
orgh ' make sure we're in HUB mode
orgh ($ < $400) ? $400 : $
which is the sequence Chip suggested for making sure the orgh goes to at least $400
Ray: I can't reproduce the byte 0[$400-$] problem you showed; when I try it I just get nothing output, although really it should report an error. Do you have an orgh somewhere before this? If not then "$" is probably not doing what you expect. In any case there should be an error about using a negative number in a byte declaration, and I'll add one.
What you're probably looking for is to do something like:
orgh ' make sure we're in HUB mode
orgh ($ < $400) ? $400 : $
which is the sequence Chip suggested for making sure the orgh goes to at least $400
Eric,
Many thanks for your great fastspin compiler
I thought the snippet showed the problem. The code was already in hub (orgh) and had already exceeded hub $400 when it encountered my long ($400-$).
Sure I'll change to using the more obtuse verilog way as it's not a problem for me. When using object modules you cannot always control the flow because you don't know what other objects are in the mix, so that's why I use the padding of longs.
It's imperative for me to map where everything fits in hub. The idea of code just floating around does not work.
I am pleased to say that fastspin lets me put code where I want it
Whoa, easy there Evan. 4.2.0 is the latest binary release. I'm really grateful for everyone who builds fastspin from sources and tries out the beta versions, but not everyone is equipped to do that.
I was referring to your newly announced fixes. My point didn't even need any testing, it was just a logical deduction. Access or not, I'm not sure why Cluso chose to dance around that.
@ersmith When starting the FlexGUI environment Ver 4.2.1-beta (Patreon origin) under Win10, I get a Windows Defender alert about an unknown publisher. Once I dismiss this message, I then get a dialogue box that says:
Error in startup script -
Unmatched open brace in list while executing "lindex $data 0" (procedure "config_open" line 19 invoked from within "config_open" (file d:/Flex2Gui/flexgui/src/gui.tcl" line 1336 involked from within "source $ROOTDIR/src/gui.tcl" (file d:/Flex2Gui/flexgui/flexgui.tcl" line 24)
At this point the execution of FlexGUI is terminated.
ADDED: One of the Minions found an error on Page 40 of the FlexBasic doc. The following example is given for EXIT FUNCTION:
functionsumif(a, x, y)
sumif = x + yif (a <> 0)
exitfunctionsumif = 0
endfunction
The issue is the standalone IF without a THEN and/or missing END IF. It should be one of these:
function sumif(a, x, y)
sumif = x + y
if (a <> 0) thenexitfunctionendif
sumif = 0endfunction
- or -
functionsumif(a, x, y)
sumif = x + yif (a <> 0) thenexitfunctionsumif = 0
endfunction
@ersmith When starting the FlexGUI environment Ver 4.2.1-beta (Patreon origin) under Win10, I get a Windows Defender alert about an unknown publisher.
I forgot to sign it, sorry.
Once I dismiss this message, I then get a dialogue box that says:
Error in startup script -
Unmatched open brace in list while executing "lindex $data 0" (procedure "config_open" line 19 invoked from within "config_open" (file d:/Flex2Gui/flexgui/src/gui.tcl" line 1336 involked from within "source $ROOTDIR/src/gui.tcl" (file d:/Flex2Gui/flexgui/flexgui.tcl" line 24)
At this point the execution of FlexGUI is terminated.
[/quote]
That's pretty weird, because I didn't in fact make any changes to src/gui.tcl since v4.2.0.
Does the problem still happen if you rename the file ".flexgui.config" to something else (like ".flexgui.config.old")? Do any of the file names you're using contain a "[" or "{" (or some other unusual character)?
@ersmith Here is an odd one. FlexBASIC's OPTION EXPLICIT is suddenly case sensitive.
This works fine:
OPTIONexplicit'<--- no problemodim a aslongfor a = 1to10
print a
next a
This throws an error:
OPTIONEXPLICIT' <--- breaks if "explicit" is in capsdim a aslongfor a = 1to10
print a
next a
And here is the complier output:
"d:/Flex2Gui/flexgui/bin/fastspin" -2 -l -D_BAUD=230400 -O1 -I "d:/Flex2Gui/flexgui/include""d:/Flex2Gui/flexgui/P2 Libs/tmptest.bas"
Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc.
Version 4.2.1-beta-14fae44b Compiled on: Jun 42020
tmptest.bas
d:/Flex2Gui/flexgui/P2 Libs/tmptest.bas:2: error: Unknown option EXPLICIT
child process exited abnormally
Finished at Sat Jun 616:11:292020
@ersmith Couple questions... Is the FCACHE size range from 1 to 256? I think so, but want to check... It doesn't seem to say anywhere...
Also, would it be good to have it possible to have some compiler options inside the main .spin2 file?
I'm thinking that if PropTool does allow the use of fastspin to compile, maybe it won't be able to maintain all the different compile options.
Also, there may be code that only works with certain compile options and you'd want the code to overrule whatever the compile line was?
I'm not sure if this is good idea or not, just wondering...
4.2.0 seems to break my inline assembly for eMMC driver. This is not using FCACHE. Doesn't work with FCACHE either.
I added fcache and optimization options to SpinEdit and then went back to look at this...
I think I may have been wrong about this... There was just something wrong the inline assembly version.
I've got it almost fixed now and it runs with FCACHE on and speed is dramatically improved.
But, only works with -O0, doesn't work with -O1.
But, it's OK because I don't really care too much about the inline assembly version any more. Maybe one day I'll try to see what is wrong with it...
The missing getrnd() identifier should be fixed in the new version (4.2.3) which I've just posted.
There are a number of other significant improvements. Most notably, I found a serious bug in lookup/lookdown if the internally generated tables weren't aligned properly. This could explain both the problems people have been having with lookup, and also the mysterious problems that would disappear when code was re-arranged.
Thanks Andy. There was a problem with detecting result variables used inside inline assembly (such as in the implementation of polxy). That's fixed in github now. Are you able to build from source?
Comments
The error points to a wrong line and perhaps wrong module.
This is the problem. I have a set of constants defined for my ROM Monitor. The call is in hub (hubexec) and the call is too far away to do a relative call. I forgot to force it to use absolute addressing on this line.
call #_SerialInit ' initialise serialBTW this is one of my bugbears that you shouldn't use the "\" absolute when in cog/lut for reasons I'm still unsure about.C:\P2\Propeller_II_Latest\ClusoZ80>f420 test.spin2 -2 -l Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc. Version 4.2.0 Compiled on: May 29 2020 test.spin2 test.spin2 MON_CONST.spin2:111: error: Operand for call is out of range Done.As far as I know you can always use "\" in any jump or LOC instruction. I've certainly used it in cog and lut in my code.
I think we (well at least me) need a definitive document as to precisely where you need to use "\", "@" and "@@" and where not to use them. I have to resort to a lot of trial and error, and to add to the mix IIRC there is still a problem with pnut although as you've probably realised I've abandoned it. Now that I've done so, I can use #include and #define and friends. This allows me to break down the code into re-usable objects nicely. I don't need to copy/paste code blocks into various pieces of code, and I only have to fix/modify/enhance once
This code when executed from hub (hubexec) it places the wrong address into the lmm_p register. I've checked the pasm listing and it is 1 long out. ie $4E0 is used and it should be $4DC.
mov lmm_p, ##str_progid ' must be in hub!Does not matter whether I use with or without "@".The same error applies for the ##str_p2d2 and ##str_p2eval a few lines back in the code. File is cog_startup.spin2 line 119.
004b4 A4 CB AF FD | call #\_hubTxStr ' 004b8 7C 00 90 FD | JMP ##_USER_HUBEXEC_BEGIN ' execute users hubexec code ..... 00534 | _USER_HUBEXEC_BEGIN ' users hubexec code begins here 00538 02 00 00 FF 0053c 13 C5 07 F6 | mov lmm_p, ##str_progid2 '\ <<<<<<<<<<<<<<<<<< your hubexec code goes hereWhen corrected004b4 A4 CB AF FD | call #\_hubTxStr ' 004b8 78 00 90 FD | JMP #_USER_HUBEXEC_BEGIN ' execute users hubexec code ..... 00534 | _USER_HUBEXEC_BEGIN ' users hubexec code begins here 00534 02 00 00 FF 00538 0F C5 07 F6 | mov lmm_p, ##str_progid2 '\ <<<<<<<<<<<<<<<<<< your hubexec code goes hereWhat is interesting besides the string address being a long out (as in the previous post) is that by changing 1 line ## to # results in a long being lost in the ## code listing. But it's not the use of AUGS which isn't invoked. The long gets consumed later. I've included the listing for both for you to compare them.I am not seeing any other errors in my code that could cause this but you never know
I'm really giving fastspin a workout now!
BTW it compiles my Z80 emulator and that's quite large. While it runs I don't have anything to compare it with. It does execute Z80 code (and 5000 instructions worth) but I don't currently have enough working to verify it.
0052f 0D 0A 00 00532 00 00 | alignl 00534 | '+=============================================================================+ 00534 | _USER_HUBEXEC_BEGIN ' users hubexec code begins here 00538 02 00 00 FF 0053c 13 C5 07 F6 | mov lmm_p, ##str_progid2 '\ <<<<<<<<<<<<<<<<<< your hubexec code goes here 00540 A4 CB AF FD | call #\_hubTxStr '/ <<<<<<<<<<<<<<<<<< your hubexec code goes hereand here is the one with correct jmp #0052f 0D 0A 00 00532 00 00 | alignl 00534 | '+=============================================================================+ 00534 | _USER_HUBEXEC_BEGIN ' users hubexec code begins here 00534 02 00 00 FF 00538 0F C5 07 F6 | mov lmm_p, ##str_progid2 '\ <<<<<<<<<<<<<<<<<< your hubexec code goes here 0053c A4 CB AF FD | call #\_hubTxStr '/ <<<<<<<<<<<<<<<<<< your hubexec code goes hereIt wasn't until I did a compare of the listing of both that I saw this. You can be sure there is a reason for this error manifesting this way, but it's a doosey!Just twigged to this problem. The alignl is not working as it should when this jmp ## error is present. Knowing how many bytes were filled, I removed the alignl and inserted byte 0,0. The missing long in no longer missing. Something is causing the alignl to skip 4 bytes. It doesn't appear to be inserting them but just bumps the pc (program counter).
Eric, I bet this is the cause of the incorrect
mov lmm_p, ##str_progid
a couple of post back. The binary is missing the long causing the displacement error in the mov address. Probably causing a lot more problems too.
Was this the cause of the misalignment when alignl was executed?
I think I’ve removed all the alignl by padding with trailing zeros. The last attachment has the listings too if you’re interested.
I’ll wait for the next fastspin release before I do anything further as I’ve plenty to continue with.
Also got to get my pcb made for those chips I ordered
Is this supposed to work?
If the hub address is less than $400 then I want to pad with zeros.
But the compiler is then resetting the hub address back to $400.
01e00 | byte 0[$400-$] ' fill to HUB $400 01e00 | _hubCogStart drvh #pincfg '\ drive pin hi 00400 59 32 64 FD 00404 1F 3C 64 FD | waitx #30*1 '| wait >1us 00408 51 32 64 FD | flth #pincfg '| float pinWhat you're probably looking for is to do something like:
orgh ' make sure we're in HUB mode orgh ($ < $400) ? $400 : $which is the sequence Chip suggested for making sure the orgh goes to at least $400Update your Fastspin. My comment only applies to that.
Many thanks for your great fastspin compiler
I thought the snippet showed the problem. The code was already in hub (orgh) and had already exceeded hub $400 when it encountered my long ($400-$).
Sure I'll change to using the more obtuse verilog way as it's not a problem for me. When using object modules you cannot always control the flow because you don't know what other objects are in the mix, so that's why I use the padding of longs.
FWIW my Z80 code is broken into sections:
'+=====================================================================================================================+ '+ COG: org 0 Initialise serial + '+ Load #@lut_code + '+ Jmp #reload_cog (in hub) + '+=====================================================================================================================+ '+ HUBEXEC: orgh $400 Z80 instruction emulation - must be $400-$1000 hub (12 bits) + '+=====================================================================================================================+ '+ HUB: orgh $1000 Z80 vector tables + '+=====================================================================================================================+ '+ HUB: orgh $2000 COG code + '+ COG: org $0 Fetch (Z80 opcode fetch & execution) + '+ Break + '+ Z80 instruction emulation + '+ io_command, z80 registers, etc + '+ org $1e0 lmm_x... + '+ org $1f0 opcode, alu, etc + '+=====================================================================================================================+ '+ HUB: orgh $2800 LUT code + '+ LUT: org $200 Z80 instruction emulation + '+=====================================================================================================================+ '+ HUB: orgh $3000 Z80 register copies + '+=====================================================================================================================+ '+ HUBEXEC: orgh $3100 hubidstring "Cluso's P2 Z80 Emulation: Experimental v????",13,10,0 + '+ Load #@cog_code + '+ Jmp #cog_code + '+=====================================================================================================================+ '+ HUBEXEC: orgh $3400 _debug_... debug/dump regs etc + '+ _debug_break + '+=====================================================================================================================+ '+ HUB: orgh $1_000 Z80_MEM Z80 RAM Memory 64KB ($1_0000[64*1024] + '+---------------------------------------------------------------------------------------------------------------------+ '+ orgh Z80_MEM + $0000 insert z80 JMP $FC00 + '+ orgh Z80_MEM + $0100 insert z80 code to execute: file: "zmac/zout/zexdoc.cim" + '+ orgh Z80_MEM + $F000 insert z80 BDOS + '+ orgh Z80_MEM + $F100 insert z80 BIOS + '+=====================================================================================================================+It's imperative for me to map where everything fits in hub. The idea of code just floating around does not work.I am pleased to say that fastspin lets me put code where I want it
Whoa, easy there Evan. 4.2.0 is the latest binary release. I'm really grateful for everyone who builds fastspin from sources and tries out the beta versions, but not everyone is equipped to do that.
Error in startup script -
Unmatched open brace in list while executing "lindex $data 0" (procedure "config_open" line 19 invoked from within "config_open" (file d:/Flex2Gui/flexgui/src/gui.tcl" line 1336 involked from within "source $ROOTDIR/src/gui.tcl" (file d:/Flex2Gui/flexgui/flexgui.tcl" line 24)
At this point the execution of FlexGUI is terminated.
ADDED: One of the Minions found an error on Page 40 of the FlexBasic doc. The following example is given for EXIT FUNCTION:
function sumif(a, x, y) sumif = x + y if (a <> 0) exit function sumif = 0 end functionThe issue is the standalone IF without a THEN and/or missing END IF. It should be one of these:function sumif(a, x, y) sumif = x + y if (a <> 0) then exit function end if sumif = 0 end function- or -function sumif(a, x, y) sumif = x + y if (a <> 0) then exit function sumif = 0 end functionAt this point the execution of FlexGUI is terminated.
[/quote]
That's pretty weird, because I didn't in fact make any changes to src/gui.tcl since v4.2.0.
Does the problem still happen if you rename the file ".flexgui.config" to something else (like ".flexgui.config.old")? Do any of the file names you're using contain a "[" or "{" (or some other unusual character)?
Thanks,
Eric
And nope, none of the files anywhere on that drive have any funky characters.
So we're back in business. Thanks, Eric!
This works fine:
OPTION explicit '<--- no problemo dim a as long for a = 1 to 10 print a next aThis throws an error:
OPTION EXPLICIT ' <--- breaks if "explicit" is in caps dim a as long for a = 1 to 10 print a next aAnd here is the complier output:
"d:/Flex2Gui/flexgui/bin/fastspin" -2 -l -D_BAUD=230400 -O1 -I "d:/Flex2Gui/flexgui/include" "d:/Flex2Gui/flexgui/P2 Libs/tmptest.bas" Propeller Spin/PASM Compiler 'FastSpin' (c) 2011-2020 Total Spectrum Software Inc. Version 4.2.1-beta-14fae44b Compiled on: Jun 4 2020 tmptest.bas d:/Flex2Gui/flexgui/P2 Libs/tmptest.bas:2: error: Unknown option EXPLICIT child process exited abnormally Finished at Sat Jun 6 16:11:29 2020So... FlexBASIC doesn't like “capitalism”!
Also, would it be good to have it possible to have some compiler options inside the main .spin2 file?
I'm thinking that if PropTool does allow the use of fastspin to compile, maybe it won't be able to maintain all the different compile options.
Also, there may be code that only works with certain compile options and you'd want the code to overrule whatever the compile line was?
I'm not sure if this is good idea or not, just wondering...
I added fcache and optimization options to SpinEdit and then went back to look at this...
I think I may have been wrong about this... There was just something wrong the inline assembly version.
I've got it almost fixed now and it runs with FCACHE on and speed is dramatically improved.
But, only works with -O0, doesn't work with -O1.
But, it's OK because I don't really care too much about the inline assembly version any more. Maybe one day I'll try to see what is wrong with it...
Whein I try to use the getrnd() function, I always get this error in fastspin:
"error: unknown identifier getrnd used in function call"
Andy
There are a number of other significant improvements. Most notably, I found a serious bug in lookup/lookdown if the internally generated tables weren't aligned properly. This could explain both the problems people have been having with lookup, and also the mysterious problems that would disappear when code was re-arranged.
getrnd() works now in the newest fastspin.
But I've found another issue:
polxy() does not return valid results. There are no getqx,getqy asm instructions in the resulting listing.
Here is a testcode:
CON _clkfreq = 160_000_000 OBJ ser : "spin/SmartSerial" PUB sincos() | x,y, sc ser.start(63, 62, 0, 115200) x,y := polxy(1000, 1 frac 10) '<-- no getqx,getqy in asm ser.printf("sin: %d cos %d\n",x,y) repeatAndy