* Y21C Bug @ 2000-01-02 0:00 reason67 2000-01-02 0:00 ` Robert Dewar 0 siblings, 1 reply; 50+ messages in thread From: reason67 @ 2000-01-02 0:00 UTC (permalink / raw) With all the overblown hyper about Y2K, no one has stopped to talk about the real problem... Ada 83 and Ada 95 both have a Y21C problem! What Happens Jan 1, 2100? Ada.Calendar will not work! Since Ada will be taking over as the premier programming language in the next 10 years, our grandchildren are in for a terrible time! (I have been joking about that for 3-4 years now, thought I would pass it along) --- Jeffrey Blatt Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-02 0:00 Y21C Bug reason67 @ 2000-01-02 0:00 ` Robert Dewar 2000-01-03 0:00 ` Tarjei T. Jensen 0 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 2000-01-02 0:00 UTC (permalink / raw) In article <84nqbo$q28$1@nnrp1.deja.com>, reason67@my-deja.com wrote: > With all the overblown hyper about Y2K, no one has stopped to > talk about > the real problem... Ada 83 and Ada 95 both have a Y21C > problem! Let's take this seriously for a moment ... In fact the problem for well written Ada programs is minimal, since the dependence is entirely hidden in the calendar package. Modifying the calendar package to have a larger year range is a trivial upwards compatible change in the spec. So as long as programs are well written wrt package Calendar, there will be no problems although recompilation sometime during the next Century may be required. One of the advantages of data hiding is precisely that your code is protected from this kind of implementation change. Note by contrast that when the Unix date runs out of 32 bits, this will cause QUITE a bit of disruption to existing programs and be quite a bit more difficult to fix. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-02 0:00 ` Robert Dewar @ 2000-01-03 0:00 ` Tarjei T. Jensen 2000-01-03 0:00 ` Jeff Creem 2000-01-03 0:00 ` Robert A Duff 0 siblings, 2 replies; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-03 0:00 UTC (permalink / raw) Robert Dewar wrote > >Note by contrast that when the Unix date runs out of 32 bits, >this will cause QUITE a bit of disruption to existing programs >and be quite a bit more difficult to fix. > Only if there are any 32 bit unixes around at that time - 2038. Many of us reading this will not be around then :-(. As far as I know all 64 bit unixes uses a time_t size of 64 bit. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-03 0:00 ` Tarjei T. Jensen @ 2000-01-03 0:00 ` Jeff Creem 2000-01-03 0:00 ` Tarjei T. Jensen 2000-01-03 0:00 ` Robert A Duff 1 sibling, 1 reply; 50+ messages in thread From: Jeff Creem @ 2000-01-03 0:00 UTC (permalink / raw) Tarjei T. Jensen <tarjei.jensen@kvaerner.com> wrote in message news:84pvrs$7q1@ftp.kvaerner.com... > > Robert Dewar wrote > > > >Note by contrast that when the Unix date runs out of 32 bits, > >this will cause QUITE a bit of disruption to existing programs > >and be quite a bit more difficult to fix. > > > > > Only if there are any 32 bit unixes around at that time - 2038. Many of us > reading this will not be around then :-(. As far as I know all 64 bit unixes > uses a time_t size of 64 bit. > > Greetings, Yes what are the chances that any 32 machine will be around then. That is as ridiculous as some old Cobol code written in the 70's being around in the year 2000......Oh wait...Dooh! Jeff ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-03 0:00 ` Jeff Creem @ 2000-01-03 0:00 ` Tarjei T. Jensen 0 siblings, 0 replies; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-03 0:00 UTC (permalink / raw) Jeff Creem wrote : >Yes what are the chances that any 32 machine will be around then. That is as >ridiculous as some old Cobol code written in the 70's being around in >the year 2000......Oh wait...Dooh! A 32 bit system can very well run a 64 bit unix. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-03 0:00 ` Tarjei T. Jensen 2000-01-03 0:00 ` Jeff Creem @ 2000-01-03 0:00 ` Robert A Duff 2000-01-04 0:00 ` Tarjei T. Jensen 2000-01-04 0:00 ` Robert Dewar 1 sibling, 2 replies; 50+ messages in thread From: Robert A Duff @ 2000-01-03 0:00 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > Robert Dewar wrote > > > >Note by contrast that when the Unix date runs out of 32 bits, > >this will cause QUITE a bit of disruption to existing programs > >and be quite a bit more difficult to fix. > > > > > Only if there are any 32 bit unixes around at that time - 2038. Many of us > reading this will not be around then :-(. As far as I know all 64 bit unixes > uses a time_t size of 64 bit. And from what I've heard, making Unix code "64-bit clean" hasn't been so easy, which is exactly the sort of thing Robert Dewar was talking about. If it were as easy as changing some "Word_Size" constant, then people wouldn't have invented a fancy term like "64-bit clean" for it. ;-) - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-03 0:00 ` Robert A Duff @ 2000-01-04 0:00 ` Tarjei T. Jensen 2000-01-04 0:00 ` Samuel Tardieu ` (2 more replies) 2000-01-04 0:00 ` Robert Dewar 1 sibling, 3 replies; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-04 0:00 UTC (permalink / raw) Robert A Duff wrote : >And from what I've heard, making Unix code "64-bit clean" hasn't been so >easy, which is exactly the sort of thing Robert Dewar was talking about. > >If it were as easy as changing some "Word_Size" constant, then people >wouldn't have invented a fancy term like "64-bit clean" for it. ;-) That does not change the fact that it is very unlikely that there will be any machines with a 32bit Unix outside museums in 2038 and that they will not run out of time any time soon. Transitioning from a 32 bit to a 64 bit Unix world is probably painful for a lot of software vendors. But this is a process that is going on today. All the big vendors either have transitioned to a 64 bit Unix or are planning to do so. I don't remember whether Linux is 32 or 64 bit or something inbetween. Regardless, by 2038 the migration will be over a long time ago. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Tarjei T. Jensen @ 2000-01-04 0:00 ` Samuel Tardieu 2000-01-04 0:00 ` Robert A Duff 2000-01-04 0:00 ` Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Samuel Tardieu @ 2000-01-04 0:00 UTC (permalink / raw) >>>>> "Tarjei" == Tarjei T Jensen <tarjei.jensen@kvaerner.com> writes: Tarjei> I don't remember whether Linux is 32 or 64 bit or something Tarjei> inbetween. It depends on the underlying hardware. 32 bits on PCs, on low-end Sparcs, and 64 bits on Ultrasparcs. Sam -- Samuel Tardieu -- sam@ada.eu.org ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Tarjei T. Jensen 2000-01-04 0:00 ` Samuel Tardieu @ 2000-01-04 0:00 ` Robert A Duff 2000-01-04 0:00 ` Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Robert A Duff @ 2000-01-04 0:00 UTC (permalink / raw) "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > That does not change the fact that it is very unlikely that there will be any > machines with a 32bit Unix outside museums in 2038 and that they will not run > out of time any time soon. That may well be turn out to be true, but those systems will still be running programs that have times hard-wired to 32-bit integers (some signed, some unsigned!), I'll bet. - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Tarjei T. Jensen 2000-01-04 0:00 ` Samuel Tardieu 2000-01-04 0:00 ` Robert A Duff @ 2000-01-04 0:00 ` Robert Dewar 2000-01-05 0:00 ` Tarjei T. Jensen 2 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 2000-01-04 0:00 UTC (permalink / raw) In article <84sltt$7s3@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > That does not change the fact that it is very unlikely that > there will be any machines with a 32bit Unix outside museums > in 2038 and that they will not run out of time any time soon. But all 64-bit unixes support 32-bit applications! I am including here Solaris, DEC-Unix, IRIX. > Transitioning from a 32 bit to a 64 bit Unix world is probably > painful for a lot of software vendors. But this is a process > that is going on today. Yes, but the "process" very often involves deciding to run applications in 32-bit mode. Indeed in many cases this makes more sense, since many applications have absolutely nothing to gain from 64-bit mode, and quite a bit to lose (increased memory usage, which given cache behavior translates to increased run-time). > All the > big vendors either have transitioned to a 64 bit Unix or are > planning to do so. I don't remember whether Linux is 32 or 64 > bit Then you are definitely not quite up on things, given that Linux most often is running on x86 machines which are 32-bits by nature. Will the ia-32 have disappeared 30 years from now? I would not be so sure of the answer to this :-) > Regardless, by 2038 the migration will be over a long time > ago. Well I hope that others are not taking this head-in-the-sand viewpoint, or we may have another Y2K fiasco :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Robert Dewar @ 2000-01-05 0:00 ` Tarjei T. Jensen 2000-01-05 0:00 ` Al Christians 2000-01-05 0:00 ` Robert Dewar 0 siblings, 2 replies; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-05 0:00 UTC (permalink / raw) Robert Dewar wrote in message <84t966$be0$1@nnrp1.deja.com>... >In article <84sltt$7s3@ftp.kvaerner.com>, > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: >> That does not change the fact that it is very unlikely that >> there will be any machines with a 32bit Unix outside museums >> in 2038 and that they will not run out of time any time soon. > >But all 64-bit unixes support 32-bit applications! I am >including here Solaris, DEC-Unix, IRIX. All vendors support old 32bit applications, but I expect with increasing difficulty. New 32bit applications is just a matter of deciding whether integers and pointers are 32 or 64 bits. time_t will still be 64 bit. I expect support for creating old type 32bit applications to be phased out within the next five years. I expect support for old type 32bit applications to be phased out within 10 years from now. I expect Unixes - even those which run on 32 bit systems - to be 64 bit (compliant) by the end of the decade. The reason for the disappearance will simply be that it costs money to maintain these environments. And it will be a long time since anybody created 32 bit applications which are not 64 bit compliant. I expect the y2k transition to have weeded quite heavily in the applications used. >Then you are definitely not quite up on things, given that >Linux most often is running on x86 machines which are 32-bits >by nature. It could still be a 64 bit operating system running on a 32 bit CPU. >Will the ia-32 have disappeared 30 years from now? I would not >be so sure of the answer to this :-) If it is around and Unix or Linux is still with us, it will most likely be a 64 bit operating system which is run on a 32 bit computer. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Tarjei T. Jensen @ 2000-01-05 0:00 ` Al Christians 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-06 0:00 ` Robert Dewar 2000-01-05 0:00 ` Robert Dewar 1 sibling, 2 replies; 50+ messages in thread From: Al Christians @ 2000-01-05 0:00 UTC (permalink / raw) "Tarjei T. Jensen" wrote: > > I expect support for creating old type 32bit applications to be > phased out within the next five years. I expect support for old > type 32bit applications to be phased out within 10 years from > now. Although 64-bits gets more PR, Intel is also developing a 32-bit successor to the Pentium. Al ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Al Christians @ 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-06 0:00 ` Robert Dewar 2000-01-06 0:00 ` Robert Dewar 1 sibling, 1 reply; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-06 0:00 UTC (permalink / raw) Al Christians wrote in message <38737352.B282CC2@easystreet.com>... >"Tarjei T. Jensen" wrote: >> >> I expect support for creating old type 32bit applications to be >> phased out within the next five years. I expect support for old >> type 32bit applications to be phased out within 10 years from >> now. > > >Although 64-bits gets more PR, Intel is also developing a 32-bit >successor to the Pentium. Anything else would be madness. 32-bit CPUs will have more than enough computing power for many if not most applications in the foreseeable future. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Tarjei T. Jensen @ 2000-01-06 0:00 ` Robert Dewar 2000-01-06 0:00 ` Robert A Duff 2000-01-07 0:00 ` Tarjei T. Jensen 0 siblings, 2 replies; 50+ messages in thread From: Robert Dewar @ 2000-01-06 0:00 UTC (permalink / raw) In article <851j2q$78q1@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > Anything else would be madness. 32-bit CPUs will have more > than enough computing power for many if not most applications > in the foreseeable future. Well I guess you think all the world is mad then because everyone (including Intel and AMD) see the future in 64-bit computing. Computing "power" is not the issue here. The point is that a lot of modern applications can benefit from an expanded address space. We are not talking about future versions of Microsoft WORD requiring more than 4 gigabytes of code, rather 64-bit addressing provides two very valuable features. 1. The ability to declare very large areas of memory with commit-on-use semantics. There are many uses of this. I have the feeling that a lot of programmers still don't understand commit-on-use. FOr example, it is fine in many environments to declare huge numbers of tasks with enormous stacks, and if you are in 64-bit mode there are simply no limitations on this approach. Of course if you USE all this stack space you will thrash etc. 2. The ability to map file systems into virtual memory. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Robert Dewar @ 2000-01-06 0:00 ` Robert A Duff 2000-01-06 0:00 ` Larry Kilgallen ` (2 more replies) 2000-01-07 0:00 ` Tarjei T. Jensen 1 sibling, 3 replies; 50+ messages in thread From: Robert A Duff @ 2000-01-06 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: > 1. The ability to declare very large areas of memory with > commit-on-use semantics. There are many uses of this. I have > the feeling that a lot of programmers still don't understand > commit-on-use. Commit on use is indeed very cool. Do you know which operating systems support it? > 2. The ability to map file systems into virtual memory. When I first used a virtual memory system (32-bit address space), I thought mapping files memory into was obviously the "right" way to do all disk I/O. At the time, the notion that a file might be too big to fit seemed ludicrous. Nowadays some people really do want to create files bigger than 4G. But it really *can* work in a 64-bit address space. On the other hand, if I'm writing a program that creates a lot of records in the heap pointing at one another, then a large portion of the data is actually addresses, and I'm not sure I want to double the size of *all* my addresses (thus almost doubling the size of all my data). The folks who say "memory is cheap" are wrong: using more memory usually costs more time (eg increases cache misses), and *time* is not cheap. - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Robert A Duff @ 2000-01-06 0:00 ` Larry Kilgallen 2000-01-07 0:00 ` Florian Weimer 2000-01-11 0:00 ` Mats Weber 2 siblings, 0 replies; 50+ messages in thread From: Larry Kilgallen @ 2000-01-06 0:00 UTC (permalink / raw) In article <wcc66x7w220.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes: > Robert Dewar <robert_dewar@my-deja.com> writes: > >> 1. The ability to declare very large areas of memory with >> commit-on-use semantics. There are many uses of this. I have >> the feeling that a lot of programmers still don't understand >> commit-on-use. > > Commit on use is indeed very cool. > > Do you know which operating systems support it? If by "use" you mean "write", a VMS demand-zero page would seem close to what you are looking for. Having been near a Unix programmer trying to deal with memory mapping, I gather Unix systems can do the same sorts of things, but using different calls for each brand of Unix. Larry Kilgallen ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Robert A Duff 2000-01-06 0:00 ` Larry Kilgallen @ 2000-01-07 0:00 ` Florian Weimer 2000-01-07 0:00 ` Robert A Duff 2000-01-11 0:00 ` Mats Weber 2 siblings, 1 reply; 50+ messages in thread From: Florian Weimer @ 2000-01-07 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > Robert Dewar <robert_dewar@my-deja.com> writes: > > > 1. The ability to declare very large areas of memory with > > commit-on-use semantics. There are many uses of this. I have > > the feeling that a lot of programmers still don't understand > > commit-on-use. > > Commit on use is indeed very cool. > > Do you know which operating systems support it? I think commit on use is the same thing what's called copy on write on Linux. For example, you can run the following program on a box which only has some 300 MB of virtual memory (RAM + swap), and it will `allocate' approximately 1.5 GB of `memory': with Ada.Text_IO, Ada.Integer_Text_IO; use Ada.Text_IO, Ada.Integer_Text_IO; procedure Alloc_Mem is type Long_String is new String (1 .. 1024 * 1024); type Long_String_Access is access Long_String; LSA : array (1 .. 1500) of Long_String_Access; Byte_Count : Natural := 0; begin for I in LSA'Range loop LSA (I) := new Long_String; Byte_Count := Byte_Count + Long_String'Size / 8; end loop; Put ("Successfully allocated "); Put (Byte_Count, 0); Put_Line (" bytes."); exception when Storage_Error => Put ("Allocation failure after "); Put (Byte_Count, 0); Put_Line (" bytes."); end Alloc_Mem; Of course, you shouldn't use an initialized allocator here. ;) ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-07 0:00 ` Florian Weimer @ 2000-01-07 0:00 ` Robert A Duff 2000-01-07 0:00 ` Robert Dewar 2000-01-11 0:00 ` Mats Weber 0 siblings, 2 replies; 50+ messages in thread From: Robert A Duff @ 2000-01-07 0:00 UTC (permalink / raw) Florian Weimer <usenet@deneb.cygnus.argh.org> writes: > I think commit on use is the same thing what's called copy on write > on Linux. Really? I thought "copy on write" (or "virtual copy") meant what, for example, most modern Unix systems do for fork() -- the fork() system call is defined to copy the entire address space of the process, producing two identical processes. Using memory-mapping hardware, you can map all the pages to the same physical locations, and mark them read-only. If either process actually wants to write, it traps into the OS, which actually makes the copy. I thought "commit on use" (or "zero on use") meant that (as in your example below), virtual memory is allocated, but physical memory is not. Then, a read or write of that memory will trap, and the operating system will gin up an all-zeros page of memory. Still nobody has answered my question about which operating systems support these fancy things. > For example, you can run the following program on a box > which only has some 300 MB of virtual memory (RAM + swap), and it will > `allocate' approximately 1.5 GB of `memory': [program that allocates large numbers of huge strings] > Of course, you shouldn't use an initialized allocator here. ;) Indeed. I once wrote a program that was doing something like that for arrays-of-pointers-to-records. I might allocate millions of pointers, and only use 3 or 4 of them in a typical case, but once in a while need a whole lot. Unfortunately, Ada wants to initialize pointers to null, which caused my program to run extremely slowly -- it spent most of its time initializing data that I was never going to use in the typical case (and probably paging it out disk for me, too -- I don't remember). I solved the problem with an ugly hack: allocate an array of integers, and unchecked-convert to an array of pointers. Or maybe I unchecked-converted a pointer to the arrays -- I don't remember. I think the DEC Ada compiler would have handled it better -- I think it was clever enough to know that the VMS operating system was going to zero those pages if they were ever referenced, and null is represented as zero, so the compiler didn't actually zero them. On the other hand, I once wrote something like: X: array(1..One_Zillion) of Integer := (others => 0); and the DEC Ada compiler blew up at compile time, apparently trying to be clever at run time. Anyway, none of these fancy memory-mapping tricks are much good if they're not portable. - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-07 0:00 ` Robert A Duff @ 2000-01-07 0:00 ` Robert Dewar 2000-02-04 0:00 ` Florian Weimer 2000-01-11 0:00 ` Mats Weber 1 sibling, 1 reply; 50+ messages in thread From: Robert Dewar @ 2000-01-07 0:00 UTC (permalink / raw) In article <wcciu157w2h.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > Florian Weimer <usenet@deneb.cygnus.argh.org> writes: > I thought "commit on use" (or "zero on use") meant that (as in your > example below), virtual memory is allocated, but physical memory is not. > Then, a read or write of that memory will trap, and the operating system > will gin up an all-zeros page of memory. > > Still nobody has answered my question about which operating systems > support these fancy things. NT, OS/2, Solaris, IRIX for sure. I sort of assume that the other major unices are the same ... Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-07 0:00 ` Robert Dewar @ 2000-02-04 0:00 ` Florian Weimer 2000-02-04 0:00 ` Robert A Duff 0 siblings, 1 reply; 50+ messages in thread From: Florian Weimer @ 2000-02-04 0:00 UTC (permalink / raw) Robert Dewar <robert_dewar@my-deja.com> writes: [commit on use] > > Still nobody has answered my question about which operating > systems > > support these fancy things. > > NT, OS/2, Solaris, IRIX for sure. I sort of assume that the > other major unices are the same ... Are you sure about Solaris? All memory you get seems to be backed by physical RAM or swap space. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-02-04 0:00 ` Florian Weimer @ 2000-02-04 0:00 ` Robert A Duff 2000-02-04 0:00 ` Florian Weimer 0 siblings, 1 reply; 50+ messages in thread From: Robert A Duff @ 2000-02-04 0:00 UTC (permalink / raw) Florian Weimer <someone@deneb.cygnus.argh.org> writes: > Are you sure about Solaris? All memory you get seems to be backed by > physical RAM or swap space. But swap space is cheap. - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-02-04 0:00 ` Robert A Duff @ 2000-02-04 0:00 ` Florian Weimer 0 siblings, 0 replies; 50+ messages in thread From: Florian Weimer @ 2000-02-04 0:00 UTC (permalink / raw) Robert A Duff <bobduff@world.std.com> writes: > Florian Weimer <someone@deneb.cygnus.argh.org> writes: > > > Are you sure about Solaris? All memory you get seems to be backed by > > physical RAM or swap space. > > But swap space is cheap. That wasn't the point, I think. I was a bit slow with my response. ;) We discussed using POSIX_Memory_Mapping.Map_Memory to create a huge private mapping -- a few hundred megabytes in size, with copy-on-write semantics, likely to exceed the the physical address space (both RAM and swap) included. Linux is the only system which permits this, because it is considered unsafe by quite a few people. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-07 0:00 ` Robert A Duff 2000-01-07 0:00 ` Robert Dewar @ 2000-01-11 0:00 ` Mats Weber 2000-01-11 0:00 ` Robert A Duff 1 sibling, 1 reply; 50+ messages in thread From: Mats Weber @ 2000-01-11 0:00 UTC (permalink / raw) Robert A Duff wrote: > I thought "commit on use" (or "zero on use") meant that (as in your > example below), virtual memory is allocated, but physical memory is not. > Then, a read or write of that memory will trap, and the operating system > will gin up an all-zeros page of memory. That is what is happening on most modern systems. For instance when you start an executable, it is mapped to virtual memory but not read into memory. Then execution is transferred to a virtual memory address within the mapped executable, causing a page fault which loads a few pages from the executable, and so on. So, if you don't use some pages of code, they will never get loaded. > Still nobody has answered my question about which operating systems > support these fancy things. It works that way on VMS (that I know for sure) and most Unices and NT. Even the current MacOS uses that scheme for loading executables. > On the other hand, I once wrote something like: > > X: array(1..One_Zillion) of Integer := (others => 0); > > and the DEC Ada compiler blew up at compile time, apparently trying to > be clever at run time. DEC Ada creates the allocator in the object file if everything is static. That's why you can't compile this. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-11 0:00 ` Mats Weber @ 2000-01-11 0:00 ` Robert A Duff 2000-01-12 0:00 ` Mats Weber 0 siblings, 1 reply; 50+ messages in thread From: Robert A Duff @ 2000-01-11 0:00 UTC (permalink / raw) Mats Weber <matsw@mail.com> writes: > Robert A Duff wrote: > > On the other hand, I once wrote something like: > > > > X: array(1..One_Zillion) of Integer := (others => 0); > > > > and the DEC Ada compiler blew up at compile time, apparently trying to > > be clever at run time. > > DEC Ada creates the allocator in the object file if everything is ^^^^^^^^^ > static. That's why you can't compile this. There's no allocator there -- it's just a package-level variable. I think on DEC Ada on VAX/VMS, the executable file would *not* contain all those zeros -- just an indication that the OS should create them as zero if and when necessary. (Assuming One_Zillion is made small enough that the compiler doesn't blow up.) - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-11 0:00 ` Robert A Duff @ 2000-01-12 0:00 ` Mats Weber 2000-01-12 0:00 ` Thierry Lelegard [not found] ` <387dfb1e.cbbf14c7@mail.com> 0 siblings, 2 replies; 50+ messages in thread From: Mats Weber @ 2000-01-12 0:00 UTC (permalink / raw) Robert A Duff wrote: > > DEC Ada creates the allocator in the object file if everything is > ^^^^^^^^^ > > static. That's why you can't compile this. > > There's no allocator there -- it's just a package-level variable. Sorry, I meant aggregate, not allocator. > I think on DEC Ada on VAX/VMS, the executable file would *not* contain > all those zeros -- just an indication that the OS should create them as > zero if and when necessary. (Assuming One_Zillion is made small enough > that the compiler doesn't blow up.) I think it does, even it they are all zeros. I ran in that problem a few times. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-12 0:00 ` Mats Weber @ 2000-01-12 0:00 ` Thierry Lelegard 2000-01-13 0:00 ` Robert A Duff 2000-01-13 0:00 ` Mats Weber [not found] ` <387dfb1e.cbbf14c7@mail.com> 1 sibling, 2 replies; 50+ messages in thread From: Thierry Lelegard @ 2000-01-12 0:00 UTC (permalink / raw) > > I think on DEC Ada on VAX/VMS, the executable file would *not* contain > > all those zeros -- just an indication that the OS should create them as > > zero if and when necessary. (Assuming One_Zillion is made small enough > > that the compiler doesn't blow up.) > > I think it does, even it they are all zeros. I ran in that problem a few times. Yes it does. If you had left the variable uninitialized (on an Ada perspective), then the variable would have been allocated in a "demand zero" section (no allocation in executable). Since you provided an explicit initial value, the compiler/linker placed it into a "copy on reference" section which contains the initial values. Of course, the compiler could make a special optimization which consists in inspecting every single byte of this initial value and if they are all zeroes then place the variable into a "demand zero" section. But, it appears that this optimization is not made. By the way, for some obscure reasons I used to know (but that I forgot), the VMS linker never creates "demand zero" sections in shareable images ("DLL" for users of dummy OS). They are turned into "copy on reference" sections filled with zeroes. "Demand zero" sections apply to executable images only. -Thierry ________________________________________________________ Thierry Lelegard, Paris, France E-mail: lelegard@club-internet.fr ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-12 0:00 ` Thierry Lelegard @ 2000-01-13 0:00 ` Robert A Duff 2000-01-13 0:00 ` Larry Kilgallen 2000-01-13 0:00 ` Thierry Lelegard 2000-01-13 0:00 ` Mats Weber 1 sibling, 2 replies; 50+ messages in thread From: Robert A Duff @ 2000-01-13 0:00 UTC (permalink / raw) "Thierry Lelegard" <lelegard@club-internet.fr> writes: > By the way, for some obscure reasons I used to know (but that I > forgot), the VMS linker never creates "demand zero" sections in > shareable images ("DLL" for users of dummy OS). They are turned > into "copy on reference" sections filled with zeroes. "Demand zero" > sections apply to executable images only. Probably because shareable imaged need to be read-only? - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-13 0:00 ` Robert A Duff @ 2000-01-13 0:00 ` Larry Kilgallen 2000-01-13 0:00 ` Thierry Lelegard 1 sibling, 0 replies; 50+ messages in thread From: Larry Kilgallen @ 2000-01-13 0:00 UTC (permalink / raw) In article <wccn1qaay08.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> writes: > "Thierry Lelegard" <lelegard@club-internet.fr> writes: > >> By the way, for some obscure reasons I used to know (but that I >> forgot), the VMS linker never creates "demand zero" sections in >> shareable images ("DLL" for users of dummy OS). They are turned >> into "copy on reference" sections filled with zeroes. "Demand zero" >> sections apply to executable images only. > > Probably because shareable imaged need to be read-only? Not for PSECTs with the SHR attribute. Larry Kilgallen ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-13 0:00 ` Robert A Duff 2000-01-13 0:00 ` Larry Kilgallen @ 2000-01-13 0:00 ` Thierry Lelegard 1 sibling, 0 replies; 50+ messages in thread From: Thierry Lelegard @ 2000-01-13 0:00 UTC (permalink / raw) > > By the way, for some obscure reasons I used to know (but that I > > forgot), the VMS linker never creates "demand zero" sections in > > shareable images ("DLL" for users of dummy OS). They are turned > > into "copy on reference" sections filled with zeroes. "Demand zero" > > sections apply to executable images only. > > Probably because shareable imaged need to be read-only? NO, a shareable image does NOT need to be read-only. First, you can use "install add/write". Second, being read-only or read/write and being dzro or cref are two independant properties which can be combined as you like -Thierry ________________________________________________________ Thierry Lelegard, Paris, France E-mail: lelegard@club-internet.fr ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-12 0:00 ` Thierry Lelegard 2000-01-13 0:00 ` Robert A Duff @ 2000-01-13 0:00 ` Mats Weber 1 sibling, 0 replies; 50+ messages in thread From: Mats Weber @ 2000-01-13 0:00 UTC (permalink / raw) Thierry Lelegard wrote: > Yes it does. If you had left the variable uninitialized (on an Ada > perspective), then the variable would have been allocated in > a "demand zero" section (no allocation in executable). Since > you provided an explicit initial value, the compiler/linker placed > it into a "copy on reference" section which contains the initial > values. Of course, the compiler could make a special optimization > which consists in inspecting every single byte of this initial > value and if they are all zeroes then place the variable into > a "demand zero" section. But, it appears that this optimization > is not made. You generally cannot guarantee that the variable is allocated in a demand-zero region. For instance, when allocated on the stack, the stack may have previously grown higher than where you allocate and you get the content left there from a previous call (unless the stack is zeroed or unmapped from the address space when it shrinks, but I doubt any system is doing that). ^ permalink raw reply [flat|nested] 50+ messages in thread
[parent not found: <387dfb1e.cbbf14c7@mail.com>]
* Re: Y21C Bug [not found] ` <387dfb1e.cbbf14c7@mail.com> @ 2000-01-13 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 50+ messages in thread From: Larry Kilgallen @ 2000-01-13 0:00 UTC (permalink / raw) Reply-To: Kilgallen@eisner.decus.org.nospam Organization: LJK Software Lines: 23 In article <387DFB1E.CBBF14C7@mail.com>, Mats Weber <matsw@mail.com> writes: > Thierry Lelegard wrote: > >> Yes it does. If you had left the variable uninitialized (on an Ada >> perspective), then the variable would have been allocated in >> a "demand zero" section (no allocation in executable). Since >> you provided an explicit initial value, the compiler/linker placed >> it into a "copy on reference" section which contains the initial >> values. Of course, the compiler could make a special optimization >> which consists in inspecting every single byte of this initial >> value and if they are all zeroes then place the variable into >> a "demand zero" section. But, it appears that this optimization >> is not made. > > You generally cannot guarantee that the variable is allocated in a > demand-zero region. For instance, when allocated on the stack, the stack > may have previously grown higher than where you allocate and you get the > content left there from a previous call (unless the stack is zeroed or > unmapped from the address space when it shrinks, but I doubt any system > is doing that). You cannot guarantee a _stack_ variable is in a demand-zero region, but you can guarantee it for static variables or by calling $EXPREG. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Robert A Duff 2000-01-06 0:00 ` Larry Kilgallen 2000-01-07 0:00 ` Florian Weimer @ 2000-01-11 0:00 ` Mats Weber 2 siblings, 0 replies; 50+ messages in thread From: Mats Weber @ 2000-01-11 0:00 UTC (permalink / raw) Robert A Duff wrote: > Commit on use is indeed very cool. > > Do you know which operating systems support it? VMS. And I think most major Unices also support it, as well as NT. If you want to know, compile and run the following program and see what happens: -- with Ada.Numerics.Discrete_Random; procedure Try_Commit_On_Use is Size : constant := 100_000_000; -- Size of memory allocated. Pages : constant := 1_000; -- Number of pages to reference. type Big is array (1 .. Size) of Character; type Big_Access is access Big; subtype Bar is Integer range 1 .. Pages; package Bar_Random is new Ada.Numerics.Discrete_Random(Bar); Generator : Bar_Random.Generator; Z : Big_Access; begin Z := new Big; loop Z(Size / Pages * Bar_Random.Random(Generator)) := Z(Size / Pages * Bar_Random.Random(Generator)); end loop; end; ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Robert Dewar 2000-01-06 0:00 ` Robert A Duff @ 2000-01-07 0:00 ` Tarjei T. Jensen 2000-01-07 0:00 ` Robert Dewar 1 sibling, 1 reply; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-07 0:00 UTC (permalink / raw) Robert Dewar wrote in message <852dt0$vdl$1@nnrp1.deja.com>... >In article <851j2q$78q1@ftp.kvaerner.com>, > "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: >> Anything else would be madness. 32-bit CPUs will have more >> than enough computing power for many if not most applications >> in the foreseeable future. > > >Well I guess you think all the world is mad then because >everyone (including Intel and AMD) see the future in 64-bit >computing. I believe the word application has more than one meaning. If you consider the use of the word applications also to include embedded application then I think you will find the statement reasonable. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-07 0:00 ` Tarjei T. Jensen @ 2000-01-07 0:00 ` Robert Dewar 0 siblings, 0 replies; 50+ messages in thread From: Robert Dewar @ 2000-01-07 0:00 UTC (permalink / raw) In article <854j43$9c63@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > I believe the word application has more than one meaning. If > you consider the > use of the word applications also to include embedded > application then I think > you will find the statement reasonable. Only if you restrict your statement to embedded applications. The embedded application market is a tiny sliver of the total application market place, particularly if we are talking work station class machines (as we are in the case of 64-bit architectures). Obviously embedded applications will continue to use 8-bit and 16-bit processors for some time, so no one is suggesting that all embedded applications wlil go to 64-bits. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Al Christians 2000-01-06 0:00 ` Tarjei T. Jensen @ 2000-01-06 0:00 ` Robert Dewar 1 sibling, 0 replies; 50+ messages in thread From: Robert Dewar @ 2000-01-06 0:00 UTC (permalink / raw) In article <38737352.B282CC2@easystreet.com>, Al Christians <achrist@easystreet.com> wrote: > Although 64-bits gets more PR, Intel is also developing a 32-bit > successor to the Pentium. Yes, well of course they are, the ia32 architecture is alive and well (note also that the Itanium includes an ia32 core) Even more interesting is AMD's plans which include making a 64-bit version of the ia32 architecture (you can't call it ia64, since that is coopted by Intel for the Itanium which is an architecture that bears no relation to the ia32). Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Tarjei T. Jensen 2000-01-05 0:00 ` Al Christians @ 2000-01-05 0:00 ` Robert Dewar 2000-01-06 0:00 ` Richard D Riehle ` (2 more replies) 1 sibling, 3 replies; 50+ messages in thread From: Robert Dewar @ 2000-01-05 0:00 UTC (permalink / raw) In article <84vev2$7p4@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote: > I expect support for creating old type 32bit applications to > be phased out within the next five years. I expect support for > old type 32bit applications to be phased out within 10 years > from now. I expect Unixes - even those which run on 32 bit > systems - to be 64 bit (compliant) by the end of the decade. I can just imagine someone saying in 1985 (easy to imagine, because it is based on memories of hearing this said often) "I expect support for COBOL-74 and related applications to be phased out by the end of the decade, and we should not have any trouble with the date change in 2000 because all old applications will be phased out by then, and all new applications are being written to be aware of this problem" Tarjei gives absolutely NO documentation for his expectations, he seems to have just based them on what seems reasonable. The actual facts are that old software stays around for a long time. Look for example at the situation on -o32 with SGI. SGI would surely like to get rid of this old ABI, and pushes customers hard to move to the new much more efficient -n32 ABI, but there are still many 3rd party libraries etc which have not made the switch. So there we are talking about a switch from one 32-bit for to another, something that has almost NO effect on existing code, and even that switch looks like it will end up taking a decade. I think you *greatly* underestimate the time scale for 32-bit mode disappearing. No vendor has indicated any push in the direction of eliminating 32-bit mode support. Besides which, many applications are smaller and run faster in 32-bit mode, so why would you switch them in any case? Yes, surely 64-bit time will become a standard before it is an issue, but that does not mean that old non-standard programs will suddenly go away :-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Robert Dewar @ 2000-01-06 0:00 ` Richard D Riehle 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-06 0:00 ` Georg Bauhaus 2 siblings, 0 replies; 50+ messages in thread From: Richard D Riehle @ 2000-01-06 0:00 UTC (permalink / raw) In article <8505tc$be4$1@nnrp1.deja.com>, Robert Dewar <robert_dewar@my-deja.com> wrote: >The actual facts are that old software stays around for a long >time. > The same is true for MS-DOS machines running on 8088 machines, old Apple IIe's in elementary schools, Atari 400 and 800 models, and other "obsolete" computers. I know someone who is quite content doing word processing on an old portable KayPro. It works great, for him. Why, we even know some people who are deliberately selecting Ada 83 as the programming language for their next project. In some cases this is because there are no suitable Ada 95 compilers for their required platform (e.g. 1750A) In other cases, they consider the more mature technology, absent the modernizations that characterize Ada 83, to be more reliable. I myself am considering purchasing a Model A Ford for my next car. It has a certain charm that seems to be lost in the glitzie bezier curves and sparkling hues of modern automobileiry. Richard Riehle ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Robert Dewar 2000-01-06 0:00 ` Richard D Riehle @ 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-06 0:00 ` Larry Kilgallen 2000-01-06 0:00 ` Georg Bauhaus 2 siblings, 1 reply; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-06 0:00 UTC (permalink / raw) Robert Dewar wrote >I can just imagine someone saying in 1985 (easy to imagine, >because it is based on memories of hearing this said often) > >"I expect support for COBOL-74 and related applications to be > phased out by the end of the decade, and we should not have > any trouble with the date change in 2000 because all old > applications will be phased out by then, and all new > applications are being written to be aware of this problem" That is an entirely different matter. There are other dynamics involved. E.g. incompatibilities between operating system versions. Programs cannot determine disk sizes in bytes because a 32 bit int is becoming too small. Some files are becoming so large that one needs more than 32 bit ints to store the size. I'm sure others can point to other such 32bit annoyances. These things and more add up to a slow pressure to phase out old 32bit programs. Note the use of the word old. If the new 32bit API does not take into account these things, then it too will disappear. It will take more time, but they will disappear. Whether it takes 10 or 20 years I'm not certain, but they will disappear. y2k bagged a lot of old programs (on the PC side where I work they retired approximately 600 applications. On the Unix side we got new versions which were y2k compliant), further change will do in more. >Tarjei gives absolutely NO documentation for his expectations, >he seems to have just based them on what seems reasonable. > >The actual facts are that old software stays around for a long >time. Look for example at the situation on -o32 with SGI. SGI >would surely like to get rid of this old ABI, and pushes >customers hard to move to the new much more efficient -n32 >ABI, but there are still many 3rd party libraries etc which >have not made the switch. But the change is being made. As of today -o32 is a problem since we cannot mix -o32 and -n32 and that pushes towards -n32. Slowly, but surely. The previous version of gcc I used on Irix generated -o32 object files. The one I use now generates -n32 and is very unwilling to generate -o32 object files. In fact I am certain that as the 32bit SGI machines falls into disuse -n32 will disappear as well. I suspect that if Irix survives 20 years from now it will be with very reduced 32 bit support. >I think you *greatly* underestimate the time scale for 32-bit >mode disappearing. > >No vendor has indicated any push in the direction of eliminating >32-bit mode support. I suggest you re-read what I wrote. I wrote that old 32bit mode would disappear. Which probably means -o32 disappears. I have not claimed that the equivalent of -n32 would disappear within a decade. I suspect that it will disappear within 20 years if it does not become 64 bit compliant. E.g. support big files and a 64 bit time. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Tarjei T. Jensen @ 2000-01-06 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 50+ messages in thread From: Larry Kilgallen @ 2000-01-06 0:00 UTC (permalink / raw) In article <85201l$7q3@ftp.kvaerner.com>, "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> writes: > > Robert Dewar wrote >>I can just imagine someone saying in 1985 (easy to imagine, >>because it is based on memories of hearing this said often) >> >>"I expect support for COBOL-74 and related applications to be >> phased out by the end of the decade, and we should not have >> any trouble with the date change in 2000 because all old >> applications will be phased out by then, and all new >> applications are being written to be aware of this problem" > > That is an entirely different matter. There are other dynamics involved. E.g. > incompatibilities between operating system versions. Programs cannot determine > disk sizes in bytes because a 32 bit int is becoming too small. Some files are > becoming so large that one needs more than 32 bit ints to store the size. I'm > sure others can point to other such 32bit annoyances. Individual programs only get replaced out of need, and the set of programs that need to calculate the size of an entire disk is quite small. Several years ago my finances became so complex that my Quicken file will no longer fit on a 1 MB floppy, but I have no chance for reaching the state where my finances half fill the 9 GB hard drive on the Macintosh. There is also not necessarily any correlation between disk size and word size. Since 1979 the 32-bit RMS API for VMS (but not the underlying hardware at the start) has been able to handle file sizes up to 2000 gigabytes. Certainly there are programs for which that limit is too small, but they are decidedly a minority. Larry Kilgallen ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-05 0:00 ` Robert Dewar 2000-01-06 0:00 ` Richard D Riehle 2000-01-06 0:00 ` Tarjei T. Jensen @ 2000-01-06 0:00 ` Georg Bauhaus 2000-01-06 0:00 ` Tarjei T. Jensen 2 siblings, 1 reply; 50+ messages in thread From: Georg Bauhaus @ 2000-01-06 0:00 UTC (permalink / raw) Robert Dewar (robert_dewar@my-deja.com) wrote: : In article <84vev2$7p4@ftp.kvaerner.com>, : Besides which, many applications are smaller and run faster in : 32-bit mode, so why would you switch them in any case? If increasing word size is about addressing larger memories and packing more ops in a word, (which might not alway be achievable?) why is it that relatively few money is spent on alternative improvements, like parallelism related research and hardware, at least PR wise? I have a feeling like there are some valuable pieces of technology lying around still rather unnoticed. Like transputers? Enough lament, this question may just reveal my nearly total lack of knowledge of hardware then... ;/ Georg Bauhaus ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-06 0:00 ` Georg Bauhaus @ 2000-01-06 0:00 ` Tarjei T. Jensen 0 siblings, 0 replies; 50+ messages in thread From: Tarjei T. Jensen @ 2000-01-06 0:00 UTC (permalink / raw) Georg Bauhaus wrote in message <8527o7$e2o$1@news-hrz.uni-duisburg.de>... >Robert Dewar (robert_dewar@my-deja.com) wrote: >: In article <84vev2$7p4@ftp.kvaerner.com>, > >: Besides which, many applications are smaller and run faster in >: 32-bit mode, so why would you switch them in any case? > >If increasing word size is about addressing larger memories >and packing more ops in a word, (which might not alway be achievable?) >why is it that relatively few money is spent on alternative improvements, >like parallelism related research and hardware, at least PR wise? >I have a feeling like there are some valuable pieces of technology >lying around still rather unnoticed. Like transputers? I think you will find that more advanced processors have more processing units onboard. e.g. more ALUs and more FPUs. This allows them to do more than one thing at a time. How useful this is for all applications I don't know. But it is not entirely unthinkable that it helps execution speed. Greetings, ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-03 0:00 ` Robert A Duff 2000-01-04 0:00 ` Tarjei T. Jensen @ 2000-01-04 0:00 ` Robert Dewar 2000-01-04 0:00 ` Charles Hixson 1 sibling, 1 reply; 50+ messages in thread From: Robert Dewar @ 2000-01-04 0:00 UTC (permalink / raw) In article <wccg0wfb02q.fsf@world.std.com>, Robert A Duff <bobduff@world.std.com> wrote: > And from what I've heard, making Unix code "64-bit clean" > hasn't been so easy, which is exactly the sort of thing Robert > Dewar was talking about. Indeed it is a HUGE effort to make some code 64-bit clean, and my guess is that unices will support 32-bit code for a long time, and it will be a bad earthquake when there is a requirement to change legacy 32-bit code to make it 64-bit compatible (as will possibly happen at the date blow up time (which will happen in our life times for at least some of us). > If it were as easy as changing some "Word_Size" constant, then > people wouldn't have invented a fancy term like "64-bit clean" > for it. ;-) Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Robert Dewar @ 2000-01-04 0:00 ` Charles Hixson 2000-01-04 0:00 ` Keith Thompson ` (2 more replies) 0 siblings, 3 replies; 50+ messages in thread From: Charles Hixson @ 2000-01-04 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Indeed it is a HUGE effort to make some code 64-bit clean, and > my guess is that unices will support 32-bit code for a long > time, and it will be a bad earthquake when there is a > requirement to change legacy 32-bit code to make it 64-bit > compatible (as will possibly happen at the date blow up time > (which will happen in our life times for at least some of us). > But I believe that it would be a mistake to begin conversions of programs to 64-bit mode for the next couple of years (except in special circumstances). After that... With 64 bit numbers available, I propose a new time standard, based around 64-bit floats. We need a SMALL floating number (16 bits?) to specify the millennium, and a large floating number (64 bits) to specify the time. (0 = center of the millennium, +- 1 = +- 500 years, etc.). Current Millennium = 2 (years 2,000->2,999, CE). (I allow for a year 0 before the year 1, if you wish to print that out as 1 BC, that's merely a formatting issue.) This would let us be as accurate as we have data available almost all the time (i.e, creation of universe to end of universe [note: the millennium was a floating point number]). ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Charles Hixson @ 2000-01-04 0:00 ` Keith Thompson 2000-01-05 0:00 ` Robert Dewar 2000-01-05 0:00 ` Y21C Bug Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Keith Thompson @ 2000-01-04 0:00 UTC (permalink / raw) Charles Hixson <charleshixsn@earthlink.net> writes: [...] > With 64 bit numbers available, I propose a new time standard, based > around 64-bit floats. We need a SMALL floating number (16 bits?) to > specify the millennium, and a large floating number (64 bits) to > specify the time. (0 = center of the millennium, +- 1 = +- 500 > years, etc.). Current Millennium = 2 (years 2,000->2,999, CE). (I > allow for a year 0 before the year 1, if you wish to print that out > as 1 BC, that's merely a formatting issue.) > > This would let us be as accurate as we have data available almost > all the time (i.e, creation of universe to end of universe [note: > the millennium was a floating point number]). Huh? I don't think that floating-point is appropriate for a time standard. The precision is too strongly dependent on how far you are from the arbitrarily chosen epoch. Floating-point arithmetic is notoriously tricky, which could be a serious problem if you want to check timestamps for equality, or reliably determine which of two files is newer. I also don't see the point of separating the millennium into a separate field, or even explicitly representing it. For 1-second precision, a signed 64-bit time_t orginating at Jan 1, 1970 can represent times nearly 300 billion years into the past and future. If one second is too coarse, a second 64-bit word can give you a precision of about 54 zeptoseconds (zepto means 10**(-21)). In Ada terms, this would be a 128-bit fixed-point type with a 'Small of 2**(-64). Conversion to and from a human-readable format is not difficult. In GNAT, I seem to recall that types Duration and Calendar.Time have the same representation, a 64-bit fixed-point type with a 'Small of 1.0e-9. That gives you nanosecond resolution over a range of times from about 1677 to about 2262. There are some fields for which that's insufficient, but for most applications it's more than enough. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Charles Hixson 2000-01-04 0:00 ` Keith Thompson @ 2000-01-05 0:00 ` Robert Dewar 2000-01-05 0:00 ` Y21C Bug :-) Charles Hixson 2000-01-05 0:00 ` Y21C Bug Robert Dewar 2 siblings, 1 reply; 50+ messages in thread From: Robert Dewar @ 2000-01-05 0:00 UTC (permalink / raw) In article <387246D7.8B1B2E8B@earthlink.net>, Charles Hixson <charleshixsn@earthlink.net> wrote: > Robert Dewar wrote: > > > > > Indeed it is a HUGE effort to make some code 64-bit clean, and > > my guess is that unices will support 32-bit code for a long > > time, and it will be a bad earthquake when there is a > > requirement to change legacy 32-bit code to make it 64-bit > > compatible (as will possibly happen at the date blow up time > > (which will happen in our life times for at least some of us). > > > > But I believe that it would be a mistake to begin conversions of > programs to 64-bit mode for the next couple of years (except in > special circumstances). After that... > > With 64 bit numbers available, I propose a new time standard, based > around 64-bit floats. We need a SMALL floating number (16 bits?) to > specify the millennium, and a large floating number (64 bits) to > specify the time. (0 = center of the millennium, +- 1 = +- 500 > years, etc.). Current Millennium = 2 (years 2,000->2,999, CE). (I > allow for a year 0 before the year 1, if you wish to print that out > as 1 BC, that's merely a formatting issue.) > I am sort of guessing that a smiley is missing here, but if not, time is clearly a case where absolute error control and not relative error control is important, so the use of fixed point is far preferable. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug :-) 2000-01-05 0:00 ` Robert Dewar @ 2000-01-05 0:00 ` Charles Hixson 2000-01-06 0:00 ` Ted Dennison 0 siblings, 1 reply; 50+ messages in thread From: Charles Hixson @ 2000-01-05 0:00 UTC (permalink / raw) Smiley? Well... I'm not too serious about this... Conversion from floats would be a bit of a hassle. But it does accurately reflect the fact that dates further from the "center" are known less accurately. Still, as Kieth Thompson points out, for less work and not much more storage one could use a 128 bit fixed number, which would avoid another Y2K problem for the history of the universe. (OK, I guess a smiley was appropriate.) But I'd rather cover more time and sacrifice a bit of precision. Say a coverage of 3,000 billion years at 260 zeptosecond resolution. :-) The GNAT standard time of 1677 to about 2262 would lead to a massive need to rewrite all of our code just as it was getting too complex to deal with! :-) (GNAT standard taken from Keith Thompson's response. Sorry, I didn't look this up. zeptoseconds huh? Hadn't heard about them! ) Robert Dewar wrote: > In article <387246D7.8B1B2E8B@earthlink.net>, > Charles Hixson <charleshixsn@earthlink.net> wrote: > > Robert Dewar wrote: > > > ... > > I am sort of guessing that a smiley is missing here, but if not, > time is clearly a case where absolute error control and not > relative error control is important, so the use of fixed point > is far preferable. > > Sent via Deja.com http://www.deja.com/ > Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug :-) 2000-01-05 0:00 ` Y21C Bug :-) Charles Hixson @ 2000-01-06 0:00 ` Ted Dennison 2000-01-07 0:00 ` Keith Thompson 0 siblings, 1 reply; 50+ messages in thread From: Ted Dennison @ 2000-01-06 0:00 UTC (permalink / raw) In article <38738A12.3C5093FC@earthlink.net>, Charles Hixson <charleshixsn@earthlink.net> wrote: > sacrifice a bit of precision. Say a coverage of 3,000 billion years > at 260 zeptosecond resolution. :-) > (GNAT standard taken from Keith Thompson's response. Sorry, I > didn't look this up. zeptoseconds huh? Hadn't heard about them! ) Didn't you know that when they started running out of good greek and latin names for metric powers, they started using names of Marx Brothers? That's what they taught me in engneering school anyway... Just 8 more bits and you could represent time down to the harposecond. :-) -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug :-) 2000-01-06 0:00 ` Ted Dennison @ 2000-01-07 0:00 ` Keith Thompson 2000-01-07 0:00 ` Robert A Duff 0 siblings, 1 reply; 50+ messages in thread From: Keith Thompson @ 2000-01-07 0:00 UTC (permalink / raw) If you're curious, the complete list of SI prefixes is at <http://www.bipm.fr/enus/3_SI/si-prefixes.html>. (If you're not curious, that web page contains something else entirely. Of course, the only way to disprove this is to go look at the page, which you'll do only if you're curious.) -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst> Welcome to the last year of the 20th century. ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug :-) 2000-01-07 0:00 ` Keith Thompson @ 2000-01-07 0:00 ` Robert A Duff 0 siblings, 0 replies; 50+ messages in thread From: Robert A Duff @ 2000-01-07 0:00 UTC (permalink / raw) Keith Thompson <kst@cts.com> writes: > If you're curious, the complete list of SI prefixes is at > <http://www.bipm.fr/enus/3_SI/si-prefixes.html>. I'm not curious. > (If you're not curious, that web page contains something else > entirely. Of course, the only way to disprove this is to go look at > the page, which you'll do only if you're curious.) Now I'm curious! ;-) - Bob ^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: Y21C Bug 2000-01-04 0:00 ` Charles Hixson 2000-01-04 0:00 ` Keith Thompson 2000-01-05 0:00 ` Robert Dewar @ 2000-01-05 0:00 ` Robert Dewar 2 siblings, 0 replies; 50+ messages in thread From: Robert Dewar @ 2000-01-05 0:00 UTC (permalink / raw) In article <387246D7.8B1B2E8B@earthlink.net>, Charles Hixson <charleshixsn@earthlink.net> wrote: > But I believe that it would be a mistake to begin conversions > of programs to 64-bit mode for the next couple of years > (except in special circumstances). After that... I think that misses the point. Well written C code is almost completely portable between 32-bit and 64-bit code (at most some typedefs may need modifying. Well written Ada code is 100% portable between 32-bit and 64-bit environments. There is no reason not to start converting badly written applications (in C or Ada :-) to well written ones, and that conversion can start immediately! Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 50+ messages in thread
end of thread, other threads:[~2000-02-04 0:00 UTC | newest] Thread overview: 50+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-01-02 0:00 Y21C Bug reason67 2000-01-02 0:00 ` Robert Dewar 2000-01-03 0:00 ` Tarjei T. Jensen 2000-01-03 0:00 ` Jeff Creem 2000-01-03 0:00 ` Tarjei T. Jensen 2000-01-03 0:00 ` Robert A Duff 2000-01-04 0:00 ` Tarjei T. Jensen 2000-01-04 0:00 ` Samuel Tardieu 2000-01-04 0:00 ` Robert A Duff 2000-01-04 0:00 ` Robert Dewar 2000-01-05 0:00 ` Tarjei T. Jensen 2000-01-05 0:00 ` Al Christians 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-06 0:00 ` Robert Dewar 2000-01-06 0:00 ` Robert A Duff 2000-01-06 0:00 ` Larry Kilgallen 2000-01-07 0:00 ` Florian Weimer 2000-01-07 0:00 ` Robert A Duff 2000-01-07 0:00 ` Robert Dewar 2000-02-04 0:00 ` Florian Weimer 2000-02-04 0:00 ` Robert A Duff 2000-02-04 0:00 ` Florian Weimer 2000-01-11 0:00 ` Mats Weber 2000-01-11 0:00 ` Robert A Duff 2000-01-12 0:00 ` Mats Weber 2000-01-12 0:00 ` Thierry Lelegard 2000-01-13 0:00 ` Robert A Duff 2000-01-13 0:00 ` Larry Kilgallen 2000-01-13 0:00 ` Thierry Lelegard 2000-01-13 0:00 ` Mats Weber [not found] ` <387dfb1e.cbbf14c7@mail.com> 2000-01-13 0:00 ` Larry Kilgallen 2000-01-11 0:00 ` Mats Weber 2000-01-07 0:00 ` Tarjei T. Jensen 2000-01-07 0:00 ` Robert Dewar 2000-01-06 0:00 ` Robert Dewar 2000-01-05 0:00 ` Robert Dewar 2000-01-06 0:00 ` Richard D Riehle 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-06 0:00 ` Larry Kilgallen 2000-01-06 0:00 ` Georg Bauhaus 2000-01-06 0:00 ` Tarjei T. Jensen 2000-01-04 0:00 ` Robert Dewar 2000-01-04 0:00 ` Charles Hixson 2000-01-04 0:00 ` Keith Thompson 2000-01-05 0:00 ` Robert Dewar 2000-01-05 0:00 ` Y21C Bug :-) Charles Hixson 2000-01-06 0:00 ` Ted Dennison 2000-01-07 0:00 ` Keith Thompson 2000-01-07 0:00 ` Robert A Duff 2000-01-05 0:00 ` Y21C Bug Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox