24 Oct
2005
24 Oct
'05
1:50 p.m.
On Mon, 24 Oct 2005, "Peter C. Wallace" <pcw at mesanet.com> wrote:
On Mon, 24 Oct 2005, Johnny Billquist wrote:
The 8650 is all ECL, man. We're talking really fast gates here...
On Sun, 23 Oct 2005, "Peter C. Wallace"
<pcw at mesanet.com> wrote:
Not sure, but my guess is that a lot of that sophisticated caching and
pipelining was needed to get the microengine to run at that 68 MHz because of
the chip-chip delays in a large multi-chip design. Well since its pretty easy to get microcode to
run at 75-100 MHz or so in
current cheap FPGAs, I'd say that 10 X a 780 should be trivial...
I'd say that's wrong. Considering that the VAX8650 microcode engine runs
at 68 MHz and manages about 7 times the 11/780, you're optimistic.
The 8650 have a very large microcode word, actually have three (or was
it four?) microcode engines running in parallell, and some very advanced
cacheing and pipelining to speed it up to get even that far. Current cheap FPGAs can manage 75-100 MHz with no
pipelining. They can
also do 32 bit adds/subtracts in < 7 or so nS. I doubt if the 8650s hardware
could manage that. Would be interesting to know the average number of
microinstructions per macroinstruction on the 8650...
It probably can do that. Without actually knowing, I would guess it
requires much less than 7 ns for an add/substract. However, since we're
talking about a pipelined machine here, you also have register copyback in
the pipe, fp stuff, the memory management with page relocation, TLB cache,
internal processor registers, and lots of other stuff going on. There is a
lot of things to cover. And since you have several micromachines, register
updates also needs to get duplicated to the other micromachines. I think I
have the documentation for the microcode for the different engines, and I
also have the binary microcode files... Anyone want to take a crack at
this? :-)
And of course, with a VAX, you have the bloody instruction fetch and
decode stuff which really is a pain. Get first byte, figure out how many
arguments it takes. Get the next byte and start parsing for the first
argument, which might be a whole number of bytes, then continue with the
next argument. Worst instructions take five arguments if I remember
correctly.
On Mon, 24 Oct 2005, woodelf <bfranchuk at jetnet.ab.ca> wrote:
Johnny Billquist wrote:
Yeah, there are some reasons why I like the 86x0 series... They are quite
brutal in their way... A number of patents DEC made on the 86x0 series
(among others) were what the fight with Intel about the Pentium and
patent infringement was about in the mid 90s.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I'd say that's wrong. Considering that the
VAX8650 microcode engine runs
at 68 MHz and manages about 7 times the 11/780, you're optimistic.
The 8650 have a very large microcode word, actually have three (or was
it four?) microcode engines running in parallell, and some very advanced
cacheing and pipelining to speed it up to get even that far.
Also compared to a smaller machine -- remember you have floating point
stuff as well
as the basic instruction set. I forgot about that too. That is a fast
engine -- about 15 ns. 
24 Oct
24 Oct
2:02 p.m.
And of course, with a VAX, you have the bloody
instruction fetch and
decode stuff which really is a pain. [...] Worst instructions take
five arguments if I remember correctly.
Eight instructions take six. Five of them (addp6, subp6, mulp, divp,
ashp) are packed-decimal and thus may not be in silicon or microcode,
and two (movtc, movtuc) are relatively rare string operations, but the
other (index) is simple and (for some languages) heavily used; I'd
expect at least that one to be done in silicon/microcode. (And for the
other seven, even if they're just traps to macrocode as they are on
(eg) the uVII, I *think* you need to do at least rudimentary argument
parsing before taking the trap.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:49 p.m.
der Mouse wrote:
A favourite game used to be to come up with the longest possible
legal VAX instruction. I forget the exact answer but it was in the
region of 54 bytes. That's actual I-stream decoded instruction
bytes, tables for MOVxxx or whatever do not count. I think the
solution is to pick something like ADDP6 and make each of
the arguemnts as long as possible (which is five or six bytes or so).
The other game was to come up with a scenario for the most
page-faults possible while executing a single instruction.
I expect that building an Alpha might be straightforward in
comparison :-) I still think that a CPU is not a VAX until
it passes AXE (and I believe that CHARON-VAX has been so tested,
no idea about SIMH).
Antonio
--
Antonio carlini
arcarlini at iee.org
And of course,
with a VAX, you have the bloody instruction fetch and
decode stuff which really is a pain. [...] Worst instructions take
five arguments if I remember correctly.
Eight instructions take six. Five of them (addp6, subp6, mulp, divp,
ashp) are packed-decimal and thus may not be in silicon or microcode,
and two (movtc, movtuc) are relatively rare string operations, but
the other (index) is simple and (for some languages) heavily used;
I'd expect at least that one to be done in silicon/microcode. (And
for the other seven, even if they're just traps to macrocode as they
are on (eg) the uVII, I *think* you need to do at least rudimentary
argument parsing before taking the trap.)
4 p.m.
A favourite game used to be to come up with the
longest possible
legal VAX instruction. I forget the exact answer but it was in the
region of 54 bytes. That's actual I-stream decoded instruction
bytes, tables for MOVxxx or whatever do not count.
Yeah, with CASEx you can create an "instruction" that's as long as you
want (within the limitations of the VAX, of course, such as 32-bitness
and how it can't be longer than 1G or 3G, depending on whether an
instruction can cross address-space boundaries).
I think the solution is to pick something like ADDP6
and make each of
the arguemnts as long as possible (which is five or six bytes or so).
I don't see how to get longer than six bytes (xxxxxxx(Rx)[Rx]) there,
which still gives you only 37 bytes. But if you use EMODH (a two-byte
opcode) with two 16-byte immediate operands, you can get 2+17+6+17+6+6
or, yes, 54 - your memory seems accurate. :)
The other game was to come up with a scenario for the
most
page-faults possible while executing a single instruction.
Hmmm...MOVTC: two for the instruction itself, two per operand while
fetching operands indirection, two for each length, one for the fill
char, 513 for the from data, 513 for the to data, two for the table
data, two each for the system pages holding the PTEs mapping the
instruction, each operand indirection, the from data, the to data, the
table data, and one for the fill char: total 1066. Did I miss
anything?
Unless you count interrupts and traps as being "while executing" the
interrupted or trapping instruction, but that is uninteresting.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:43 p.m.
The 8650 is all ECL, man. We're talking really
fast gates here...
The 8650 was pretty slow for an ECL machine, as I think it was just
10K. That really is not a big step above something using 74ASxx series
technology. 100K, MECL III, 10G and 10E were the fast ECLs.
William Donzelli
aw288 at osfn.org
6852
days inactive
6852
days old
4 comments
4 participants
participants (4)
-
arcarlini＠iee.org -
aw288＠osfn.org -
bqt＠Update.UU.SE -
mouse＠Rodents.Montreal.QC.CA