The whole reason for the {Spin2_vNN} is so that older sources will work correctly with newer compilers, i.e. to keep OBEX objects working. Making the default be the current Spin2 version would defeat that. Unless of course people put {Spin2_vNN} tags in all of their OBEX uploads, but I suspect there's a fair amount of existing code which doesn't do that.
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
@Rayman said:
@cgracey Do you have an example of OFFSETOF() usage included in the new v53 release?
Glad you got Next/Quit sorted out...
OFFSETOF() can be used in both Spin2 and Pasm, though it is mostly useful in Pasm.
COGINIT(NEWCOG, @pasm_code, @structure_instance)
DAT ORG
pasm_code ADD ptrMemberA, PTRA
ADD ptrMemberB, PTRA
ADD ptrMemberC, PTRA
...some code that uses the ptr's...
ptrMemberA LONG OFFSETOF(structure.MemberA)
ptrMemberB LONG OFFSETOF(structure.MemberB)
ptrMemberC LONG OFFSETOF(structure.MemberC)
@Rayman said:
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
Yeah, this poses difficulty because of the way things are set up. The problem mainly develops when you have to report an error and your source offsets are all off.
@Rayman said:
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
Yeah, this poses difficulty because of the way things are set up. The problem mainly develops when you have to report an error and your source offsets are all off.
I use FlexSpin because it supports #include but I only need it in the CON section to include a file that contains auto-generated skip pattern constants. FlexSpin always uses the right source file line numbers when reporting coding errors.
My P2 programs are pure PASM and typically need 150-200 different skip patterns, far too many to create by hand.
@JonnyMac said:
I've done that, too, but would be nice to access constants without using object.constant or object#constant notation.
What if we had a way to define public constants in an object which were ALWAYS given to the parent, without any need for 'objectname.constantname' notation, just 'constantname', as if they had been expressed locally in the parent? Might create a potential name-conflict mess, though.
Yeah, that would be a landmine of trouble. We could make a way to bring in all the constants, though, through some express notation in the OBJ instantiation line.
Bitfields added for byte/word/long structure members.
CON STRUCT sMulti(A, B .tnib[31..28] .bnib[3..0]) 'declaration - longs with bits
VAR sMulti vMulti 'instantiation
vMulti.A, vMulti.B 'long members
vMulti.B.tnib, vMulti.B.bnib 'long bitfield members
Single-byte/word/long structures can have just bitfields - obviates a <name.> to simplify syntax.
CON STRUCT sByte(byte .top3[7..5] .bot5[4..0]) 'declaration - just bits!
VAR sByte vByte 'instantiation
vByte 'byte structure/variable
vByte.top3, vByte.bot5 'only bitfield members
I made new compressed bytecodes in the Spin2 interpreter to implement faster/shorter bitfield reads and writes. Each read or write takes one less bytecode than before. Also, ++/-- word/long/structure pointer steps are now taking one less bytecode.
I've been using lots of structures with bitfields and this knocked down my OBJ code size by a little over 1%.
I was digging through some info on the P2 debugger code and noticed that there were a couple of free longs left in the 16 long entry DEBUG ISR that gets loaded when BRK occurs. I also see that the counter hi and counter lo values are latched right away here, so putting two and two together I wonder if the latching of INA and INB IO pin states make sense to do here in addition to the free running counter regs before waiting for the lock to be given and the rest of the debug code gets loaded into the COGRAM. It might be useful to essentially have a recorded "log" of the IO state at the instant that the BRK fired (or at least very near to that time and synchronous to it), and if no other useful things for these spare longs have been found yet then maybe that's a possible use for it? Exactly where/how this is ever presented is another story, but it may be useful to help debug HW/SW interaction perhaps, it's somewhat like having a logic analyser state capture of the IO pins in each debug log message / debugger entry point. Just a thought....
Also this is assuming that latching the INA/INB I/O state is not somehow going to affect the P2 state trying to be preserved, and its not already latched automatically by the BRK. Or perhaps in DEBUG mode these INA/INB reg addresses are no longer readable at this time, since they get used for the ROM code return addresses? Not too sure there of how it all works. Perhaps it requires a multi-stage reload sequence in those 16 longs to even fit.
Comments
Agreed.
The whole reason for the
{Spin2_vNN}is so that older sources will work correctly with newer compilers, i.e. to keep OBEX objects working. Making the default be the current Spin2 version would defeat that. Unless of course people put{Spin2_vNN}tags in all of their OBEX uploads, but I suspect there's a fair amount of existing code which doesn't do that.The new v53 is now posted on the OBEX and on Github.
https://obex.parallax.com/obex/pnut-spin2-latest-version/
A new method OFFSETOF(structure.member) was added and a lingering NEXT/QUIT {level} bug was fixed.
OFFSETOF() is very useful for PASM programs to get offsets of members within a structure that was passed in PTRA via the third term in COGINIT.
Would adding #include to Spin2 be difficult?
Maybe not really needed and might mess things up, maybe more for Spin Tool and Flexprop, than PNut.
Just wondering... If really easy to do for all the compilers, could possibly be useful...
@cgracey Do you have an example of OFFSETOF() usage included in the new v53 release?
Glad you got Next/Quit sorted out...
OFFSETOF() can be used in both Spin2 and Pasm, though it is mostly useful in Pasm.
DAT ORG pasm_code ADD ptrMemberA, PTRA ADD ptrMemberB, PTRA ADD ptrMemberC, PTRA ...some code that uses the ptr's... ptrMemberA LONG OFFSETOF(structure.MemberA) ptrMemberB LONG OFFSETOF(structure.MemberB) ptrMemberC LONG OFFSETOF(structure.MemberC)Yeah, this poses difficulty because of the way things are set up. The problem mainly develops when you have to report an error and your source offsets are all off.
I use FlexSpin because it supports #include but I only need it in the CON section to include a file that contains auto-generated skip pattern constants. FlexSpin always uses the right source file line numbers when reporting coding errors.
My P2 programs are pure PASM and typically need 150-200 different skip patterns, far too many to create by hand.
I would like #include for constants. It may not be a good idea for code due to possible naming conflicts.
@JonnyMac one thing I’m trying now is to have a config.spin2 sub object with constants in it. Not as clean as #include but seems to work…
I've done that, too, but would be nice to access constants without using object.constant or object#constant notation.
What if we had a way to define public constants in an object which were ALWAYS given to the parent, without any need for 'objectname.constantname' notation, just 'constantname', as if they had been expressed locally in the parent? Might create a potential name-conflict mess, though.
Yeah, that would be a landmine of trouble. We could make a way to bring in all the constants, though, through some express notation in the OBJ instantiation line.
In my simple world #include for Spin would only allow files with comments and constant definitions -- no var, obj, pub, pri, or dat sections.
Or, since Spin is different, anyway, a new directive:
Sounds good but maybe spin2 extension is better for colors
But this probably already breaks the line # error issue…
Maybe compiler could just include the includes into a new file with some change to filename, open that, and then compile the super version ?
That seems like easy first step ?
The new v54 is now posted on the OBEX and on Github.
https://obex.parallax.com/obex/pnut-spin2-latest-version/
There is a new PNut v55:
https://obex.parallax.com/obex/pnut-spin2-latest-version/
I made new compressed bytecodes in the Spin2 interpreter to implement faster/shorter bitfield reads and writes. Each read or write takes one less bytecode than before. Also, ++/-- word/long/structure pointer steps are now taking one less bytecode.
I've been using lots of structures with bitfields and this knocked down my OBJ code size by a little over 1%.
Hi @cgracey ,
I was digging through some info on the P2 debugger code and noticed that there were a couple of free longs left in the 16 long entry DEBUG ISR that gets loaded when BRK occurs. I also see that the counter hi and counter lo values are latched right away here, so putting two and two together I wonder if the latching of INA and INB IO pin states make sense to do here in addition to the free running counter regs before waiting for the lock to be given and the rest of the debug code gets loaded into the COGRAM. It might be useful to essentially have a recorded "log" of the IO state at the instant that the BRK fired (or at least very near to that time and synchronous to it), and if no other useful things for these spare longs have been found yet then maybe that's a possible use for it? Exactly where/how this is ever presented is another story, but it may be useful to help debug HW/SW interaction perhaps, it's somewhat like having a logic analyser state capture of the IO pins in each debug log message / debugger entry point. Just a thought....
Also this is assuming that latching the INA/INB I/O state is not somehow going to affect the P2 state trying to be preserved, and its not already latched automatically by the BRK. Or perhaps in DEBUG mode these INA/INB reg addresses are no longer readable at this time, since they get used for the ROM code return addresses? Not too sure there of how it all works. Perhaps it requires a multi-stage reload sequence in those 16 longs to even fit.
Cheers
Roger.