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

1222325272869

Comments

  • I'll check to make sure I factored in the offset to BMP data. Maybe that is the problem...
  • Ooops. False alarm, sorry. Seems I copied from the original source instead of the source with the fixed offsets to bmp data...
  • Ok, it's all working now. Whew...

    Only thing I see now is that the FPS is 30% slower now that as objects instead of all in one file with cogs started by assembly instead of spin.

    Any reason this could be?
  • RaymanRayman Posts: 11,359
    edited 2019-09-18 - 21:04:44
    Never mind again, sorry. Figured it out... I had added a delay in the serial routine that was holding things up...

    The serial cog is just for debugging, but the way it is now, the graphics cog waits for the serial cog to process before continuing...
    I had added a delay in the serial cog when trying to figure out the previous issue and forgot to remove it.
  • msrobotsmsrobots Posts: 3,250
    edited 2019-09-19 - 03:34:31
    LOC should be called LEA

    68000 assembler had cute opcode names anyway

    ANDI, PFLUSH, ILLEGAL I actually like BRA more then jmp :smile:

    ABCD is also nice, FATAN also...

    Mike
  • BCF = Branch and Catch Fire
    I think Samsung implemented this one in a recent phone ;)
  • Cluso99 wrote: »
    BCF = Branch and Catch Fire
    I think Samsung implemented this one in a recent phone ;)


    You might be thinking of the MC6802 with HCF = Halt and Catch Fire
    Also known as Drop Dead because it is encoded as 0xDD

    https://en.wikipedia.org/wiki/Halt_and_Catch_Fire

    Maybe they shouldn't have built a MC6802 feature into the Note 7 :-D
  • whickerwhicker Posts: 650
    edited 2019-09-19 - 05:08:22
    Does LOC have any syntax to distinguish between load the value, and add the value to PC (PC relative)?

    If not, shouldn't it be two distinct instructions?

    Edit:
    let's look at disassembly. Would the slash have to be printed next to the constant to say it's direct addressing? So then you use ## and it's now a compound instruction. But since that is printed prior to LOC you'd always have to be looking ahead for it specifically.

    So yeah, why wouldn't LOC just be the PC relative, and LEA just be the load direct?
  • evanhevanh Posts: 9,964
    edited 2019-09-19 - 06:29:54
    The LOC worked correctly for Rayman. It wasn't the issue.

    ## won't work on LOC just like it won't work on long branching either. Interestingly, Pnut gets a typical cryptic error but Fastspin just nose dives into bad code generation that crashes.
  • OK, that clears that part up.
    But at the same time, again how would a LOC that's PC relative and a LOC that's absolute be shown in a disassembly without symbolic labels?
    It still feels like it would need two different opcodes.
  • whicker wrote: »
    OK, that clears that part up.
    But at the same time, again how would a LOC that's PC relative and a LOC that's absolute be shown in a disassembly without symbolic labels?
    It still feels like it would need two different opcodes.
    It's no different to the immediate "#" operand prefix
  • The PC-relative encoding just means relative from the following instruction. Don't even need to know where in memory you are to know where it points within the disassembled file.
  • Eric,

    I have these spin objects that I want to compile for P2 ASM. How do I do it?

    I tried fastspin filename -2 -l --fcache=0 but it deletes the unused PUBs and hence most PRIs too.
    So I tried the -O0 option without success.
    It compiles but there isn't much output :(
  • RaymanRayman Posts: 11,359
    edited 2019-09-19 - 10:16:16
    LOC worked after I added the backslash.
    But, now it is fixed, so I don't need the backslash.

    Still, another way might have been to always use the backslash.
  • Rayman wrote: »
    LOC worked after I added the backslash.
    But, now it is fixed, so I don't need the backslash.
    You're not talking about recently adding the backslash are you? It's been a while since the assemblers were messing that up.
  • Rayman wrote: »
    Never mind again, sorry. Figured it out... I had added a delay in the serial routine that was holding things up...

    The serial cog is just for debugging, but the way it is now, the graphics cog waits for the serial cog to process before continuing...
    I had added a delay in the serial cog when trying to figure out the previous issue and forgot to remove it.

    Glad you got it sorted out. Thanks for your help debugging this!
  • Cluso99 wrote: »
    Eric,

    I have these spin objects that I want to compile for P2 ASM. How do I do it?

    I tried fastspin filename -2 -l --fcache=0 but it deletes the unused PUBs and hence most PRIs too.
    So I tried the -O0 option without success.
    It compiles but there isn't much output :(

    I'm not sure exactly what you're trying to do here... do you want fastspin to just translate from Spin to PASM but not compile the code to binary? If so then there are a few options; which one is best probably depends on what you're trying to achieve.

    In general for translating between source languages (Spin/BASIC/C to PASM or C) use the spin2cpp frontend instead of fastspin. For example to just look at how fastspin/spin2cpp is translating some Spin to PASM I usually use:
      spin2cpp --p2 --asm foo.spin
    
    which produces the "foo.p2asm" assembly file. You can also add "--code=hub" to force hubexec code, although for P2 this makes very little difference.

    For the somewhat niche case of automatically producing a COG object from some Spin code you can use the "-w" option to fastspin to convert the Spin to PASM with wrappers around it. That option doesn't get used much so it may have some rough edges.
  • Cluso99Cluso99 Posts: 16,663
    edited 2019-09-19 - 12:02:16
    Thanks Eric. I just want to get some spin files converted to p2asm so i'll give spin2cpp a try :)
    Just looking for spin2cpp?
  • Thanks Eric. I now have a big p2asm file to look thru ;)
  • evanh wrote: »
    You're not talking about recently adding the backslash are you? It's been a while since the assemblers were messing that up.

    There was a recent issue identified when using Spin to start assembly with hubexec.
    ersmith fixed it and posted a new fastspin.exe in this thread.

    If you look at garryj's USB code for Spin, you can see how he needed to use the backslash in his hubexec code.

  • That's not answering my question.
  • Cluso99Cluso99 Posts: 16,663
    edited 2019-09-20 - 13:37:07
    Eric,
    I just used this trick (works) with fastspin :)
      sd_tristate   = $F << ((sd_do > 31) ? (sd_do-32) : (sd_do)) 'WARNING: presumes contiguous and DO lowest!
      dirab         = ((sd_do > 31) ? ($1FB) : ($1FA))            'select DIRB or DIRA register
    
                    andn    dirab,            ##sd_tristate ' tristate CS/CK/DI/DO
    
    Do you know of an easier way?
    BTW I still need to check if the pins are sequential (later)

    And of course the new silicon can handle this.

    How do I force a compile error?
      _sequence1     = ((sd_ck > sd_cs > sd_di > sd_do) ? 0 : (?)) ' force an error if not in sequence
      _sequence2     = ((sd_ck == (sd_do+3)) ? 0 : (?))            ' force an error if not sequential
    
  • Cluso99 wrote: »
    Eric,
    I just used this trick (works) with fastspin :)
      sd_tristate   = $F << ((sd_do > 31) ? (sd_do-32) : (sd_do)) 'WARNING: presumes contiguous and DO lowest!
      dirab         = ((sd_do > 31) ? ($1FB) : ($1FA))            'select DIRB or DIRA register
    
                    andn    dirab,            ##sd_tristate ' tristate CS/CK/DI/DO
    
    Do you know of an easier way?
    BTW I still need to check if the pins are sequential (later)

    And of course the new silicon can handle this.

    For PASM that seems like a reasonable way to do it. For Spin I would just use:
    PUB tristate1
      if sd_do > 31
        dirb &= !(1<<(sd_do - 32))
      else
        dira &= !(1<<sd_do)
    
    which, if sd_do is constant, will end up generating the same code, something like (for sd_do == 35):
    _tristate1
            andn    dirb, #8
    _tristate1_ret
            reta
    
  • This works. Just need to force a compile error.
      _sequential   = (((sd_ck==(sd_do+3))&(sd_ck==(sd_di+2))&(sd_ck==(sd_cs+1))) ? 0 : 1)
    
  • Instead of forcing a compile error, can't you just make the interface such that only the DO pin is specified explicitly and the other three are calculated from that?
  • Eric,
    I seem to have hit a wall with including spin objects (a pasm file).

    How do I get the hub starting address so that I can load the program with COGINIT?

    Of course I went around a loop because I used the same names so I was just restarting my own cog :(
  • Eric,
    Also including an object at the end of the program - fastspin ignores the code and compiles without warning.
  • Cluso99 wrote: »
    Eric,
    I seem to have hit a wall with including spin objects (a pasm file).

    How do I get the hub starting address so that I can load the program with COGINIT?

    Of course I went around a loop because I used the same names so I was just restarting my own cog :(

    The usual way is:
    DAT
        org 0
    entry
       ...
    PUB start
       cognew(@entry, args)
    
    But I know you know that, so I guess you're trying to do something different. Could you explain what you're after? Does "@" not work somehow for your use case?
  • Cluso99 wrote: »
    Eric,
    Also including an object at the end of the program - fastspin ignores the code and compiles without warning.

    Is the object used? If not, it's just being removed as unused code.

    I don't understand your overall objective. Are you trying to convert some Spin code to PASM and then hoping to re-use that PASM? If so, may I ask why? The original Spin code would be easier to maintain.
  • RaymanRayman Posts: 11,359
    edited 2019-09-21 - 12:44:44
    So, I thought the latest fastspin posted here fixed my loc with hubexec issue, but it seems not...

    I guess the problem with getting addresses to embedded DAT objects is fixed, but using LOC to load a constant hub address doesn't work the same way in cog exec as it does in hubexec…

    Here's the hubexec code that has the issue:
    DAT   'Fillbottom             
    FillBottom  'RJA:  just the bottom now that floorcasting is working 
                    loc     ptrb,#OffscreenBufferAddress 'image buffer  
                    'loc     ptrb,#\OffscreenBufferAddress 'image buffer
    

    OffscreenBufferAddress is just a fixed location defined like this:
    CON 'graphics constants 
        OffscreenBufferAddress=$40000   '320x240 =$12C00
        DisplayBufferAddress=$50000+$3000 'size is 320x240=$12C00 (was 640x480=$4B0000)
    

    Using either the backslash or "##" fixes it. But, it seems to not need this in cog exec code...
Sign In or Register to comment.