From: tkoenig@netcologne.de   
      
   Anton Ertl  schrieb:   
   > Thomas Koenig  writes:   
   >>Anton Ertl  schrieb:   
   >>> Thomas Koenig  writes:   
   >>>>Anton Ertl  schrieb:   
   >>>>   
   >>>>> The I32LP64 mistake   
   >>>>   
   >>>>If you consider I32LP64 a mistake, how should FORTRAN's (note the   
   >>>>upper case, this is pre-Fortran-90) storage association rules have   
   >>>>been handled, in your opinion?   
   > ...   
   >>By the time the 64-bit worksations   
   >>were being designed, REAL was firmly established as 32-bit and   
   >>DOUBLE PRECISION as 64-bit, from the /360, the PDP-11, the VAX   
   >>and the very 32-bit workstations that the 64-bit workstations were   
   >>supposed to replace.   
   >   
   > On the PDP-11 C's int is 16 bits.  I don't know what FORTRAN's INTEGER   
   > is on the PDP-11 (but I remember reading about INTEGER*2 and   
   > INTEGER*4, AFAIK not in a PDP-11 context).  In any case, I expect that   
   > FORTRAN's REAL was 32-bit on a PDP-11, and that any rule chain that   
   > requires that C's int is as wide as FORTRAN's REAL is broken at some   
   > point on the PDP-11.   
      
   It is possible to have a two-byte integer and a 32-byte real.   
   Storage association then requires four bytes for an integer.   
   This wastes space for integers (at least for arrays) but that   
   is not such a big deal, because most big arrays in scientific   
   code are reals.   
      
   The same held for the Cray-1 - default ingegers (24 bit)   
   and their weird 64-bit reals   
      
   The main problem is when the size of default INTEGER size _exceeds_ the   
   smallest useful REAL, then REAL arrays either become twice as big,   
   plus you need to implement 128-bit REALs.   
      
   >>So, put yourself into the shoes of the people designing workstations   
   >>RS4000 they could allow their scientific and technical customers   
   >>to use the same codes "as is", with no conversion, or tell them   
   >>they cannot use 32-bit REAL any more, and that they need to rewrite   
   >>all their software.   
   >   
   > If they want to use their software as-is, and it is written to work   
   > with an ILP32 C implementation, the only solution is to continue using   
   > an ILP32 implementation.   
      
   So, kill the 64-bit machines in the scientific marketplace. I'm glad   
   you agree.   
      
   >   
   >>What would they have expected their customers to do?  Buy a system   
   >>which forces them to do this, or buy a competitor's system where   
   >>they can just recompile their software?   
   >   
   > If just recompiling is the requirement, what follows is ILP32.   
      
   There is absolutely no problem with 64-bit pointers when recompiling   
   Fortran.   
      
   >   
   >>You're always harping about how compilers should be bug-comptatible   
   >>to previous releases.   
   >   
   > Not in the least.  I did not ask for bug compatibility.   
      
   I'll keep that in mind for the next time.   
   --   
   This USENET posting was made without artificial intelligence,   
   artificial impertinence, artificial arrogance, artificial stupidity,   
   artificial flavorings or artificial colorants.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)