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

12324262829

Comments

  • Works for me. I stuck this in the middle of my current cogexec code:
    con
    	LOCTEST1	= $40000	'256 kB
    	LOCTEST2	= $50000+$3000
    
    dat
    		...
    		call	#putsp
    		loc	pa, #$4000
    		call	#itoh
    		call	#putsp
    		loc	pa, #$40
    		call	#itoh
    		call	#putsp
    		loc	pa, #LOCTEST1
    		call	#itoh
    		call	#putsp
    		loc	pa, #LOCTEST2
    		call	#itoh
    		call	#putnl
    		...
    
    and the terminal reports
       00004000   00000040   00040000   00053000
    
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • printf beats a debugger any day. :D
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Does your code include Spin?
    Prop Info and Apps: http://www.rayslogic.com/
  • Oh, nope, don't really know the language.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • I think I have confirmed this "bug" (or feature) by moving the code from hubexec to the cog. In the cog, it works with or without the backslash.
    But, in hubexec, the backslash is required.

    Note: This is for Spin+ASM. It was all working in pure ASM...
    Prop Info and Apps: http://www.rayslogic.com/
  • Doh! I see now it's hubexec with the issue too, so double fail for me.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Cluso99Cluso99 Posts: 15,410
    edited 2019-09-21 - 14:44:11
    Eric,
    I have written an Asm object that will run in its own cog. It’s an SD Driver and communicates via a hub mailbox.
    To test it I have another asm file. It starts the above file with coginit. There is no spin in either - they are straight P2 assembly.

    I have two problems.
    First I cannot include the second file as an object...
    OBJ
    sd: “file2.spin2”
    Second, I cannot reference the entry address in this object.

    I had to place this file at the end after an
    ORGH $2000
    so I could use a fixed address to start it with
    COGINIT #%01_0000,
    and include the following in the calling file...
    xyz long $2000
    This was the only way I could get the coginit address.

    And, the compiler did not include the file in the binary output.

    I have had to resort to making one big file.

    The P1 spin conversion to P2 asm is a separate issue. I am trying to convert Kyes spin P1 SD FAT driver to P2 asm. My asm Driver above will replace the asm section of Kyes driver.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Eric,
    I have written an Asm object that will run in its own cog. It’s an SD Driver and communicates via a hub mailbox.
    To test it I have another asm file. It starts the above file with coginit. There is no spin in either - they are straight P2 assembly.

    First I cannot include the second file as an object...
    OBJ
    sd: “file2.spin2”

    Ah, I think I see where you're coming from. But OBJ is a Spin language feature, not PASM, so it's not going to work with pure PASM code. This isn't just a fastspin restriction, it's the same in original Spin too.
    Second, I cannot reference the entry address in this object.
    Probably you'll want to use #include to include the source file, something like:
    file2_start
    #include "file2.spin2"
    

    Now the label @file2_start will refer to the start of the file2.spin2 code.
    The P1 spin conversion to P2 asm is a separate issue. I am trying to convert Kyes spin P1 SD FAT driver to P2 asm. My asm Driver above will replace the asm section of Kyes driver.

    You can keep the Spin code as Spin, and just replace the assembly code. In fact you could even keep the assembly code and #ifdef it so that it can be compiled for P1 or for P2.

  • Rayman wrote: »
    I think I have confirmed this "bug" (or feature) by moving the code from hubexec to the cog. In the cog, it works with or without the backslash.
    But, in hubexec, the backslash is required.

    Note: This is for Spin+ASM. It was all working in pure ASM...

    In the next release of fastspin the loc should work without slash. I've just given up and in mixed Spin + PASM all constant references in LOC will be absolute. References to labels will still be relative, and references in pure PASM will still be relative, it'll only be in mixed code that the rules will be a little different. This should be transparent to the programmer.
  • Thanks. I’m just being greedy here and using loc to save an instruction...

    I suppose you could also make loc to a constant illegal...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Thanks. I’m just being greedy here and using loc to save an instruction...

    I suppose you could also make loc to a constant illegal...

    A constant for loc is perfectly legal, as long as the constant fits in 20 bits. There is a case to be made that you should always use "\" with a constant, because otherwise the code will be position dependent, but for programs that don't move code around it shouldn't matter. In some sense Spin objects are always potentially moved, so loc in Spin objects should use "\" for constants. As I mentioned, that will happen automatically in the final version of fastspin 3.9.32 (so if you leave the "\" off it'll still be absolute with a constant, just as it would when referring to HUB variables from COG and vice-versa).


  • Thanks for your help Eric.
    I’ll try include. This should be easier than OBJ anyways.

    BTW we did use objects with PASM, just that they were always wrapped with spin. And we didn’t have include in proptool although we did in best and homespun.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • ersmithersmith Posts: 3,423
    edited 2019-09-21 - 22:01:02
    Cluso99 wrote: »
    Thanks for your help Eric.
    I’ll try include. This should be easier than OBJ anyways.

    BTW we did use objects with PASM, just that they were always wrapped with spin. And we didn’t have include in proptool although we did in best and homespun.

    I don't think it's ever been possible to refer to an object from PASM though. Having PASM inside of objects is fine (and will work in fastspin) but to actually use the objects you need to write some Spin code. Or am I missing something?
  • I've posted new versions of fastspin and the GUI for it. That gui is now called "FlexGUI" instead of "spin2gui" to better reflect the multi-language nature of it.

    The current versions of both are 3.9.32, and they are available at:

    https://www.patreon.com/totalspectrum
    https://www.github.com/totalspectrum/flexgui/releases
    https://www.github.com/totalspectrum/spin2cpp/releases

    The "flexgui.zip" file contains everything you'll need for development on Windows, including fastspin.

    This new release supports the new silicon via a "-2b" flag. The old silicon is still available as "-2a". Just plain "-2" selects the most common P2 variant, which is still "2a" but eventually will become "2b". FlexGUI has a button to switch between these.

    Other changes are some more editor configuration options in FlexGUI, better handling of loc and jmps in PASM within Spin objects, and some C library fixes.
  • ersmith wrote: »
    Cluso99 wrote: »
    Thanks for your help Eric.
    I’ll try include. This should be easier than OBJ anyways.

    BTW we did use objects with PASM, just that they were always wrapped with spin. And we didn’t have include in proptool although we did in best and homespun.

    I don't think it's ever been possible to refer to an object from PASM though. Having PASM inside of objects is fine (and will work in fastspin) but to actually use the objects you need to write some Spin code. Or am I missing something?

    Yes, you're missing something here ;)
    The pasm in my case is a complete object that gets loaded into another cog. The interface is via a 4 long mailbox, used as a command + parameters and a status reply in response. So there is no interaction between objects except via the mailbox. When the COGINIT is launched, it is preceeded by a SETQ mailbox that passes the address of the mailbox into PTRA of the started cog. Works easy, save for the include :)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 15,410
    edited 2019-09-21 - 23:11:45
    Include syntax...

    Found it :)
    DAT
                    org     0                        
                    .....
                    SETQ    ptrmailbox                      ' set to pass addr of hub mailbox
                    COGINIT #%01_0000,      sd_run          ' start the SD Driver Cog
                    .....
    sd_run        long    @sd_entry       ' hub start address to load/run the SD Driver code
    
    DAT
                    orgh
                    org     0                        
    #include "SD202a.spin"
    

    This is currently how I am getting the start entry point hub address and starting the cog passing the hub address of the mailbox into PTRA of the called cog.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    ersmith wrote: »
    Cluso99 wrote: »
    Thanks for your help Eric.
    I’ll try include. This should be easier than OBJ anyways.

    BTW we did use objects with PASM, just that they were always wrapped with spin. And we didn’t have include in proptool although we did in best and homespun.

    I don't think it's ever been possible to refer to an object from PASM though. Having PASM inside of objects is fine (and will work in fastspin) but to actually use the objects you need to write some Spin code. Or am I missing something?

    Yes, you're missing something here ;)
    The pasm in my case is a complete object that gets loaded into another cog. The interface is via a 4 long mailbox, used as a command + parameters and a status reply in response. So there is no interaction between objects except via the mailbox.
    Ah, I see. Yes, that's a good way to use objects from PASM. You'll still need some Spin to set the objects up though. Is there some way in regular Spin for PASM code to get the address of an object? As far as I can see it would have to be passed to the PASM code from some Spin initialization code.
  • I just tried 3.9.32 and it seems to not work for me... The version you posted here worked except for that LOC in hubexec…

    Is there something I need to change in my code for this version to work?
    Prop Info and Apps: http://www.rayslogic.com/
  • Sorry, something is really wrong with this new fastspin…
    My old pure ASM version of this code doesn't work with it either...

    The attached was working perfectly in pure ASM with the two Spin lines commented out.
    With the Spin in, it almost worked, except for something just a bit wrong with the very top graphics line...

    Graphics are all messed up. I think it might be getting the offset to the palette wrong...
    Looks like it might be an issue with the palette anyway...

    Serial output looks right, so the code is running...
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,716
    edited 2019-09-22 - 00:23:17
    Just a guess, but I think it's getting this address to palette info wrong somehow:
    rdfast  #0,##@BmpAddressBackground-$400+$436    'load .bmp palette into lut
    

    This is how that bitmap is specified:
    DAT' Graphics Resources bitmapBitmap
    
    '
    BmpAddressBackground        
            'orgh    BmpAddressBackground - $436    'justify pixels at $1000, pallete at $1000-$400
            file    "bgr_combopal2.bmp"   '640 x 100, 8pbb-lut  '65,080 bytes, 64,000 for data, $438 for other
    
    Prop Info and Apps: http://www.rayslogic.com/
  • Cluso99Cluso99 Posts: 15,410
    edited 2019-09-22 - 09:37:05
    Eric,
    I have found a problem. Attached is the source together with listings for fastspin 3.9.31 & 3.9.32
    The listing so not match due to incorrect relative jmp forward compilation.
    3.9.31 is definately wrong.

    The jmp #@_fail at $19C 067 is an example. Currently not sure about 3.9.32 yet.
    Spent days trying to get this working with weird results. Now I know why :(

    Anyone have the link to the definitive use of @ and \ ?
    There is no definitive answer in Chips reference for cog to cog in cog for the #@. Without @ it will use relative and with #\ it will use absolute.

    Meanwhile off to try 3.9.32 :)

    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Rayman wrote: »
    Sorry, something is really wrong with this new fastspin…
    My old pure ASM version of this code doesn't work with it either...

    Yes, there's a bug in the encoding of the rdlut and wrlut instructions :(. It'll actually work correctly if you tell it to compile for the rev 2b silicon (give it the "-2b" flag instead of "-2" or "-2a"). I changed rdlut and wrlut to handle the new PTRA++ addressing modes for the new silicon, but in the process managed to break encoding of the original silicon (it's just a silly typo in the source code, but it's enough to get a bit wrong in the output).

    Code compiled for "-2b" will actually work fine on your original 2a silicon as long as you're not using any of the new features.

  • Cluso99 wrote: »
    Eric,
    I have found a problem. Attached is the source together with listings for fastspin 3.9.31 & 3.9.32
    The listing so not match due to incorrect relative jmp forward compilation.
    3.9.31 is definately wrong.

    The jmp #@_fail at $19C 067 is an example. Currently not sure about 3.9.32 yet.
    Spent days trying to get this working with weird results. Now I know why :(
    I think this is a bug in your code... the label _fail is located at hub address $238, so I don't think you can run code from there in hubexec mode. Which by definition a "jmp #@_fail" is doing ("@" says to always use the HUB address).
    Anyone have the link to the definitive use of @ and \ ?
    There is no definitive answer in Chips reference for cog to cog in cog for the #@. Without @ it will use relative and with #\ it will use absolute.
    By definition anything involving @ is a HUB access, not cog to cog.

    "@" says to use the HUB address of the following label
    "\" says to use absolute rather than relative addressing

  • Cluso99Cluso99 Posts: 15,410
    edited 2019-09-22 - 11:53:14
    ersmith wrote: »
    Cluso99 wrote: »
    Eric,
    I have found a problem. Attached is the source together with listings for fastspin 3.9.31 & 3.9.32
    The listing so not match due to incorrect relative jmp forward compilation.
    3.9.31 is definately wrong.

    The jmp #@_fail at $19C 067 is an example. Currently not sure about 3.9.32 yet.
    Spent days trying to get this working with weird results. Now I know why :(
    I think this is a bug in your code... the label _fail is located at hub address $238, so I don't think you can run code from there in hubexec mode. Which by definition a "jmp #@_fail" is doing ("@" says to always use the HUB address).
    Anyone have the link to the definitive use of @ and \ ?
    There is no definitive answer in Chips reference for cog to cog in cog for the #@. Without @ it will use relative and with #\ it will use absolute.
    By definition anything involving @ is a HUB access, not cog to cog.

    "@" says to use the HUB address of the following label
    "\" says to use absolute rather than relative addressing
    Chips latest reference definitely says @ is usable in cog to cog jumps. Page 21. I don’t have it to hand.

    I did remove all the @ and the code still doesn’t get past go so I still think there’s a problem but it’s too late for me to test and likely no time for a few days :(

    I was trying to debug two cogs communicating via hub, and they were each variously going off the rails. In the end I counted the nesting levels thinking there was a stack issue. I ended up separating them and trying to debug one of them when I struck the problem. The JMP #@_fail just before the .command8 label has a relative offset of IIRC 470 where the actual offset would have only been around 200 if the compiler was treating both as hub so I think something is still amiss.

    We desperately need to sort this addressing mess out. The source should be able to be compiled for either cog or hub by a simple org statement. It would be nicer if the same compiled code could run in either but I’m not sure how relative works between the two modes. Is the relative bytes or longs.

    Please don’t take this the wrong way Eric. You’re done a fantastic job!!!
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99 wrote: »
    Chips latest reference definitely says @ is usable in cog to cog jumps. Page 21. I don’t have it to hand.
    I think there's some misunderstanding there. @ means "use the hub value of the label". Now, theoretically, if you compile some code in orgh that's using @ and relative jumps, and then load it into COG, then the jumps should still work, so in that sense it "works" for cog to cog jumps. But @ definitely means "this is a hub address", so using it when you're intending that the code run in a COG is something that needs a really hard look.

    "\" on the other hand means "use absolute addressing no matter what". Without it the assembler will try to use relative addressing if it can (for jumps that stay inside the same space -- COG, LUT, or HUB).
    We desperately need to sort this addressing mess out. The source should be able to be compiled for either cog or hub by a simple org statement. It would be nicer if the same compiled code could run in either but I’m not sure how relative works between the two modes. Is the relative bytes or longs.

    The rules for addressing are a little complicated, but I think they're clear:

    (1) Labels have two values, a hub address (where the code is physically loaded by the loader into HUB memory at boot time) and a default address. The default address may be the same as the hub address (for code after orgh) or may be different (for code after org).

    (2) Putting "@" in front of a label says to use its hub address. Otherwise its default address (the one established by org, if any) is used.

    (3) If you put a "\" after the immediate symbol in a jmp or loc instruction, you're requesting that absolute addressing be used. This overrides any other consideration for relative vs. absolute addressing.

    (4) If there is no "\", then the choice of relative vs absolute addressing is:
    - if both addresses are in COG (between $0 and $1ff inclusive), use relative
    - if both addresses are in LUT (between $200 and $3ff inclusive) use relative
    - if both addresses are in HUB (above $400) use relative
    - otherwise use absolute (as if "\" had been specified)

    The only ambiguity I can think of is for the case where you try to jump to a HUB address below $400, for example by specifying @ on such a label or if it comes after an orgh without an org. In that case the various assemblers may differ in what they do -- some may treat it as a COG/LUT address, some may notice that it's really HUB and try to use that, etc. The hardware will always treat absolute jumps to below $400 as being into COG or LUT memory. So it's probably a very bad idea to try to hubexec code below $400. Maybe, possibly, a relative jump could be made to hub code in that space (@cgracey, please correct me if I'm wrong). But there are so many potential problems that I would *strongly* recommend not doing this. For example, if code that's in HUB below $400 does a subroutine call, any RET will end up jumping into COG/LUT rather than back to HUB.

  • A bug is just a bug. Where's the mess?
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • ersmith: Yes, it does appear to work with "-2b" option... I'll check on the loc soon...
    Prop Info and Apps: http://www.rayslogic.com/
  • Cluso99Cluso99 Posts: 15,410
    edited 2019-09-22 - 13:16:36
    Code cannot run in hub below $400 from what Chip has said.

    If your definitions are correct, then Chip needs to change his document as it disagrees.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Eric isn't saying it would work under any circumstance, just that an attempt to code it in source would likely produce differing machine code from the different assemblers.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • RaymanRayman Posts: 9,716
    edited 2019-09-22 - 15:51:50
    USB doesn't seem to work with the new fastspin either...

    I'm working with the "test.spin2" I think ersmith posted here earlier...
    It could be the serial coms that are broke, not sure...

    Nope, doesn't appear to be just the serial coms. I rigged it to toggle P56 led on keypress and it doesn't do it with new fastspin...
    Prop Info and Apps: http://www.rayslogic.com/
Sign In or Register to comment.