Advantages of Parallel Hz

[Wilco Dijkstra]

On May 8, 2:37 pm, "Wilco Dijkstra" <[email protected]>
wrote:

No, the criteria is that the number of instructions be low and the
transistors that would have done the seldom used instructions used to
speed up the common ones.

Or in other words, fewer and simpler instructions that can execute directly
in 1 cycle - thus not needing micro code.

I don't think you would want to call
something like the CDP1802 a RISK. It had no microcode. It had 16,
16 bit registers and a low number of instructions.

I doubt that it had no micro code. Instructions take 16 or 24 clock cycles to
complete, far worse than similar microcoded CPUs of that era, like Z-80.
If it was micro sequenced like 6502 instructions would take 1-3 cycles.
In any case it definitely doesn't fit any of the RISC criteria.

Wilco

 

[daytripper]

Simple instructions in the architecture implies no microcode in the implementation.


Complex is a relative term. POWER, unlike most other RISCs, has quite a few
complex instructions that take more than 1 cycle, do more than 1 memory access
or have more than 2 input and 1 destination register (all RISC criteria). Examples
are multiple load/store, load/store with base update, unaligned load/store, string
instructions, and so on...

Alpha is an example of a pure RISC that only supports simple instructions.

[...]

And an example of a microcoded RISC processor.

There blows your theory ;-)

/daytripper

 

[MooseFET]

Or in other words, fewer and simpler instructions that can execute directly
in 1 cycle - thus not needing micro code.

I think "in a low number of cycles" qualifies as well as one cycle.
Also if you include the very long instruction word machines in the
RISC group, you wouldn't really have a low number of instructions.
You can have quite a few instructions. Some may even argue that the
instructions aren't "simple". Simple is often in the eye of beholder.

A very long instruction machine may have an instruction like:

IF SIGN THEN R1 = R2 + R3++

This whole thing would be done in one machine cycle.

I doubt that it had no micro code. Instructions take 16 or 24 clock cycles to
complete, far worse than similar microcoded CPUs of that era, like Z-80.
If it was micro sequenced like 6502 instructions would take 1-3 cycles.
In any case it definitely doesn't fit any of the RISC criteria.

The 1802 was all serial internally. The instructions are done
directly without micro code but very slowly because the bits all shift
around for each instruction. The transistor count was very low.

 

[Robert Redelmeier]

A bigger market might be "standalone" thin clients. Home internet
appliances with built-in browsers, but otherwise no programmability
(state retained). Certainly more than the 32 MB LTSP minimum, but
probably not more than 128 MB RAM. US$50 plus monitor (or S-video/HDMI
out for exhibitionists/remotecontrol-hogs who want to surf on the TV!)

Such a device would be attractive to non-computer experts
(nothing to go wrong) or as second PCs in a household.

You could even use a USB port and flashsticks to hold per-user
state (settings, downloaded email, files, etc, pgms?).
Appliance-PC totally unwriteable (inviolate) except by flash
upgrades and maybe some PPPoE login credentials.

-- Robert

 

[krw]

Simple instructions in the architecture implies no microcode in the implementation.

It implies nothing of the kind. You may infer this (incorrectly).

Complex is a relative term. POWER, unlike most other RISCs, has quite a few
complex instructions that take more than 1 cycle, do more than 1 memory access
or have more than 2 input and 1 destination register (all RISC criteria). Examples
are multiple load/store, load/store with base update, unaligned load/store, string
instructions, and so on...

Those are "simple" instructions, for the purposes of "RISC".

Alpha is an example of a pure RISC that only supports simple instructions.


They most definitely are not. You're confusing the out of order execution engine
with a micro code engine. These are completely different beasts.

No I'm not. You simply have no clue what you're talking about here.
Each instruction (even the single cycle ones) is translated in the
microcode "PLA".

 

[nobody]

Simple instructions in the architecture implies no microcode in the implementation.


Complex is a relative term. POWER, unlike most other RISCs, has quite a few
complex instructions that take more than 1 cycle, do more than 1 memory access
or have more than 2 input and 1 destination register (all RISC criteria). Examples
are multiple load/store, load/store with base update, unaligned load/store, string
instructions, and so on...

Alpha is an example of a pure RISC that only supports simple instructions.


They most definitely are not. You're confusing the out of order execution engine
with a micro code engine. These are completely different beasts.

Wilco

Boy you don't know who you're up against. Don't even try to provoke
the heavyweights like Keith or Daytripper. If your musings have even
a slitest hole - and I bet there are quite a few - they'll find it and
rip you apart.

NNN

 

[The little lost angel]

Boy you don't know who you're up against. Don't even try to provoke
the heavyweights like Keith or Daytripper. If your musings have even
a slitest hole - and I bet there are quite a few - they'll find it and
rip you apart.

Especially when some of these heavyweights might have actually had a
hand in developing the item in discussion. pP

 

[Wilco Dijkstra]

I think "in a low number of cycles" qualifies as well as one cycle.

Yes. The original goal of RISC was to execute all instructions in one cycle,
but having multicycle instructions is better than splitting them into simpler
ones (eg. multiply/divide steps were a bad idea like branch delay slots).
But you'd want the vast majority of ALU instructions to execute in 1 cycle
with results available in the next cycle.

Also if you include the very long instruction word machines in the
RISC group, you wouldn't really have a low number of instructions.
You can have quite a few instructions. Some may even argue that the
instructions aren't "simple". Simple is often in the eye of beholder.

Yes one instruction can specify several operations, but the number of
operations is far smaller than on RISCs as each operation field has
a specific purpose on VLIW. VLIW is one step beyond RISC making
instructions even easier to decode and execute.

A very long instruction machine may have an instruction like:

IF SIGN THEN R1 = R2 + R3++

This whole thing would be done in one machine cycle.

Yes. ARM has many instructions like that.

The 1802 was all serial internally. The instructions are done
directly without micro code but very slowly because the bits all shift
around for each instruction. The transistor count was very low.

OK, so there are effectively 3 micro sequence steps then. Being serial
explains the low power usage as well.

Wilco

 

[Wilco Dijkstra]

On Wed, 09 May 2007 09:18:19 GMT, "Wilco Dijkstra"

Alpha is an example of a pure RISC that only supports simple instructions.

[...]

And an example of a microcoded RISC processor.

Troll.

Point me to a Alpha micro architecture document that proves it is micro coded.

Wilco

 

[krw]

On Wed, 09 May 2007 09:18:19 GMT, "Wilco Dijkstra"

Alpha is an example of a pure RISC that only supports simple instructions.

[...]

And an example of a microcoded RISC processor.

Troll.

'tripper a troll? You sir, are *nuts*.

 

[kony]

You could even use a USB port and flashsticks to hold per-user
state (settings, downloaded email, files, etc, pgms?).
Appliance-PC totally unwriteable (inviolate) except by flash
upgrades and maybe some PPPoE login credentials.

-- Robert

If thin clients are running off a central server(s) why
would you require per-user settings on yet another device
that adds to the complexity instead of just storing on the
central server(s)?

Not that thumbdrives are a bad idea for mobile data &
settings but it would seem more useful when that user is
away from the thin client network rather than on it. Except
perhaps if these are public terminals where there are no
assigned accounts.

 

[daytripper]

On Wed, 09 May 2007 09:18:19 GMT, "Wilco Dijkstra"

Alpha is an example of a pure RISC that only supports simple instructions.

[...]

And an example of a microcoded RISC processor.

Troll.

Point me to a Alpha micro architecture document that proves it is micro coded.

Wilco

Easily done: Google "palcode" and go from there...

/daytripper

 

[Eliot Miranda]

On Wed, 09 May 2007 09:18:19 GMT, "Wilco Dijkstra"
Alpha is an example of a pure RISC that only supports simple instructions.
[...]

And an example of a microcoded RISC processor.

Troll.

Point me to a Alpha micro architecture document that proves it is micro coded.

Wilco

Easily done: Google "palcode" and go from there...

"In the VAX, these functions are generally provided by microcode. This
is not seen as a problem because the VAX architecture lends itself to a
microcoded implementation.

One of the goals of Alpha is that microcode will not be necessary for
practical implementation. However, it is still desirable to provide an
architected interface to these functions that will be consistent across
the entire family of machines. The Priviledged Architecture Library
(PALcode) provides a mechanism to implement these functions without
resorting to a microcoded machine."

Alpha Architecture Reference Manual, Ch 6. Common PALcode Architecture.

PALcode ain't microcode. Its a subroutine library that implements
low-level operations the designers didn't want to support in hardware.

 

[Andrew Reilly]

Alpha is an example of a pure RISC that only supports simple instructions.
[...]

And an example of a microcoded RISC processor.

Troll.

Point me to a Alpha micro architecture document that proves it is micro coded.

Wilco

Easily done: Google "palcode" and go from there...

I doubt that there would be many reading this thread in comp.arch who were
completely comfortable seeing palcode called microcode. They achieve some
of the same ends, but there are some significant differences.

I don't read any of the other groups, so perhaps dialects differ, there,
but I'd have thought that the comp.arch group dialect was authorative on
this particular topic...

Cheers,

 

[daytripper]

On Wed, 09 May 2007 09:18:19 GMT, "Wilco Dijkstra"
Alpha is an example of a pure RISC that only supports simple instructions.
[...]

And an example of a microcoded RISC processor.
Troll.

Point me to a Alpha micro architecture document that proves it is micro coded.

Wilco

Easily done: Google "palcode" and go from there...

"In the VAX, these functions are generally provided by microcode. This
is not seen as a problem because the VAX architecture lends itself to a
microcoded implementation.

One of the goals of Alpha is that microcode will not be necessary for
practical implementation. However, it is still desirable to provide an
architected interface to these functions that will be consistent across
the entire family of machines. The Priviledged Architecture Library
(PALcode) provides a mechanism to implement these functions without
resorting to a microcoded machine."

Alpha Architecture Reference Manual, Ch 6. Common PALcode Architecture.

PALcode ain't microcode. Its a subroutine library that implements
low-level operations the designers didn't want to support in hardware.

And given even cisc machines hardwire the quick stuff and bin the rest to
microcode, where's the distinction, again?

/daytripper

 

[Andrew Reilly]

And given even cisc machines hardwire the quick stuff and bin the rest to
microcode, where's the distinction, again?

Microcode is an implementation technique: one of many. There have been
no-microcode CISC machines in the past. Look up the Z8000 and Z80000
parts some time: their designer was famous for not liking microcode, yet
they're pretty much cannonical CISC machines for their time. Even the
non-quick stuff was hard coded.

PAL-code isn't microcode because it's essentially the same instruction
set, processed through the same decoders and schedulers as the externally
visible instruction set. It's a subroutine library.

 

[Robert Redelmeier]

If thin clients are running off a central server(s) why would
you require per-user settings on yet another device that adds to
the complexity instead of just storing on the central server(s)?

They wouldn't, of course. I switched from talking about
tethered thin-clients to standalone thin "clients". Something
of an oxymoron because these are full [small] appliance-like
machines, nobody's client. Although they could be made so.

Not that thumbdrives are a bad idea for mobile data & settings
but it would seem more useful when that user is away from the
thin client network rather than on it. Except perhaps if these
are public terminals where there are no assigned accounts.

I'm thinking more along the lines of public terminals (tethered
to a server in larger installations like schools, standalone
in convenience kiosks) _and_ multi-user use in homes. Plug in
your stick, and any machine is basically the same as home.
Something like Google is trying to do with their massive
servers for gmail and goffice and Yahoo my.yahoo.com .

-- Robert

 

[krw]

Microcode is an implementation technique: one of many. There have been
no-microcode CISC machines in the past. Look up the Z8000 and Z80000
parts some time: their designer was famous for not liking microcode, yet
they're pretty much cannonical CISC machines for their time. Even the
non-quick stuff was hard coded.

Of course there are examples of hardwired CISC machined (360/75).
That wasn't the point.

PAL-code isn't microcode because it's essentially the same instruction
set, processed through the same decoders and schedulers as the externally
visible instruction set. It's a subroutine library.

Is it called by a JSR instruction?

 

[Peter Dickerson]

Of course there are examples of hardwired CISC machined (360/75).
That wasn't the point.


Is it called by a JSR instruction?

Petty much. More like a system call.

Peter

 

[Nick Maclaren]

|> |>
|> >> PAL-code isn't microcode because it's essentially the same instruction
|> >> set, processed through the same decoders and schedulers as the externally
|> >> visible instruction set. It's a subroutine library.
|> >
|> > Is it called by a JSR instruction?
|>
|> Petty much. More like a system call.

I think that you meant "Not really"! It changes to kernel context
(well, roughly).

There were systems that had the equivalent that was more like a
subroutine - the Ferranti Atlas/Titan extracodes were done like that.
There are MASSIVE advantages to such a mechanism, because it can be
used to provide complex instruction emulation efficiently and
transparently without any of the scheduling or RAS problems that
come in if you have iffy PALcode.


Regards,
Nick Maclaren.