PNut/Spin2 Latest Version (v34s)

13468919

Comments

  • Seems that could be useful for debugging with breakpoints...
    Maybe adding a breakpoint would cause the PropTool to swap out that method with one that includes something that happens at the breakpoint...
  • Will spin2 allow "#include" type includes?

    I think this is very useful when code starts to get big...

    My main GUI .spin file was over 3000 lines long, so I decided to make use of FastSpin's "#include" feature...
  • Rayman wrote: »
    Will spin2 allow "#include" type includes?

    I think this is very useful when code starts to get big...

    My main GUI .spin file was over 3000 lines long, so I decided to make use of FastSpin's "#include" feature...

    Does #include just insert the file, verbatim?
  • Yes
  • Yes. It's not always great if what you're including also includes any of the same files.

    Makes me wish there was an #include_once
    Or a #pragma once.

    So if you're going to add #include, please add the other #define and #ifdef Preprocessor stuff as well.

    https://github.com/parallaxinc/OpenSpin/wiki/Preprocessor
  • Yeah, if you add #include, you really need #define & #ifdef/#endif to go with it as a minimum.
  • Well, #include sounds easy and the other sounds hard...

    Anyway, wouldn't an assignment in a CON section be the same as a #define?
  • By that logic, #include_once doesn't sound too hard either. Store the filenames, the length of the file, and the hash/crc of the contents in the file. If they're all equal, don't include it again.
  • whicker wrote: »
    By that logic, #include_once doesn't sound too hard either. Store the filenames, the length of the file, and the hash/crc of the contents in the file. If they're all equal, don't include it again.

    How could the length and hash possibly differ if they're the same file? Isn't there any way on Windows to tell if two different paths are the same file, even if there are symlinks or shortcuts or junctions complicating things?
  • #include is the best way to handle automatically generated skip patterns, I think.
  • whicker wrote: »
    By that logic, #include_once doesn't sound too hard either. Store the filenames, the length of the file, and the hash/crc of the contents in the file. If they're all equal, don't include it again.

    How could the length and hash possibly differ if they're the same file? Isn't there any way on Windows to tell if two different paths are the same file, even if there are symlinks or shortcuts or junctions complicating things?

    That's what i was thinking to make it simpler, because of those blasted virtual files and directories. Or handle the case of two files with the same name, in different directories, with different content.

    Thought to just keep it simple as this is being written in 486 assembler.
  • I don't think I will jump into this, just yet. I need to get the documentation done for the tool, first.

    Eventually, I will singulate duplicated routines, if there are any. An include-file would make it very easy to bring functionality into an object, without having to bring an object in. For example, some routines that just prints numbers and strings.
  • cgraceycgracey Posts: 12,809
    edited 2020-03-09 - 02:28:49
    whicker wrote: »
    ...
    Thought to just keep it simple as this is being written in 486 assembler.

    The Spin2 compiler is almost 13,000 lines of '386 code now, all in a single file. It uses only two include files, one for the interpreter and one for the flash programmer. Both of those files just define bytes that make up the respective programs.
  • A preprocessor could be a separate program, right?
  • Indeed, a stand alone preprocessor should work well. There's one called mcpp that I use for FlexC and that can be built as a library (easy to call, I think even from assembly).

    There's also a simpler preprocessor that fastspin shares with openspin and which is less C specific.
  • Is there some kind of high level support for qrotate and qvector in spin2?
  • How do you start a Spin2 methode in another cog?

    I've tried this, but it does not work:
    PUB main()
       coginit(16, @blink, 0)
    
    
    PUB blink()
      repeat
        pintoggle(60)
        waitms(300)
    

    Andy
  • RaymanRayman Posts: 11,058
    edited 2020-03-10 - 13:00:50
    You probably need to give it a stack pointer as the last parameter...
    Maybe it needs to be above $400?
  • RaymanRayman Posts: 11,058
    edited 2020-03-10 - 14:02:27
    I just remembered the other thing that was discussed being "fixed" for Spin2.

    This is the step in a downward repeat loop.

    This doesn't work as expected in Spin1:
    repeat x from 10 to 1 step -1
    


    You'd think you'd want to make the step negative to count down, but this makes it actually count up.

    Was this changed in Spin2?

  • Rayman wrote: »
    Is there some kind of high level support for qrotate and qvector in spin2?

    ROTXY(x,y,t) 'rotates (x,y) by t, returns x and y
    POLXY(r,t) 'converts polar to cartesian, returns x and y
    XYPOL(x,y) 'converts cartesian to polar, return rho and theta
  • Ariba wrote: »
    How do you start a Spin2 methode in another cog?

    I've tried this, but it does not work:
    PUB main()
       coginit(16, @blink, 0)
    
    
    PUB blink()
      repeat
        pintoggle(60)
        waitms(300)
    

    Andy

    COGSPIN(cognumber, spinmethod({params}), stackaddress)

    COGSPIN returns the cog number if used as a function. -1 means no free cog, if 16 was used as cognumber.
  • Rayman wrote: »
    I just remembered the other thing that was discussed being "fixed" for Spin2.

    This is the step in a downward repeat loop.

    This doesn't work as expected in Spin1:
    repeat x from 10 to 1 step -1
    


    You'd think you'd want to make the step negative to count down, but this makes it actually count up.

    Was this changed in Spin2?

    Spin2 makes the step value absolute, then negates it if it needs to count downward. So, it ignores the sign that the user specifies.
  • Interesting... Prop manual says the "step" value is re-evaluated in every loop.
    Is true for "Start" and "finish" values as well?
    I guess so, but Prop Manual doesn't seem to say...
  • Rayman wrote: »
    Interesting... Prop manual says the "step" value is re-evaluated in every loop.
    Is true for "Start" and "finish" values as well?
    I guess so, but Prop Manual doesn't seem to say...

    In Spin2, the start, finish, and delta values are evaluated only initially. During looping, the delta is added to the current value and, based on the sign of the delta, a comparison is made to the finish value.
  • COGSPIN(cognumber, spinmethod({params}), stackaddress)

    COGSPIN returns the cog number if used as a function. -1 means no free cog, if 16 was used as cognumber.
    Does this mean the programmer has to keep track of which cogs are running? Is there a mechanism for learning which cogs are available?
  • JonnyMac wrote: »
    COGSPIN(cognumber, spinmethod({params}), stackaddress)

    COGSPIN returns the cog number if used as a function. -1 means no free cog, if 16 was used as cognumber.
    Does this mean the programmer has to keep track of which cogs are running? Is there a mechanism for learning which cogs are available?

    If cognumber = 16, that will start a free cog. COGSPIN will return the started cog, or -1 if none was available.
  • The COGID instruction with the WC flag will return if the given cog, defined by D[3:0], is on or not. It sets C if the cog is active.
    Is there a Spin2 equivalent of that, or just use inline asm?
  • Roy Eltham wrote: »
    The COGID instruction with the WC flag will return if the given cog, defined by D[3:0], is on or not. It sets C if the cog is active.
    Is there a Spin2 equivalent of that, or just use inline asm?

    COGCHK(cognumber)
  • I'm currently trying to get my keyboard/mouse USB object working using Spin2 (PNut v34L). The fastspin version is currently running well. This object has Spin2 methods and the USB host is DAT pasm, using both cog/lut exec and hub exec routines. The cog/lut exec routines look to be working fine, but when the first hub exec routine is called the train quickly goes off the rails. As far as I can tell now, it looks like it may be associated to the object relocation that Spin2 does.

    Calls/jmps cog->hub are invoked using loc pa, #@target_label - #@cog_start_label followed by add pa, cog_start_offset to calculate the hub target address. All #relative and #.local_labels work fine without fix-up.

    But it looks like something wonky is going on when calculating call/jmp targets in hub space. Below is a list of label locations used in the USB pasm code and it looks like there may be something going on with #label and #@label calculation when in hub space.

    The top spin2 object imports two child objects, a serial spin2-only object and the USB host Spin2+pasm object. The label addresses below are calculated in cog/lut and hub space. The "usb_host_start" label is the cog start address and the "hparse_con_desc" label is the label that follows the first ORGH in the object. The label locations come from the compiled .BIN file.
    -------------------------------------------------------------------------------
    Cog/LUT exec space:
    All labels in cog space calculated as expected.
    -------------------------------------------------------------------------------
    PTRB offset at cog start == hcog_base_addr == $1950
    wrlong #usb_host_start == $0
    wrlong #@usb_host_start == $1c
    loc #usb_host_start == $0
    loc #\usb_host_start == $0
    loc #@usb_host_start == $1c
    loc #\@usb_host_start == $1c
    -------------------------------------------------------------------------------
    wrlong ##hparse_con_desc == $c9c
    wrlong ##@hparse_con_desc == $c9c
    loc #hparse_con_desc == $c9c
    loc #\hparse_con_desc == $c9c
    loc #@hparse_con_desc == $c9c
    loc #@\hparse_con_desc == $c9c
    -------------------------------------------------------------------------------
    Hub exec space:
      Labels in cog space calculated as expected.
      Hub exec space # and #@ labels not calculated as expected?
    -------------------------------------------------------------------------------
    wrlong #usb_host_start == $0
    wrlong #@usb_host_start == $1c
    loc #usb_host_start == $0
    loc #\usb_host_start == $0
    loc #@usb_host_start == $1c
    loc #\@usb_host_start == $1c
    -------------------------------------------------------------------------------
    wrlong ##hparse_con_desc == $c9c
    wrlong ##@hparse_con_desc == $c9c
    **loc #hparse_con_desc == $2e68
    loc #\hparse_con_desc == $c9c
    **loc #@hparse_con_desc == $2e68
    loc #\@hparse_con_desc == $c9c
    **loc #@hparse_con_desc - @usb_host_start == $2e4c ($2e68 - $2e4c == $1c)
    loc #\@hparse_con_desc - @usb_host_start == c80 (c80 + 1c == c9c)
    
  • Garryj, yes, I just discovered this, myself. I'm trying to figure out how to track addresses for ORGH code now. I'm hoping to be able to use ORGH to set up an offset that will be added to all PASM references for address computation. I don't fully have my head around this, yet.
Sign In or Register to comment.