conor@wren.inmos.co.uk (Conor O'Neill) (04/11/90)
>In article <12393@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > >I pose this strawman... > > how many machines exist where the following does not hold. > > a) now > b) yet to be announced (i.e in the future) > > > (double)0 is represented as binary zeros > (float)0 is represented as binary zeros > int,short,long 0 is represented as binary zeros > char*, struct FOO* NULL is represented as binary zeros > > >Is a potention vendor of some brave,new architecture not asking for >trouble by changing these "happy coincidences". How many applications >assume that "smearing" binary zeroes into a region of memory will >initialise the datatypes mapped at that region to 0 or NULL as the >case may be? Transputers use a signed address space, going from the most negative integer address, through zero, to the most positive address. In many cases this can simplify address calculations (you don't need to worry about overflow). Hence the all-bits-zero pointer points smack into the middle of the address space. There are three approaches to take: 1) Use a different bit-pattern for the NULL pointer. Transputers normally use MOSTNEG INT as a NULL pointer, because it is the address of a transputer link, so `data' cannot reside there. 2) Use all-bits-zero to indicate NULL. Ensure that nothing is ever allocated which crosses (or approaches very closely from below) the 'zero' address. 3) Ignore the problem. Use all-bits-zero anyway. We use approach 3) on our 32-bit processors. So far as we know, no one has attached 2 Gigabytes to a transputer, so the problem of making sure that nothing is allocated there does not arise. Also, transputers do not use virtual memory. No doubt it would be possible to tailor both the loader and malloc so that no memory was ever allocated at zero. This would then satisfy approach 2). 16-bit processors are a different matter. Many (:-) of our customers use more than 32K of memory. Therefore we've taken approach 1), but used a specific bit-pattern (MOSTNEG INT, or 0x8000) which can never correspond to user accessible memory. --- Conor O'Neill, Software Group, INMOS Ltd., UK. UK: conor@inmos.co.uk US: conor@inmos.com "It's state-of-the-art" "But it doesn't work!" "That is the state-of-the-art".
gwyn@smoke.BRL.MIL (Doug Gwyn) (04/13/90)
In article <5515@ganymede.inmos.co.uk> conor@inmos.co.uk () writes: >>In article <12393@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>I pose this strawman... I didn't say that! Please check attributions before posting. Thanks.