Shop OBEX P1 Docs P2 Docs Learn Events
PNut/Spin2 Latest Version (v46 - DEBUG gating, clock-setter control, VAR flexibility, C_Z for DEBUG) - Page 7 — Parallax Forums

PNut/Spin2 Latest Version (v46 - DEBUG gating, clock-setter control, VAR flexibility, C_Z for DEBUG)

1…457910…65

Comments

  • JonnyMacJonnyMac Posts: 9,102
    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.
  • garryjgarryj Posts: 337
    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!
  • cgraceycgracey Posts: 14,150
    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: 14,150
    edited 2020-03-11 08:30
    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.
  • garryjgarryj Posts: 337
    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.
  • TubularTubular Posts: 4,701
    Nice going GarryJ
    Is it the same code that runs under both compilers? Or are there two versions
  • RaymanRayman Posts: 14,632
    edited 2020-03-12 00:59
    Great news!

    That’s a big milestone for Spin2.

    Tiny codes are one thing, big ones are another ...
  • cgraceycgracey Posts: 14,150
    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: 337
    edited 2020-03-12 01:24
    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...😉
  • cgraceycgracey Posts: 14,150
    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?
  • RaymanRayman Posts: 14,632
    As a worst case maybe there is something we can drop in and then do replace all on to make work for both...
  • garryjgarryj Posts: 337
    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.
  • Roy ElthamRoy Eltham Posts: 3,000
    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.
  • TubularTubular Posts: 4,701
    Yes there's no problem having two versions for now, I was just asking out of curiosity

  • cgraceycgracey Posts: 14,150
    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
  • RaymanRayman Posts: 14,632
    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...
  • cgraceycgracey Posts: 14,150
    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?
  • Wuerfel_21Wuerfel_21 Posts: 5,049
    LOCKNEW and GETRND yes, because those are like functions.

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

    GETCT idk...
  • TubularTubular Posts: 4,701
    I think the brackets are reasonable
  • cgraceycgracey Posts: 14,150
    Tubular wrote: »
    I think the brackets are reasonable

    I added them. It feels very right, now that it's done.
  • wmosscropwmosscrop Posts: 409
    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.
  • cgraceycgracey Posts: 14,150
    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: 360
    edited 2020-03-14 01:35
    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.
  • wmosscropwmosscrop Posts: 409
    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: 14,150
    edited 2020-03-13 21:43
    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.
  • evanhevanh Posts: 15,910
    Nice! I wondered how that hardware feature could be taken advantage in a higher level language.
  • cgraceycgracey Posts: 14,150
    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.
  • evanhevanh Posts: 15,910
    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.
  • wmosscropwmosscrop Posts: 409
    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, " ")
  • cgraceycgracey Posts: 14,150
    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.