hartley@uvm-cs.UUCP (Steve) (09/18/85)
Laex Colvin asks about an architecture that traps on using uniniitialized
data. The CDC 6000 series architecture does sort of. An option to the loader
will cause all data locations to be filled with a bit pattern representing
"indefinite" which the CPU will choke on.
--
Stephen J. Hartley
USENET: {decvax,ihnp4}!dartvax!uvm-gen!uvm-cs!hartley University of Vermont
CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323robison@uiucdcsb.CS.UIUC.EDU (09/21/85)
One way to trap on uninitialized memory locations is to set the parity bit incorrectly for uninitialized locations. If the location is read before being written, a bad parity interrupt will occur. The Burroughs stack machines use this technique. - Arch
faunt@hplabs.UUCP (Doug Faunt) (09/23/85)
> > One way to trap on uninitialized memory locations is to set the parity bit > incorrectly for uninitialized locations. If the location is read before being > written, a bad parity interrupt will occur. The Burroughs stack machines use > this technique. > > - Arch This is what the original WATFOR for the 7040/44 did, also. -- ....!hplabs!faunt faunt%hplabs@csnet-relay.ARPA HP is not responsible for anything I say here. In fact, what I say here may have been generated by a noisy telephone line.
jfk@tulane.UUCP (John Kreuter) (09/25/85)
> > Laex Colvin asks about an architecture that traps on using uniniitialized > data. The CDC 6000 series architecture does sort of. An option to the loader > will cause all data locations to be filled with a bit pattern representing > "indefinite" which the CPU will choke on. > -- > Stephen J. Hartley > USENET: {decvax,ihnp4}!dartvax!uvm-gen!uvm-cs!hartley University of Vermont > CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323 This is an extremely high overhead way of checking for uninitialized data. An alternative would be an architecture in which a small tag field identifies the type of the data. This would have the further advantage of allowing, say, arithmetic operators to be overloaded as they are in high level languages. See "Advances in Computer Architecture", by Glenford J. Meyers (John Wiley and sons, 1978) John Kreuter Tulane University New Orleans {decvax, ihnp4}!ulysses!tulane!jfk
wdm@ecn-pc.UUCP (William D Michael) (09/29/85)
In article <164@tulane.UUCP> jfk@tulane.UUCP (John Kreuter) writes: >> >> Laex Colvin asks about an architecture that traps on using uniniitialized >> data. The CDC 6000 series architecture does sort of. An option to the loader >> will cause all data locations to be filled with a bit pattern representing >> "indefinite" which the CPU will choke on. >> -- >> Stephen J. Hartley >> USENET: {decvax,ihnp4}!dartvax!uvm-gen!uvm-cs!hartley University of Vermont >> CSNET: hartley%uvm@csnet-relay (802) 656-3330, 862-5323 > >This is an extremely high overhead way of checking for uninitialized data. Extremely high overhead, you say? Please explain how this method is has a higher overhead than a tagged architecture. >An alternative would be an architecture in which a small tag field identifies >the type of the data. This would have the further advantage of allowing, say, >arithmetic operators to be overloaded as they are in high level languages. > >See "Advances in Computer Architecture", by Glenford J. Meyers (John Wiley >and sons, 1978) Tags are nice, I'll grant you, but I think you are missing the boat here. Tags can indeed be useful for this sort of problem, but their real value comes from simplifying instructions set, and making os-type jobs easier to implement (ie, garbage collection). > > John Kreuter Bill Michael (wdm@pur-ee)
kjm@ut-ngp.UTEXAS (Ken Montgomery) (10/01/85)
> Laex Colvin asks about an architecture that traps on using uniniitialized >data. The CDC 6000 series architecture does sort of. An option to the loader >will cause all data locations to be filled with a bit pattern representing >"indefinite" which the CPU will choke on. [Stephen J. Hartley] Unfortunately, this only works for floating point. The non-floating-point arithmetic units will have no problem with this pattern. -- The above viewpoints are mine. They are unrelated to those of anyone else, including my cat and my employer. Ken Montgomery "Shredder-of-hapless-smurfs" ...!{ihnp4,allegra,seismo!ut-sally}!ut-ngp!kjm [Usenet, when working] kjm@ngp.UTEXAS.EDU [Internet, if the nameservers are up]
rcd@opus.UUCP (Dick Dunn) (10/01/85)
>One way to trap on uninitialized memory locations is to set the parity bit >incorrectly for uninitialized locations. If the location is read before being >written, a bad parity interrupt will occur. The Burroughs stack machines use >this technique. Of course, you only want to be able to do such a thing in some protected processor mode (if at all) because if a user process can execute an instruction which will put bad parity on one of its words, you've just traded one class of error for another. (Scenario: Program goes off and trashes an instruction into something that puts bad parity on a data word. Megacycles and parsecs away, it finally uses the data and gets a parity error.) BTW, if you use the mechanism of "bad parity" as a detector for a program using uninitialized data, haven't you (in principle) removed the usefulness of bad parity for detecting memory errors (which is what it was designed to detect in the first place)? Seems that if you really want an uninit-data value, you should add hardware tagging for that purpose rather than usurping the purpose of some other indicator. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...If you plant ice, you're gonna harvest wind.
rcd@opus.UUCP (Dick Dunn) (10/01/85)
> > Laex Colvin asks about an architecture that traps on using uniniitialized > > data. The CDC 6000 series architecture does sort of. An option to the loader > > will cause all data locations to be filled with a bit pattern representing > > "indefinite" which the CPU will choke on. > ... > This is an extremely high overhead way of checking for uninitialized data. Actually, it's almost no overhead. A loader can initialize a data area very quickly (faster than transferring data from disk). The "indefinite" bit pattern really only works for floating-point data (although a modification for pointers is fairly easy), and it comes for free. The indefinite value is roughly the equivalent of a NaN (not a number) representation, which the floating point unit has to handle anyway. (Strange as it may seem, this machine traps ONLY on invalid operands, not on invalid results.) Since words are much wider than addresses, the uninitialized-data bit pattern can contain not only the "indefinite" indicator (which affects only the exponent of the number), but the address of the uninitialized location. Thus, although a value might be picked up and moved around before being used as an operand, when used it will show the location where it was originally stored. Obviously the "bad parity" trick catches the reference to uninitialized data right away, but it has some other problems mentioned in other current articles. (And there is yet another tweak which will cause an error on an attempt to execute the uninitialized word.) -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...If you plant ice, you're gonna harvest wind.
mash@mips.UUCP (John Mashey) (10/02/85)
John Kreuter writes: > This is an extremely high overhead way of checking for uninitialized data. > An alternative would be an architecture in which a small tag field identifies > the type of the data. This would have the further advantage of allowing, say, > arithmetic operators to be overloaded as they are in high level languages. > > See "Advances in Computer Architecture", by Glenford J. Meyers (John Wiley > and sons, 1978) For perspective, let us remember that one finds there [2nd Ed, 1982, p.335]: "In light of the material discussed so far in this book, the development of the iAPX 432 system by Intel Corporation might be considered the most significant architectural development in the last 5-10 years. First,... Second, it is a commercial product, rather than an experimental vehicle, and thus is evidence of both the practicality and feasibility of these concepts." -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
woolsey@umn-cs.UUCP (Jeff Woolsey) (10/07/85)
This was known as PRESETA=DEBUG (a loader option) , which consisted of
filling the field length with 60000460000400400000B+address, which
1) fell into the class of floating point numbers known as Negative Indefinite,
2) contained the address of its original location, and
3) disassembles as
SB0 A0+46000B A No-op of sorts, since B0 is hardwired to 0
EQ *+400000B which produces an address range error.
As I recall, this was a rather ugly integer, as well.
I suppose the reason for the 15-bit NO-OP (46000B) as the operand of the Set B0
instruction was that on the 7600 and its descendants, 30-bit instructions
could start in the last parcel of a word, meaning that the 60000B was the
operand of the previous instruction.
All manner of bizarre things were done on Cybers:
o memory was cleared by doing out-of-range reads of ECS (external core storage)
which returned blocks of zeros quite rapidly (faster than a loop).
o Some folks would do 'display code math' in which two words containing the
display code representations of 10 digits were added together (with the
machine's integer add instruction) and then unbiased with '0000000000',
having propgating carry.
o In order to get anything done in a PPU (Peripheral Processing Unit), you HAD
to do code-modification.
--
--
Even the ghosts will have settled down and raised families by now.
Jeff Woolsey
...ihnp4{!stolaf}!umn-cs!woolsey
woolsey@umn-cs.csnetjer@peora.UUCP (J. Eric Roskos) (10/09/85)
> For perspective, let us remember that one finds there [2nd Ed, 1982, p.335]:
This approach of claiming that a major text in Computer Science is
discredited just because it took Intel's "preliminary" announcements on the
432 as describing a completed product is not a very reasonable one. Myers'
text is well-known and respected.
Likewise, the argument "the 432 didn't succeed, so the architectural
principles behind it are invalid" is a very common one among CISC-detractors,
but it makes little sense. Just because someone's implementation of an
architecture was unsuccessful doesn't mean the architecture is somehow
invalidated. Look at Multics vs. Unix.
--
Shyy-Anzr: J. Eric Roskos
UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer
US Mail: MS 795; Perkin-Elmer SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642guy@sun.uucp (Guy Harris) (10/12/85)
> Just because someone's implementation of an architecture was unsuccessful > doesn't mean the architecture is somehow invalidated. Look at Multics vs. > Unix. UNIX does not (in general) support mapping files into a process' address space, nor does it support dynamic linking, or a multi-ring privilege scheme. As such, UNIX is not an implementation of the same (software) architecture as Multics. The point is still valid in general; however, I know of no implementation of an iAPX432-style architecture which has become a general success. Either nobody's done it right yet, or it isn't as good a general-purpose architecture as the currently dominant architectural style (which could, I guess, be considered descendants either of the 360 or its PDP-11 offshoot - there's probably a machine of that style which preceded the 360, but I'm not enough of a historian to know what it was). There is not enough data to say which is the case. Guy Harris