* Re: Overflows (lisp fixnum-bignum conversion)
@ 1997-04-08 0:00 Marin David Condic, 561.796.8997, M/S 731-93
0 siblings, 0 replies; 16+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-93 @ 1997-04-08 0:00 UTC (permalink / raw)
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.
===============================================================================
^ permalink raw reply [flat|nested] 16+ messages in thread
* What Happened While I Wasn't Looking? @ 1997-04-02 0:00 Charles H. Sampson 1997-04-03 0:00 ` Robert A Duff 1997-04-08 0:00 ` Jon S Anthony 0 siblings, 2 replies; 16+ messages in thread From: Charles H. Sampson @ 1997-04-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: What Happened While I Wasn't Looking? 1997-04-02 0:00 What Happened While I Wasn't Looking? Charles H. Sampson @ 1997-04-03 0:00 ` Robert A Duff 1997-04-05 0:00 ` Overflows (lisp fixnum-bignum conversion) Clayton Weaver 1997-04-08 0:00 ` Jon S Anthony 1 sibling, 1 reply; 16+ messages in thread From: Robert A Duff @ 1997-04-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-03 0:00 ` Robert A Duff @ 1997-04-05 0:00 ` Clayton Weaver 1997-04-05 0:00 ` Robert Dewar 1997-04-06 0:00 ` Robert A Duff 0 siblings, 2 replies; 16+ messages in thread From: Clayton Weaver @ 1997-04-05 0:00 UTC (permalink / raw) (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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-05 0:00 ` Overflows (lisp fixnum-bignum conversion) Clayton Weaver @ 1997-04-05 0:00 ` Robert Dewar 1997-04-08 0:00 ` Robert A Duff 1997-04-06 0:00 ` Robert A Duff 1 sibling, 1 reply; 16+ messages in thread From: Robert Dewar @ 1997-04-05 0:00 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-05 0:00 ` Robert Dewar @ 1997-04-08 0:00 ` Robert A Duff 1997-04-09 0:00 ` Charles H. Sampson 0 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 1997-04-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-08 0:00 ` Robert A Duff @ 1997-04-09 0:00 ` Charles H. Sampson 0 siblings, 0 replies; 16+ messages in thread From: Charles H. Sampson @ 1997-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-05 0:00 ` Overflows (lisp fixnum-bignum conversion) Clayton Weaver 1997-04-05 0:00 ` Robert Dewar @ 1997-04-06 0:00 ` Robert A Duff 1997-04-06 0:00 ` Nick Roberts 1 sibling, 1 reply; 16+ messages in thread From: Robert A Duff @ 1997-04-06 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-06 0:00 ` Robert A Duff @ 1997-04-06 0:00 ` Nick Roberts 1997-04-07 0:00 ` Robert A Duff 0 siblings, 1 reply; 16+ messages in thread From: Nick Roberts @ 1997-04-06 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-06 0:00 ` Nick Roberts @ 1997-04-07 0:00 ` Robert A Duff 1997-04-07 0:00 ` Robert Dewar 0 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 1997-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Robert A Duff @ 1997-04-07 0:00 ` Robert Dewar 1997-04-07 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 16+ messages in thread From: Robert Dewar @ 1997-04-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Robert Dewar @ 1997-04-07 0:00 ` Larry Kilgallen 1997-04-07 0:00 ` Robert Dewar ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Larry Kilgallen @ 1997-04-07 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Larry Kilgallen @ 1997-04-07 0:00 ` Robert Dewar 1997-04-09 0:00 ` Robert A Duff 1997-04-07 0:00 ` Nick Roberts 1997-04-09 0:00 ` Joel VanLaven 2 siblings, 1 reply; 16+ messages in thread From: Robert Dewar @ 1997-04-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Robert Dewar @ 1997-04-09 0:00 ` Robert A Duff 0 siblings, 0 replies; 16+ messages in thread From: Robert A Duff @ 1997-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Larry Kilgallen 1997-04-07 0:00 ` Robert Dewar @ 1997-04-07 0:00 ` Nick Roberts 1997-04-07 0:00 ` Robert Dewar 1997-04-09 0:00 ` Joel VanLaven 2 siblings, 1 reply; 16+ messages in thread From: Nick Roberts @ 1997-04-07 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Nick Roberts @ 1997-04-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 16+ messages in thread From: Robert Dewar @ 1997-04-07 0:00 UTC (permalink / raw) 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 .... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-07 0:00 ` Larry Kilgallen 1997-04-07 0:00 ` Robert Dewar 1997-04-07 0:00 ` Nick Roberts @ 1997-04-09 0:00 ` Joel VanLaven 2 siblings, 0 replies; 16+ messages in thread From: Joel VanLaven @ 1997-04-09 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Overflows (lisp fixnum-bignum conversion) 1997-04-02 0:00 What Happened While I Wasn't Looking? Charles H. Sampson 1997-04-03 0:00 ` Robert A Duff @ 1997-04-08 0:00 ` Jon S Anthony 1 sibling, 0 replies; 16+ messages in thread From: Jon S Anthony @ 1997-04-08 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~1997-04-09 0:00 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1997-04-08 0:00 Overflows (lisp fixnum-bignum conversion) Marin David Condic, 561.796.8997, M/S 731-93 -- strict thread matches above, loose matches on Subject: below -- 1997-04-02 0:00 What Happened While I Wasn't Looking? Charles H. Sampson 1997-04-03 0:00 ` Robert A Duff 1997-04-05 0:00 ` Overflows (lisp fixnum-bignum conversion) Clayton Weaver 1997-04-05 0:00 ` Robert Dewar 1997-04-08 0:00 ` Robert A Duff 1997-04-09 0:00 ` Charles H. Sampson 1997-04-06 0:00 ` Robert A Duff 1997-04-06 0:00 ` Nick Roberts 1997-04-07 0:00 ` Robert A Duff 1997-04-07 0:00 ` Robert Dewar 1997-04-07 0:00 ` Larry Kilgallen 1997-04-07 0:00 ` Robert Dewar 1997-04-09 0:00 ` Robert A Duff 1997-04-07 0:00 ` Nick Roberts 1997-04-07 0:00 ` Robert Dewar 1997-04-09 0:00 ` Joel VanLaven 1997-04-08 0:00 ` Jon S Anthony
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox