PNut/Spin2 Latest Version (v34z - Lots of DEBUG display stuff)

145791034

Comments

  • cgracey wrote: »
    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.

    Thank you.
  • cgracey wrote: »
    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.
    Thanks!
  • JonnyMac wrote: »
    cgracey wrote: »
    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.

    Thank you.

    Soon I will add some constants to the compiler for use in cases like this.

    HUBEXEC = 32
    NEWCOG = 16

    COGINIT(HUBEXEC+NEWCOG, @pasmhubcode, 0)
  • cgraceycgracey Posts: 13,077
    edited 2020-03-11 - 08:30:42
    I just posted v34m at the top of this thread.

    Hub-exec code defined in Spin2 programs now orients properly at $400 (default). Hub-exec programs in Spin must rely on relative addressing:
    pub go()
      coginit(32+16,@blink,0)		'launch hub-exe program in free cog
    
    DAT	orgh				'being hub-exec program
    
    blink	setbyte	dirb,#$FF,#3		'make LEDs outputs
    	mov	pb,#0			'clear pb
    
    loop	loc	pa,#table		'get address of table (relative)
    	add	pa,pb			'add pb
    	rdbyte	pa,pa			'read table byte
    	not	pa			'NOT for LEDs
    	setbyte	outb,pa,#3		'write to LEDs
    	incmod	pb,#7			'inc pb 0..7 and repeat
    	waitx	##clkfreq_/10		'wait 1/10 second
    	jmp	#loop			'loop
    
    table	byte	$01,$02,$04,$08,$10,$20,$40,$80
    

    Also, empty IF/ELSEIF/ELSE/REPEAT/CASE/CASE_FAST blocks are now allowed.
  • cgracey wrote: »
    I just posted v34m at the top of this thread.

    Hub-exec code defined in Spin2 programs now orients properly at $400 (default). Hub-exec programs in Spin must rely on relative addressing:
    Also, empty IF/ELSEIF/ELSE/REPEAT/CASE/CASE_FAST blocks are now allowed.
    Woohoo! My USB keyboard/mouse Spin2 demo is working now with PNut Spin2.
    I've got some code cleanup to do, but I should be posting updated Spin2 demos for both FastSpin and PNut v34m soon.
  • Nice going GarryJ
    Is it the same code that runs under both compilers? Or are there two versions
  • RaymanRayman Posts: 11,352
    edited 2020-03-12 - 00:59:51
    Great news!

    That’s a big milestone for Spin2.

    Tiny codes are one thing, big ones are another ...
  • garryj wrote: »
    cgracey wrote: »
    I just posted v34m at the top of this thread.

    Hub-exec code defined in Spin2 programs now orients properly at $400 (default). Hub-exec programs in Spin must rely on relative addressing:
    Also, empty IF/ELSEIF/ELSE/REPEAT/CASE/CASE_FAST blocks are now allowed.
    Woohoo! My USB keyboard/mouse Spin2 demo is working now with PNut Spin2.
    I've got some code cleanup to do, but I should be posting updated Spin2 demos for both FastSpin and PNut v34m soon.

    Super! I was waiting to hear something from you. Glad it's working.
  • garryjgarryj Posts: 327
    edited 2020-03-12 - 01:24:45
    Tubular wrote: »
    Nice going GarryJ
    Is it the same code that runs under both compilers? Or are there two versions
    Currently a version for each. FastSpin hub-exec addressing is mostly absolute, PNut Spin2 addressing is relative. The edits are numerous, but simple. One file doable if PNut gets #ifdef...😉
  • garryj wrote: »
    Tubular wrote: »
    Nice going GarryJ
    Is it the same code that runs under both compilers? Or are there two versions
    Currently a version for each. FastSpin hub-exec addressing is mostly absolute, PNut Spin2 addressing is relative. The edits are numerous, but simple. One file doable if PNut gets #ifdef...😉

    I'm glad you figured out what to do so quickly and you didn't have any problems. I suppose you could make both versions relatively-addressed. Would there be any code growth if you did that? Did you use the LOC instruction to get addresses of data your program uses?
  • As a worst case maybe there is something we can drop in and then do replace all on to make work for both...
  • cgracey wrote: »
    garryj wrote: »
    Tubular wrote: »
    Nice going GarryJ
    Is it the same code that runs under both compilers? Or are there two versions
    Currently a version for each. FastSpin hub-exec addressing is mostly absolute, PNut Spin2 addressing is relative. The edits are numerous, but simple. One file doable if PNut gets #ifdef...😉

    I'm glad you figured out what to do so quickly and you didn't have any problems. I suppose you could make both versions relatively-addressed. Would there be any code growth if you did that? Did you use the LOC instruction to get addresses of data your program uses?

    That is part of the plan, now that both versions are working. Yes, LOC is used extensively and that made it easier to find where changes were needed. I'm done for the night, but I'll dive into this tomorrow.
  • I would wait for ersmith to be back working on FastSpin. He plans to make it compatible with official Spin2 as much as possible.
    I think having two versions for now is ok, eventually you will be able to just keep the official Spin2 version and it'll work on both.
  • Yes there's no problem having two versions for now, I was just asking out of curiosity

  • I finished the part of the documentation that covers blocks, constants, and variable syntax, including size overrides, indexes, and bitfields.

    https://docs.google.com/document/d/16qVkmA6Co5fUNKJHF6pBfGfDupuRwDtf-wyieh_fbqw/edit?usp=sharing
  • Was just thinking...

    I'd be nice to have something like a macro that could turn 4 byte constants into a long constant...
    Something like RGBA(r,g,b,a) or just RGB() or maybe RGBx().

    On the other hand, this could be part of some preprocessor that I'm sure somebody will make before long...
  • I just realized an inconsistency in Spin2.

    All methods have parentheses '()' after their names, even if they have no parameters. This helps distinguish methods from variables and constants.

    We have some built-in methods which currently and historically have not had parentheses after their names:
    COGID
    LOCKNEW
    GETRND
    GETCT
    

    Should we change these built-in methods to look like these:
    COGID()
    LOCKNEW()
    GETRND()
    GETCT()
    

    What do you think?
  • LOCKNEW and GETRND yes, because those are like functions.

    COGID no, because it is more like a constant than a function.

    GETCT idk...
  • I think the brackets are reasonable
  • Tubular wrote: »
    I think the brackets are reasonable

    I added them. It feels very right, now that it's done.
  • This won't compile for me:
    OBJ
      jm_numbers[2] : "jm_nstrings"  
     
    PUB begin(value) | str
      str := jm_numbers[0].fmt_number(value, 10, 0, 8, " ")
    

    It expects a "." after the jm_numbers reference in the begin method, as if the object wasn't part of an array.
  • wmosscrop wrote: »
    This won't compile for me:
    OBJ
      jm_numbers[2] : "jm_nstrings"  
     
    PUB begin(value) | str
      str := jm_numbers[0].fmt_number(value, 10, 0, 8, " ")
    

    It expects a "." after the jm_numbers reference in the begin method, as if the object wasn't part of an array.

    Okay. I'll have this fixed in about 8 hours. I need to get some sleep, first. Sorry about this. We'll get it figured out soon.
  • PropGuy2PropGuy2 Posts: 290
    edited 2020-03-14 - 01:35:45
    Just an inquiry - From the new SPIN2 revision just released, Are there any plans for 64-bit math?
    Reply - Thanks, the CORDIC instruction is fine.
  • cgracey wrote: »
    Okay. I'll have this fixed in about 8 hours. I need to get some sleep, first. Sorry about this. We'll get it figured out soon.

    Please, no rush on my part. This is a minor issue and I have a workaround. Just wanted to report it.

    With so many new features there are bound to be some flaws in the tools.
  • cgraceycgracey Posts: 13,077
    edited 2020-03-13 - 21:43:36
    PropGuy2 wrote: »
    Just an inquiry - From the new SPIN2 revision just released, Are there any plans for 64-bit math?

    No, but we do have one instruction called MULDIV64, which multiplies two 32 bit unsigned numbers and then divides their 64-bit product by another 32-bit value. It's useful for doing clock frequency computations, where you need 64-bit intermediate values. In that case, the CORDIC handles the 64-bit math.
  • Nice! I wondered how that hardware feature could be taken advantage in a higher level language.
  • evanh wrote: »
    Nice! I wondered how that hardware feature could be taken advantage in a higher level language.

    For converting 64-bit CT ticks to 32-bit time units, we need a DIV64 method.
  • A 64-bit -> 32-bit shift and truncate would do I think. That shouldn't be hard to make a small function/macro with existing language.
  • Another small quirk... You can specify an index for an object reference even if the object isn't defined as an array. This code compiles (I didn't try to run it):
    OBJ
        jm_nstrings  : "jm_nstrings"
    
    PUB go()
      jm_nstrings[5].fmt_number(1234, 10, 0, 8, " ")
    
  • wmosscrop wrote: »
    Another small quirk... You can specify an index for an object reference even if the object isn't defined as an array. This code compiles (I didn't try to run it):
    OBJ
        jm_nstrings  : "jm_nstrings"
    
    PUB go()
      jm_nstrings[5].fmt_number(1234, 10, 0, 8, " ")
    

    Sorry I didn't get to the object index issue yet. I will get to it tomorrow. Yes, you can put an index on just about anything.
Sign In or Register to comment.