The Perfect Computer - 36 bits?
|
From: Brian Inglis on 13 Apr 2007 02:27 On Wed, 04 Apr 2007 23:12:38 +0200 in alt.folklore.computers, Terje Mathisen <terje.mathisen(a)hda.hydro.com> wrote: >Brian Inglis wrote: >> On Mon, 02 Apr 07 11:53:42 GMT in alt.folklore.computers, >> jmfbahciv(a)aol.com wrote: >>> DEC documented all of its opcodes. Those that were not used >>> were documented as "Reserved for future use". >> >> Some documented opcodes did different things on different >> implementations, making it possible to determine what kind of CPU you >> were running on, based on the bugs. > >That was the case for early x86 cpus as well: > >One 808x clone (possibly NEC?) implemented one of the BCD/ASCII opcodes >as documented, without noticing that the opcode had the decimal 10 as >the second opcode byte: On an Intel cpu you can/could replace that value >with something else, like using 16 to split a byte value into two hex >nibbles. Is that feature still supported under Pentium and documented anywhere? Anyone test to see what range of values work properly? Was thinking of old UK pounds-shillings-pence currency handling built into old CPUs and/or languages, but also realised it might be useful for handling dates and times, for some calendar systems. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Brian Inglis on 13 Apr 2007 02:49 On Fri, 06 Apr 07 10:36:24 GMT in alt.folklore.computers, jmfbahciv(a)aol.com wrote: >In article <m3lkh6eamk.fsf(a)garlic.com>, > Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: >> >>Rich Alderson <news(a)alderson.users.panix.com> writes: >>> Yes, people did, and do. And I mean besides me. >>> >>> On the hardware side, there are bits of code in the beginning of several of >the >>> diagnostics that determine what hardware platform is under test, for >example by >>> checking the result of >>> >>> MOVE 1,[-2,,777777] >>> AOBJN 1,.+1 >>> SKIPE 1 >>> <branch to code for KA-10 processor> >>> >>> since the KA-10 actually adds 1,,1 to the AC so that the carry out of the >right >>> half propagates to the left. >>> >>> There are programmatic ways to detect the Model 166 processor (PDP-6), >>> the KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume >>> that there were checks for various Foonly and Systems Concepts boxen. >> >>370 introduced store cpuid ... which included processor model number as >>well as processor serial number. > >How did you ship the software if it had numbers "hardwired" in the >software? We had to be generic with all the specifics because >our customers also had multiple systems running software built >from the same distribution tapes. Most OSes, including DEC, had numbers "hardwired" in the software, for disk drives, models, geometries, and capacities. These often had to be hacked for OEM equipment. Newer drive architectures allowed for discovery of these and other features, faked them, or hid them entirely. I'm personally in favour of detailed drive characteristics being available in case developers again become interested in drive performance at a low level. Possibly the gains obtainable from tweaks these days are mainly masked by internal caching, and treating drives as relatively slow peripherals, to be avoided if possible, may be a better overall approach. >>current description of the instruction >>http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/10.58?SHE >LF=DZ9ZBK03&DT=20040504121320 >> >>the problem was then you still needed (potentially new) software that >>had the processor specific logic >> >>one of the things that vm370 had was a table of processor cpuids and >>associated values. when i was doing with dynamic adaptive control >>algorithms and the resource manager product ... was to be able to have >>completely dynamic adaptive values ... w/o requiring a (software lookup) >>table of all possible cpuids (with corresponding values). > >Do you and I have different defintion of processor ID? Each >of our processors had its own number assigned to it. (yea, yea, >the KS was different and that caused tonnes of trouble so I dismiss >it). IBM 5 digit serial numbers were set during IMPL (Initial MicroProgram Load) from each system's custom microcode, and the CPU # was the top sixth digit IIRC, allowing for between 99999 and FFFFF (1M) systems of that type and 16 CPUs per system. No small computer thinking there! -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Brian Inglis on 13 Apr 2007 03:06 On Fri, 06 Apr 07 10:27:51 GMT in alt.folklore.computers, jmfbahciv(a)aol.com wrote: >In article <mddhcru5xde.fsf(a)panix5.panix.com>, > Rich Alderson <news(a)alderson.users.panix.com> wrote: >>jmfbahciv(a)aol.com writes: >> >>> Our attitude was to provide a documented way to query the system both >>> software and hardware. If there is disagreement, we wanted to know about >it. >>> It was called a sanity check. Please not that ITS, TOPS-20, TOPS-10, and >>> something else OSes each have a value assigned to them. Any software could >>> write a UUO asking the system which OS it thought it was running. Then the >>> code could then branch to the appropriate section of code that knew how to >>> interface with the returned OS. This was a design feature and allowed any >>> app code to interface with any PDP-10 OS without rebuilding. >> >>That's software. >> >>> I don't know if anybody wrote code that used this feature. >> >>Yes, people did, and do. And I mean besides me. >> >>On the hardware side, there are bits of code in the beginning of several of >the >>diagnostics > >Oh! Of course! Stupid me...diags. > >> that determine what hardware platform is under test, for example by >>checking the result of >> >> MOVE 1,[-2,,777777] >> AOBJN 1,.+1 >> SKIPE 1 >> <branch to code for KA-10 processor> >> >>since the KA-10 actually adds 1,,1 to the AC so that the carry out of the >right >>half propagates to the left. >> >>There are programmatic ways to detect the Model 166 processor (PDP-6), the >>KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume that there >>were checks for various Foonly and Systems Concepts boxen. > >There was also a need to put the setting in software, too. >Imagine a development shop that has four OS development projects >going on at the same time and one person is working on all four. > >It makes interesting problems if the developer has to have stand-alone >packs to do the development. Current PC chips setup feature information on reset which can be stored by the OS or queried later by privileged instructions. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: jmfbahciv on 13 Apr 2007 06:56 In article <rm8u13d6epff3j0t35arr37ckqem4uns73(a)4ax.com>, Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: >On Fri, 06 Apr 07 10:36:24 GMT in alt.folklore.computers, >jmfbahciv(a)aol.com wrote: > >>In article <m3lkh6eamk.fsf(a)garlic.com>, >> Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: >>> >>>Rich Alderson <news(a)alderson.users.panix.com> writes: >>>> Yes, people did, and do. And I mean besides me. >>>> >>>> On the hardware side, there are bits of code in the beginning of several of >>the >>>> diagnostics that determine what hardware platform is under test, for >>example by >>>> checking the result of >>>> >>>> MOVE 1,[-2,,777777] >>>> AOBJN 1,.+1 >>>> SKIPE 1 >>>> <branch to code for KA-10 processor> >>>> >>>> since the KA-10 actually adds 1,,1 to the AC so that the carry out of the >>right >>>> half propagates to the left. >>>> >>>> There are programmatic ways to detect the Model 166 processor (PDP-6), >>>> the KA-10, the KI-10, the KL-10, the KS-10, and the Toad-1. I assume >>>> that there were checks for various Foonly and Systems Concepts boxen. >>> >>>370 introduced store cpuid ... which included processor model number as >>>well as processor serial number. >> >>How did you ship the software if it had numbers "hardwired" in the >>software? We had to be generic with all the specifics because >>our customers also had multiple systems running software built >>from the same distribution tapes. > >Most OSes, including DEC, had numbers "hardwired" in the software, for >disk drives, models, geometries, and capacities. Huh? Do this exercise. RUN MONGEN and then answer the questions. <snip> /BAH
From: Terje Mathisen on 13 Apr 2007 08:45
Brian Inglis wrote: > On Wed, 04 Apr 2007 23:12:38 +0200 in alt.folklore.computers, Terje > Mathisen <terje.mathisen(a)hda.hydro.com> wrote: >> One 808x clone (possibly NEC?) implemented one of the BCD/ASCII opcodes >> as documented, without noticing that the opcode had the decimal 10 as >> the second opcode byte: On an Intel cpu you can/could replace that value >> with something else, like using 16 to split a byte value into two hex >> nibbles. > > Is that feature still supported under Pentium and documented anywhere? Yes, it is most certainly still there. > Anyone test to see what range of values work properly? It is effectively using a full DIV operation, with similar speed. :-( Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching" |