The Importance of Terminology's Quality

[Phil Runciman]

Apologies: By the time my posts have been added the discussion has moved
on a lot. I have to make a correction too.

It was not a System 4 machine but an ICL 2900 series (Once known as the
New Range Series). Hey it was a long time ago and I have moved countries
4 times since then and anno domini catches up with you.

However, the notion that microcode just fills in the gaps for
instructions not implemented directly in hardware may have been the case
in some systems, but it was not the case in several UK computers. The
micro code enabled interleaving of the execution of machine code so that
different parts of the hardware were active in executing adjacent
instructions at any one instant. 

It also meant that as assembler programmers we could detect performance
improvements when new microcode was implemented. On the HSD DCC2 one of
our microcode programmers was a Cambridge undergrad called Robert. (He
was the sort of guy who saw humour in a mathematical text. A breed
apart?)

He obviously did a good job because my navigational simulator programs
were a third shorter on DCC2 than on the 4130. Shame we did not have
floating point though. Spherical trig was tricky enough in reverse* but
in fixed point hardware it all got a bit convoluted. 

Phil (KDF9 Fan)
 


-----Original Message-----
From: Phil Runciman 
Sent: Friday, 22 August 2008 8:32 a.m.
To: python-list at python.org
Subject: RE: The Importance of Terminology's Quality




>On Thu, 21 Aug 2008 02:36:39 +0000, sln wrote:

>>>Whats os interresting about all this hullabaloo is that nobody has
coded
>>>machine code here, and know's squat about it.
>>>
>>>I'm not talking assembly language. Don't you know that there are
>>>routines that program machine code? Yes, burned in, bitwise encodings
>>>that enable machine instructions? Nothing below that.
>>>
>>>There is nobody here, who ever visited/replied with any thought
>>>relavence that can be brought foward to any degree, meaning anything,
>>>nobody....
>>>
>>>sln
>> 
>> At most, your trying to validate you understanding. But you don't
pose
>> questions, you pose terse inflamatory declarations.
>> 
>> You make me sick!

>Could you elaborate a little on what it is that you're upset about?  I 
>suspect that there are probably quite a few readers of these posts that

>have designed and built their own processors, and coded them in their
own 
>machine language.  I have, and that was before FPGAs started to make
that 
>exercise quite commonplace.  But I don't see how that's at all relevant

>to the debate about the power or other characteristics of programming 
>languages.  Certainly anyone who's programmed a machine in assembly 
>language has a pretty fair understanding of what the machine and the 
>machine language is doing, even though they don't choose to bang the
bits 
>together manually.

>Hope you get better.

>-- 
>Andrew
>

I hope he gets better too. 

I cannot remember the boot sequences for either the TAC computer or the
H16 series. I used to know them but it became so automatic I could do
them in my sleep... and sometimes did. Late nights were common.

However, no-one has mentioned the fact that even machine code is
interpreted when the actual execution of each instruction is managed by
a micro program. I am not up with modern architectures but many
computers used micro programming to enable them to emulate rival
computers back in the late 60's and 70's. 

I believe ICL in South Africa supplied as a 1900 series that in reality
was System 4 hardware running the 1900 instruction set. It was a 1906T
if I remember correctly. (circa 1977). Perhaps someone out there can
confirm this snippet? (To a customer in Bloemfontein?)

FWIW even high-level language programmers got to know machine code if
they had to interpret memory dumps. I know this was very useful to work
out what went wrong with PL/1 code.

Phil (KDF9 Fan)