When is orgh not orgh in PNut Spin2?

I thought an orgh was supposed to place things at address $400 or above. I have the following at the end of my Spin2 code.
dat	orgh

marker	byte    $3a[4]
I did a memory search and found the array at $014. Fastspin placed it at $00878. I also tried with orgh $400 with the same result.

Am I missing something here?

Comments

  • I'm guessing that since it is an array and not code, that it is safe to place there as hub data.
  • Cluso99Cluso99 Posts: 16,193
    edited 2020-05-15 - 05:43:15
    larryvc wrote: »
    I thought an orgh was supposed to place things at address $400 or above. I have the following at the end of my Spin2 code.
    dat	orgh
    
    marker	byte    $3a[4]
    
    I did a memory search and found the array at $014. Fastspin placed it at $00878. I also tried with orgh $400 with the same result.

    Am I missing something here?

    Yes :(

    pnut (when using spin2) does not place it anywhere in particular! If you want it somewhere in particular, you have to move it there :(

    Take a look at my P2 Serial Monitor thread which shows how to move it to where you require.

    Be very careful as jmps/calls/djnz etc must be relative or your code will go crazy. It's an absolute nightmare if you want to place things in hub yourself!
  • @Peter Jakacki I am still guessing about pretty much everything here. ;)

    @Cluso99 Thanks for that, not a showstopper, but certainly an inconvenience. It has been a long time since I used a tool that did not follow its own directives.

    Was reading your fine code last night and gleaned a few jewels in the process. Found the byte fill at LMM Monitor - HUBEXEC code, is that what you were referring to?

    I read that you were able to get your code to work with both PNut and Fastspin, any pointers, pun intended, in that regard?
  • larryvc wrote: »
    @Peter Jakacki I am still guessing about pretty much everything here. ;)

    @Cluso99 Thanks for that, not a showstopper, but certainly an inconvenience. It has been a long time since I used a tool that did not follow its own directives.

    Was reading your fine code last night and gleaned a few jewels in the process. Found the byte fill at LMM Monitor - HUBEXEC code, is that what you were referring to?
    Sort of. While you can tell the code to compile for an address using orgh, it will not place your code there. You have to do that. Next, you have to be extremely careful of any labels used as the addresses are likely to use the ones where is placed, not where you directed. There are too many caveats that will catch you out! I have spent man months trying to get a working piece of code (it's working in the P2 ROM) working with the compilers.
    I read that you were able to get your code to work with both PNut and Fastspin, any pointers, pun intended, in that regard?
    Yes (so short lived), and now it's No :(

    I didn't realise that the two are so far apart that they will never be compatible. Fastspin compiles spin2 into assembler and does not use Chip's interpreter. This is a very major and fundamental difference.
    My code shouldn't work with fastspin because fastspin does leave any cog registers free. Currently it's a fluke that it works!

    Eric has done a magnificent job:) I just didn't realise the fundamental difference. :(

  • "Cluso99 wrote:
    Eric has done a magnificent job:) I just didn't realise the fundamental difference.
    The way the two programs handle indirect addressing was the first indication to me that they are very different indeed. That is why I mentioned pointers earlier. I think a clean delineation of the P1 and P2 tools should be considered with the goal of having two separate toolsets even if that means backwards compatibility is not retained. Then a clear goal for the new P2 Spin tools to be compatible in syntax and semantics, while the underlying methods to achieve that can be up to the implementers. Oh, and survival of the fittest falls in there too! :)

    Finding the simplicity of the language to be what is keeping me from jumping ship and using C/C++ instead.
  • Cluso99 wrote: »
    larryvc wrote: »
    I read that you were able to get your code to work with both PNut and Fastspin, any pointers, pun intended, in that regard?
    Yes (so short lived), and now it's No :(

    I didn't realise that the two are so far apart that they will never be compatible.
    That's rather extreme. I think at least 90% of Spin2 code will compile with fastspin. There are a few places (mainly around inline assembly) where PNut and fastspin are not compatible, but it certainly should be possible to write code that works in both.
    My code shouldn't work with fastspin because fastspin does leave any cog registers free. Currently it's a fluke that it works!

    fastspin leaves registers free at the start and end of COG memory. In particular it leaves free the registers used by the ROM. I think it's rather unfortunate that PNut did not do this.
  • There's all of LUT free too, right?
    I'd like to learn how to jump into LUTEXEC and then jump back to fastspin code...
  • ersmith wrote: »
    Cluso99 wrote: »
    larryvc wrote: »
    I read that you were able to get your code to work with both PNut and Fastspin, any pointers, pun intended, in that regard?
    Yes (so short lived), and now it's No :(

    I didn't realise that the two are so far apart that they will never be compatible.
    That's rather extreme. I think at least 90% of Spin2 code will compile with fastspin. There are a few places (mainly around inline assembly) where PNut and fastspin are not compatible, but it certainly should be possible to write code that works in both.
    My code shouldn't work with fastspin because fastspin does leave any cog registers free. Currently it's a fluke that it works!

    fastspin leaves registers free at the start and end of COG memory. In particular it leaves free the registers used by the ROM. I think it's rather unfortunate that PNut did not do this.
    Eric,
    I mean no disrespect. You have done a fantastic job, and you've had to chase Chip's tail too!

    However, pnut and fastspin are opposites because of the interpreter vs pasm.
    Hence my quote "I didn't realise that the two are so far apart that they will never be compatible."

    This alone gives problems with code trying to run under both regimes. I have come unstuck on this many times along the way and you've been able to fix them in literally no time. But, the problem is trying to share a mix of pasm and spin objects that can be callable from both pasm and spin. The way it is now, there is no way I can see to do this. Chip has made certain cog space ($000-$132 and PR0-PR7) available for use within spin. You've made $000-$01F (???) only available. My serial/monitor uses 16 cogs and I cut my SD down to 16 (actually 14 IIRC). As the pasm hubexec code using these registers is littered with these register usage it's not viable to patch the code to shift the register usage. Also, my plan is to make these resident for my OS and that will not work either. I have to decide which compiler to use, and the routines will be for that one alone :(
    Also I wanted to shift one of these subroutines (the SPI SD bitbanging) into cog at runtime (may require up to 16 longs).

    I see no solution to this problem. We are just going to have objects that will work with pnut/PropTool and others that just work with fastspin.

    I wanted to use spin because
    1. Smaller bytecodes
    2. Use higher level code when speed is irrelevant
    3. Pasm when necessary

    512KB is not that great if you have large screen buffers doing 1080 VGA.

    I'll just go back and stick my head in the sand again :(

  • PNut Spin2 was heading towards "online edits" to running code. Instead of the reset, download, initialize, run programming cycle.

    So you'd best start leaning how to calculate addresses before use and to reference labels, instead of hardcoding absolute hub addresses.
  • whicker wrote: »
    PNut Spin2 was heading towards "online edits" to running code. Instead of the reset, download, initialize, run programming cycle.

    So you'd best start leaning how to calculate addresses before use and to reference labels, instead of hardcoding absolute hub addresses.
    Callable (and resident) hubexec routines do not work that way. Forcing relocatable code on microcontrollers is the wrong way to go about it!
  • whicker wrote: »
    PNut Spin2 was heading towards "online edits" to running code. Instead of the reset, download, initialize, run programming cycle.

    So you'd best start leaning how to calculate addresses before use and to reference labels, instead of hardcoding absolute hub addresses.
    Who is hardcoding addresses?

    I was wondering why the orgh was not putting the marker array somewhere above $400, so decided that something was not right with this. Tried it on a different computer and the memory search showed the marker array above $400. Wiped, downloaded, and extracted PNut v34s onto the original computer again and it also showed the marker array above $400. No idea what was wrong, other than perhaps a bad extract. Same memory test code was used for all tests.

    Now have Spin2 pointers down rock solid. Still a bit dismayed about the differences between PNut and Fastspin.
  • larryvclarryvc Posts: 26
    edited 2020-05-16 - 02:43:40
    Cluso99 wrote: »
    ... Forcing relocatable code on microcontrollers is the wrong way to go about it!
    That is absolutely correct!

    My company may have to develop and rely on our own tools for the P2 if this is the way things are headed. That is going to be a hard sell, considering we can get full, proven, development environments from other chip manufacturers.
  • larryvc wrote: »
    Cluso99 wrote: »
    ... Forcing relocatable code on microcontrollers is the wrong way to go about it!
    That is absolutely correct!

    My company may have to develop and rely on our own tools for the P2 if this is the way things are headed. That is going to be a hard sell, considering we can get full, proven, development environments from other chip manufacturers.
    Why not use FastSpin?

  • larryvclarryvc Posts: 26
    edited 2020-05-20 - 04:50:09
    David Betz wrote: »
    Why not use FastSpin?

    @David Betz , Sorry for not answering this sooner.

    Now that we understand more about how Spin2 and Fastspin work, thanks to many helpful others on this forum, it has become quite apparent that they both will work for us, and as such, all our company code will be written to run with either.

    I personally, will be experimenting with everything that I find here with the ultimate goal of knowing this chip inside out and having fun in the process. As Rayman recently said to me, Happy propellering!
  • @larryvc
    Since there are so many specific asm instructions in the P2, it would be worthwhile to look at the asm instructions in the P1 first. This will give you a good understanding of the base instructions and the Propeller Manual breaks down each of these instructions (pasm and spin) nicely. There is also a nice 2 page summary for PASM and a 2 page summary for spin.

    Using that as a base, remember these things...
    * P1 pasm instructions HUBOP (coginit), LOCKs, WAITxxx are all different
    * JMPRET (JMP, CALL, RET) doesn't have a 1:1 equivalent in P2
    * There is no NR (no write) bit in the P2
    * The conditional execution code cccc=0000=never is re-purposed as an implicit RET on completion of the instruction. This was used to effectively force a NOP. The NOP instruction is now a special case of all 0's in P2 whereas in P1 if the top 4 bits were 0's then the rest of the instruction/bits were ignored and treated as a NOP and there were some tricks used here that are not valid in P2.
    * The top 14 bits are re-arranged in P2 compared to P1
    * P1 doesn't have LUT
    * P1 cannot run hubexec although we did use a method known as LMM to run code from hub via a little 4 long routine in cog that fetched instructions one by one from hub and execute them.
    * There are some subtle differences in the condition codes in some of the base instructions - see the Tricks and Traps threads.

    IMHO this will get you familiar with the propeller the quickest.
  • larryvclarryvc Posts: 26
    edited 2020-05-20 - 19:45:41
    @Cluso99,
    Thanks for the pointers. The asm instuction set for the P2 is what earned my interest in this chip, that without having any real meaningful exposure to the P1. I found it quite straight forward, very easy to envision the operations happening within each instruction, very logical. Sure there are some instructions that I don't completely understand yet, but all up, this appears to be a very easy chip to write code for. Certainly not as obscure as the asm for the Arm Cortex M and A series chips that I've had to use in other projects.

    Assembly comes easy, knowing how the register structure is defined and what the registers are used for is not well defined yet in the P2 doc, so the P1 manual has helped in that regard. The P1 Spin documentation is quite informative, it provides the much needed meaningful context to the P2 Spin2 document.

    For anybody just starting out with the P2, the Propeller 1 Documentation should be a must read.
  • @larryvc,
    There are not many registers that have specific meaning in the P2. From asm there are just the 16 of which the top 8 are the relevant ones. The DIRx, OUTx & INx are equivalent to the P1 I/O registers except that the 'B' versions were not implemented in the silicon on P1 as there are only 32 I/O pins.

    PA, PB, PTRA, PTRB are the special "pointer" ones as they have particular purposes when used with read/write instructions that can automatically increment/decrement the pointers.

    There is no PAR or CNT register in P2.
    PTRA & PTRB can be set by the coginit function (see coginit writeup).
    Use getct to get the counter.

    CTR, FRQ, PHS, and VCFG, VSCL do not exist in P2.

    see this for a brief description
    https://forums.parallax.com/discussion/comment/1448040/#Comment_1448040

    All these registers can be used as normal registers too, except for the 6 I/O registers DIRx/OUTx/INx.

    And in case you come across the P1 using these 16 registers differently, there are 16 "hidden" shadow registers underneath these registers. I used PAR,CNT,INA,INB to hide an lmm debug and trace routine in there.
Sign In or Register to comment.