How to read code from P87C750?

Rotate Right. As Spehro said, you can replace it with 8 Rotate Left instructions. And it may have been robust with EMI, but it was seriously slow.

13 clocks to read an instruction at 8MHz. Nearly as bad as the CDP1802 from RCA.
Reply to
Rocky
Loading thread data ...

I've seen several CPUs that don't have instruction counters. One had an LFSR to do the instruction fetch. That was weird but the assembler/compiler straightened everything out for the user.

The higher level PowerPCs (and I suspect the same goes for all OoO, super-scalars) don't have any piece of hardware called an "instruction counter". There is an Instruction Address Register that points to the next instructionS to get fetched from memory. The instructions then get thrown into the hopper and decoded sometime later. When they execute is up to the hardware to figure out. An "instruction counter" makes no sense in an architecture like this. There is, of course a virtual PC that the programmer would imagine his program executing from but it doesn't exist in reality.

Reply to
krw

therby reducing the worst-case carry propogation time on the increment, neat.

that doesn't sound radically different to the prefetch on the 8088

When you call a subroutine what goes onto the stack, how virtual is that PC?

--
?? 100% natural
Reply to
Jasen Betts

It is, because the 8088 executed everything in order. OoO machines don't (duh!).

Well, it does have a virtual address (which somehow maps to a real address - somewhere). But there is no "instruction counter" at all.

Reply to
krw

neat.

"instruction

the

counter"

Well let's see. Intel calls the register pair CS:IP for code segment and instruction pointer. Please explain to us just how instruction pointer is all that different from instruction counter.

?-)

Reply to
josephkk

It's not, but the IP increments pointing to the next instruction executed. In a 8086/8 the instructions are fetched and executed in order, OK, with some pipeline delay. In an OoO processor the instructions are *not* executed in any order (by definition) defined by an IP. Ad virtualization on top and the counter or "pointer" no longer exists, excepts in the minds of the programmers. Buckets of instructions are shoveled in at the top in some almost random order, the instructions are executed in any order, and the results are posted when all of the inputs to the instructions are known. There is no piece of hardware that tells you what address is currently being executed, or will execute next. The concept doesn't exist.

Add virtualization and the concept of the IP, as a piece of hardware, gets even more murky.

Reply to
krw

and

is

No, the situation is nowhere as severe as you imagine. Instructions are not executed randomly at all, there is some indeterminism of the execution (completion) order in fine, but not in large. The Tomasulo algorithm and register scoreboarding are methods to keep track of when a particular instruction can be retired (removed from the pending list).

Virtualization, per se, has nothing to do with it. The virtual machine implemented may be a totally different architecture. Java comes to mind.

Yet the effect of all of these things must be, to not disrupt the semantics of the instruction stream as supplied in the executing code versus what would happen on a machine without these properties.

QED; the instruction pointer concept is still valid as a programming concept and as a hardware register.

?-)

Reply to
josephkk

CLueless.

I was in the development group (tracked these things daily) on the PPC970. I *KNOW* how they work.

When you've got a hundred instructions in flight, some executing several times, it is "random".

It might be *exactly* the "same" architecture, 370, PPC, X86. Though the concept of "architecture" tends to break down at some point down in the muddle.

Good grief. Learn how to read.

Good grief. Learn how to read.

Reply to
krw

If you have an old 16 bit laying about put the ROM contents into a disk file and view the hex dump with Xtreegold.

Reply to
Ian Field

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.