24 Jul
2014
24 Jul
'14
7:22 p.m.
On Thu, Jul 24, 2014 at 4:21 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
[1] The VAX11/730 also loads the CPU microcode at
power-up, but from what
I rememebr, ther eare some hardware features that optimise it for the VAX
instruction set. While it is possible to give it a differnet instruciton
set, I think it wopuld be a lot less efficient.
All of the microcoded processors DEC designed, whether they had
loadable microcode or only ROM, had hardware that was substantially
oriented toward the normal DEC macroinstruction set(s), and would have
been very inefficient at implementing other instruction sets. The
VAX-11/7xx series hardware was designed for efficient execution of
both VAX and PDP-11 instruction sets, but the other machines were
designed for a single instruction set only. Even the machines that
officially supported user-written microcode (PDP-11/03, PDP-11/60,
some VAXen) were generally unsuited to implementing entirely different
instruction sets, and user-added instructions were expected to have
similar structure to standard instructions. The Western Digital chip
set used in the PDP-11/03 was used for at least two other instruction
sets, the WD16 used by Alpha Micro, which was very similar to the
PDP-11, and the Pascal Microengine, which executed UCSD p-System
p-code. The latter was not a very efficient use of the
microarchitecture, and consequently the Pascal Microengine was not
much faster than the UCSD p-System running on the fastest
general-purpose microprocessors available at its introduction. Since
general-purpose microprocessors were evolving quickly, soon it was too
slow to be taken seriously.
Early on, it was very expensive to use fast RAM chips for a microcode
store, so DEC used bipolar PROMs except on relatively high-priced
machines (e.g., KL10 and KS10), and if serious bugs were found, the
microcode PROMs had to be replaced.
For the KS10, it was considered that the RAM chips used in the control
store were unreliable, so they did parity checking on the control
store, and if there was an error, the CPU would halt and the console
processor would reload the control store. They patented that:
http://www.google.co.in/patents/US4231089
The VAX-11/780 introduced the concept of patchable control store,
where most of the control store was PROM but there was a small amount
of patch RAM. Costs of high speed RAM declined quickly enough that
most later non-microprocessor VAXen used entirely RAM control store.
With the advent of VAX microprocessors, the larger die area required
for RAM vs ROM shifted the economics shifted back to favor ROM with a
small RAM patch area.
25 Jul
25 Jul
12:04 a.m.
On Thu, Jul 24, 2014 at 10:22 PM, Eric Smith <spacewar at gmail.com> wrote:
...
The VAX-11/780 introduced the concept of patchable control store,
where most of the control store was PROM but there was a small amount
of patch RAM. Costs of high speed RAM declined quickly enough that
most later non-microprocessor VAXen used entirely RAM control store.
With the advent of VAX microprocessors, the larger die area required
for RAM vs ROM shifted the economics shifted back to favor ROM with a
small RAM patch area.
Intel started supporting a RAM patch area, I believe, after the Pentium bug
so that they could field-update during the low-level boot process to
(quietly!) overcome any similar problem in the future. Does anyone have
more specifics on this feature, and does this capability currently exist in
any of their more modern CPU architectures?
-----
paul
3:56 a.m.
On 7/25/2014 12:04 AM, Paul Birkel wrote:
On Thu, Jul 24, 2014 at 10:22 PM, Eric Smith
<spacewar at gmail.com> wrote:
As far as I know they still have a patch capability, but I think the
processors run pretty well before they leave the fold now days. There is
a capability to load and install signed blocks of updates that are added
to bios which support some processors. These are dumped into the
processor and are encrypted so that the bios manufacturers have little
to no way to know what they contain. The processor unpacks and does
with them as need be after the bios dumps them in (or as they do, don't
know the mechanism fully).
The mechanism in the Pentium was almost open compared to what is there
now. All of this is under heavy NDA as far as it even being there, and
it may or may not be these days.
...
The VAX-11/780 introduced the concept of patchable control store,
where most of the control store was PROM but there was a small amount
of patch RAM. Costs of high speed RAM declined quickly enough that
most later non-microprocessor VAXen used entirely RAM control store.
With the advent of VAX microprocessors, the larger die area required
for RAM vs ROM shifted the economics shifted back to favor ROM with a
small RAM patch area.
Intel started supporting a RAM patch area, I believe, after the Pentium bug
so that they could field-update during the low-level boot process to
(quietly!) overcome any similar problem in the future. Does anyone have
more specifics on this feature, and does this capability currently exist in
any of their more modern CPU architectures?
-----
paul
10:24 a.m.
On 7/25/2014 3:56 AM, jwsmobile wrote:
The mechanism in the Pentium was almost open compared
to what is there
now. All of this is under heavy NDA as far as it even being there, and
it may or may not be these days.
It has been widely speculated (and supported by the Snowden documents)
that the NSA can defeat the Intel random number generator - and
therefore any crypto based on that RNG) with a microcode patch.
Microcode patches - it's not just for /fixing/ bugs...
Rob
12:10 p.m.
A lot of the techniques described in the "NSA ANT Catalogue" [1] seem to be
based on exploiting the machine at the level of the BIOS/ROM monitor,
microcode, etc. Really very sneaky to compromise the hardware itself; it
often goes overlooked that firmware can be surreptitiously re-flashed, CPU
microcode surreptitiously modified, FPGAs reprogrammed... you really start
to question your confidence in _any_ hardware... maybe it's all been pre
compromised for mass surveillance before it even gets into our hands...
certainly select bits of equipment are [2]. Reload the software, heck, even
go and try to re-flash the monitor thinking you are being thorough, only to
be hit with the thought that the CPU itself could be irreversibly
compromised. It certainly gives one an appreciation for the straightforward
old minicomputer implemented with all discrete components... at least you
can get in there and see what's going on, convince yourself, LOL!
I don't want this to go into OT political territory but I for one am
grateful that guys like Snowden come forward... As an engineer and IT pro,
reading about what is really going on out there, it's a real slap in the
face; really wakes you up.
Best,
Sean
[1]
https://www.aclu.org/files/natsec/nsa/20140130/NSA's%20Spy%20Catalogue.…
[2]
http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory…
On Fri, Jul 25, 2014 at 1:24 PM, Rob Doyle <radioengr at gmail.com> wrote:
On 7/25/2014 3:56 AM, jwsmobile wrote:
The mechanism in the Pentium was almost open compared to what is there
now. All of this is under heavy NDA as far as it
even being there, and
it may or may not be these days.
It has been widely speculated (and supported by the Snowden documents)
that the NSA can defeat the Intel random number generator - and therefore
any crypto based on that RNG) with a microcode patch.
Microcode patches - it's not just for /fixing/ bugs...
Rob
1:12 p.m.
On Jul 25, 2014, at 3:10 PM, Sean Caron <scaron at umich.edu> wrote:
A lot of the techniques described in the "NSA ANT
Catalogue" [1] seem to be
based on exploiting the machine at the level of the BIOS/ROM monitor,
microcode, etc. Really very sneaky to compromise the hardware itself; it
often goes overlooked that firmware can be surreptitiously re-flashed, CPU
microcode surreptitiously modified, FPGAs reprogrammed... you really start
to question your confidence in _any_ hardware... maybe it's all been pre
compromised for mass surveillance before it even gets into our hands...
certainly select bits of equipment are ...
Good reason not to use the BIOS.
http://cm.bell-labs.com/who/ken/trust.html is very relevant. It?s a different approach to
hiding a security attack; this one is hidden in the compiler. Same sort of issue; you
wouldn?t tend to expect it there.
One conclusion is that the security benefits of open source software carry over to open
source hardware. Don?t trust your processor? Build your own from an FPGA plus open
source VHDL.
On the supposed attack on the RNG: that demonstrates what security people know quite well,
which is that it?s not in fact an RNG and it should never be used that way. Instead, it
is one (of several) sources of entropy. The actual strong RNG is a bit of software like
the /dev/random driver in your favorite kernel, or open source libraries like Yarrow or
others. If you feed them bits from a compromised ?hardware RNG?, nothing bad happens.
The worst possible outcome is that those bits contribute zero entropy; the more likely
answer is that whatever patterns had been built into it are wiped out by the mixing
machinery of the software strong RNG.
There?s a reason for that: tradional hardware randomness sources, like noise or the like,
are biased. It?s very unlikely that they produce actual white noise, with equally
probably 1 and 0 bits and no higher level patterns. The software RNG takes care of all
that.
paul
3:54 p.m.
On 7/25/2014 10:24 AM, Rob Doyle wrote:
On 7/25/2014 3:56 AM, jwsmobile wrote:
There is no reason to speculate about the microcode. Once you
compromise the bios there is no reason to worry about microcode. You can
pretty much do anything with a number of mechanisms at that point.
Note what I said. The Intel guys make the NSA look like they are
posting stuff publicly on street corners. They are beyond paranoid to
the point of putting in an encryption hardware component dedicated to
this load of microcode.
The bios is only knows as much about the microcode patching mechanism as
a wire knows about what is transmitted down it. Nothing. It is just
passing thru.
The Trusted computing component they added is much the same sort of
device to be sure that code is executed on a machine that is not
compromised. That Microsoft still makes a mess of it isn't the fault of
the mechanism. They just have too many things that are apparently
written by people who don't know or don't care being executed in trusted
code that they still give away the farm.
However back to the patch, I am pretty sure there is no remaining
mechanism for putting in any patches anymore in any production part.
And most prototypes are not very useful as it is hard to find a system
running anything other than just a bare install of whatever windows is
lying around with no application software loaded on it or network access.
Other than being subject to massive legal problems by violating the
trust of either organization, I'd say the NSA and Intel are both pretty
far up there in maintaining their trust, and the there will not be many
ways to send out a patch without it coming from inside Intel somewhere.
I don't know that AMD does any patching, someone else will have to
comment on that. What I saw of their processor development I was not
near such a mechanism.
Jim
The mechanism in the Pentium was almost open
compared to what is there
now. All of this is under heavy NDA as far as it even being there, and
it may or may not be these days.
It has been widely speculated (and supported by the Snowden documents)
that the NSA can defeat the Intel random number generator - and
therefore any crypto based on that RNG) with a microcode patch.
Microcode patches - it's not just for /fixing/ bugs...
Rob
4:28 p.m.
On Fri, Jul 25, 2014 at 4:54 PM, jwsmobile <jws at jwsss.com> wrote:
There is no reason to speculate about the microcode.
Once you compromise
the bios there is no reason to worry about microcode. You can pretty much do
anything with a number of mechanisms at that point.
It's possible and not even terribly difficult to detect an altered
BIOS, if you have a image or even just a crytographic hash of the
correct BIOS image. There are tricks that a BIOS could do to attempt
to conceal its presence, like an OS rootkit, but there is no way to do
it without any detectable effects. It's also possible to install a
non-vendor BIOS, which would render any back doors in the
vendor-supplied BIOS useless.
If the processor microcode has a back door, either built into the chip
or installed as an update at runtime, that's far harder to detect,
because there's no documented mechanism (and probably no undocumented
mechanism) for reading back the microcode or microcode patch.
While it appears based on the Snowden leaks that the NSA already has
the ability to install BIOSes with back doors, it is unknown whether
they have similar capability with microcode. The cost to develop that
ability would be very high, the potential benefit to them is
absolutely huge, so I wouldn't be quick to write it off.
However back to the patch, I am pretty sure there is
no remaining mechanism
for putting in any patches anymore in any production part.
If you're referring to Intel x86 parts, you are incorrect. The
mechanism is there, and it is routinely used. BIOSes contain a
microcode update which is installed at power-up, and Windows will
install newer ones. Even Linux has support for installing the
microcode updates. Here's an Intel web page with a list of Intel
processors supporting microcode updates, and a downloadable file
containing the updates as of October 2012:
https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=21925&a…
I don't know that AMD does any patching,
They have in all their x86 parts since the K8 (their first 64-bit x86
microarchitecture, introduced in 2003), and they currently distribute
microcode updates for the K10 (2007) and newer:
http://www.amd64.org/microcode.html
4:46 p.m.
On 7/25/2014 4:28 PM, Eric Smith wrote:
If you're referring to Intel x86 parts, you are
incorrect. The
mechanism is there, and it is routinely used.
Try to put some code of your own in
there. All of those updates are
encrypted. W/o being Intel and encoding and encrypting updates now you
can't install microcode anymore.
These are the updates I referred to that are routinely added to Bios to
be installed automatically, so you don't need to do it with a tool like
this.
Once various chips would make the street, a rollup patch would be sent
to the bios development groups I knew of and they'd be incorporated into
the bios to be loaded based on each processor id as needed.
The P3's up to the coppermine always seemed to have a lot of issues, but
as what became the Core type processors came out less so.
the P4 had some while I worked on it, but less than the P3s. Some
shipped parts barely worked w/o an update.
If you can encrypt and code a patch, then you have access to internal
Intel tools and documentation I won't even describe to code them. I
don't know if the NSA or others outside Intel could compromise that, but
it would require doing it around the time the chip shipped, not
something that could be done and assumed to be distributed to systems
much after that time.
I don't know a lot of people who do chip code updates, but if they
update their Bios, in my experience it is usually while the system is
relatively new.
Compromising and reflashing the Bios based on the motherboard is another
matter and is sufficent to do anything that one could do to the
microcode. The bios which is compromised would have to be such that it
installed it and concealed its presence. There may be some bios
compromise kits in the wild, have not checked the sites that scan for
such. They most likely would be very difficult to detect by signature
if done correctly once installed in the bios.
Jim
5:03 p.m.
On Fri, Jul 25, 2014 at 4:54 PM, jwsmobile <jws at jwsss.com> wrote:
I am pretty sure there is no remaining mechanism for
putting in any patches anymore in any production part.
On 7/25/2014 4:28 PM, Eric Smith wrote:
If you're referring to Intel x86 parts, you are
incorrect. The
mechanism is there, and it is routinely used.
On Fri, Jul 25, 2014 at 5:46 PM, jwsmobile <jws at jwsss.com> wrote:
Try to put some code of your own in there. All of
those updates are
encrypted. W/o being Intel and encoding and encrypting updates now you
can't install microcode anymore.
Certainly I didn't claim that I could create a microcode update for
it. But the mechansim IS there, and it IS used. Whether the NSA uses
it is unknown, but it seems foolish to assume that they can't. If
they want to, they'll do it, with or without assistance officially
provided by Intel or AMD.
If you can encrypt and code a patch, then you have
access to internal Intel
tools and documentation I won't even describe to code them.
Or a massive budget for reverse-engineering or espionage. Who do we
know that might have that?
I don't know if
the NSA or others outside Intel could compromise that, but it would require
doing it around the time the chip shipped, not something that could be done
and assumed to be distributed to systems much after that time.
It most certainly can be done after the systems ship. Intel and AMD
created the mechanisms for installing those updates so that the OS can
do it, not just the BIOS, and OSes do in fact do that.
I don't know a lot of people who do chip code
updates, but if they update
their Bios, in my experience it is usually while the system is relatively
new.
But many people update Windows routinely, and it sometimes installs
new microcode updates. So do Linux updates. I'm not sure about Mac
OS X, but I'd guess that it probably does as well.
Should we be trembling in fear and refusing to use computers because
the NSA might be spying on them? No. But should we be aware of the
possibility? Yes.
Eric
6:38 p.m.
On 7/25/2014 5:03 PM, Eric Smith wrote:
Should we be trembling in fear and refusing to use
computers because
the NSA might be spying on them? No. But should we be aware of the
possibility? Yes.
I actually don't care about the NSA. I care about exploits
to root or
compromise systems from other sources more.
The NSA is very unlikely to target anything I do, and if they do, they
will see this nonsense.
Also, the NSA is likely to just sign a contract with Intel to get the
patches and pay for them. I don't believe they could or would bother
trying to crack the encryption.
Certainly there were such things going on in other plants I've been in
related to hardware. There were certainly secured areas where such
things could happen.
The surprise is that people are shocked this is going on. Most of what
I've seen has either been publicized in the past and just not understood
by the public, or if one knew how the technical side of things work the
way most do here, i suspect none is a shock to anyone who comes to this
list with the experience I suspect most have.
Jim
26 Jul
26 Jul
10:44 a.m.
If you can encrypt and code a [microcode] patch, then
you have access
to internal Intel tools and documentation I won't even describe to
code them.
Except for the encryption, I'm not convinced. People have
reverse-engineered harder things.
I don't know if the NSA or others outside Intel
could compromise
that, [...]
Depends on how you define "compromise". From their point of view, I
doubt there is any compromise involved; I would expect that Intel rolls
over for the letter agencies, providing documentation and encryption
help as desired, so there is no compromise in the sense of doing it
without Intel's cooperation. But from the end user's point of view,
being attacked by NSA (or whoever) malware reflashing the BIOS to
include (say) a subtly broken RNG, that is a compromise, and a rather
serious one.
I've long been irritated that motherboards don't include hardware
en/disables for reflashing, so that to reflash the BIOS you have to do
something physical like move a jumper. This is actually a moderately
plausible reason for that - it improves security too much.
but it would require doing it around the time the chip
shipped, not
something that could be done and assumed to be distributed to systems
much after that time.
Oh, I don't see it as being a mass compromise. I see it as being
targeted: the letter agencies want to see what person (or corporation)
XYZ is doing, so they release stealth malware which, when it determines
it's reached (one of) the right machine(s), reflashes the BIOS with the
tweaked microcode.
It's one reason I like old hardware: it's significantly less vulnerable
all around to such attacks. (It's also another reason to prefer RISC
CPUs: they tend to be less microcoded.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
4:41 p.m.
If someone was snooping, the BIOS would be the place
to do it. The space for uC update is really quite small and
only intended for a few instructions. It could be useful with
a bios change to make use of something like a trap.
Otherwise, it is not like writing a pile of code that runs
its own extensive code.
Dwight
5:57 p.m.
New subject: Malicious microcode patches (was Re: microcode store)
On 26/07/14 7:41 PM, dwight wrote:
If someone was snooping, the BIOS would be the place
to do it. The space for uC update is really quite small and
But still enough to include a privilege escalation bug (for example),
surely.
--Toby
only intended for a few instructions. It could be
useful with
a bios change to make use of something like a trap.
Otherwise, it is not like writing a pile of code that runs
its own extensive code.
Dwight
6:45 p.m.
On Jul 26, 2014 5:45 PM, "dwight" <dkelvey at hotmail.com> wrote:
If someone was snooping, the BIOS would be the place
to do it. The space for uC update is really quite small and
only intended for a few instructions.
The point of a microcode hack wouldn't be to do the snooping. It would be
to provide a hook so that some other piece of seemingly innocuous software
that the user runs could completely bypass normal system security snd do
the snooping. For instance, a microcode hack could both make it easier to
install a rootkit, and harder to detect one.
As a purely hypothetical example, a microcode hack could be designed to let
a specially crafted ActiveX control get ring 0 system access. With somewhat
more difficulty it might even be possible to do that for Javascript or
Java, or even PDF documents or VBA scripts, based on known instruction
sequences in specific interpreters.
As compared to a normal exploit, this would be essentially undetectable,
and by virtue of that, unfixable. That's the motivation for spending vast
amounts of money developing it.
25 Jul
25 Jul
1:06 p.m.
On Jul 24, 2014, at 10:22 PM, Eric Smith <spacewar at gmail.com> wrote:
On Thu, Jul 24, 2014 at 4:21 PM, Tony Duell <ard at
p850ug1.demon.co.uk> wrote:
That?s probably pretty accurate, but even so, it was well know around DEC that the
PDP-11/60 was the world?s fastest PDP-8. (The WPS-8 development team, which was right
next to Typeset-11 where I started, used an 11/60 for their development work.)
paul
[1] The VAX11/730 also loads the CPU microcode at
power-up, but from what
I rememebr, ther eare some hardware features that optimise it for the VAX
instruction set. While it is possible to give it a differnet instruciton
set, I think it wopuld be a lot less efficient.
All of the microcoded processors DEC designed, whether they had
loadable microcode or only ROM, had hardware that was substantially
oriented toward the normal DEC macroinstruction set(s), and would have
been very inefficient at implementing other instruction sets. The
VAX-11/7xx series hardware was designed for efficient execution of
both VAX and PDP-11 instruction sets, but the other machines were
designed for a single instruction set only. Even the machines that
officially supported user-written microcode (PDP-11/03, PDP-11/60,
some VAXen) were generally unsuited to implementing entirely different
instruction sets, and user-added instructions were expected to have
similar structure to standard instructions. 
1:47 p.m.
-----Oorspronkelijk bericht-----
From: Paul Koning
Sent: Friday, July 25, 2014 10:06 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: microcode store (was Re: Looking to get into a Mini
Computer...)
On Jul 24, 2014, at 10:22 PM, Eric Smith <spacewar at gmail.com> wrote:
All of the microcoded processors DEC designed, whether
they had
loadable microcode or only ROM, had hardware that was substantially
oriented toward the normal DEC macroinstruction set(s), and would have
been very inefficient at implementing other instruction sets. The
VAX-11/7xx series hardware was designed for efficient execution of
both VAX and PDP-11 instruction sets, but the other machines were
designed for a single instruction set only. Even the machines that
officially supported user-written microcode (PDP-11/03, PDP-11/60,
some VAXen) were generally unsuited to implementing entirely different
instruction sets, and user-added instructions were expected to have
similar structure to standard instructions.
That?s probably pretty accurate, but even so, it was well know around DEC
that the PDP-11/60 was the world?s fastest PDP-8. (The WPS-8 development
team, which was right next to Typeset-11 where I started, used an 11/60 for
their development work.)
paul
That is what I have read somewhere, long ago ... Owning an 11/60 with WCS
I wonder if there is anybody out there who has the "pdp8 microcode" ...?
Or is that piece of software lost forever?
- Henk
2:31 p.m.
On Fri, Jul 25, 2014 at 2:47 PM, Henk <henk.gooijen at hotmail.com> wrote:
That is what I have read somewhere, long ago ...
Owning an 11/60 with WCS
I wonder if there is anybody out there who has the "pdp8 microcode" ...?
Or is that piece of software lost forever?
It appears to be lost forever. Richie Lary, the author, no longer had
it when I inquired some years back, and didn't think that anyone else
was likely to.
1:56 p.m.
On Fri, Jul 25, 2014 at 2:06 PM, Paul Koning <paulkoning at comcast.net> wrote:
That?s probably pretty accurate, but even so, it was
well know around DEC that the PDP-11/60 was the world?s fastest PDP-8.
And just imagine how fast an -8 the 11/60 would have been if the
hardware data paths and microbranches had been designed to efficiently
be an -8! :-)
If -8 microcode was written for a KL10, that might have made an even
faster -8 than the 11/60, but I've never heard of anyone even
attempting it. I think -8 microcode for the KS10 probably would have
been slower than the 11/60.
2:53 p.m.
On Thu, Jul 24, 2014 at 4:21 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
This makes a lot of sense if the mcirocode is in ROM and can't easily be
changed. Having some of the instruction decoding in the hardware speeds
things up and simplifies the microcode. Other machiens with ROM-pased
microcodes do much the same thing (even if it's just the 'not a memory
reference instruciton decode gate' and the ditect contro fo the
accumulator select FF from bit 10 of the iQ register in the HP98x0 CPU.)
The PERQ is one of the few machines that makes no hardwae assumptions
about the machine code instruciton set. So it is equally (in)efficient
and implementing just about anything.
[1] The VAX11/730 also loads the CPU microcode at
power-up, but from what
I rememebr, ther eare some hardware features that optimise it for the VAX
instruction set. While it is possible to give it a differnet instruciton
set, I think it wopuld be a lot less efficient.
All of the microcoded processors DEC designed, whether they had
loadable microcode or only ROM, had hardware that was substantially
oriented toward the normal DEC macroinstruction set(s), and would have The VAX-11/780 introduced the concept of patchable
control store,
where most of the control store was PROM but there was a small amount
of patch RAM. Costs of high speed RAM declined quickly enough that
THe 11/730 uses 200ns DRAMs (!) for the stnadard microcode store. I
didn't beleive it either, but it's in the printset and the tech manual
(both on bitsavers). Ridiculously slow _and_ the CPU has to be halted
every few ms to refresh the control store (the nature fof microdcode is
that it epends a lot of time in small loops, so you can't assume that hte
normal CPU instrucion exectuion will acess enough to the control store to
refresh it). Ho-hum...
-tony
4:01 p.m.
On Fri, Jul 25, 2014 at 2:53 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
The PERQ is one of the few machines that makes no hardwae assumptions
about the machine code instruciton set. So it is equally (in)efficient
and implementing just about anything.
Well, that's true in a sense -- the PERQ's hardware *is* optimized for
building microcode to execute bytecode (hence the system's heavy use of
Pascal), the byte-wide opcode file and dispatch mechanisms are provided in
the hardware to make this fairly quick. You *could* make it implement just
about anything, though. (I've often toyed with the idea of building a
68000 in PERQ microcode, though I've never had time to actually do anything
about it. An 8-bit microprocessor would be pretty easy, though...)
- Josh
The VAX-11/780
introduced the concept of patchable control store,
where most of the control store was PROM but there was a small amount
of patch RAM. Costs of high speed RAM declined quickly enough that
THe 11/730 uses 200ns DRAMs (!) for the stnadard microcode store. I
didn't beleive it either, but it's in the printset and the tech manual
(both on bitsavers). Ridiculously slow _and_ the CPU has to be halted
every few ms to refresh the control store (the nature fof microdcode is
that it epends a lot of time in small loops, so you can't assume that hte
normal CPU instrucion exectuion will acess enough to the control store to
refresh it). Ho-hum...
-tony
26 Jul
26 Jul
1:35 p.m.
New subject: microcode store (was Re: Looking to get into a Mini Computer...)#
The PERQ is
one of the few machines that makes no hardwae assumptions
about the machine code instruciton set. So it is equally (in)efficient
and implementing just about anything.
Well, that's true in a sense -- the PERQ's hardware *is* optimized for
building microcode to execute bytecode (hence the system's heavy use of Pascal), the byte-wide opcode file and dispatch
mechanisms are provided in
the hardware to make this fairly quick. You *could* make it implement just
about anything, though. (I've often toyed with the idea of building a
68000 in PERQ microcode, though I've never had time to actually do anything
about it. An 8-bit microprocessor would be pretty easy, though...)
THere is a rumour that there was a PDP11-compatible microcode at 3RCC. I
know nothing about it, and AFAIK it doens't still exist :-(
-tony
3801
days inactive
3803
days old
22 comments
12 participants
participants (12)
-
ard＠p850ug1.demon.co.uk -
derschjo＠gmail.com -
dkelvey＠hotmail.com -
henk.gooijen＠hotmail.com -
jws＠jwsss.com -
mouse＠Rodents-Montreal.ORG -
paulkoning＠comcast.net -
pbirkel＠gmail.com -
radioengr＠gmail.com -
scaron＠umich.edu -
spacewar＠gmail.com -
toby＠telegraphics.com.au