WAITPNE: a missed opportunity?

Phil Pilgrim (PhiPi)

When using the waitpne d,s instruction, it's almost always necessary to know which bits caused the mismatch. One can always read ina, of course, and with s, and xor with d, but that won't always yield the correct information. The problem comes if ina changes again between the waitpne and the read of ina. Plus, if you want to reuse the same waitpne, you've got to rewrite d with the current state.

Wouldn't it have been neat if waitpne d,s wr did all that for you? d would not only be rewritten automatically, but with the actual state of ina & s that caused the waitpne to terminate, not something that gets read later. But, alas, executing waitpne d,s wr results in d += s+1! I'm not sure if this was an accident, an oversight, or a "running out of silicon" problem. Perhaps the more useful behavior will be included in the Prop II.

-Phil

Cluso99

Phil, a definate idea for the Prop II. However, IIRC, the various bits were being used for numerous instructions and I believe that is also how Chip is getting the extra instructions for the prop II.

In fact, once again IIRC, the wr bit is used to differentiate the read and write to hub. Very smart indeed.

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

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Phil Pilgrim (PhiPi)

waitpne isn't a hub instruction. I think it's the wc bit that's used in this instruction to differentiate between ina and inb. (The manual says the carry bit itself is used for this, but that has to be wrong.)

-Phil

ericball

Yeah, I was reading the instruction manual for WAITPNE (probably for the same challenge you were) and was trying to make sense of the result. And I agree that D := INA & S would be the ideal result.

However, I think there's more to it than simply running out of silicon. I suspect the WAITPNE / WAITPEQ logic is handled outside of the ALU path, so it doesn't have access to the result bus. (Although the hub instructions write a result.) There also may be pipeline issues if the wait states happen after the write result state.

I wouldn't be sure that WC is the INA/INB flag - I bet Chip did intend on using the Carry bit. (Although I agree that using WC would have been easier from a coding perspective.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Phil Pilgrim (PhiPi)

I don't think using the carry flag for choosing between ina and inb would make any sense. That's why I'm assuming the manual is in error. Not only would using carry in this way break an otherwise beautiful archtectural symmetry, but I can't imagine a situation where I'd want the result of a prior instruction to affect which entire bank of 32 pins I'd want to monitor. It's better left as part of the instruction itself. Besides, there's already a mechanism for selecting an instruction based on the carry flag: if_c and if_nc.

-Phil

Mike Green

It may make more sense in some ways to use the WC bit to choose between INA and INB, but the I/O driver code that Chip wrote that assumes both INA and INB are available does use the carry flag for choosing between I/O banks.

Cluso99

I was referring to read/write-byte/word/long hub instructions. The wr bit is on for read from hub (because it is writing to cog) and the wr bit is off for write from hub (because it is not writing to cog) - same op code - very smart indeed!!!

Once you start to do an emulation of the prop op codes and flags (I started on a Spartan 3A FPGA), you see that Chip is/was extremely smart in how he designed the prop. It's a pitty other micros were not done with the same foresight, especially the Intel 80x86 family !!!

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

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

kuroneko

Phil Pilgrim (PhiPi) said...
I don't think using the carry flag for choosing between ina and inb would make any sense. That's why I'm assuming the manual is in error.

The manual also says that the P8X32A is an exception to the rule, it uses always ina. So the manual may well be right regarding the carry flag. We just can't validate it [noparse]:)[/noparse]

Phil Pilgrim (PhiPi)

Mike Green said...
...the I/O driver code that Chip wrote that assumes both INA and INB are available does use the carry flag for choosing between I/O banks.

Wow. He must have had his reasons, but I'm at a loss with that one. It's going to break a lot of code that carries the carry over a wait instruction if that scheme persists in the Prop II.

-Phil

Addendum: This really bothers me. Nowhere else is the carry flag — a state variable that can be set gosh knows where — used implitictly to determine the operands of an instruction. It runs against the grain of the entire architecture.

Post Edited (Phil Pilgrim (PhiPi)) : 10/5/2009 3:22:36 AM GMT

Cluso99

The carry flag is indeed used for selecting INA & INB. It is just that the Prop I just uses INA for both INA & INB.

Why do I know this... The spin interpreter uses the carry flag to select INA and INB. There is no change required to the ROM for a Prop IB.

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

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Phil Pilgrim (PhiPi)

Cluso99 said...
Once you start to do an emulation of the prop op codes and flags (I started on a Spartan 3A FPGA), you see that Chip is/was extremely smart in how he designed the prop.

There's certainly no denying that. But this is akin to Leonardo painting a small tattoo on the Mona Lisa's left bosom: it wouldn't have detracted from his oeuvre, yet art scholars would still be arguing loudly about why he did it.

-Phil

potatohead

I think he did it to fit the SPIN interpreter into one COG. [noparse]:)[/noparse] Just a guess on my part, but it's a reason I can think of that makes sense.

Maybe we will find out some day.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!

Cluso99

No potatohead. Chip was very specific in his spin interpeter.

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

· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm