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.
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.
@Cluso99 : Thanks. There's something funny going on with line numbers after #include inside DAT.
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 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 here
and 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 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:
function sumif(a, x, y)
sumif = x + y
if (a <> 0)
exit function
sumif = 0
end function
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) 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 function
@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:
OPTION explicit '<--- no problemo
dim a as long
for a = 1 to 10
print a
next a
This throws an error:
OPTION EXPLICIT ' <--- breaks if "explicit" is in caps
dim a as long
for a = 1 to 10
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 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 2020
@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. 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.
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. 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.
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.
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.
What you're probably looking for is to do something like: which is the sequence Chip suggested for making sure the orgh goes to at least $400
Update 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: 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 -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)?
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:
This throws an error:
And here is the complier output:
So... 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