Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 14 — Parallax Forums

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

11112141617115

Comments

  • evanh wrote: »
    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:
    --- 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:
     loc  pa, #label testing
    =========================
       PC    Op-code  PA-data Cog-dref Hub-dref
    0000000e fe9ffffb 00000008 0badf00d 00000000
    00000010 fe900101 00000110 fda00257 deadbeef
    00000012 fe80047c 0000047c 00000000 cafef00d
    
    which at least gets the PA-data right in all 3 cases.

    Thanks for your bug report!

    Eric

  • evanh wrote: »
    I've just had a nosy at the Fastspin sources looking for encoding details of LOC instruction. One thing that looked mismatched is in frontends/lexer.c
      // long jumps
        { "jmp" ,   0x0d800000, P2_JUMP, OPC_JUMP, 0 },
        { "call",   0x0da00000, P2_JUMP, OPC_GENERIC_BRANCH, 0 },
        { "calla",  0x0dc00000, P2_JUMP, OPC_CALL, 0 },
        { "callb",  0x0de00000, P2_JUMP, OPC_GENERIC_BRANCH, 0 },
    
    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)
  • evanhevanh Posts: 15,091
    edited 2019-04-11 13:25
    Thanks for the explanation.

    which at least gets the PA-data right in all 3 cases.
    Good stuff. Looks perfect. I'll go grab the update ... confirmed same good results for me. Thanks.
  • evanhevanh Posts: 15,091
    edited 2019-04-11 13:56
    ersmith wrote: »
    With this change your test program produces:
     loc  pa, #label testing
    =========================
       PC    Op-code  PA-data Cog-dref Hub-dref
    0000000e fe9ffffb 00000008 0badf00d 00000000
    00000010 fe900101 00000110 fda00257 deadbeef
    00000012 fe80047c 0000047c 00000000 cafef00d
    
    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.
  • RaymanRayman Posts: 13,767
    Should this work?
    #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

  • Rayman wrote: »
    Should this work?
    #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.

    Thanks,
    Eric
  • RaymanRayman Posts: 13,767
    of course, thanks. I rarely use #define, so didn't think of that...
  • 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.
  • RaymanRayman Posts: 13,767
    edited 2019-04-15 00:34
    jmp with no # has bitten me a few times in the past...
    I'd make it always give a warning, personally...

    Maybe you can have a command line warning option to override.. Like "-W2" or something...
  • Cluso99Cluso99 Posts: 18,066
    Been bitten by missing # a number of times before bst.

    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.
  • jef_vtjef_vt Posts: 23
    edited 2019-04-17 19:33
    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.
  • @jef_vt:

    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.
  • ersmith wrote: »
    @jef_vt:

    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.
  • evanhevanh Posts: 15,091
    ... after 2048 bytes ...
    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!
  • Cluso99Cluso99 Posts: 18,066
    @Eric/Dave,
    Is there a built loadp2.exe windows version somewhere for download?
  • Loadp2.exe is in the Bin directory of Spin2gui (along with fastspin.exe and proploader.exe)
  • Cluso99Cluso99 Posts: 18,066
    Tubular wrote: »
    Loadp2.exe is in the Bin directory of Spin2gui (along with fastspin.exe and proploader.exe)

    No \bin directory in the spin2gui download :(
    https://github.com/totalspectrum/spin2gui/releases
  • It's in the spin2gui.zip file, see attachment.
    693 x 497 - 76K
  • Cluso99Cluso99 Posts: 18,066
    edited 2019-04-24 07:15
    whicker wrote: »
    It's in the spin2gui.zip file, see attachment.
    Not in mine that I just downloaded today :(

    Ok its in the previous zip, but not the one before that. Thanks
  • 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
  • Cluso99 wrote: »
    whicker wrote: »
    It's in the spin2gui.zip file, see attachment.
    Not in mine that I just downloaded today :(

    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.
  • tritonium wrote: »
    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.
  • Win 10 also complains when installing I need to click 'run anyway'.

    But this is a 'normal' windows behavior if you use other then MS compilers.

    Enjoy!

    Mike
  • RaymanRayman Posts: 13,767
    edited 2019-04-26 14:09
    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?
  • Rayman wrote: »
    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).
  • RaymanRayman Posts: 13,767
    edited 2019-04-26 17:39
    Do you have an example where a Spin2 file (Spin, not PASM) includes an assembly driver from another file?

    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...
  • Rayman wrote: »
    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.
  • RaymanRayman Posts: 13,767
    If you do this with "OBJ", then you must need some kind of Spin "Start" function to start the assembly cog, right?

    Sounds like you're saying to just do it the same way as with P1...
Sign In or Register to comment.