[M3devel] 32bit host 64bit target TextLiteral recurring problem

[Jay K]

Do you want 64bit targets to be "better" or "the same"?What if I say the Modula-3 equivalent of, three programs: 1 printf("%d", (int)sizeof(void*));  
 2 printf("%d", (int)sizeof(size_t)); 3 printf("%d", (int)sizeof(int)); 
One could argue in your favor here.The user of void* and size_t is expecting "better".The user of int is expecting "same".
Modula-3 could have two integer types, builtin, short names.Or, today, it offers all 4 sizes, you just have to go slightly out of your way.
You can say:  TYPE int = Ctypes.int; or maybe BasicCtypes.int.
and go about your business using int instead of INTEGER andget the compability you desire.
Perhaps this should be: int = IntegerTypes.INT32?
to not be be C-related?
 - Jay



Date: Thu, 4 Jun 2015 16:01:37 +0200
From: estellnb at elstel.org
To: jay.krell at cornell.edu; m3devel at elegosoft.com
Subject: Re: [M3devel] 32bit host 64bit target TextLiteral recurring problem


  
    
  
  
    Am 03.06.15 um 03:58 schrieb Jay K:

    
    
      
      
        We cannot cross from 32bit host to 64bit target.
        

        
        

        
        Ok to commit this?
        

        
        

      
    
    

    Compatibility between the 32bit and the 64bit version of the same
    program would be the minimum I expected from a pickle.

    To me this is just another argument for a language specified value
    range of INTEGER.

    It makes certain things easier. 

    

    My suggestion was:

    TYPE OFFSET = BITS BITSIZE(ADDRESS) FOR INTEGER; (and INTEGER = BITS
    32 FOR INTEGER for 32 and 64bit targets)

    while also allowing BITS 16 FOR INTEGER (if that works for WIDECHAR
    I believe there is no reason to forbid it for INTEGER)

    BITS 64 FOR INTEGER would only work on x64 systems.

    

    The value range - bitsize correlation problem could be solved easily
    by automatically extending and reducing the value 

    range of an integer type to what its binary representation allows as
    long as no explicit range has ever been specified for 

    any of its supertypes (i.e. BITS 16 FOR INTEGER = BITS 16 FOR
    [-32768..+32767]).

    

    Finally it needs to be said that the argument that target size
    arithmetics is always the fastest which was often used in 

    here can be very wrong. It does not hold for the 64bit systems of
    today because the CPU is no more the bottleneck. In

    a fact now the memory hierarchy has become the new bottleneck (which
    means that using more memory for the same 

    tends to be much slower).

    

    Regards,

    Elmar

    

    Can't
      do this.  Non-open arrays must have static constant bounds, 

      which the above does not.  Open arrays have extra dope and are
      accessed 

      through two extra pointers, which we really wouldn't want for text
      literals. 

      

      TextLiteral.Ts are unsafe only in UNSAFE code, which is no worse
      that anything 

      else in UNSAFE code.  The interface is UNSAFE, which means safe
      code can't IMPORT 

      it, and thus can't see the declaration.  Not very likely that
      anybody other than 

      the runtime, compiler-generated code, and debugger (written in C
      anyway) would 

      want to mess with it. 

      

    
    
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150604/f345476c/attachment-0002.html>