31 Dec
2008
31 Dec
'08
9:49 p.m.
Subject: Language-specific CPUs was Re: uIEC/SD == AWESOME!
From: Cameron Kaiser <spectre at floodgap.com>
Date: Wed, 31 Dec 2008 13:27:08 -0800 (PST)
To: cctalk at classiccmp.org
C was written for or about the PDP-11. Just about all the C addressing
modes and basic OPs are native for pdp11 addressing and many instructions.
Then we have the WD Pascal Microengine that basically was the implementation
of P-code in microcode.
There are machines that are coded for forth primitives directly.
I believe somewhere there was or is a a Java engine.
Memory says there was a Wang machine that directly executed Basic.
Generally it was not uncommon but most were lost to time.
Allison
(Interesting question, though - I wonder what a
CPU might look like where you
could just throw C source code at it, for instance :)
Well, there *was* the AT&T Hobbit:
http://en.wikipedia.org/wiki/AT%26T_Hobbit
Not quite that, but still optimized for C, allegedly. Never worked with
the architecture myself.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Immigration is the sincerest form of flattery. -- Jack Paar ----------------
1 Jan
1 Jan
9:51 a.m.
Allison wrote:
Memory says there was a Wang machine that directly
executed Basic.
Yes, the Wang 2200-series machines used a microcoded architecture that
implemented a BASIC interpreter as a native "language". These machines
were an extension of the architecture developed for the Wang 700-series
electronic calculators. It's an interesting twist of fate. Wang hadn't
intended to make an advanced scientific calculator, as the thought was
that their 300-Series calculators were all that they needed. Dr. Wang
felt that the important market was in computers, and had a development
effort underway to make a computer that was to compete with IBM's
System/360. It was Dr. Wang's intent to have Wang become the largest
computer company in the world. However, when Hewlett Packard introduced
the HP 9100A calculator, it immediately took most of the market share
away from Wang in the scientific calculator marketplace, where Wang was
the leader. This quickly put Wang into a cash crunch, as they had a hard
time selling the 300-Series machines. The efforts to develop a
computer were quickly re-targeted -- it was mandated that the basic
computer design (a microcoded architecture) was to be refitted to serve
as an advanced programmable calculator. This became the Wang 700-Series
calculators (as well as follow-on machines such as the 500-Series,
600-Series, and later 400- and C-Series machines). While the 700-Series
machines did help rescue Wang's calculator business, the real savior for
Wang's stockholders was the introduction of Wang's word processing
equipment, also based on much the same microcoded architecture as the
700-Series calculators. As it became clear that calculators were
becoming a commodity market, driven mainly by semiconductor
manufacturers who had the resources to fabricate LSI calculator
chipsets, and later single-chip implementations, Wang Labs revisited
building a computer at a much "smaller" level than going after IBM. The
2200-series BASIC computers (although Wang initially marketed them as
"calculators") were the result. The architecture went from computer, to
calculator, and back to computer, with sidelines into word processors.
Check out Jim Battle's http://www.wang2200.org . There's even an
emulator of the 2200 that actually runs the actual 2200 microcode!
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
10:24 a.m.
Rick Bensene wrote:
Allison wrote:
It is perhaps a religious question, but where does microcode end and an instruction set
architecture begin? That is, what distinguishes microcode from a conventional instruction
set?
It isn't necessarily width -- there are narrow and wide styles of microcode, and all
points in between. The Wang 700 was 43 bits wide (as Rick certainly knows well), the
first generation Wang 2200 had 20b microwords, and the 2200 VP had 23b+parity microwords.
As a side note, I'm surprised that the 700 was so wide. Considering the expense of
making the core-based ROMs, a narrower microword with more logic spend decoding seems like
the more economical choice.
On common feature of microcode is having multiple orthogonal control fields. On that
basis, the 2200 was microcode.
Another common feature of microcode, but not universal, is exposed pipeline hazards. The
2200 fails this, as the effects of each microword is finished before the next microword
starts. It is not any more tricky to write 2200 microcode than asm for the typical
microprocessor.
Dave Angel, one of the guys who wrote the microcode for the 2200T and the 2200VP, took
umbrage that my webpage disputes the oft-stated claim that the 2200 implemented BASIC in
hardware. He seemed stuck on the distinction that "all other" BASICs have two
levels of
interpretation -- the code that the interpreter is written in, and the microcode that is
interpreting the lower level instruction set. I pointed out that the Z80 isn't
microcoded
at all and therefore there is one level of interpretation going on, but the point seemed
lost on him. For that matter, the overwhelming majority of x86 instructions in
today's
processors, measured dynamically, are also executed directly without microcode
assistance.
Memory says there was a Wang machine that
directly executed Basic.
Yes, the Wang 2200-series machines used a microcoded architecture that
implemented a BASIC interpreter as a native "language". These machines
were an extension of the architecture developed for the Wang 700-series
electronic calculators. It's an interesting twist of fate. Wang hadn't
intended to make an advanced scientific calculator, as the thought was
that their 300-Series calculators were all that they needed. Dr. Wang
felt that the important market was in computers, and had a development
effort underway to make a computer that was to compete with IBM's
System/360. It was Dr. Wang's intent to have Wang become the largest
computer company in the world. However, when Hewlett Packard introduced
the HP 9100A calculator, it immediately took most of the market share
away from Wang in the scientific calculator marketplace, where Wang was
the leader. This quickly put Wang into a cash crunch, as they had a hard
time selling the 300-Series machines. The efforts to develop a
computer were quickly re-targeted -- it was mandated that the basic
computer design (a microcoded architecture) was to be refitted to serve
as an advanced programmable calculator. This became the Wang 700-Series
calculators (as well as follow-on machines such as the 500-Series,
600-Series, and later 400- and C-Series machines). While the 700-Series
machines did help rescue Wang's calculator business, the real savior for
Wang's stockholders was the introduction of Wang's word processing
equipment, also based on much the same microcoded architecture as the
700-Series calculators.
I have a website on the Wang 1200 that is all ready to turn on, but I'm waiting to
hear
back from Jay West to see if he is willing to host it.
I'm looking forward to digging into it more, but one difference between the 700 and
the
1200 is that the 700 has a nibble wide data path; the 1200 logically has a nibble wide
data path, but it is implemented bit serially. Some of the data sources in the A & B
ALU
inputs that are "don't cares" in Rick's reverse engineering of the 700
definitely act as
sources on the 1200.
The 1200 wasn't ever a cash producer for Wang, but its failures did educate them such
that
when they did come out with the Wang WPS in 1976 (which was 8080-based), they offered
something that really did serve the market well.
As it became clear that calculators were
becoming a commodity market, driven mainly by semiconductor
manufacturers who had the resources to fabricate LSI calculator
chipsets, and later single-chip implementations, Wang Labs revisited
building a computer at a much "smaller" level than going after IBM. The
2200-series BASIC computers (although Wang initially marketed them as
"calculators") were the result. The architecture went from computer, to
calculator, and back to computer, with sidelines into word processors.
Check out Jim Battle's http://www.wang2200.org . There's even an
emulator of the 2200 that actually runs the actual 2200 microcode!
Thanks for the plug!
Rick Bensene
The Old Calculator Museum
http://oldcalculatormuseum.com
And to return the favor, visit Rick's site -- in addition to the great assortment of
old
calculators, Rick has a lot of original research, and a number of interviews with the
designers of these machines that you can't find anywhere else.
10:33 a.m.
On 1 Jan 2009 at 9:51, Rick Bensene wrote:
Yes, the Wang 2200-series machines used a microcoded
architecture that
implemented a BASIC interpreter as a native "language".
Like an IBM 5150 without any disks? If we're talking about
"directly executing" shouldn't the hardware be so tightly wound up
with the language that reprogramming it (say, by replacing ROMs) to
host some other language is impossible? Otherwise, it's just a
conventional processor executing a stored program.
Cheers,
Chuck
10:56 a.m.
On 1 Jan 2009 at 9:51, Rick Bensene wrote:
OK, suppose we take a typicel microcomputer with BASIC in ROM and replace
the ROMs with a (very large) set of AND and OR gates to carry out the
same logic function (after all, a ROM is just a fixed AND matrix
(the address decoder) follered by a programablt OR matrix (combines the
outputs of that decoder into the desired output words). Is that a
hardware implenentation of BASIC or not :-)
-tony
Yes, the Wang 2200-series machines used a
microcoded architecture that
implemented a BASIC interpreter as a native "language".
Like an IBM 5150 without any disks? If we're talking about
"directly executing" shouldn't the hardware be so tightly wound up
with the language that reprogramming it (say, by replacing ROMs) to
host some other language is impossible? Otherwise, it's just a
conventional processor executing a stored program.
11:27 a.m.
On 1 Jan 2009 at 18:56, Tony Duell wrote:
OK, suppose we take a typicel microcomputer with BASIC
in ROM and replace
the ROMs with a (very large) set of AND and OR gates to carry out the
same logic function (after all, a ROM is just a fixed AND matrix
(the address decoder) follered by a programablt OR matrix (combines the
outputs of that decoder into the desired output words). Is that a
hardware implenentation of BASIC or not :-)
Yes, if the gates were soldered onto the PCB :)
Cheers,
Chuck
11:05 a.m.
Chuck Guzis wrote:
On 1 Jan 2009 at 9:51, Rick Bensene wrote:
Sounds like Rick's saying that the interpreter essentially ran within the
CPU's microcode though, rather than in any kind of external ROM.
I'm really not sure where the distinction between assembly and 'not assembly'
should lie, though. What does a stream of tokenised BASIC or Java bytecode
count as? It's not the language in it's original (source) form, so the CPU
doesn't "directly run" BASIC or Java (more like it runs assembled code,
albeit
using pretty coarse instructions).
I'm not sure what the benefit would be in a CPU where human-readable source
could be thrown at it, though; it'd likely be a lot less efficient than
something requiring a compilation step. That doesn't mean someone hasn't
tried. Heck, I suppose you could take a PC with some form of bidirectional
data bus (a parallel port, say) which accepted whatever data you wanted -
enact on the data fed to it and as a self-contained box, call the entire PC a
"CPU".
cheers
Jules
Yes, the Wang 2200-series machines used a
microcoded architecture that
implemented a BASIC interpreter as a native "language".
Like an IBM 5150 without any disks? 
11:34 a.m.
The FORTH chip I've used is the Rockwell R65F11P running RSC-FORTH ver 1.5
in a little robot dog called " FIFO ". FORTH is great for controlling robots
and telescopes but kinda sucks for number crunching.
Best regards, Steven
C was written for or about the PDP-11. Just about all the C addressing
modes and basic OPs are native for pdp11 addressing and many instructions.
Then we have the WD Pascal Microengine that basically was the implementation
>
>Subject: Language-specific CPUs was Re: uIEC/SD == AWESOME!
> From: Cameron Kaiser <spectre at floodgap.com>
> Date: Wed, 31 Dec 2008 13:27:08 -0800 (PST)
> To: cctalk at classiccmp.org
>
>> (Interesting question, though - I wonder what a CPU might look like
where
you
could just throw C source code at it, for instance :)
Well, there *was* the AT&T Hobbit:
http://en.wikipedia.org/wiki/AT%26T_Hobbit
Not quite that, but still optimized for C, allegedly. Never worked with
the architecture myself.
of P-code in microcode.
There are machines that are coded for forth primitives directly.
I believe somewhere there was or is a a Java engine.
Memory says there was a Wang machine that directly executed Basic.
Generally it was not uncommon but most were lost to time.
Allison
12:42 p.m.
On Thu, Jan 1, 2009 at 2:34 PM, Scanning
<steven.alan.canning at verizon.net> wrote:
FORTH is great for controlling robots
and telescopes but kinda sucks for number crunching.
Not once a few modifications have been done: RPL on HP calculators is
essentially FORTH. (and to stay on-topic, I believe the Saturn
Processor was designed specifically for RPL)
Joe.
--
Joachim Thiemann :: http://www.tsp.ece.mcgill.ca/~jthiem
3:16 p.m.
Not once a few modifications have been done: RPL on HP
calculators is
essentially FORTH. (and to stay on-topic, I believe the Saturn
Processor was designed specifically for RPL)
Was it? The first (production) machine to use the Saturn was the HP71B,
which had BASIC in ROM. Maybe RPL was being considered at that time, but
I am not certain of that.
Later versions of the Saturn did add some instructions to assist in RPL
(the main one being PC=(A), basically a threading instruction). But I
don't think Saturn machine code is particularly close to RPL even then.
-tony
8:47 p.m.
----------------------------------------
Date: Thu, 1 Jan 2009 11:34:37 -0800
The FORTH chip I've used is the Rockwell R65F11P running RSC-FORTH ver 1.5
in a little robot dog called " FIFO ". FORTH is great for controlling robots
and telescopes but kinda sucks for number crunching.
Best regards, Steven
Hi
An interesting statement. The Forth Chip, RTX2000, was often added
to machines to be specifically used to enhance the number crunching
ability of systems.
I suspect your thinking is related to the fact that most cheep/free
Forth's lacked floating point, built in. I do have to admit that
a single stack is a little clumsy for multi dimensional vector operations.
Still, there is always the possibility of using some some type of local
variables ( most professional Forths support locals ).
Dwight
_________________________________________________________________
Send e-mail anywhere. No map, no compass.
http://windowslive.com/oneline/hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_anywhe…
9:45 p.m.
New subject: Ot - ebay listing - 8 bit development
Item number: 110331830581
Motorola M68HC705KICS in-circuit simulator
11:32 p.m.
On Jan 1, 2009, at 11:47 PM, dwight elvey wrote:
An interesting statement. The Forth Chip, RTX2000,
was often added
to machines to be specifically used to enhance the number crunching
ability of systems.
I have a couple of Harris RTX2001 chips and some dev info. I've
been meaning to do something with them but haven't gotten anywhere
yet. They should be fun.
-Dave
--
Dave McGuire
Port Charlotte, FL
2:17 p.m.
Allison wrote:
C was written for or about the PDP-11. Just about all the C addressing
modes and basic OPs are native for pdp11 addressing and many instructions.
While there seems to be a popularly-held association between C and the PDP-11,
I believe the suggestion of design influence is overstated.
The funky addressing operations (post/pre-inc/dec,indirection,etc.)
of C were present in the earlier B language, which ran on other machines
before the 11. Dennis Ritchie actually specifically addresses this in his
history of the C language: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html,
see the "More History" section).
A primary change from B to C was the addition of byte types and a further
abstraction of pointers to facilitate byte-addressed machines.
Porting the early unix to the 11 may have helped instigate this (see Ritchie's
History of C again), but byte-handling and addressing were nothing
unique to, or uniquely beneficial to, the 11. (If it hadn't been done for the 11
it would have been done for another port.)
While C and the PDP-11 were a nice fit, I'd suggest the correlation is more one of
common trends of the time influencing both, than (either) being written or designed
for the other.
3 p.m.
On Thu, 1 Jan 2009, Allison wrote:
C was written for or about the PDP-11. Just about all
the C addressing
modes and basic OPs are native for pdp11 addressing and many instructions.
Then we have the WD Pascal Microengine that basically was the implementation
of P-code in microcode.
There are machines that are coded for forth primitives directly.
I believe somewhere there was or is a a Java engine.
Memory says there was a Wang machine that directly executed Basic.
Generally it was not uncommon but most were lost to time.
I get a little uncomfortable contemplating the possibility of a machine
designed to execute ASP.NET.
3:03 p.m.
Generally it
was not uncommon but most were lost to time.
I get a little uncomfortable contemplating the possibility of a machine
designed to execute ASP.NET.
3:03 p.m.
On Jan 1, 2009, at 6:00 PM, Fred Cisin wrote:
WHY did you go there??
--
Dave McGuire
Port Charlotte, FL
C was written
for or about the PDP-11. Just about all the C
addressing
modes and basic OPs are native for pdp11 addressing and many
instructions.
Then we have the WD Pascal Microengine that basically was the
implementation
of P-code in microcode.
There are machines that are coded for forth primitives directly.
I believe somewhere there was or is a a Java engine.
Memory says there was a Wang machine that directly executed Basic.
Generally it was not uncommon but most were lost to time.
I get a little uncomfortable contemplating the possibility of a
machine
designed to execute ASP.NET.
4:03 p.m.
New subject: Sorry (Was: Language-specific CPUs
>> Then we have the WD Pascal Microengine that
basically was the
>> implementation
>> of P-code in microcode.
>> There are machines that are coded for forth primitives directly.
>> I believe somewhere there was or is a a Java engine.
>> Memory says there was a Wang machine that directly executed Basic.
>> Generally it was not uncommon but most were lost to time.
> I get a little uncomfortable contemplating the possibility of a
> machine
> designed to execute ASP.NET.
On Thu, 1 Jan 2009, Cameron Kaiser wrote:
Please, I'm trying to eat here.
On Thu, 1 Jan 2009, Dave McGuire wrote:
WHY did you go there??
Sorry for such an excremental comparison, this is an aspect of the field
that I am interested in, but know very little about.
But some systems, such as Java bytecode, and including ones that might
support multiple languages such as UCSD P-system, compile to a moderately
low level intermediate language.
IF that intermediate is low enough, then it becomes feasable to design
hardware that is closely tied to the language, such as the p-system
micro-engine, or SOAR ("Smalltalk On A Risc"), etc.
ASP appears to be designed that way, and I have been meaning to get and
read the ASP ILASM ("Intermediate level assembler"?) books.
Would MICROS~1 not be working on a dedicated hardware system?
For that matter (sorry for the mass indigestion), surely Intel is studying
and doing massive statistical analyses of the relative frequency of
different instructions, in order to optimize processors for what they will
actually be used for. If their data is real world, then such
optimizations would ultimately result in creation of processors that are
specifically optimized for the weirdities of Windoze!
I had hoped that this year would be better than last.
--
Grumpy Ol' Fred cisin at xenosoft.com
8:06 p.m.
New subject: Sorry (Was: Language-specific CPUs
Fred Cisin wrote:
For that matter (sorry for the mass indigestion),
surely Intel is studying
and doing massive statistical analyses of the relative frequency of
different instructions
Presumably - I expect this is common practice for all CPU manufacturers (and
what I believe fed the first RISC designs way back when)
If their data is real world, then such
optimizations would ultimately result in creation of processors that are
specifically optimized for the weirdities of Windoze!
Multiple types of halt instruction, you mean?
2 Jan
2 Jan
3:52 a.m.
New subject: Sorry (Was: Language-specific CPUs
Jules Richardson wrote:
Fred Cisin wrote:
There is actually a Windows hardware accelerator, which speeds things up
massively. Having only four opcodes, it's very easy to program:
MSB - Make Screen Blue
DMH - Display Memory as Hex, optionally with cryptic messages
HLT - Halt until a key is pressed, then reset
SOD - Scribble On Disk, just in case any data managed to be written out
before the crash.
Although the microcode behind these instructions is quite complex, the
simple instruction set makes it easy for the end user to use.
One added advantage is that having only four opcodes makes it ideally
suited to two-bit architectures.
Gordon
For that matter (sorry for the mass indigestion),
surely Intel is
studying
and doing massive statistical analyses of the relative frequency of
different instructions
Presumably - I expect this is common practice for all CPU manufacturers
(and what I believe fed the first RISC designs way back when)
If their data is real world, then such
optimizations would ultimately result in creation of processors that are
specifically optimized for the weirdities of Windoze!
Multiple types of halt instruction, you mean?
3 Jan
3 Jan
7:49 p.m.
New subject: Little Man Computer ( LMC ) simulator ?
Anybody in the group familiar with / have code / or seen a simulator for the
Little Man Computer ( LMC ) ? It is a simplified theoretical computer
architecture out of MIT from 1965 ( I believe ), not a computer for people
with short stature.
Best regards, Steven
5608
days inactive
5611
days old
22 comments
16 participants
participants (16)
-
ajp166＠bellatlantic.net -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
cisin＠xenosoft.com -
dkelvey＠hotmail.com -
frustum＠pacbell.net -
gordonjcp＠gjcp.net -
hilpert＠cs.ubc.ca -
joachim.thiemann＠gmail.com -
jules.richardson99＠gmail.com -
mcguire＠neurotica.com -
rickb＠bensene.com -
spectre＠floodgap.com -
steven.alan.canning＠verizon.net -
wdonzelli＠gmail.com