What Happened While I Wasn't Looking?

What Happened While I Wasn't Looking?

[Charles H. Sampson]

The Prologue, being information fascinating to all and necessary to un-
derstand the author's position before reading The Questions: 

     I was unlucky enough to be heavily involved with "something else" 
during most of the Ada 9X work.  I know many people were, but in my case 
it really minimized the time I could devote to even following the work, 
much less trying to contribute to it.  In spite of that, I have been 
congratulating myself on understanding the major changes pretty well, 
the OO features, child packages, etc.  That self congratulation might be 
well founded, but I've certainly been stung several times when I stum-
bled across little tweaks that I failed to notice.  My most recent dis-
covery is that the Ada 83 injunction against using address clauses to 
cause overlaying has been dropped.

     The majority of my career has been spent in maintenance program-
ming, with almost all of that in FORTRAN and CMS-2.  Based on my experi-
ence, the single greatest cause of maintenance problems (bugs) and 
enhancement difficulties is the overlay.  Colleagues agree with this 
opinion.  When I taught Ada 83 I pointed out this issue and used it as a 
selling point, saying that overlaying was impossible in a non-erroneous 
Ada program.  I went on to extol the virtues of Unchecked_conversion, in 
particular the point that it makes the "aliasing" obvious at the point 
where it is being used.  Now I will be forced to admit that the beast is 
alive and kicking, at least to some degree, in Ada 95.

The Questions:

     My primary question is, why was this change made?  Was the negative 
impact on maintenance considered?  I haven't found anything on the issue 
in the Rationale.  I've misplaced my copy of the AARM, but I wouldn't 
expect to find anything on it there.  Robert Dewar has pointed out that 
there are efficiency gains coming from never having to do a copy when 
changing from one view to another.  Was that the only consideration?

The Epilogue, being divers observations on the issue:

     The saddest aspect of this mistaken change (my opinion, obviously) 
is that it doesn't adequately support overlaying.  Even if a compiler 
implements the recommended level of support (RM 13.3(12-19)) it is only 
required to do the right thing for the one of the overlaid data whose 
address has been specified (RM 13.3(19)).  To the response that a com-
piler implemented to minimally satisfy the requirement would be very 
poor, consider the example used to demonstrate why overlays through ad-
dress clauses couldn't work in Ada 83: The overlaid data come from dif-
ferent package specifications.  A conventional Ada compiler, retrieving 
information about the packages from its library, would probably find 
that only one of the data should be treated conservatively.  (The much 
maligned CMS-2, which raised aliasing to undreamed of heights, had a 
rule preventing this kind of thing.)  I suppose it would be possible 
after compiling the second package specification (the one that contains 
the address clause) to modify the library information for the first 
package, but how many compilers do this kind of thing?

     Robert has written that he always uses pragma(volatile) on both 
data to make sure the overlay works.  That should do the trick, but I 
see two problems; there may be more.  The first is that code that reads 
the overlaid data becomes overly conservative, fetching them every time 
rather than ever using an in-register value.  (This seems to weaken the 
claim of efficiencies made for the feature.)  The second is that it 
amounts to lying to the compiler and, more important, to the maintenance 
programmer.  According to RM C.6(1), pragma(volatile) is used to "con-
trol the use of shared variables".  While it might seem like a harmless 
white lie to tell the maintenance programmer that a non-shared variable 
is shared, in my experience any lie in programming eventually comes back 
to haunt you, usually at the most inopportune moment.

     It's interesting to note that GNAT handles the two package example 
"right".  My guess is that that's a result of GNAT's treating package 
specifications like include files.  On the other hand, GNAT (PC version 
3.07) allows one of the overlaid objects to be a constant and the other 
to be variable.  Furthermore, the generated code allows the value of the 
constant to be changed.  This is clearly a bug, either in GNAT or the 
language specification.  It is not prohibited in RM 13.3.  Is it prohib-
ited elsewhere?

				Charlie

Re: What Happened While I Wasn't Looking?

[Robert A Duff]

In article <1997Apr2.202514.1843@nosc.mil>,
Charles H. Sampson <sampson@cod.nosc.mil> wrote:
>The Prologue, being information fascinating to all and necessary to un-
>derstand the author's position before reading The Questions: 

OK, here's my Prologue: I was on the Ada 9X language design team, and I
wrote much of chapter 13.

>     The majority of my career has been spent in maintenance program-
>ming, with almost all of that in FORTRAN and CMS-2.  Based on my experi-
>ence, the single greatest cause of maintenance problems (bugs) and 
>enhancement difficulties is the overlay.

Ah, but overlays are *not* a big cause of maintenance problems in Ada 83
or Ada 95.  This isn't because they're forbidden -- it's because they're
not needed most of the time.

>...  When I taught Ada 83 I pointed out this issue and used it as a 
>selling point, saying that overlaying was impossible in a non-erroneous 
>Ada program.

I don't understand how this can be a benefit.  Ada compilers are not
required to detect erroneous things (neither at compile time nor at run
time).  So how can it be beneficial (in terms of eliminating bugs) for
the RM to declare something erroneous?

Analogy: Suppose you write a signed integer expression that overflows.
In C, you get unpredictable results (exactly what Ada calls erroneous).
In Ada, you get a run-time error.  In Lisp, you get the right answer.
It seems to me that, as far as preventing bugs goes, with respect to
this particular issue, C is worst, Ada is better (because it detects the
error), and Lisp is better still (because it prevents the error).
[Before somebody starts a three-way language war -- please note that I
said "with respect to this particular issue"!]
Erroneousness/unpredictability seems like the worst possible semantics
(from the point of view of getting rid of bugs -- from the point of view
of efficiency, erroneousness can be a good thing, which is why it exists
in the first place).

Anyway, IMHO, a language definition should not try to "prevent evil" so
much as "encourage good".  Example: I've seen cases in FORTRAN 66 (I
haven't used FORTRAN in a long time!), where EQUIVALENCE was used for
space efficiency.  Two unrelated subroutines wanted to use the same
storage for totally unrelated purposes, and the programmer ensured that
this storage wasn't being used at the same time.  Well, in Ada (or
Pascal or C or ...), you just use local variables, which get allocated
on the stack, for this purpose.  You end up reusing the same memory, but
in a much safer, more maintainable way.  The reason people do it this
way in Ada is because Ada has this nice feature of local variables --
not because of some admonishment against Address clauses.

>...  I went on to extol the virtues of Unchecked_conversion, in 
>particular the point that it makes the "aliasing" obvious at the point 
>where it is being used.

Well, unchecked conversions can be erroneous, too, in some cases.

Also, note that unchecked_conv can create aliases, in some cases.  The
obvious case is that you can convert from an address or access value to
an access value, which, if it works at all, which it does on most
compilers for most data types, creates an alias.  It seems to me that
these kinds of aliases are just as damaging as the ones created by
Address clauses.

A lesser-known case is 13.9(12), "An implementation may return the
result of an unchecked conversion by reference, ...".  This was also
true in Ada 83, by virtue of an AI (though the original RM83 didn't say
so).  The reason for this rule is efficiency.  Furthermore,
implementations are *encouraged* to do the by-ref thing, in 13.9(15).
It can create aliases, which is why the explicit permission is needed,
since functions normally return their results by copy.

>...Now I will be forced to admit that the beast is 
>alive and kicking, at least to some degree, in Ada 95.

Methinks you exaggerate.  Just because the RM has changed, doesn't mean
everybody is going to go out and sprinkle address clauses all over their
code.  The goal of the language designer should be to provide enough
safe features, that Address clauses and unchecked conversions and
whatnot are rarely needed.  (E.g. if space efficiency is the goal, give
the programmer local variables, variant records, class-wide types, etc.
If the goal is to break the typing system in an efficient manner, then,
well, there's not much you can do -- let the programmer worry about it.)

>The Questions:
>
>     My primary question is, why was this change made?

First of all, the change was not to simply eliminate the Ada 83 rule.
The rule was replaced by 13.3(13), which says almost the same thing, and
certainly lets one know of the potential evils of this feature.

I think the change was made for these reasons:

(1) It's hard to formally define what an "overlay" is.  I mean, suppose
you use an Address clause to put an Ada variable at a location that is
some sort of I/O control register.  Is that an overlay?  In some sense,
it is -- you're overlaying the Ada variable with a non-Ada "variable".
But this is exactly what Address clauses are *for*.  Does "overlay" only
mean overlaying two Ada variables?  Why?

(2) In practise, although Ada 83 programmers didn't use address_clauses
much, when they did, they sometimes used them to make overlays, and
their programs worked fine (albeit non-portably).  It seems silly to
insist that common practise is erroneous.  The real rule is that you
have to know what sort of code your compiler is generating, and that's
what 13.3(13) says.

(3) Other features are just as "evil" (for example unchecked conversion
of access values).  Why single out address clauses?

(4) Overlays can be useful (but you have to be careful, if you're going
to avoid maintenance headaches).

(5) It's possible to encapsulate one's use of overlaid storage.

(6) The language design team, and the reviewers, spent most of their
time worrying about features outside chapter 13.  This was also true of
the Ada 83 RM, and partly explains why chapter 13 was and is more buggy
than other parts of the RM.

>...Was the negative 
>impact on maintenance considered?  I haven't found anything on the issue 
>in the Rationale.  I've misplaced my copy of the AARM, but I wouldn't 
>expect to find anything on it there.

There's quite a bit of discussion in the AARM about how Address clauses
can cause trouble.  There is no explicit list of reasons for the change.

>...  Robert Dewar has pointed out that 
>there are efficiency gains coming from never having to do a copy when 
>changing from one view to another.  Was that the only consideration?
>
>The Epilogue, being divers observations on the issue:
>
>     The saddest aspect of this mistaken change (my opinion, obviously) 
>is that it doesn't adequately support overlaying.  Even if a compiler 
>implements the recommended level of support (RM 13.3(12-19)) it is only 
>required to do the right thing for the one of the overlaid data whose 
>address has been specified (RM 13.3(19)).

If you make the other variable "aliased", then you'll be OK.

>...To the response that a com-
>piler implemented to minimally satisfy the requirement would be very 
>poor, consider the example used to demonstrate why overlays through ad-
>dress clauses couldn't work in Ada 83: The overlaid data come from dif-
>ferent package specifications.  A conventional Ada compiler, retrieving 
>information about the packages from its library, would probably find 
>that only one of the data should be treated conservatively.  (The much 
>maligned CMS-2, which raised aliasing to undreamed of heights, had a 
>rule preventing this kind of thing.)  I suppose it would be possible 
>after compiling the second package specification (the one that contains 
>the address clause) to modify the library information for the first 
>package, but how many compilers do this kind of thing?

I don't think any such thing is possible, even in theory.  That's why we
talk about "erroneous", rather than "illegal".  Consider:

    X: T;
    
    procedure P(A: Address) is
        Y: T2;
        for Y'Address use A;
    begin
        ...
    end P;
    
    P(X'Address + Ident_Int(17));

...where the declaration of X, the procedure body P, and the call to P,
might be in three different compilation units, and neither of the body
of P and the call to P have visibility upon each other.

>     Robert has written that he always uses pragma(volatile) on both 
>data to make sure the overlay works.  That should do the trick, but I 
>see two problems; there may be more.  The first is that code that reads 
>the overlaid data becomes overly conservative, fetching them every time 
>rather than ever using an in-register value.  (This seems to weaken the 
>claim of efficiencies made for the feature.)  The second is that it 
>amounts to lying to the compiler and, more important, to the maintenance 
>programmer.  According to RM C.6(1), pragma(volatile) is used to "con-
>trol the use of shared variables".  While it might seem like a harmless 
>white lie to tell the maintenance programmer that a non-shared variable 
>is shared, in my experience any lie in programming eventually comes back 
>to haunt you, usually at the most inopportune moment.
>
>     It's interesting to note that GNAT handles the two package example 
>"right".  My guess is that that's a result of GNAT's treating package 
>specifications like include files.  On the other hand, GNAT (PC version 
>3.07) allows one of the overlaid objects to be a constant and the other 
>to be variable.  Furthermore, the generated code allows the value of the 
>constant to be changed.  This is clearly a bug, either in GNAT or the 
>language specification.  It is not prohibited in RM 13.3.  Is it prohib-
>ited elsewhere?

No, except that 13.3(13) allows the compiler to declare this case
erroneous.

I think the idea is that you don't clutter low-level features with all
kinds of safety-related rules.  If you want safety, use all the nice
features in chapters 1 to 12.  If you use something in chapter 13 that's
unsafe, encapsulate it, and be careful.

- Bob

Re: What Happened While I Wasn't Looking?

[Robert Dewar]

Charles said

<<     It's interesting to note that GNAT handles the two package example
"right".  My guess is that that's a result of GNAT's treating package
specifications like include files.  On the other hand, GNAT (PC version
3.07) allows one of the overlaid objects to be a constant and the other
to be variable.  Furthermore, the generated code allows the value of the
constant to be changed.  This is clearly a bug, either in GNAT or the
language specification.  It is not prohibited in RM 13.3.  Is it prohib-
ited elsewhere?>>


nope! it's not a bug. That can still be erroneous in Ada 95. I guess that
will make you happy, since for some incomprehensible reason, you prefer
that this be erroneous, and would like more cases to be erroneous :-)

Re: What Happened While I Wasn't Looking?

[Robert Dewar]

<<I don't understand how this can be a benefit.  Ada compilers are not
required to detect erroneous things (neither at compile time nor at run
time).  So how can it be beneficial (in terms of eliminating bugs) for
the RM to declare something erroneous?
>>

Furthermore, the status of overlays in Ada 83 is identical to the status
in Fortran, i.e. that officially they do not work, but in practice they
can be used successfully in some circumstances. I find Charles Sampson's
concern about the change from Ada 83 to Ada 95 here quite misplaced!

Re: Overflows (lisp fixnum-bignum conversion)

[Clayton Weaver]

(Is this nit-picking? Just a special case for the lisp fixnum to bignum
conversion:)

On Thu, 3 Apr 1997, Robert A Duff wrote:

> Analogy: Suppose you write a signed integer expression that overflows.
> In C, you get unpredictable results (exactly what Ada calls erroneous).
> In Ada, you get a run-time error.  In Lisp, you get the right answer.
> It seems to me that, as far as preventing bugs goes, with respect to
> this particular issue, C is worst, Ada is better (because it detects the
> error), and Lisp is better still (because it prevents the error).
> [Before somebody starts a three-way language war -- please note that I
> said "with respect to this particular issue"!]

Suppose the integer expression that overflows is used to determine the
index size for an array allocation.
 
Std lisp limits array indexes to fixnums. Lisp can transparently cast the
overflowing representation from fixnum to bignum, but it will still error
if it tries to allocate an array ("vector") with an index size beyond the
fixnum bound, unless you have a custom handler for that case that either
changes the array to some other storage type or virtualizes the data
structure into an array of arrays, and sets a flag that whatever function
accesses that array can read to change its lookup method.

Regards, Clayton Weaver  cgweav@eskimo.com  (Seattle)

Re: Overflows (lisp fixnum-bignum conversion)

[Robert Dewar]

Robert Duff said

<<> Analogy: Suppose you write a signed integer expression that overflows.
> In C, you get unpredictable results (exactly what Ada calls erroneous).
> In Ada, you get a run-time error.  In Lisp, you get the right answer.
> It seems to me that, as far as preventing bugs goes, with respect to
> this particular issue, C is worst, Ada is better (because it detects the
> error), and Lisp is better still (because it prevents the error).>>

I find this too facile. The trouble is that better means better according
to some metric. What are you interested in?

More flexibility
More efficiency
More simplicity
...


Sure, it is more convenient for a programmer if all integers have unlimited
length, including array subscripts, but there is a real cost for this (if
I remember, even in LISP standard arrays do not allow bignums as subscripts).
If you are interested in expressive power, and do not care about efficiency,
then Ada is not the apprropriate language level (neither is C++ or Java).
LISP is getting somewhere closer to where you want to be, but in general
you want to take a better look at very high level languages like SETL
(In SETL *all* integers, including those used for subscripts, are unlimited
in size, and indeed general mappings mean that you can do arbitrary things
with the equivalent of arrays like:

    a (1) := 0;
    a (1000000000000000000000000000000000000000000000000) := 0;

and it works fine -- BUT slowly! You pay a price for this kind of
flexibility. I often find that I can write things in SPITBOL (a
dialect of SNOBOL-4) in a fraction of the time that it would take
in a language like C++ or Ada. But I do not expect to use SPITBOL
for writing high efficiency general purpose code.

Someone who is interested in efficiency to the exclusion of any other
consideration may consider C to be the best language with respect to
overflow handling, since neither the language nor the compiler is
burdened by "useless" overflow checks.

In practice language design is a series of compromises, and we choose
different places on the scale depending on our purpose. In Ada we make
a concious decision to give up a small amount of efficiency in the
interests of safety, and Java makes a similar decision.

That's why arguing that one language is better than another is always
a confusing activity, where lack of communication is common!

Re: Overflows (lisp fixnum-bignum conversion)

[Robert A Duff]

In article <dewar.860257082@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Robert Duff said
>
><<> Analogy: Suppose you write a signed integer expression that overflows.
>> In C, you get unpredictable results (exactly what Ada calls erroneous).
>> In Ada, you get a run-time error.  In Lisp, you get the right answer.
>> It seems to me that, as far as preventing bugs goes, with respect to
>> this particular issue, C is worst, Ada is better (because it detects the
>> error), and Lisp is better still (because it prevents the error).>>
>
>I find this too facile. The trouble is that better means better according
>to some metric. What are you interested in?
>
>More flexibility
>More efficiency
>More simplicity
>...

I thought I made that clear: I said, "as far as preventing bugs goes".
I meant logic errors in the program.  In general, with respect to *this*
metric, the worst possible semantics is "erroneous", better is to detect
the error (either at compile time or run time), and best of all is to
prevent the error.  This is because it is easier to reason about the
program, if you don't have to worry about weird boundary conditions
involving numbers like 2**31-1, which (usually) have nothing to do with
the problem, and everything to do with the underlying hardware.  I am
well aware that other concerns (mainly efficiency) might produce a
different rating -- in particular, for efficiency, "erroneous" is best,
detection second best, and prevention (i.e. Lisp bignums) worst.

Remember that this was all in response to somebody who claimed that
declaring a certain feature of Ada 83 "erroneous" somehow made this
feature of Ada 83 safer, than corresponding features in other languages
that require the feature to "work" (such as Ada 95).  I disagree with
that.

I also made it clear I was talking about overflows of signed integer
numbers -- that is, on arithmetic.  For this particular feature, and
this particular metric (bug prevention), I stand by my statement that C
is worst, Ada better, and Lisp better still.  Note that I was *not*
talking about array bounds checking, nor about range checking.  Just
overflows.

Aside: It would be possible to design a language that had range checking
as in Ada, but prevented overflows as in Lisp.  In such a language, I
could write:

    type T is range 0 .. N;
    X: T := ...;
    Y: T := ...;
    Average: T := (X + Y) / 2;

and be guaranteed that Average will contain the "right" answer.  In Ada,
if N is 10, it will probably not overflow.  If N is 2**31, it will
overflow on some compilers in some cases, and if N is 2**32, some
compilers won't even accept it.  And don't beat me up about efficiency:
I understand that there would be an efficiency cost to such
functionality, in some cases.  (OTOH, the inefficiency could be pretty
much avoided by writing "(T'(X) + T'(Y)) / 2", and make sure the bounds
of T match the hardware bounds.)

Maybe I could also write:

    type T is range 0..Infinite;

or

    type T is range 0..<>;

or some such thing, meaning the upper bound is arbitrarily large.

Maybe I could also write:

    type T is range 0..<non-static-expression>;

- Bob

Re: Overflows (lisp fixnum-bignum conversion)

[Charles H. Sampson]

In article <E8Bvpy.Ixq@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>
>Remember that this was all in response to somebody who claimed that
>declaring a certain feature of Ada 83 "erroneous" somehow made this
>feature of Ada 83 safer, than corresponding features in other languages
>that require the feature to "work" (such as Ada 95).  I disagree with
>that.
>
     Hold on!  I'm pretty sure you're referring to me, the guy who 
started this thread, and I said no such thing.  It's beyond me how what 
I originally said could have been interpreted that way, but I later 
elaborated.  Repeating: In my shop, erroneous means not checked by the 
compiler (maybe not checkable) and compiler dependent, ad hoc, seman-
tics; therefore don't use.

     Ada 83 had a pretty short list of erroneous constructs, so it was 
generally easy to avoid them.  Not always.  Some were treacherous, such 
as referencing an actual parameter directly and through its correspond-
ing formal parameter, which fortunately doesn't arise very often in a 
well-designed program.  In any case, that's an aliasing problem and my 
original complaint was that by adding overlays to Ada 95 another form of 
aliasing is made available, with its attendant impact on maintenance and 
enhancement.  Ada 83 had pretty well minimized aliasing to those cases 
that were unavoidable in any practical sense.

				Charlie

Re: Overflows (lisp fixnum-bignum conversion)

[Robert A Duff]

In article <Pine.SUN.3.96.970405054237.22894A-100000@eskimo.com>,
Clayton Weaver  <cgweav@eskimo.com> wrote:
>Std lisp limits array indexes to fixnums. Lisp can transparently cast the
>overflowing representation from fixnum to bignum, but it will still error
>if it tries to allocate an array ("vector") with an index size beyond the
>fixnum bound, unless you have a custom handler for that case that either
>changes the array to some other storage type or virtualizes the data
>structure into an array of arrays, and sets a flag that whatever function
>accesses that array can read to change its lookup method.

I won't complain if I can't allocate an array bigger than 2**32 bytes on
a machine that has a 32-bit address space.  That's a lot different from
telling me I can't allocate a 1000-bit integer on such a machine.

- Bob

Re: Overflows (lisp fixnum-bignum conversion)

[Nick Roberts]

Robert A Duff <bobduff@world.std.com> wrote in article 
> I won't complain if I can't allocate an array bigger than 2**32 bytes on
> a machine that has a 32-bit address space.  That's a lot different from
> telling me I can't allocate a 1000-bit integer on such a machine.


In ten years time we'll all have 64-bit machines with hundreds of Gb of RAM
(as well as content-addressed memory etc.) and look back at 32-bit
addressing as ludicrously small. "How ever did we manage with such tiny
amounts of memory?" we will ask each other ;-)

Nick.

Re: Overflows (lisp fixnum-bignum conversion)

[Robert A Duff]

In article <01bc42b0$a88691c0$90f482c1@xhv46.dial.pipex.com>,
Nick Roberts <Nick.Roberts@dial.pipex.com> wrote:
>
>
>Robert A Duff <bobduff@world.std.com> wrote in article 
>> I won't complain if I can't allocate an array bigger than 2**32 bytes on
>> a machine that has a 32-bit address space.  That's a lot different from
>> telling me I can't allocate a 1000-bit integer on such a machine.
>
>
>In ten years time we'll all have 64-bit machines with hundreds of Gb of RAM
>(as well as content-addressed memory etc.) and look back at 32-bit
>addressing as ludicrously small. "How ever did we manage with such tiny
>amounts of memory?" we will ask each other ;-)

Perhaps, but the typical Ada, C++, Pascal, etc. compiler will *still*
not handle my 1000-bit integer correctly!  Lisp and Smalltalk, which
never had any problem with 1000-bit integers on 16-bit machines, will
*still* have no problem.

(By the way, in going from a 32-bit address to a 64-bit address, don't
think in terms of doubling the size of the address.  In fact, you're
multiplying the the size of the address space by about 4 billion, which
is an awful lot.  Much bigger than the switch from 16 to 32.  It's hard
for me to even imagine how big 2**64 bytes is.)

- Bob

Re: Overflows (lisp fixnum-bignum conversion)

[Robert Dewar]

Bob Duff said

<<(By the way, in going from a 32-bit address to a 64-bit address, don't
think in terms of doubling the size of the address.  In fact, you're
multiplying the the size of the address space by about 4 billion, which
is an awful lot.  Much bigger than the switch from 16 to 32.  It's hard
for me to even imagine how big 2**64 bytes is.)>>

Yes, but this is address space, not actual data in a program, if you start
mappiong entire file systems into virtual memory, you can be surprised how
fast the 64 bits gets eaten up.

Re: Overflows (lisp fixnum-bignum conversion)

[Larry Kilgallen]

In article <dewar.860424609@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Bob Duff said
> 
> <<(By the way, in going from a 32-bit address to a 64-bit address, don't
> think in terms of doubling the size of the address.  In fact, you're
> multiplying the the size of the address space by about 4 billion, which
> is an awful lot.  Much bigger than the switch from 16 to 32.  It's hard
> for me to even imagine how big 2**64 bytes is.)>>
> 
> Yes, but this is address space, not actual data in a program, if you start
> mappiong entire file systems into virtual memory, you can be surprised how
> fast the 64 bits gets eaten up.

I don't see it going that fast.  Disks I use hold 1 GB, while others
can hold 4 or 9 GB.  64 bits allows me to address the contents of about
2,000,000,000 of the 9 GB drives.  How many disk drives have ever been
built ?

Larry Kilgallen

Re: Overflows (lisp fixnum-bignum conversion)

[Robert Dewar]

Larry said

<<I don't see it going that fast.  Disks I use hold 1 GB, while others
can hold 4 or 9 GB.  64 bits allows me to address the contents of about
2,000,000,000 of the 9 GB drives.  How many disk drives have ever been
built ?>>

First, the 10GB drives you are used to using on small machines are by no 
means the largest storage devices in use to day, many large mainframe
installations approach terabyte storage capacity, and some exceed it.

Second, your calculation assumes that you are linearly mapping the disks
into memory, that's not at all the way it works, instead you would map
them into a hierarchical arrangemnent, allowing LOTS of extra space for
expansion in each node. The whole idea of a 64-bit address space is that
you can "waste" it lavishly to allow for growth of structures, and not
run out. 

For instance, in an Ada environment in a 64-bit machine, it makes perfectly
good sense to give every task a gigabyte stack, even if you have thousands
of tasks, but you cannot use this approach at all on a 32-bit machine.

Re: Overflows (lisp fixnum-bignum conversion)

[Robert A Duff]

In article <dewar.860441935@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>For instance, in an Ada environment in a 64-bit machine, it makes perfectly
>good sense to give every task a gigabyte stack, even if you have thousands
>of tasks, but you cannot use this approach at all on a 32-bit machine.

How about this scheme for a 32-bit machine?  Reserve half the address
space for code and heap.  Give the other half to the environment task.
If a second task is created, steal half of the unused address space from
the first task.  If a third task is created, steal half of the unused
address space from the task with the biggest unused stack space.  And so
on.

Thus, you can create lots of small tasks, or a few huge ones, without
ever having to say "pragma Storage_Size".  (Of course, you can't create
a huge number of huge tasks -- but that's a limitation of the machine,
not the run-time model.)

This seems better than having a particular default size for each task's
stack.  Has anybody done it?

(As Robert says, on a 64-bit machine, you can allocate, say, 16 G of
address space to each task, and still have enough address space for
about a billion task stacks.)

- Bob

Re: Overflows (lisp fixnum-bignum conversion)

[Nick Roberts]

Larry Kilgallen <kilgallen@eisner.decus.org> wrote in article
<1997Apr7.130018.1@eisner>...
[...]
> [...]  Disks I use hold 1 GB, while others
> can hold 4 or 9 GB.  64 bits allows me to address the contents of about
> 2,000,000,000 of the 9 GB drives.  How many disk drives have ever been
> built ?


Already IBM scientists (at Boca Raton, is it?) are building prototype '3D'
computers - which use laser holography within a block of a very special
material which switches its angle of polarisation very fast at a certain
precise temperature - which promise to be able to store the equivalent of
2^64 bytes of information easily (probably a lot more). Such computers
would certainly have the potential for outsmarting humans by several orders
of magnitude. This is actually true. Sleep well!

Nick.

Re: Overflows (lisp fixnum-bignum conversion)

[Robert Dewar]

Nick said

<<Already IBM scientists (at Boca Raton, is it?) are building prototype '3D'
computers - which use laser holography within a block of a very special
material which switches its angle of polarisation very fast at a certain
precise temperature - which promise to be able to store the equivalent of
2^64 bytes of information easily (probably a lot more). Such computers
would certainly have the potential for outsmarting humans by several orders
of magnitude. This is actually true. Sleep well!!!>

Nick if you really think that simply providing computers with 2**64 bytes
of information will magically ensure that they can outsmart humans, you
have been watching too much Startrek. Yes, I know you said potential, but
still ....

Re: Overflows (lisp fixnum-bignum conversion)

[Joel VanLaven]

Larry Kilgallen (kilgallen@eisner.decus.org) wrote:
: In article <dewar.860424609@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
: > Bob Duff said
: > 
: > <<(By the way, in going from a 32-bit address to a 64-bit address, don't
: > think in terms of doubling the size of the address.  In fact, you're
: > multiplying the the size of the address space by about 4 billion, which
: > is an awful lot.  Much bigger than the switch from 16 to 32.  It's hard
: > for me to even imagine how big 2**64 bytes is.)>>
: > 
: > Yes, but this is address space, not actual data in a program, if you start
: > mappiong entire file systems into virtual memory, you can be surprised how
: > fast the 64 bits gets eaten up.

: I don't see it going that fast.  Disks I use hold 1 GB, while others
: can hold 4 or 9 GB.  64 bits allows me to address the contents of about
: 2,000,000,000 of the 9 GB drives.  How many disk drives have ever been
: built ?

I aggree.  Given progress similar to history, 64 bits ought to be enough
for many decades.  Assuming that capacity doubles every two years and
that only highly specialized systems today would need more than 1 terrabyte
of disk space, the first time 64 bit addresses will not cover a very large
filesystem will be in about 48 years.  The average 4gig home system 
(extrapolated) won't hit that barrier for another 16 years after that.
Before either UNIX 32-bit times will wrap around.  In between we will
probably think that 32 bit addressing wasn't enough but 64 bits is more
than enough.

-- Joel.
-- 
-- Joel VanLaven

Architectures

[Nick Roberts]

Joel VanLaven <jvl@ocsystems.com> wrote in article
<1997Apr9.214815.16233@ocsystems.com>...
> Given progress similar to history, 64 bits ought to be enough
> for many decades.  Assuming that capacity doubles every two years and
> that only highly specialized systems today would need more than 1
terrabyte
> of disk space, the first time 64 bit addresses will not cover a very
large
> filesystem will be in about 48 years.  The average 4gig home system 
> (extrapolated) won't hit that barrier for another 16 years after that.
> Before either UNIX 32-bit times will wrap around.  In between we will
> probably think that 32 bit addressing wasn't enough but 64 bits is more
> than enough.


It's interesting that good old MULTICS (remember MULTICS?), back in the
swinging sixties, was based on a 48-bit (I think it was about that)
addressing scheme, divided into 24 bits for a segment selector, and 24 for
the offset. The idea was that all files (eventually) would be mapped
straight into a segment each.

Of course, in the end, it never happened (not due to technical reasons).

Nowadays, 16MB would be considered much too small a limit for file size,
but it probably seemed plenty then. It's not too difficult to imagine
applications requiring data sets bigger than 4GB to be loaded into
(virtual) memory, in the not too distant future. For example, an
application which implemented very sophisticated voice recognition.
Tomorrow's architecture will have to cope with this sort of thing.

Nick.

Re: What Happened While I Wasn't Looking?

[Nick Roberts]

Robert A Duff <bobduff@world.std.com> wrote in article
<E82sM5.Gwv@world.std.com> a long and rambling answer to a fairly long and
rambling post in the first place :-) about how Lisp does the right thing
with arithmetic, and how he doesn't want to start a language war. Surely we
are all men of the world? All credit to Lisp for doing the right thing!
Also, this illustrates the difficulties of avoiding sexism: how does one
convert "all men of the world" into a politically correct equivalent?

More to the point, Ada is used to create real-time applications. Like it or
not, this often requires interfacing with the hardware in a pretty dirty
manner. It is wrong, of course, but this is a world of deadlines, and
expediency sometimes has to happen. No-one in business is going to trust a
language which prevents this sort of expediency, no matter how 'ugly' it
may be. So, dislike it as you may (and I can assure you, I do as much as
anyone), Ada just has to allow it. Thus, the RM is right. What would be
wrong would be for any programmer to use the facility when not strictly
necessary.

Nick.

Re: What Happened While I Wasn't Looking?

[Charles H. Sampson]

     Can someone e-mail a copy of my original post to me? I needed to 
save a copy and I forgot; my news service deletes outgoing posts very 
quickly.  Thanks.

				Charlie

Re: What Happened While I Wasn't Looking?

[Charles H. Sampson]

     My thanks to Bob for his response to my post.  I truly appreciate
it.  Unfortunately, I don't agree with much of it, so I follow up.

     I apologize for the length of this post.  I've cut it down as much 
as seems possible, but it's still pretty long.

In article <E82sM5.Gwv@world.std.com>,
Robert A Duff <bobduff@world.std.com> wrote:
>In article <1997Apr2.202514.1843@nosc.mil>, Charles H. Sampson <me> wrote:
>
>>     The majority of my career has been spent in maintenance program-
>>ming, with almost all of that in FORTRAN and CMS-2.  Based on my experi-
>>ence, the single greatest cause of maintenance problems (bugs) and 
>>enhancement difficulties is the overlay.
>
>Ah, but overlays are *not* a big cause of maintenance problems in Ada 83
>or Ada 95.  This isn't because they're forbidden -- it's because they're
>not needed most of the time.
>
     I agree, to a point.  Certainly most of the overlaying that I've 
seen in both CMS-2 and FORTRAN arose as an attempt to get around short-
comings of those languages, shortcomings that Ada doesn't have.  How-
ever, I'm pretty sure that overlaying through address clauses being 
erroneous has helped keep it down to some degree.  (See below.)

>>...  When I taught Ada 83 I pointed out this issue and used it as a 
>>selling point, saying that overlaying was impossible in a non-erroneous 
>>Ada program.
>
>I don't understand how this can be a benefit.  Ada compilers are not
>required to detect erroneous things (neither at compile time nor at run
>time).  So how can it be beneficial (in terms of eliminating bugs) for
>the RM to declare something erroneous?
>
     It depends on how you treat erroneousness.  I've been surprised at 
some of the responses to this thread that seem very close to relishing 
the erroneous constructs as potentially nice holes that can be exploited 
when necessary.  When I taught Ada 83 I pointed out that they have no 
language defined semantics, a compiler is not required to detect them 
and often can't, and, even if you discover what the semantics are for 
your particular combination of compiler and target computer, there's a 
very good chance that it's not portable and they might even change in 
the next version of the compiler.  Conclusion: Avoid them.  (By the way, 
I know the drill.  I'm using "erroneous construct" as a convenient 
shorthand for the much longer, technically correct, phrase.)
>
>Anyway, IMHO, a language definition should not try to "prevent evil" so
>much as "encourage good".  ...
>
     That's at least an arguable point.  Carried to its extreme, which 
I know is not being advocated here, you get to the point of saying, "Put 
anything at all into the language, provided you've included good ver-
sions of all the bad things."  Certainly the effort that culminated in 
Ada 83 had a lot of "do not allow" guidelines.

>>       ...  I went on to extol the virtues of Unchecked_conversion, in 
>>particular the point that it makes the "aliasing" obvious at the point 
>>where it is being used.
>
>Well, unchecked conversions can be erroneous, too, in some cases.
>
     Yes, they can, and they can be non-portable as well.  Rephrasing the 
point that I tried to make before: The advantage of Unchecked_conversion 
is that it is "self-flagging".  Every place that it appears in the 
source code is a potential trouble spot that has to be investigated when 
porting.  In the case of overlaying, it's not the overlay itself that 
must be investigated, but every reference to the two objects involved.  
Probably most of those references will be benign.

>Also, note that unchecked_conv can create aliases, in some cases.  The
>obvious case is that you can convert from an address or access value to
>an access value, which, if it works at all, which it does on most
>compilers for most data types, creates an alias.  It seems to me that
>these kinds of aliases are just as damaging as the ones created by
>Address clauses.
>
     I don't follow this.  You seem to be saying that because an access 
value can sometimes (often) be created using Unchecked_conversion, then
it can create aliases.  I'll concede that, but it seems to me to be no-
thing more than the general problem of aliasing through pointers.

>A lesser-known case is 13.9(12), "An implementation may return the
>result of an unchecked conversion by reference, ...".  This was also
>true in Ada 83, by virtue of an AI (though the original RM83 didn't say
>so).  The reason for this rule is efficiency.  Furthermore,
>implementations are *encouraged* to do the by-ref thing, in 13.9(15).
>It can create aliases, which is why the explicit permission is needed,
>since functions normally return their results by copy.
>
     This is off my main subject, but maybe somebody can explain 
13.9(15) to me.  I find it unusual for a language definition to say, "A 
compiler may generate code to implement the semantics of this feature."

>>                    ...Now I will be forced to admit that the beast is 
>>alive and kicking, at least to some degree, in Ada 95.
>
>Methinks you exaggerate.  Just because the RM has changed, doesn't mean
>everybody is going to go out and sprinkle address clauses all over their
>code.  ... 

     No, certainly everybody isn't going to do that.  There's a large 
body of software engineers out there who, like me, look upon Ada as a 
gift from the gods.  On the other hand, there are a lot of Ada program-
mers, the kind that used to be called hackers, who will try anything to 
"get the job done".  They might even be anti-Ada.  (Let's avoid discus-
sion of the mandate.  Such people could be part of the troops on a large 
project whose leaders have chosen Ada for reasons that have nothing to 
do with the mandate.)  If their mindset is such that they don't see any-
thing wrong with overlays, they'll try to use them.

     I know of one CMS-2 to Ada translator that uses address clauses in 
Ada 83 to translate the CMS-2 overlay.  This translator was created by a 
group that should know better, who should understand at least the port-
ability implications of the code they are generating.  Never mind that 
simply forcing two objects to share memory is no guarantee that the 
CMS-2 semantics have been reproduced.

>>     My primary question is, why was this change made?
>
>First of all, the change was not to simply eliminate the Ada 83 rule.
>The rule was replaced by 13.3(13), which says almost the same thing, and
>certainly lets one know of the potential evils of this feature.
>
     Wait a minute!  The injunction in Ada 83 is against overlaying ob-
jects and program units.  13.3(13) says that the programmer must ensure 
that the address given in an address clause is valid.  Other than the 
appearance of the word _erroneous_, I see no connection between them.  
(The term _valid address_ appears to be undefined in the RM--at least 
it's not in the index--so I have to guess that it means things like en-
suring word or paragraph alignment when required by the datum.)

>I think the change was made for these reasons:
>
>(1) It's hard to formally define what an "overlay" is.  I mean, suppose
>you use an Address clause to put an Ada variable at a location that is
>some sort of I/O control register.  Is that an overlay?  In some sense,
>it is -- you're overlaying the Ada variable with a non-Ada "variable".
>But this is exactly what Address clauses are *for*.  Does "overlay" only
>mean overlaying two Ada variables?  Why?
>
     When I use the term _overlay_ I mean two objects sharing memory.  
That's what I meant in my original post.  As to why, because I'm pretty 
sure that that's what most people mean by the term.  What you're refer-
ring to here I call "mapping to memory" and I agree that that is exactly 
what address clauses used to be for.  I see only the slightest connec-
tion between the two.

>(2) In practise, although Ada 83 programmers didn't use address_clauses
>much, when they did, they sometimes used them to make overlays, and
>their programs worked fine (albeit non-portably).  ...

     They sometimes worked fine for a particular version of a particu-
lar compiler for a particular target computer.

>                                              ...  It seems silly to
>insist that common practise is erroneous.  ...

     The above seems to me to be exactly why such a usage should be 
classified as erroneous.

>                                      ...  The real rule is that you
>have to know what sort of code your compiler is generating, and that's
>what 13.3(13) says.
>
     Again, I can't read 13.3(13) that way.

>(3) Other features are just as "evil" (for example unchecked conversion
>of access values).  Why single out address clauses?
>
     Again, Unchecked_conversion is a lesser evil because of its self-
flagging nature.  Also, Unchecked_conversion is being used for precisely 
the purpose it was designed for, albeit in a non-portable application 
when used to generate access values.

>(4) Overlays can be useful (but you have to be careful, if you're going
>to avoid maintenance headaches).
>
>(5) It's possible to encapsulate one's use of overlaid storage.
>
     I'd like to see examples of both of these claims.  In particular, 
I'd like to know what the "be careful" rules are that are going to avoid 
maintenance headaches.  Remember, my long experience is just the oppo-
site, that overlaying causes maintenance headaches.  I need to be con-
vinced that all of that experience is anomalous.

>>     The saddest aspect of this mistaken change (my opinion, obviously) 
>>is that it doesn't adequately support overlaying.  Even if a compiler 
>>implements the recommended level of support (RM 13.3(12-19)) it is only 
>>required to do the right thing for the one of the overlaid data whose 
>>address has been specified (RM 13.3(19)).
>
>If you make the other variable "aliased", then you'll be OK.
>
     You get reluctant o. k. from me on that one.  It seems to me to be 
very close to lying to the compiler and maintenance programmer again, 
although technically it isn't.  I think the implication is that aliased 
objects will be designated by access values, but nothing in the RM that 
I can find says that that is the purpose of aliasing.

     [An example illustrating the kind of knots that you can get tied 
into using address clauses to overlay has been deleted.  To me, this ex-
ample illustrates why such stuff should not be allowed.]

>>     It's interesting to note that GNAT handles the two package example 
>>"right".  My guess is that that's a result of GNAT's treating package 
>>specifications like include files.  On the other hand, GNAT (PC version 
>>3.07) allows one of the overlaid objects to be a constant and the other 
>>to be variable.  Furthermore, the generated code allows the value of the 
>>constant to be changed.  This is clearly a bug, either in GNAT or the 
>>language specification.  It is not prohibited in RM 13.3.  Is it prohib-
>>ited elsewhere?
>
>No, except that 13.3(13) allows the compiler to declare this case
>erroneous.

     I'm impressed.  Apparently 13.3(13) can be read to say: If an ad-
dress clause causes a bad effect, then the specified address was invalid 
and the program is erroneous.  I certainly don't get any comfort out of 
such a flexible reading.

				Charlie

Re: What Happened While I Wasn't Looking?

[Robert A Duff]

In article <1997Apr7.182117.22958@nosc.mil>,
Charles H. Sampson <sampson@nosc.mil> wrote:
>     My thanks to Bob for his response to my post.  I truly appreciate
>it.  Unfortunately, I don't agree with much of it, so I follow up.

Well, at least we both seem to agree that one shouldn't make overlaid
variables very much.  There's not much difference between "never" and
"hardly ever", in practise.

>     It depends on how you treat erroneousness.  I've been surprised at 
>some of the responses to this thread that seem very close to relishing 
>the erroneous constructs as potentially nice holes that can be exploited 
>when necessary.  When I taught Ada 83 I pointed out that they have no 
>language defined semantics, a compiler is not required to detect them 
>and often can't, and, even if you discover what the semantics are for 
>your particular combination of compiler and target computer, there's a 
>very good chance that it's not portable and they might even change in 
>the next version of the compiler.  Conclusion: Avoid them.  (By the way, 
>I know the drill.  I'm using "erroneous construct" as a convenient 
>shorthand for the much longer, technically correct, phrase.)

Agreed -- one should avoid things that are erroneous.  It helps if it's
quite clear what's erroneous, and you can't do it by accident.  That's
probably the case here -- if you write an Address clause, you know
you're doing something questionable, and you can be careful.  A much
worse case is like in Ada 83, where use of an uninitialized variable is
erroneous -- it's easy to do by accident, and it doesn't help to say,
"Well, don't do that."

>     That's at least an arguable point.  Carried to its extreme, which 
>I know is not being advocated here, you get to the point of saying, "Put 
>anything at all into the language, provided you've included good ver-
>sions of all the bad things."  Certainly the effort that culminated in 
>Ada 83 had a lot of "do not allow" guidelines.

True, but I think the language designer should concentrate on making
sure enough functionality is available in a safe way, so that the evil
features aren't needed very often.  IMHO, that's a more effective
strategy than going around forbidding evil deeds.  (Forbidding evil
deeds is really hard in chap 13, because it's at the "wrong" level of
abstraction -- it's hard to write precise rules that apply to all
possible machines, so it's better to let implementers decide, since they
have their hands on a particular machine.)

>     Yes, they can, and they can be non-portable as well.  Rephrasing the 
>point that I tried to make before: The advantage of Unchecked_conversion 
>is that it is "self-flagging".  Every place that it appears in the 
>source code is a potential trouble spot that has to be investigated when 
>porting.  In the case of overlaying, it's not the overlay itself that 
>must be investigated, but every reference to the two objects involved.  
>Probably most of those references will be benign.

If you unchecked-convert X'Address to an access type, then the same
problem occurs -- you have to track down all uses of that access value.

>     I don't follow this.  You seem to be saying that because an access 
>value can sometimes (often) be created using Unchecked_conversion, then
>it can create aliases.  I'll concede that, but it seems to me to be no-
>thing more than the general problem of aliasing through pointers.

It's worse, because normally, you know that (1) you can't have an access
value pointing at X unless X is aliased, and (2) if X is of type T, you
only have to worry about access-to-T types.  Unchecked_conv breaks these
nice properties.

>     This is off my main subject, but maybe somebody can explain 
>13.9(15) to me.  I find it unusual for a language definition to say, "A 
>compiler may generate code to implement the semantics of this feature."

I don't see how you read it that way -- it's not saying "may generate
code to implement".  It's saying *should* generate *efficient* code.
Yes, I think that should go without saying.  The reason 13.9(15) exists
is to make some reviewers happy.  Those reviewers had been burned by
inefficient implementations of unch conv in Ada 83, and wanted to use
RM95 as a hammer to beat on implementers.  I don't think that's what
standards are for, and I didn't really think 13.9(15) was needed.

>     No, certainly everybody isn't going to do that.  There's a large 
>body of software engineers out there who, like me, look upon Ada as a 
>gift from the gods.  On the other hand, there are a lot of Ada program-
>mers, the kind that used to be called hackers, who will try anything to 
>"get the job done".  They might even be anti-Ada.  (Let's avoid discus-
>sion of the mandate.  Such people could be part of the troops on a large 
>project whose leaders have chosen Ada for reasons that have nothing to 
>do with the mandate.)  If their mindset is such that they don't see any-
>thing wrong with overlays, they'll try to use them.

True, but those are the same folks who will happily use erroneous
things, and will who believe that language semantics is defined by
whatever their current compiler happens to do.  IMHO, you can't prevent
incompetent programmers from writing bad code without crippling the
language so far as to be useless.  So you shouldn't try.

>     Wait a minute!  The injunction in Ada 83 is against overlaying ob-
>jects and program units.  13.3(13) says that the programmer must ensure 
>that the address given in an address clause is valid.  Other than the 
>appearance of the word _erroneous_, I see no connection between them.  
>(The term _valid address_ appears to be undefined in the RM--at least 
>it's not in the index--so I have to guess that it means things like en-
>suring word or paragraph alignment when required by the datum.)

Right -- the term "valid address" is not defined by the RM.  It is
entirely up to the implementation which addresses are valid in which
circumstances.  Word alignment might be part of it, but it could easily
be much more.  There's some discussion of this in the AARM-13.3:

12.b    The validity of a given address depends on the run-time model; thus,
        in order to use Address clauses correctly, one needs intimate
        knowledge of the run-time model.

12.g    If X is not allocated on a storage element boundary, X'Address points
        at the first of the storage elements that contains any part of
        X. This is important for the definition of the Position attribute to
        be sensible.

[Note that the implementation gets to choose how to allocate...]

>     I'd like to see examples of both of these claims.  In particular, 
>I'd like to know what the "be careful" rules are that are going to avoid 
>maintenance headaches.  Remember, my long experience is just the oppo-
>site, that overlaying causes maintenance headaches.  I need to be con-
>vinced that all of that experience is anomalous.

No, your experience is quite correct.

As far as encapsulating: If you declare a pair of local objects in a
single procedure, 5 lines long, and use address clauses, then it's
pretty well encapsulated.  If you need the objects to live longer than
that, then put them in a package body.  I wouldn't normally expect such
variables to be globally visible!

>     You get reluctant o. k. from me on that one.  It seems to me to be 
>very close to lying to the compiler and maintenance programmer again, 
>although technically it isn't.  I think the implication is that aliased 
>objects will be designated by access values, but nothing in the RM that 
>I can find says that that is the purpose of aliasing.

13.3(16) makes that connection:

   16  X'Address should produce a useful result if X is an object that
       is aliased or of a by-reference type, or is an entity whose
       Address has been specified.

>     I'm impressed.  Apparently 13.3(13) can be read to say: If an ad-
>dress clause causes a bad effect, then the specified address was invalid 
>and the program is erroneous.  I certainly don't get any comfort out of 
>such a flexible reading.

Well, I think 13.3(13) is pretty broad.  It allows the implementation a
lot of freedom in declaring things erroneous.  On most machines,
addresses will behave as you might be used to.  But, for example on a
Symbolics Lisp machine, pretty much *any* use of addresses will be
incorrect.  Also, the compiler has some freedom in making the trade-off
between agressive optimizations, versus making low-level features work
"as expected".

- Bob

Re: Overflows (lisp fixnum-bignum conversion)

[Jon S Anthony]

In article <01bc43ae$811f1680$3ef882c1@xhv46.dial.pipex.com> "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:

> precise temperature - which promise to be able to store the equivalent of
> 2^64 bytes of information easily (probably a lot more). Such computers
> would certainly have the potential for outsmarting humans by several orders
> of magnitude. This is actually true. Sleep well!

Despite folks like Dennett, I would be willing to bet basically
anything that the probability of this is zero.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: Overflows (lisp fixnum-bignum conversion)

[Marin David Condic, 561.796.8997, M/S 731-93]

Robert Dewar <dewar@MERV.CS.NYU.EDU> writes:
><<Already IBM scientists (at Boca Raton, is it?) are building prototype '3D'
>computers - which use laser holography within a block of a very special
>material which switches its angle of polarisation very fast at a certain
>precise temperature - which promise to be able to store the equivalent of
>2^64 bytes of information easily (probably a lot more). Such computers
>would certainly have the potential for outsmarting humans by several orders
>of magnitude. This is actually true. Sleep well!!!>
>
>Nick if you really think that simply providing computers with 2**64 bytes
>of information will magically ensure that they can outsmart humans, you
>have been watching too much Startrek. Yes, I know you said potential, but
>still ....
>
    Seems I've heard this sort of claim by the AI croud before - just
    about every time there's a major advancement in the capacity of
    computer memory or processor throughput. And the claim has (so
    far) never materialized. The problem is not memory or throughput,
    but one of algorithm. Nobody has yet demonstrated a "thinking"
    algorithm that just needs more horsepower to make it work. (Of
    course, if we redefine "thinking" to stretch it far enough, we
    could probably demonstrate a box of rocks undertaking the task!)

    "You can lead a computer to data, but you can't make it think."

        --  M. D. Condic

    MDC

Marin David Condic, Senior Computer Engineer    ATT:        561.796.8997
M/S 731-96                                      Technet:    796.8997
Pratt & Whitney, GESP                           Fax:        561.796.4669
P.O. Box 109600                                 Internet:   CONDICMA@PWFL.COM
West Palm Beach, FL 33410-9600                  Internet:   CONDIC@FLINET.COM
===============================================================================
    "That which belongs to another."

        --  Diogenes, when asked what wine he liked to drink.
===============================================================================