Y21C Bug

Y21C Bug

[reason67]

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.

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Robert A Duff]

"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

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Samuel Tardieu]

>>>>> "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

Re: Y21C Bug

[Robert A Duff]

"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

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Georg Bauhaus]

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

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Richard D Riehle]

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

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Larry Kilgallen]

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

Re: Y21C Bug

[Al Christians]

"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

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Robert A Duff]

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

Re: Y21C Bug

[Larry Kilgallen]

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

Re: Y21C Bug

[Florian Weimer]

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. ;)

Re: Y21C Bug

[Robert A Duff]

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

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Florian Weimer]

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.

Re: Y21C Bug

[Robert A Duff]

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

Re: Y21C Bug

[Florian Weimer]

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.

Re: Y21C Bug

[Mats Weber]

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.

Re: Y21C Bug

[Robert A Duff]

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

Re: Y21C Bug

[Mats Weber]

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.

Re: Y21C Bug

[Thierry Lelegard]

> > 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

Re: Y21C Bug

[Mats Weber]

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).

Re: Y21C Bug

[Robert A Duff]

"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

Re: Y21C Bug

[Larry Kilgallen]

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

Re: Y21C Bug

[Thierry Lelegard]

> > 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

Re: Y21C Bug

[Larry Kilgallen]

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.

Re: Y21C Bug

[Mats Weber]

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;

Re: Y21C Bug

[Tarjei T. Jensen]

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,

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Charles Hixson]

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]).

Re: Y21C Bug

[Keith Thompson]

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.

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug

[Robert Dewar]

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.

Re: Y21C Bug :-)

[Charles Hixson]

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.

Re: Y21C Bug :-)

[Ted Dennison]

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.

Re: Y21C Bug :-)

[Keith Thompson]

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.

Re: Y21C Bug :-)

[Robert A Duff]

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

Re: Y21C Bug

[Jeff Creem]

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

Re: Y21C Bug

[Tarjei T. Jensen]

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,