When is orgh not orgh in PNut Spin2?
larryvc
Posts: 42
in Propeller 2
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.
Am I missing something here?
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
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!
@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?
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.
Finding the simplicity of the language to be what is keeping me from jumping ship and using C/C++ instead.
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.
I'd like to learn how to jump into LUTEXEC and then jump back to fastspin code...
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
So you'd best start leaning how to calculate addresses before use and to reference labels, instead of hardcoding absolute hub 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.
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.
@"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!
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.
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.
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.