Advantages of Parallel Hz

[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.

 

[Peter Dickerson]

|> |>
|> >> 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.

Well, my very old Alpha architecture book calls the instruction CALL_PAL,
which has a 6-bit opcode (0) and 26 function code bits (what I might call an
abstract target address). The expectation from the opcode name is that after
it does whatever it does it will return to the instruction following the
CALL_PAL instruction. JSR, presumably jump-to-subroutine, is much the same.
The differences are in how the target address is determined and some state.
But then I'd say an INTn instruction on x86 is like a call too...

Peter

 

[krw]

Petty much. More like a system call.

Is it a dedicated call to this "microcode"?

 

[krw]

Well, my very old Alpha architecture book calls the instruction CALL_PAL,
which has a 6-bit opcode (0) and 26 function code bits (what I might call an
abstract target address). The expectation from the opcode name is that after
it does whatever it does it will return to the instruction following the
CALL_PAL instruction. JSR, presumably jump-to-subroutine, is much the same.
The differences are in how the target address is determined and some state.
But then I'd say an INTn instruction on x86 is like a call too...

The (if any) difference is the system state before and after. Can
these be called from "user" state and does the PAL code run in
"system" or perhaps "microcode" state. IOW, is there a change in
protection that has to be figured in here?

 

[Nick Maclaren]

|>
|> Well, my very old Alpha architecture book calls the instruction CALL_PAL,
|> which has a 6-bit opcode (0) and 26 function code bits (what I might call an
|> abstract target address). The expectation from the opcode name is that after
|> it does whatever it does it will return to the instruction following the
|> CALL_PAL instruction. JSR, presumably jump-to-subroutine, is much the same.
|> The differences are in how the target address is determined and some state.
|> But then I'd say an INTn instruction on x86 is like a call too...

Grrk. And so would most SVCs be on System/370. But that is ONLY in
control flow, for the non-exceptional case. PALcode is documented
to change the environment, which is entirely unlike a subroutine
call on modern systems. Oh, yes, you could change addressing mode
on System/370, but full context changes at a subroutine call are
very different.

Yes, PALcode is USED like a subroutine, but that isn't how it works.


Regards,
Nick Maclaren.

 

[DaveM]

|>
|> Well, my very old Alpha architecture book calls the instruction CALL_PAL,
|> which has a 6-bit opcode (0) and 26 function code bits (what I might call
an
|> abstract target address). The expectation from the opcode name is that
after
|> it does whatever it does it will return to the instruction following the
|> CALL_PAL instruction. JSR, presumably jump-to-subroutine, is much the same.
|> The differences are in how the target address is determined and some state.
|> But then I'd say an INTn instruction on x86 is like a call too...

Grrk. And so would most SVCs be on System/370. But that is ONLY in
control flow, for the non-exceptional case. PALcode is documented
to change the environment, which is entirely unlike a subroutine
call on modern systems. Oh, yes, you could change addressing mode
on System/370, but full context changes at a subroutine call are
very different.

Yes, PALcode is USED like a subroutine, but that isn't how it works.


Regards,
Nick Maclaren.

Where has Radium gone? Haven't seen any of his dribble in a few days. Maybe
the idiocy of his notion finally sunk in??

--
Dave M
MasonDG44 at comcast dot net (Just substitute the appropriate characters in the
address)

Life is like a roll of toilet paper; the closer to the end, the faster it goes.

 

[Radium]

Where has Radium gone? Haven't seen any of his dribble in a few days. Maybe
the idiocy of his notion finally sunk in??

LOL, I'm still here and dreaming of a PC that has the advantages of
the world's current best PC along with additional advantages. For
example, my dream PC is entirely chip-based and does *not* require any
of the following:

1. Fans or other cooling equipment
2. Moving parts
3. Magnetic parts
4. Discs
5. ROM

In addition, my dream PC does not experience any latency or use any
buffering at all.

 

[Scott Wood]

LOL, I'm still here and dreaming of a PC that has the advantages of
the world's current best PC along with additional advantages. For
example, my dream PC is entirely chip-based and does *not* require any
of the following:

1. Fans or other cooling equipment
2. Moving parts
3. Magnetic parts
4. Discs
5. ROM

In addition, my dream PC does not experience any latency or use any
buffering at all.

<feed target="troll">
My dream PC can do all of the above, *and* it can give me a blowjob
at the same time! And it also doesn't need RAM! Or gates! Or
atoms!
</feed>

-Scott

 

[Daniel Mandic]

1. Fans or other cooling equipment
2. Moving parts
3. Magnetic parts
4. Discs
5. ROM

In addition, my dream PC does not experience any latency or use any
buffering at all.

take what's available or make a better one ;-), yes?


But you are right with new, so called 'modern', Soundcards.


Bloating the Kernel, MickyMouse Connectors, Crippled FLAT sound, no
instruments, whistling system-RAM sample sounds played via a
communication-OS (XP, 2000 etc.).


Purest crap in its modest form. PC.

(With hardware sound buffer ))).... what a sh..)




Best regards,

Daniel Mandic

 

[[email protected]]

LOL, I'm still here and dreaming of a PC that has the advantages of
the world's current best PC along with additional advantages. For
example, my dream PC is entirely chip-based and does *not* require any
of the following:

1. Fans or other cooling equipment
2. Moving parts
3. Magnetic parts
4. Discs
5. ROM

In addition, my dream PC does not experience any latency or use any
buffering at all.

Add to that wish list:

Peace for the peoples
Bread for the hungry
Land for the farmers
Factories for the workers

LOL

NNN

 

[Richard The Dreaded Libertarian]

Add to that wish list:

Peace for the peoples
Bread for the hungry
Land for the farmers
Factories for the workers

LOL

No problem! Just kill all of the politicians! ;-)

Cheers!
Rich

 

[MooseFET]

LOL, I'm still here and dreaming of a PC that has the advantages of
the world's current best PC along with additional advantages. For
example, my dream PC is entirely chip-based and does *not* require any
of the following:

1. Fans or other cooling equipment

We already do this.

2. Moving parts

We can do this too.

3. Magnetic parts

Why would you care if it is magnetic? Non-linear magneto-optical
effects could allow very fast logic at extremely low power levels.

4. Discs

We already do this.

5. ROM

Why no ROM. It is very handy stuff.

 

[[email protected]]

No problem! Just kill all of the politicians! ;-)

And kill it was!!!

Cheers!
Rich

Looks like you didn't get the dark humor of that enumeration.
Originally there was one more item on the list: "All power to the
Sovets!" These populist slogans were coined by Lenin in Apr.1917, and
resulted in the Communist coup in Nov.1917. Politicians were indeed
killed, and then more and more of them. The killings continued up to
the death of Stalin in 1953, and then some.
But then, you've got a legitimate excuse that the US schools don't
teach Russian history in such details. Though IMO they should, at
least this part - to make sure the history does not repeat itself.
Every time a politician declares his/her intent to stand for "Peace
for the peoples" and "Bread for the hungry" I hear deep inside me
Lenin's voice demanding ALL power.

NNN

 

[Radium]

We already do this.

We can do this too.

Why would you care if it is magnetic? Non-linear magneto-optical
effects could allow very fast logic at extremely low power levels.

Eventually the signal has to become electric for processing. Why waste
time converting signals from electric to magnetic [and visa versa]?

We already do this.

Why no ROM. It is very handy stuff.

Because I prefer that the info usually stored in ROM, be generated in
real-time.

The following is a bad analogy but I'll add it anyway.

PC reading info from ROM = sample playback synth playing back its
samples of sounds of an FM synth.

PC chip generating its signals in real-time = an *actual* FM synth
freshly-generating its tones "on the fly".

Yes, I know, the above is a poor analogy but I couldn't think of
anything better.

 

[Ken Hagan]

Eventually the signal has to become electric for processing. Why waste
time converting signals from electric to magnetic [and visa versa]?

No problem, just use electromagnetic devices for everything. No tedious
conversions necessary.

 

[John Fields]

LOL, I'm still here and dreaming of a PC that has the advantages of
the world's current best PC along with additional advantages. For
example, my dream PC is entirely chip-based and does *not* require any
of the following:

1. Fans or other cooling equipment
2. Moving parts
3. Magnetic parts
4. Discs
5. ROM

In addition, my dream PC does not experience any latency or use any
buffering at all.

 

[MooseFET]

Why would you care if it is magnetic? Non-linear magneto-optical
effects could allow very fast logic at extremely low power levels.

Eventually the signal has to become electric for processing. Why waste
time converting signals from electric to magnetic [and visa versa]?

I think you missed the point. The signals start out as keystrokes and
mouse clicks and end up as dots on a CRT. We only make them into
electronic signals because we have a very easy way to process
electronic signals. There is no reason to not convert them to light
or magnetic fields if that provides a way to process them very quickly
at low power levels.

[.....]

Because I prefer that the info usually stored in ROM, be generated in
real-time.

The "generated in real-time" step requires hardware that knows what to
generate. How do you propose that the hardware knows what to do.
Remember that logic gates can perform AND and OR operations but they
can't create information. All the information must come from
somewhere.

The following is a bad analogy but I'll add it anyway.

PC reading info from ROM = sample playback synth playing back its
samples of sounds of an FM synth.

PC chip generating its signals in real-time = an *actual* FM synth
freshly-generating its tones "on the fly".

Yes, I know, the above is a poor analogy but I couldn't think of
anything better.

Perhaps you can't come up with a good explanation because you need to
think this part through a bit more. I'll get you started with a very
simple case. My keyboard has a "A" key. When I press it the hex code
for the letter "a" or for the uppercase "A" gets created. Which code
gets created depends on the state of the shift key. The "a" key and
the shift key just close switches. Without having a ROM how would the
circuit make the right codes.

 

[MooseFET]

Eventually the signal has to become electric for processing. Why waste
time converting signals from electric to magnetic [and visa versa]?

No problem, just use electromagnetic devices for everything. No tedious
conversions necessary.

Actually all the signals would be light. The magnetic field would be
sort of a bias point.

 

[Guy Macon]

He said he is Aspergered. This will mean that he may have some
trouble really understanding your suggestion and its intended
purpose. It doesn't prevent him from learning electronics but he will
have to develop his own was of dealing with things. It is likely that
he will work in terms of images in places you would work with
equations.

My suggestion was that he work with actual electronic components.
A proto-board and 74HC chips will teach him far more than this
discussion ever will.

Guy Macon
<http://www.guymacon.com/>