Prop II Coding
hippy
Posts: 1,981
Assuming the Prop II has more than 64KB Ram, which is likely, all Propeller code which currently uses word variables to store pointers will likely break. This affects user code, particularly code in the Object Exchange with Spin and PASM code both affected.
It seems logical then that Propeller programmers should be using long variables for pointers for compatibility with Prop II but as this is wasteful on a Prop Mk I and word variables for pointers 'feel natural for a 64KB configuration' it's not happening - I'm as guilty as anyone else.
I can see two options; conditional compilation, so a programmer can use word variables for pointers on the Mk I and longs on a Mk II, or a new 'pointer' or 'addr' type which is 16-bit or 32-bit depending upon target compiled for. The later probably being the easiest to implement now as it can simply be an alias for "word" ( or "long" ) and any further complication caused to the Propeller Tool can be resolved in the fullness of time.
I think the issue needs some resolution now and people need educating and guiding in how they should code for both Mk I and Mk II compatibility. The longer the issue is ignored the more code which will break on the Mk II will exist. The last thing I think anyone wants is a flurry of "my code worked on Mk I but doesn't on the Mk II" posts to address, especially for Obex code and when it causes a lack of confidence in, or criticism of, the Mk II.
I would personally go as far as saying no code which is incompatible with the Mk II should be in the Obex when the Mk II is released and incompatible code there should be deleted.
One problem is that I am second-guessing how Spin etc will change for the Mk II, assuming byte[noparse][[/noparse] ], word[noparse][[/noparse] ] and long[noparse][[/noparse] ] will be valid for the full memory as it is now. If not that would add another level of difference. Although I appreciate the Mk II isn't necessarily fully defined and some way off, some guidance from Parallax would be appreciated.
It seems logical then that Propeller programmers should be using long variables for pointers for compatibility with Prop II but as this is wasteful on a Prop Mk I and word variables for pointers 'feel natural for a 64KB configuration' it's not happening - I'm as guilty as anyone else.
I can see two options; conditional compilation, so a programmer can use word variables for pointers on the Mk I and longs on a Mk II, or a new 'pointer' or 'addr' type which is 16-bit or 32-bit depending upon target compiled for. The later probably being the easiest to implement now as it can simply be an alias for "word" ( or "long" ) and any further complication caused to the Propeller Tool can be resolved in the fullness of time.
I think the issue needs some resolution now and people need educating and guiding in how they should code for both Mk I and Mk II compatibility. The longer the issue is ignored the more code which will break on the Mk II will exist. The last thing I think anyone wants is a flurry of "my code worked on Mk I but doesn't on the Mk II" posts to address, especially for Obex code and when it causes a lack of confidence in, or criticism of, the Mk II.
I would personally go as far as saying no code which is incompatible with the Mk II should be in the Obex when the Mk II is released and incompatible code there should be deleted.
One problem is that I am second-guessing how Spin etc will change for the Mk II, assuming byte[noparse][[/noparse] ], word[noparse][[/noparse] ] and long[noparse][[/noparse] ] will be valid for the full memory as it is now. If not that would add another level of difference. Although I appreciate the Mk II isn't necessarily fully defined and some way off, some guidance from Parallax would be appreciated.
Comments
Then you also need a rdpointer/rdaddr. wrpointer/wraddr
Macros should work best and will solve some other bad coding-style too.
Nick (did I once ask for "sizeof"?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 1/6/2008 6:42:59 PM GMT
Code that works on the current Propeller should work fine on the 256K as long as:
1) You limit your program and data to the 1st 64K. Remember that the stack works upwards from the end of the program.
2) All references to ROM are done using long values and these should be based on named constants. Many of the display drivers that use the built-in font tables "hard-code" the starting address of the font table.
3) A few specific "got-ya"s in assembly language are accounted for that actually apply to the current Propeller. For example, the use of the C flag with WAITPxx instructions to indicate which "bank" of 32 I/O pins is referenced. This is defined for the current Propeller, but works OK if you ignore it. Some of the I/O drivers are written to handle this and some are not including some of mine.
Maybe after that will be a new area of 64 (or 128 KB) RAM?
Maybe....
Memory is tight in the prop as it is, if they introduce conditional compiling all may be helped. Revising the code will be anyways necessary due to increased speed.
@ Mike : Keeping to under 64KB will work, but people will include objects where they end up above that 64K. Worse still, there will be code which by luck does work, but as development continues it stops working, that invariably leads people to thinking it's the code they'd just added which is faulty when the issue is far removed.
Good points about the other changes which come with the Prop II, not just pointer size.
@ deSilva : Rom could be kept where it is, but I think that would be a nightmare and a major kludge. Adjusting hard-coded addresses for Character , Sine and Cosine is going to be an issue as well. Unless that's done programmatically using ChipVer, conditional compilation is going to be a necessity for code which runs on both Mk I and Mk II.
At some point I expect a Mk III will be considered, so it would be nice to have scalability resolved for the future rather than just hacking around Mk I to Mk II changes. If there's 128KB Rom as suggested, that also has to go somewhere, interleaved Ram and Rom is going to be horrible to deal with.
@ Ale : It's never too early to start looking at potential problems. The 31st of December wouldn't have been a good time to start considering Millennium Bugs. It always annoys me when the Millennium Bug is cited as a 'failed prophecy' because it never materialised as feared; only because so much effort went into ensuring it didn't !
IMO, far better to start worrying now and have a smooth transition later than put it to one side and have 'blind panic' when Prop II arrives and issues haven't been resolved or even looked into.
I agree that memory is often tight on a Prop Mk I, and that will lead to a reluctance to use longs for pointers ( I feel that way ). Thus the Propeller Tool has to provide the mechanisms to make both Mk I and Mk II use optimal for each.
I have no idea what issues you are talking about... Leaving the ROM where it is, is the only possible compatible solution. Many old SPIN programs will run!
Utilizing the Prop II features would need starting your programs @ 64k. The low 32 kb can be used for stack data, video memory... It is not such an issue that it is not consecutive.
Post Edited (deSilva) : 1/7/2008 7:55:59 PM GMT
There are three issues really; running Prop I programs on a Prop II, writing objects which will run on either Prop I or Prop II, expanding Prop I programs once they move to a Prop II.
> expanding Prop I programs once they move to a Prop II.
A ROM-relocation-register. If not set (non Prop II aware programs), the original ROM moves to where it was in the Prop I.
But I certainly woudndn't like the ROM to lie in the middle of RAM.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
they should follow the Intel x86 method, eg. address segmentation.
That means the prop II could run multiple prop I programs (if cogs available)
because each program runs in its own segment (like .COM programs).
A virtual mode register can put the prop II·in virtual mode, allowing programs
to use more than 32KByte ram. This could be activated by the downloader
if a special tag (like used for the basic stamps) is used, or instructed
by the program itself by setting the virtual mode register.
regards peter
Whenever I hear "Intel" and "x86", I get curly footnails!
Please no pages, segments, A20 or other oddities.
Having had a look at the registers and RAM-map, I see that there is no room left for an extra configuration-register (without losing valuable COG-RAM). But at least the downloader in ROM could reject files that are for the Prop I (some signature or lack thereof or such).
I personally could live well with that. I really prefer making things simple and straight. As soon as compatibility-Smile is introduced, new problems pop up in every corner.
KISS!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
However, it should be a simple fix. Just the appropriate offset to everything that accesses the rom. If we had macros and a preprocessor then you could even make an object that could run on either.
Further, I expect that code written for PropII will _have_ to have some sort of PropVer setting in order for the Propeller Tool to compile above 32K anyway - isn't that what they did with the Stamp?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
Steven
1) The developer hasn't distributed it. He has the source and can alter it if he moved to Prop 2.
2) The developer distributes software to customers as part of hardware product that includes a Propeller. The only way that the user will be moving to the Prop 2 is if they buy a different hardware product. And that will come with Prop2 software included.
3) The developer has open sourced the software and distributed it via the forums or obex. Everyone has the source, the original developer can update it for Prop2 or anyone else can.
It appears that the current spin compiler assumes a 64K memory map. So binaries for Prop 2 will be different from binaries for Prop 1. But that's not an issue as software is rarely distributed as binaries.
I don't believe it would be worth any architectural tricks or compromises at all to make the Prop 2 100% compatible with Prop 1 binaries. Just update Spin to use 32 bit addresses internally, and put the ROM at the top of the 32 bit address space.
Source code needs some small changes, as already outlined for LONG pointers, ROM accesses and the odd case where flags do something on the Prop2 that they don't on the Prop 1. It's no big deal. We're already used to having to modify source to get software working on different development boards.
But Parallax can do one thing to really help the transition, and make inter board portability easier too. Add conditional compilation to Prop Tool. The sooner the better.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
For Prop 3 (far in future), byte can have 12 bits, and so on.
yawer
You'd be opening a can of worms if a byte wasn't 8 bits. 8 bit bytes are just so ingrained in so many things.
But your objective isn't necessary. There is nothing about the current 32 bit instruction format that limits it to a 16 bit address space. The format is completely compatible with a 32 bit address-space without change. The instructions only ever hold Cog RAM addresses, not Hub RAM addresses. Hub RAM Addresses are held in registers and registers are 32 bit already.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Help to build the Propeller wiki - propeller.wikispaces.com
Play Defender - Propeller version of the classic game
Prop Room Robotics - my web store for Roomba spare parts in the UK
> and long will have 40 bits.
In that case, I prefer waiting for the Prop III which is a 64 bit Processor having 128 COGs, 2MB of COG RAM and 4GB HUB-RAM. I can see it clearly in my crystall ball!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
You are correct.
It took many years for a byte to go from 7 bits to 8 and now you want 10?
Your idea is a bit inflationary[noparse]:)[/noparse]
Better to go to ternary logic... the hardware is already in the Prop... sort of[noparse]:)[/noparse] Ternary logic would give you 12+ bits per byte and no hardware changes.
Rich
My solution on ROM problem ..
With start Prop I program one extra instruction to copy ROM to Prop I addres in Prop II continguos Ram
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Steven