Spin2

11213141618

Comments

  • Rayman wrote: »
    Will it be safe to use asm block to setup an interrupt inside the spin2 cog?

    Yes, and by using ORG with different addresses, you can load code in different places. You can place code/data from $000..$137.
  • cgraceycgracey Posts: 12,612
    edited 2020-02-13 - 05:09:29
    Ozpropdev,

    I'll see about always outputting the list file. May not be able to get to it tonight, but I'll try.

    Here are the symbols that might show up in a listing:
    TYPE_CON			  Number 0040
    TYPE_CON_FLOAT			  Number 0041
    TYPE_REG			  Number 0042
    TYPE_LOC_BYTE			  Number 0043
    TYPE_LOC_WORD			  Number 0044
    TYPE_LOC_LONG			  Number 0045
    TYPE_VAR_BYTE			  Number 0046
    TYPE_VAR_WORD			  Number 0047
    TYPE_VAR_LONG			  Number 0048
    TYPE_DAT_BYTE			  Number 0049
    TYPE_DAT_WORD			  Number 004A
    TYPE_DAT_LONG			  Number 004B
    TYPE_DAT_LONG_RES		  Number 004C
    TYPE_HUB_BYTE			  Number 004D
    TYPE_HUB_WORD			  Number 004E
    TYPE_HUB_LONG			  Number 004F
    TYPE_OBJ			  Number 0050
    TYPE_OBJPUB			  Number 0051
    TYPE_OBJCON			  Number 0052
    TYPE_OBJCON_FLOAT		  Number 0053
    TYPE_METHOD			  Number 0054
    
  • Okay. I got the string() technique improved so it doesn't require patching and now takes only two bytes of overhead, instead of four bytes. It allowed me to get rid of a lot of stuff in the compiler that was carried over from Spin1.

    There should be no more string trouble. Here is the newest PNut_v34d:

    https://drive.google.com/file/d/1iF73rgf-Gl0pWAFFDDD91uQzOtLgL-d4/view?usp=sharing
  • Ozpropdev,

    Turned out it was pretty easy. Here is PNut_v34e which always saves the list file:

    https://drive.google.com/file/d/1zRWVjAlzfDUXKwKK6I2tGJws8p6AU46N/view?usp=sharing
  • cgraceycgracey Posts: 12,612
    edited 2020-02-13 - 05:35:21
    By the way, you can load and flash programs from the command line with PNut now.

    To run a .spin2 file:
    PNut_v34e vga_text_demo -r
    
    To flash and run a .spin2 file:
    PNut_v34e vga_text_demo -f
    
  • cgracey wrote: »
    Rayman, at this time, inline assembly code needs a RET, which could be a _RET_.

    Maybe I should add a RET after the user's code.

    At the cost of one less instruction for inline code I think that is the safest and it won't preclude users from doing their own RETs wherever they need to. Otherwise missing the RET at the end of an inline block is going to catch people a LOT unless there is a warning generated for it.
  • rogloh wrote: »
    cgracey wrote: »
    Rayman, at this time, inline assembly code needs a RET, which could be a _RET_.

    Maybe I should add a RET after the user's code.

    At the cost of one less instruction for inline code I think that is the safest and it won't preclude users from doing their own RETs wherever they need to. Otherwise missing the RET at the end of an inline block is going to catch people a LOT unless there is a warning generated for it.

    I agree. I'll have the interpreter tack a RET onto the end of the user's PASM code.
  • RaymanRayman Posts: 10,435
    edited 2020-02-13 - 14:42:01
    My vga file compiles and gets through the print fine now.
    But, there's no image on the monitor...

    Seems there's something wrong with the VGA output now.
    I just looked at vsync and hsync on a scope and it looks fine...

    Update: VGA output is back when I disable the cursor drawing...
    I had to do a lot of PASM tricks to get the cursor to work, there's a lot of stuff to go wrong there...

    I have some of these in there:
    CursorJump  call    #\DoCursor1      'need absolute jump here
    

    Should that work?
  • RaymanRayman Posts: 10,435
    edited 2020-02-13 - 14:58:36
    Ok, seems the VGA driver itself is outputting pixels when cursor drawing is disabled.
    But, the cog that builds the scanlines is broke.
    And the shared LUT cog that is supposed to dynamically update LUT colors is also broke...
  • RaymanRayman Posts: 10,435
    edited 2020-02-13 - 15:09:08
    Looks to me like addressing is all messed up...

    Cogs are trying to start at the wrong places and the pointers to arrays are all wrong...

    Here's one symptom:
    My VGA driver cog is attempting to start two other cogs like this:
                coginit   #Scan_Cog,##@ScanlineStart
                coginit   #Color_Cog,##@ColorDriverStart 
    

    But, looks like they are not being started at the right location...

    If I move them into Spin, they appear to start correctly (although still appear to be using bad array pointers).
    So, this at least starts the scanline cog correctly:
    PUB Start(pMousexy):cog 
    
        cog:=VGA_Cog
        coginit(cog,@VGA_Driver, pMousexy)  
        coginit( Scan_Cog,@ScanlineStart, pMousexy)
    
  • RaymanRayman Posts: 10,435
    edited 2020-02-13 - 15:10:55
    My guess is that getting pointers to arrays in the hub like this is not working:
                loc     ptra,#@TileBuffer1
    
  • cgraceycgracey Posts: 12,612
    edited 2020-02-13 - 15:41:50
    > @Rayman said:
    > Looks to me like addressing is all messed up...
    >
    > Cogs are trying to start at the wrong places and the pointers to arrays are all wrong...
    >
    > Here's one symptom:
    > My VGA driver cog is attempting to start two other cogs like this: coginit #Scan_Cog,##@ScanlineStart coginit #Color_Cog,##@ColorDriverStart
    >
    >
    > But, looks like they are not being started at the right location...
    >
    > If I move them into Spin, they appear to start correctly (although still appear to be using bad array pointers).
    > So, this at least starts the scanline cog correctly: PUB Start(pMousexy):cog cog:=VGA_Cog coginit(cog,@VGA_Driver, pMousexy) coginit( Scan_Cog,@ScanlineStart, pMousexy)

    Rayman, because Spin2 builds objects and stacks them together, there is no absolute addressing at compile time.

    You have a few options...

    Spin2 can always resolve absolute addresses at runtime using @symbol. This pointer can be passed to cogs via COGINIT, where it winds up in PTRA.

    Cogs can initially get the hub address of their code in PTRB. A PTRB offset to hub assets can be used to determine their location. See how the VGA and HDTV drivers get the address of their font data.

    In DAT sections, you can make address tables and use @@table[index] to get absolute addresses:

    [code]
    DAT
    table long @asset0, @asset1, @asset2
    asset0 byte "hello",0
    asset1 byte "today",0
    asset2 byte "box",0
    [/code]
  • Ok, I see the issue now.
    Unfortunately, this is a major difference between Spin2 and Fastspin.
    Hopefully, the same code will work for both one day.

    On the bright side, I now see the usefulness of having PTRB loaded with hub address of code.
  • Should I be able to add ptrb to address to get absolute address like this:
    DAT 'VGA_Driver   'vsync and hsync normally low
    orgh
    org 0        
    VGA_Driver
                SETLUTS #1    'Let color cog take care of LUT
                mov       pa,##@ScanlineStart
                add       pa,ptrb
                setq      ptra 'pass mousex pointer to scanline driver
                coginit   #Scan_Cog,pa '##@ScanlineStart
    
  • Rayman wrote: »
    Should I be able to add ptrb to address to get absolute address like this:
    DAT 'VGA_Driver   'vsync and hsync normally low
    orgh
    org 0        
    VGA_Driver
                SETLUTS #1    'Let color cog take care of LUT
                mov       pa,##@ScanlineStart
                add       pa,ptrb
                setq      ptra 'pass mousex pointer to scanline driver
                coginit   #Scan_Cog,pa '##@ScanlineStart
    

    PTRB will be the absolute address from which the program was loaded, or started in the hub.

    If ScanlineStart was declared relative to where the program came from, that would work. That's probably not the case, though.

    You may need to pass the pointer via a Spin2-generated structure pointed to by PTRA. That way, the cog can get any number of addresses that it may need.
  • Rayman, I did not get around to looking at your two files yesterday. I imagine, at this point, your work has moved on to a new point. If you want to send me your current files, I can look at them. Just post them here.
  • It would be a fair amount of work to fix all the pointers.

    I guess I've been spoiled by being able to just do this in FastSpin:
    loc     ptra,#@TileBuffer1
    

    To get the address of an array defined in HUB RAM.
  • I do have a question about another way to send pointers to the assembly driver...

    Before I start the driver, can I change one of the longs in that DAT section to be equal to the pointer?

    Say I have a working long in the driver DAT section like this:
    pArray         long    0
    

    and an array defined elsewhere like this:
    Array       long    0[1000]
    

    Could I do this before starting the driver from inside the Spin start method:
    pArray:=@Array
    

    Does that work?
  • Trying to understand this...

    Is LOC just useless in Spin2?

    If adding ptrb to it doesn't work, I guess I don't see what it's good for...
  • Wuerfel_21Wuerfel_21 Posts: 597
    edited 2020-02-13 - 21:38:35
    Does something like this work?
    org 0
    CogCode
        loc pa,#\(@somewhere-@CogCode)
        add pa,ptrb
    
    ' Imagine code here
    
    somewhere   long 1234
    

    Altough this just uses LOC as a glorified MOV.

    I guess you can still do the usual Spin thing, in which you let Spin figure out the pointers and patch them into the cog code before launching it.
  • Rayman wrote: »
    Trying to understand this...

    Is LOC just useless in Spin2?

    If adding ptrb to it doesn't work, I guess I don't see what it's good for...

    If both the LOC instruction itself and the target address are in HUB memory then "loc pa, #@target" should work without any fixup, since in that case LOC will be PC relative. But if the LOC is in COG or LUT then you'll have to add ptrb to the relative offset of the code base, something like what @Wuerfel_21 suggested above
  • Rayman wrote: »
    I do have a question about another way to send pointers to the assembly driver...

    Before I start the driver, can I change one of the longs in that DAT section to be equal to the pointer?

    Say I have a working long in the driver DAT section like this:
    pArray         long    0
    

    and an array defined elsewhere like this:
    Array       long    0[1000]
    

    Could I do this before starting the driver from inside the Spin start method:
    pArray:=@Array
    

    Does that work?

    Yes, you could certainly do that.
  • RaymanRayman Posts: 10,435
    edited 2020-02-14 - 00:51:50
    Hmm... Or, better yet, maybe I can change the source term in the LOC instructions before launching the cog?

    Looks like I'd need to change the lower 18 bits to the address that I need...

    Actually, this would be great because I could then make code that works for both FastSpin and Spin2 by calling a routine that fixes all the LOC instructions when used with Spin2.
  • I'm curious as to whether whatever magic ersmith uses in FastSpin to get the addresses come out the way they to could be applied to Spin2...

    Is there a fundamental issue that prevents this?
  • > @Rayman said:
    > I'm curious as to whether whatever magic ersmith uses in FastSpin to get the addresses come out the way they to could be applied to Spin2...
    >
    > Is there a fundamental issue that prevents this?

    Spin2 builds objects in a heirarchy, innermost to outermost. They are movable during compilation and even at run time. They only know the offsets to their internal assets. Their base address is a run-time matter which can be gotten using @. Spin2 is probably not going to get compile-time address resolution because it's counter to the whole concept of the implementation.
  • cgracey wrote: »
    > @Rayman said:
    > I'm curious as to whether whatever magic ersmith uses in FastSpin to get the addresses come out the way they to could be applied to Spin2...
    >
    > Is there a fundamental issue that prevents this?

    Spin2 builds objects in a heirarchy, innermost to outermost. They are movable during compilation and even at run time. They only know the offsets to their internal assets. Their base address is a run-time matter which can be gotten using @. Spin2 is probably not going to get compile-time address resolution because it's counter to the whole concept of the implementation.

    Now that is getting interesting. It would allow of dynamic loading modules from SD/Flash/HyperRam to say replace VGA by Scope, Editor by Compiler and back to Editor or other interesting things like overlays...

    Getting absolute HUB addresses was a pain in P1 Spin, thus the triple @ was introduced by other Spin Compilers to solve exactly that issue. Maybe that could be (re)introduced to Spin2 (another compiler pass?) so that the same source code could compile with Spin2 and fastspin.

    Enjoy!

    Mike
  • Chip,
    We found on P1 there were some cases where the absolute hub address was required. That was one of the main drivers for best and homespun and they introduced the 3 x @.

    If a third pass is required if 3 x @ is found, that would be fine.

    While I cannot site the cases, it was a real requirement for some of us with more complex code. I am absolutely certain this will be a requirement for P2 too. Please bite the bullet and include it while these things are fresh in your mind.
  • I tried a bunch to get the triple @ to work in OpenSpin and because of how Chip's compiler worked, it was not really possible without major rewriting of parts of it and how it worked, including adding an additional pass.
    The part that made it extra hard was that it needed to work as part of expressions.

    I recall a couple of threads a long time ago about it with people explaining why it was needed and thinking that they could have just done things differently in the design of their programs to not need it. I've never run into a case where I needed it.
    I think many of the people wanted it just because BST had it, not because they actually really needed it themselves. Only a few people were actually using it for something, I think one was a compiler that produced Spin and then compiled that with BST. Seems like a compiler could be changed to produce Spin that didn't need it.

    Anyway, OpenSpin has been open source since it was released, and none of the people who really wanted triple @ ever bothered to even look at the code or offer help with the feature implementation.
  • Roy ElthamRoy Eltham Posts: 2,788
    edited 2020-02-15 - 02:49:18
    Short version,
    I don't think Chip needs to put triple @ in Spin2. If you really need it and want it, help add it. Or just use FastSpin if it gives you what you need.

    (edit, he hasn't shared the compiler source, but I hope he does, so you all can see how it works and it's not like you think it does)
  • RaymanRayman Posts: 10,435
    edited 2020-02-15 - 02:45:25
    I find that the way it works currently in FastSpin is very convenient. I think it took Eric a few days to get it the way it is now...
    If it can't or won't be made to work that way in Spin2, that's OK, but just adds some extra work for the programmer...
Sign In or Register to comment.