So, the Wikipedia link wasn't helpful at all. A little more reading of other links tells me it is usually used to portray the CPU facilities that are available to the programmer, the flow of execution and addressing. Things like bank switching and segmentation. MMU's will be a major player. Register sets obviously.
Harvard vs Von Neumann are quoted as educational examples.
Yes. While I think the Wikipedia position on this is a bit painful, you expressed the basic idea.
I think I am going to start on one. SVG format so it can be hacked on, until it is representative. I get the feeling the moment one is started, all of the, "yes, but it needs", and "nope, that should be" chatter will get us one quickly.
The Prop 2 is challenging!
May need to do it from multiple perspectives.
Chip
COG COGEX
COG HUBEX
HUB
Smart PIN
While most of us grok the internals, we may find this sort of thing helps others.
When learning a new CPU, this is the first thing I went for.
Was just reading an article about a bunch of galaxies that, preliminarily, have no dark matter in them. That got me thinking about the static of untuned radios and old analogue TV receivers and noted that uninitialised DRAM also looks that way.
Question: Is hubRAM also this random on power up? I think it might be. Count this as a reminder to look tomorrow.
Was just reading an article about a bunch of galaxies that, preliminarily, have no dark matter in them. That got me thinking about the static of untuned radios and old analogue TV receivers and noted that uninitialised DRAM also looks that way.
Question: Is hubRAM also this random on power up? I think it might be. Count this as a reminder to look tomorrow.
From my experiments with power-cycling the P2 for brief periods of time after loading an picture into hubram and then displaying it with VGA, hubram ends up pretty much random after being powered off for enough time. I don't know whether certain bits tend to default to the same state on every power-up or whether it's actually random every time.
There may be some amount of capacitive bias in a bit cell design which causes one side to drag down more than the other during power-up, causing that bit to usually take on a certain state. I remember on my old Apple ][, memory would typically power up with a run of $FF's, followed by a run of $00's, repeating.
I saw the same thing with un-initiated VGA buffer... I assumed it was totally random... I'd be surprised if it turned out to be fixed...
If it is, would almost be like a serial number... Would any two P2's be the same?
Each smartpin has a different GIO and VIO calibration value, eg GIO is typically around 11000 and VIO around 55000 when using 16 bit ADC counts.
I've been thinking it should be possible to use these as a kind of digital thumbprint. You could certainly do a linear regression style fit to do the matching.
What would be neat is to turn this information into a code (serial number) that is sufficiently robust and unchanging.
I've got my reasons. It's part of the Spin2 interpreter's inline PASM feature. You can load code into $000..$167 and execute it. That code sequence is for loading PASM code of some length, starting at some register, executing it, and then resuming bytecode execution from where the PASM binary left off. I needed PTRA to stay current.
Here is how this interpreter code looks now:
'
'
' a: In-line PASM
' b: REGEXEC(hubadr)
' c: REGLOAD(hubadr)
' d: CALL(anyadr)
'
inline_pasm setq #16-1 'a load local variables from hub into buff
rdlong buff,dbase 'a
bith v,#31 'a set flag to later restore local variables to hub
mov ptrb,pb 'a get bytecode ptr into ptrb
skip ##%11100100000111 'a x2 begin inline_pasm skip pattern
regexec_ skip ##%1111000000 '| b x2 begin REGEXEC skip pattern
regload_ mov ptrb,x '| b c get hubadr into ptrb
rdword w,ptrb++ 'a b c read start register
rdword y,ptrb++ 'a b c read length of pasm code, minus 1
setq y 'a b c read in code
altd w 'a b c
rdlong 0,ptrb++ 'a b c altd causes ptrb++ to inc by 1*4, not by (y+1)*4
_ret_ popa x '| | c REGLOAD done, pop stack
shl y,#2 'a | update bytecode ptr for inline_pasm
add y,ptrb 'a |
call_pasm mov w,x '| | d get CALL address
popa x '| b d pop stack
mov y,pb '| b d save bytecode ptr
mov z,ptra 'a b d save ptra
call w 'a b d call pasm code (can use pa/pb/ptra/ptrb/stack)
testb v,#31 wc 'a b d if inline_pasm, restore local variables to hub
if_c setq #16-1 'a b d
if_c wrlong buff,dbase 'a b d
mov ptra,z 'a b d restore ptra
_ret_ mov pb,y 'a b d restore bytecode ptr
Some questions related to a, In-line PASM:
Q1. Is the skip pattern correct?
Q2. For max speed, couldn't rflong be used to read w and y together? More longs but quicker?
Q3. Is pb a copy of the bytecode ptr, or the actual ptr and must always point to current bytecode before doing _ret_ for the next one?
Q4. The inline PASM is copied to cog RAM and executed there, but what if, in other cases, there is no room in the cog and therefore inline code must be run in situ in hub RAM?
The last question is a general one about how to escape from bytecode to P2 code, then return to bytecode.
I've got my reasons. It's part of the Spin2 interpreter's inline PASM feature. You can load code into $000..$167 and execute it. That code sequence is for loading PASM code of some length, starting at some register, executing it, and then resuming bytecode execution from where the PASM binary left off. I needed PTRA to stay current.
Here is how this interpreter code looks now:
'
'
' a: In-line PASM
' b: REGEXEC(hubadr)
' c: REGLOAD(hubadr)
' d: CALL(anyadr)
'
inline_pasm setq #16-1 'a load local variables from hub into buff
rdlong buff,dbase 'a
bith v,#31 'a set flag to later restore local variables to hub
mov ptrb,pb 'a get bytecode ptr into ptrb
skip ##%11100100000111 'a x2 begin inline_pasm skip pattern
regexec_ skip ##%1111000000 '| b x2 begin REGEXEC skip pattern
regload_ mov ptrb,x '| b c get hubadr into ptrb
rdword w,ptrb++ 'a b c read start register
rdword y,ptrb++ 'a b c read length of pasm code, minus 1
setq y 'a b c read in code
altd w 'a b c
rdlong 0,ptrb++ 'a b c altd causes ptrb++ to inc by 1*4, not by (y+1)*4
_ret_ popa x '| | c REGLOAD done, pop stack
shl y,#2 'a | update bytecode ptr for inline_pasm
add y,ptrb 'a |
call_pasm mov w,x '| | d get CALL address
popa x '| b d pop stack
mov y,pb '| b d save bytecode ptr
mov z,ptra 'a b d save ptra
call w 'a b d call pasm code (can use pa/pb/ptra/ptrb/stack)
testb v,#31 wc 'a b d if inline_pasm, restore local variables to hub
if_c setq #16-1 'a b d
if_c wrlong buff,dbase 'a b d
mov ptra,z 'a b d restore ptra
_ret_ mov pb,y 'a b d restore bytecode ptr
Some questions related to a, In-line PASM:
Q1. Is the skip pattern correct?
Q2. For max speed, couldn't rflong be used to read w and y together? More longs but quicker?
Q3. Is pb a copy of the bytecode ptr, or the actual ptr and must always point to current bytecode before doing _ret_ for the next one?
Q4. The inline PASM is copied to cog RAM and executed there, but what if, in other cases, there is no room in the cog and therefore inline code must be run in situ in hub RAM?
The last question is a general one about how to escape from bytecode to P2 code, then return to bytecode.
1) Yes, the SKIP pattern is correct. Note that the first SKIP pattern must skip over the second SKIP which uses AUGD.
2) A RDLONG could be done, but then it would take 3 more instructions to split the words. Not worth it, I thought.
3) There is a short routine that calls this code which uses PB as a storage for the bytecode pointer which gets used in a RDFAST later.
4) The supposition is that in-line PASM, REGEXEC, and REGLOAD all use available register space. If you want to call to hub-exec code, just do a CALL(hubaddr).
All PASM code gets free use of PA/PB/PTRA/PTRB and six hardware stack levels. The in-line PASM is special because it gets to access the first 16 parameters, results, and local variables by name, since they are temporarily moved into registers $1E0..$1EF.
ON Semi contacted us today and let us know that the new wafers are already out of the fab and being sorted, so they can be sent off for packaging at Amkor. Wendy let me know that our new test program is working fine, too, so they are able to fully test the new silicon. It will take until March 3 to receive the newly packaged chips from Amkor, though. It's amazing how quickly these last wafers got built.
There is another lot of wafers coming at the end of March, but we will have lots of packaged chips before that.
I'm glad they used the test program that I modified for the new silicon. They were talking like they weren't going to use it because the risk was too high, but they did use it and it worked okay.
10 chips on March 3rd. A few thousand at end of March (many of which are booked already) with several thousand more end of April. The whole schedule was pulled in by a few weeks.
10 chips on March 3rd. A few thousand at end of March (many of which are booked already) with several thousand more end of April. The whole schedule was pulled in by a few weeks.
Yay, so I may have a P2 for my birthday instead of chipmas.
10 chips on March 3rd. A few thousand at end of March (many of which are booked already) with several thousand more end of April. The whole schedule was pulled in by a few weeks.
Yay, so I may have a P2 for my birthday instead of chipmas.
Today we received ten (10) of the revision C P2 silicon chips. They're being mounted on a couple of Propeller 2 ES Evaluation Boards and Chip is on his way to pick them up.
Today we received ten (10) of the revision C P2 silicon chips. They're being mounted on a couple of Propeller 2 ES Evaluation Boards and Chip is on his way to pick them up.
Comments
Harvard vs Von Neumann are quoted as educational examples.
http://members.casema.nl/hhaydn/howel/parts/6809_prog_model.htm
Yes. While I think the Wikipedia position on this is a bit painful, you expressed the basic idea.
I think I am going to start on one. SVG format so it can be hacked on, until it is representative. I get the feeling the moment one is started, all of the, "yes, but it needs", and "nope, that should be" chatter will get us one quickly.
The Prop 2 is challenging!
May need to do it from multiple perspectives.
Chip
COG COGEX
COG HUBEX
HUB
Smart PIN
While most of us grok the internals, we may find this sort of thing helps others.
When learning a new CPU, this is the first thing I went for.
Question: Is hubRAM also this random on power up? I think it might be. Count this as a reminder to look tomorrow.
From my experiments with power-cycling the P2 for brief periods of time after loading an picture into hubram and then displaying it with VGA, hubram ends up pretty much random after being powered off for enough time. I don't know whether certain bits tend to default to the same state on every power-up or whether it's actually random every time.
If it is, would almost be like a serial number... Would any two P2's be the same?
I've been thinking it should be possible to use these as a kind of digital thumbprint. You could certainly do a linear regression style fit to do the matching.
What would be neat is to turn this information into a code (serial number) that is sufficiently robust and unchanging.
Q1. Is the skip pattern correct?
Q2. For max speed, couldn't rflong be used to read w and y together? More longs but quicker?
Q3. Is pb a copy of the bytecode ptr, or the actual ptr and must always point to current bytecode before doing _ret_ for the next one?
Q4. The inline PASM is copied to cog RAM and executed there, but what if, in other cases, there is no room in the cog and therefore inline code must be run in situ in hub RAM?
The last question is a general one about how to escape from bytecode to P2 code, then return to bytecode.
1) Yes, the SKIP pattern is correct. Note that the first SKIP pattern must skip over the second SKIP which uses AUGD.
2) A RDLONG could be done, but then it would take 3 more instructions to split the words. Not worth it, I thought.
3) There is a short routine that calls this code which uses PB as a storage for the bytecode pointer which gets used in a RDFAST later.
4) The supposition is that in-line PASM, REGEXEC, and REGLOAD all use available register space. If you want to call to hub-exec code, just do a CALL(hubaddr).
All PASM code gets free use of PA/PB/PTRA/PTRB and six hardware stack levels. The in-line PASM is special because it gets to access the first 16 parameters, results, and local variables by name, since they are temporarily moved into registers $1E0..$1EF.
That’d be great news.
Hopefully the adc issue is fixed and everything else is the same...
I'm glad they used the test program that I modified for the new silicon. They were talking like they weren't going to use it because the risk was too high, but they did use it and it worked okay.
Yay, so I may have a P2 for my birthday instead of chipmas.
The best gift you could get.
Good luck!
Mike
And Ken's photos request - https://forums.parallax.com/discussion/169765/request-for-p2-photos-of-all-types-for-propeller-parallax-com-web-site/p1
Ken Gracey
Cool Beans!
Closer to a roll-out party!