<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> I believe the proposal is that INTEGER be more like int in C and C+ -- 32bits always.<BR> <BR><br> > I do have the impression that some Windows targets are not currently<BR> <BR> <BR> All targets have a 64bit LONGINT. I implemented this years ago in the NT/x86 backend.<br> The C backend depends on the underlying C compiler having __int64 or long long or a 64bit long. <br> All targets have BYTESIZE(INTEGER) == BYTESIZE(ADDRESS).<BR>In C and C++, long is smaller than a pointer on Win64.<br>On Windows, int and long are always 32 bits.<BR> <BR><br>This might be the case at least sort of on VMS and HP-UX, at least when the<br>upper bits of 64bit pointers are guaranteed all zeros or all ones or ignored.<br>They have such environments -- 32bit-ish pointers on Alpha, 32bit-ish pointers on IA64.<BR><br>I started writing up more detail.<BR> <BR> <BR> There are obviously 8 underlying integer types: unsigned/signed 8/16/32/64 <BR> <BR> <BR> A typical C99 environment has around 40 names for them: <br> stdint.h: 8+16+32+64 x signed/unsigned x fast+least+exact: 24 <br> short/int/long/long long; unsigned: 8 <br> char/unsigned char/signed char: 3 <br> [u]intptr_t: 2 <br> size_t/ptrdiff_t: 2 <br> wchar_t: 1 <br> => 40 <br><BR> <br> In C++, some of them are distinct for overloading/mangling purposes.<BR> Windows has far more, like almost double, for various historical and typographical and stylistic reasons.<br> e.g. INT, UINT, LONG, ULONG, WCHAR, CHAR, UCHAR, BYTE, WORD, DWORD, DWORD_PTR, INT_PTR, UINT_PTR, SIZE_T, HALF_PTR, etc.<BR><br> <BR> But still the same underlying 8 types. <BR> <BR><br> It can be difficult to chose the right type.<br> It is tempting to discount many of them, and many can be discounted, but it hard<br> to really narrow the list to be small.<BR> <br><BR> Should we add some more builtins to the frontend?<br> Like [U]INT[8,16,32,64]? <br> Or lowercase and _t? <BR> <BR> <BR> - Jay<br><br><br><br> <BR><div>> Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent?<br>> From: hosking@purdue.edu<br>> Date: Thu, 28 May 2015 05:03:39 +0300<br>> CC: rodney.m.bates@acm.org; jay.krell@cornell.edu; m3devel@elegosoft.com<br>> To: estellnb@elstel.org<br>> <br>> BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing.<br>> <br>> Sent from my iPhone<br>> <br>> > On May 27, 2015, at 7:32 PM, Elmar Stellnberger <estellnb@elstel.org> wrote:<br>> > <br>> > Enough words about the history, now let us see how we can profit <br>> > from both kinds of types when we wanna step on virgin soil:<br>> > <br>> > In what way we may ever turn things there actually needs to be <br>> > a target sized type which is uses to be unsigned: the pointer.<br>> > However there needs to be a way to do certain address <br>> > calculations manually, apart from array indexing: <br>> > multiply, add, subtract & evtl. shift.<br>> > I would also believe that it would be handy to have such a type <br>> > signed.<br>> > i.e. offset = adress1 - adress2<br>> > <br>> > Naturally such a type will profit from extending its value range <br>> > to the bit size of pointers.<br>> > Up to now converting everything to an int has sufficed. However<br>> > it will no more for a 64bit arch.<br>> > Will we need to convert to a LONGINT then? - but that will be in-<br>> > compatible as LONGINT currently takes the 'l'-suffix and longint<br>> > is not even supported for the 32bit arch as far as I know.<br>> > <br>> > Having an own type for this and other purposes like optimized<br>> > numeric code would to my believe be beneficial.<br>> > Call it OFFSET, TARGETINT, TargetInt.T or Offset.T<br>> > Whether to just support such a type by a Word.T like interface<br>> > or by a built-in type would likely be worth another discussion.<br>> > <br>> > So what for now? As I recall things we have introduced<br>> > a LONGINT which takes the 0l - suffix for AMD64 only.<br>> > <br>> > The first thing would be to introduce a 64bit LONGINT for x86/32bit.<br>> > <br>> > and then?<br>> > TYPE Offset.T = BITS BITSIZE(ADDRESS) FOR LONGINT ?<br>> > <br>> > We will have to rewrite some code that assumed offsets to be<br>> > integers, then. <br>> > <br>> > The other possibility we have would be to make an offset a built-in <br>> > type and assignment compatible to both int and longint which will <br>> > save us from rewriting too much old code. I would claim this not to <br>> > be a too big problem as converting back and forth between an <br>> > OFFSET and an [LONG]INT should rarely happen. It would only<br>> > be used in unsafe interfaces as all address arithmetics <br>> > i.e. we should at least make that require an explicit conversion <br>> > outside of unsafe interfaces. That way all expressions remained<br>> > 100% compatible while only having to declare certain variables<br>> > as OFFSET rather than INTEGER.<br>> > <br>> > <br>> >> <br>> >> Am 22.05.2015 um 19:55 schrieb Rodney M. Bates:<br>> > <br>> >>> The evolving nature of first UCS and then Unicode standards has left<br>> >>> many language designers knocked off balance. Critical Mass first<br>> >>> introduced WIDECHAR as 16-bit when that was what everybody thought<br>> >>> was enough. Then things changed, and it wasn't anymore. Right now,<br>> >>> it's a configuration parameter (must be the same for the entire link<br>> >>> closure) in Modula-3. I personally favor making it full Unicode<br>> >>> by default, in the next release, as this is where the world is now.<br>> >>> This is hopefully a simpler problem than INTEGER, etc., because, as of<br>> >>> now, the Unicode committee has emphatically assured us that the range will<br>> >>> *never* increase. We can hope.<br>> > <br>> > By now I welcome your decision to make the WIDECHAR 32bit!<br>> > I believe it should become the default for the upcoming release.<br>> > Pure Modula-3 code will take advantage of the new value range.<br>> > Just interfacing with certain external toolkits is not enough <br>> > justification to freeze things as they are - interfaces need to be<br>> > adapted anyway while supporting all three types is just too much <br>> > unnecessary work.<br>> > <br></div> </div></body>
</html>