fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

15253545557

Comments

  • Cluso99Cluso99 Posts: 16,263
    edited 2020-06-04 - 23:08:45
    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.
  • ersmith wrote: »
    @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.
  • Cluso99Cluso99 Posts: 16,263
    edited 2020-06-05 - 07:54:22
    Just noticed this jmp ## error was not being reported, and resulted in something wrong
    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 here
    
    When corrected
    004b4     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 here
    
    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.
  • Cluso99 wrote: »
    ... 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.

  • evanh wrote: »
    Cluso99 wrote: »
    ... 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.
  • Thanks Eric.
    Was this the cause of the misalignment when alignl was executed?
  • Obviously it won't happen if the assembler doesn't generate the binary. Cluso, I'm presuming you don't have another way to get these outcomes.

  • 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 :sunglasses:
  • 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.
    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 pin
    
  • 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
  • evanhevanh Posts: 9,642
    edited 2020-06-05 - 23:25:28
    Cluso,
    Update your Fastspin. My comment only applies to that.

  • Here's a beta version of fastspin with all the various bug fixes.
  • Cluso99Cluso99 Posts: 16,263
    edited 2020-06-05 - 23:43:07
    evanh wrote: »
    Cluso,
    Update your Fastspin. My comment only applies to that.
    Uh??? I am using the latest 4.2.0
  • Cluso99Cluso99 Posts: 16,263
    edited 2020-06-05 - 23:42:41
    ersmith wrote: »
    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.

    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 :)
  • Come on Cluso. You know that's not the latest.
  • evanh wrote: »
    Come on Cluso. You know that's not the latest.

    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.

  • JRoarkJRoark Posts: 438
    edited 2020-06-06 - 18:24:16
    @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 
    
  • JRoark wrote: »
    @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)?

    Thanks,
    Eric
  • @ersmith Deleting the .flexgui.config seems to have fixed the issue completely. (I didn't intend to delete it, but Windows had other ideas).

    And nope, none of the files anywhere on that drive have any funky characters.

    So we're back in business. Thanks, Eric!
  • JRoarkJRoark Posts: 438
    edited 2020-06-07 - 03:10:56
    @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
    

    So... FlexBASIC doesn't like “capitalism”! :)
  • @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...
  • Rayman wrote: »
    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...
  • Eric

    Whein I try to use the getrnd() function, I always get this error in fastspin:
    "error: unknown identifier getrnd used in function call"

    Andy
  • 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.
  • Thank's Eric
    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)
      repeat
    
    Andy
  • 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?
Sign In or Register to comment.