[M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent?

[Jay K]

1) Ctypes.int

2) I wrapped everything anyway because the rewriting of /usr/include in m3core/unix was terribly tedious and error prone and a frequent source of problems.I favor size_t/INTEGER. The "direct" calls were not worth the trouble. I've debugged enough stack corruptions due to getting struct stat wrong there.

3) But not always, the Win32 and X windows stuff is still direct.
INTEGER is not the only integer type, it is just kinda the default easiest to use if you must use one, use it.If you want to think more about it, there are more options.
The 8 underlying types are all in there -- 8/16/32/64 unsigned and signed.Perhaps they should be exposes differently, like as INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64?Or int8_t, uint8_t, int16_t, uint16_t, etc.?
Those types are all available to all programs, albeit in the WinNT and cstdint modules I believe. Not "global" like INTEGER.
 - Jay



Date: Thu, 28 May 2015 21:53:33 +0200
From: estellnb at elstel.org
To: hosking at purdue.edu
CC: m3devel at elegosoft.com; jay.krell at cornell.edu; rodney.m.bates at acm.org
Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent?


  
    
  
  
    

      How for the hell do you interface with operating system services
      requiring a 32bit int when you only have the 64bit INTEGER??

      

      Am 28.05.15 um 19:46 schrieb Elmar Stellnberger:

    
    
      
      Am 28.05.15 um 04:03 schrieb Antony
        Hosking:

      
      
        BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing.


      
      on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit

      

      I have just noticed that and when taking a practical standpoint -
      i.e. what really matters to new and old programs -

      this is a really bad decision which I wish to change for the next
      release.

      

      If you have not examined it yet please reclaim the design
      decisions for leaving int 32bit in C:

      However things turned out to be very different when the extension from 
32bit to 64bit was at stake. There was no more gain by automatically
extending the value ranges from 2^32 to 2^64 for 95% of all application
purposes while the memory hierarchy has increasingly become a bottle 
neck in recent time. Additionally doubling the size of all integers would
initially have doubled our memory needs which would have been a
potential drawback for introducing the AMD64 arch. Just think of a machine
with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while
making all INTS 64bit would have shrunken our memory to an effective size
of 2GB. Luckily the decision was taken differently this time:

* keep all ints of at most 32bit and just extend pointers to 64bit
 
       Same reasoning applies to Modula-3. - and I believe you have
      failed to notice when 

      making your decisions for cm3 5.8.6. Or do you want to tell me
      that Modula-3 

      developers are more prudent than the C/C++ community?

      

        Even worse I have discovered the following:

      BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3
      5.8.6:

      

      :: BITS FOR size too small, must be at least (64)

      

      That will break existing legacy code when trying to compile it
      with cm3 5.8.6. 

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