Prop II , CLUT ram and RDQUADL/WRQUADL OR How fast can you reload a Prop II C

LewisD

Hi Chip,
I was rereading some of the old thread about the prop II and daydreaming about the future again.
I came across your posts about the CLUT ram as well as your post about read/write 4 longs to/from HUB memory.(RDQUADL/WRQUADL )
I was hoping you could give some more hints about these two items.
The most interesting question I have is : Will the CLUT ram·be persistent over a COG reload?
Example:
I load a COG with a program that samples data and stores it into the CLUT.
I reload the same COG with new code to work on the sampled data in the CLUT.
The other question I have is : How fast will a Prop II cog load/reload and will it use the new RDQUADL/WRQUADL instructions to do it?
Example:
ericball said:“CogInit/CogNew forces the cog to execute a RDLONG for each word of cog RAM.·
So the startup delay will be 512*16 = 8192 cycles
(probably a few more for the initial HUB access and other startup delays). “ (Link)
Prop I
Cog memory in longs = 512
Hub access time in cycles = 16
512*16 = 8192 cycles
Currently it take a Prop I cog· ~ 0.1024 ms to reload with the cog at 80 MHz.
Prop II
Cog memory in longs = 512
Hub access time in cycles = 8
512*8 = 4096 cycles
At 160MHz that is ~ 0.0256 ms ?
Or will the Prop II us the fatter pipe and load 4 longs per HUB access?
Prop II using 4 long HUB access
Cog memory in longs = 512 / 4 long per HUB access = 128 loads
Hub access time in cycles = 8
128*8 = 1024 cycles
At 160MHz that is ~ 0.0064 ms or ~6.4us or ~156250 time a sec?
“As your teacher Mr. Spock is fond of saying: I like to think that there are always possibilities. “ -Kirk
LewisD

cgracey

LewisD,

The CLUT will not be rewritten during a cog reload, so it will retain its prior contents.

Currently, the cog does not use the four-long pipe for reloading, since this would complicate the circuitry for what seems like only a marginal benefit (to me, at this time, anyway). This means that a load takes 512 * 8 cycles, which at 160MHz is 25.6us.

Chip

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

LewisD

Hi, Chip

I'm very happy to hear the CLUT will be persistent.
And reloading a COG at 25.6us is 4x faster then the Prop I.

I will be daydreaming for a while with this information.

Thank you Chip!

LewisD

Cluso99

@Chip: I am presuming with the repeat instruction and the quad read, we could reload most of the cog from within the cog at the faster speed anyway (like a variable length overlay). Is this correct?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

cgracey

Cluso99 said...
@Chip: I am presuming with the repeat instruction and the quad read, we could reload most of the cog from within the cog at the faster speed anyway (like a variable length overlay). Is this correct?

Yes, a cog can reload itself (once running) at 4x speed using the RDQUAD and INDirect registers. No need to even use the repeat. This will make overlays take 6.4us, or more likely a fraction of that time, since you are only overlaying a fraction of the cog's memory.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

Sapieha

Hi Chip Gracey (Parallax)

My concern is if we will have instructions to handle BITS/BYTES/WORDS in LONG's that not needs little programs to handle that.
As Swapping Bytes/Words, Moving Bytes/Words from one long to other in any position, reordering Bits significance in Bytes/Words/Longs, moving Bit/Bit's from one long to other with possibility to change its placement.

Regards
Christoffer J

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Cluso99

Thanks Chip. This will be excellent for overlays, or even for reloading the cog.

We can use an extremely short stub and perform a waitpeq for one of the internal pins (to minimise power). Another program only needs to set the hub with an address+length and set the pin and the cog could reload itself (without resetting any registers). This opens up a lot of possibilities.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

evanh

Sapieha said...
As Swapping Bytes/Words, Moving Bytes/Words from one long to other in any position, reordering Bits significance in Bytes/Words/Longs, moving Bit/Bit's from one long to other with possibility to change its placement.

So ... purpose endianess instructions then? There is the REV instruction. Isn't that suitable?

Bill Henning

No, the reason for these would be quick shuffling of bytes, quick assembly of longs from bytes, quickly extracting specific bytes from a long etc - and this would significantly speed up external memory, pixel plotting, etc

evanh said...

Sapieha said...
As Swapping Bytes/Words, Moving Bytes/Words from one long to other in any position, reordering Bits significance in Bytes/Words/Longs, moving Bit/Bit's from one long to other with possibility to change its placement.

So ... purpose endianess instructions then? There is the REV instruction. Isn't that suitable?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

Cluso99

Bill: Hopefully we will not need external memory (tongue in cheek)! At least we will have the pins as I guess one of my first pcbs will have external memory as I see EVEN MORE uses for it with Prop II · DR-DOS 6.0 emulation perhaps???

And I don't see the requirement for external memory on Prop I disappearing either as I expect the Prop II to legitimise the Prop I and there is a lot left for the Prop I

BTW: I have stopped asking for features as I just want the Prop II no matter what it ends up with. The revealed features are good enough for me.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

evanh

Bill: Mask and shift covers those cases surely? That's only two instructions per byte instead of one per byte for special case instruction. Doesn't sound like a great advantage just off hand. Got some examples of what you mean?

Bill Henning

Mask/shift/or is far slower than byte manipulation of registers.

Proposed syntax:

movbDS dst,src

D=byte destination is placed in
S=byte source is fetched from

Examples:

movb00 reg,ina
movb10 reg,ina
movb20 reg,ina
movb30 reg,ina

Packs P0-AP7 into reg in 4 instructions

movb01 reg,ina
movb11 reg,ina
movb21 reg,ina
movb31 reg,ina

Packs P8-P15 into reg in 4 instructions

and so on.

movb03 r2,r1
movb12 r2,r1
movb21 r2,r1
movb30 r2,r1

Big endian/little endian conversion

movw01 dst,src
movw10 dst,src

would also be very useful.

- external memory data bus can be on any 8 bit boundary
- a long can be unpacked faster for emulators

also, Cluso... I asked for this feature over a year ago, in the original P2 threads - so its not like I am asking for a new feature; I was actually explaining what Sapieha was asking for.

evanh said...
Bill: Mask and shift covers those cases surely? That's only two instructions per byte instead of one per byte for special case instruction. Doesn't sound like a great advantage just off hand. Got some examples of what you mean?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system

Post Edited (Bill Henning) : 4/15/2010 4:15:57 PM GMT

Cluso99

Bill: Yes I did recall that. Just hoping this thread does not go the way of the others.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz

evanh

Good point, and-shift-or is three instructions per byte. And I presume this is a tight burst loop you have in mind.

That example of big to little-endian byte shuffle you've given is a corrupted form. But surprisingly common all the same. If the wiring was done correctly then the REV instruction would be the correct one to use.

PowerPC representation of data encoding perfectly fits little-endian but it's only used as a big-endian processor.

evanh

External serial memories will become faster and more prominent in the future I expect. And being able to process multiple serial streams from one device would also be a bonus - does that cover fast SD cards or are they just parallel nibbles?

JRetSapDoog

It's·kind of a pity that the proposal I mentioned in Sapieha's thread "MOV Reverse

---

Ideas to Chip Gracey (Parallax)" for a general-purpose bit manipulator·would consume too much silicon, provide too little benefit for the costs involved, simply not work due to flawed design, or any combination of the foregoing.· Anyway, I gave it a shot and we can dream.· However, I, too, am ready for whatever we can get (as reasonably soon as we can get it), greedy guy that I am.

By the way, I noticed that some speakers of Chinese have difficulty distinguishing between l's and r's and producing the same.· As such, sometimes the saying "My pleasure!" in response to "Thanks" will come out sounding like "My pressure!"· I kind of like that and so I've adopted that and sometimes say it in response to the·thanks I receive (on the rare occassions I have ability to help).· I think Chip should adopt this habit anytime we say "Thanks" to him for his hard work, etc.· It's his pressure.· Actually, it's both:· both pleasure and pressure...mixed together in hopefully an overall good·way.