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@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) -- http://mail.python.org/mailman/listinfo/python-list
