<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
I have to add something. There is another use of LONGINT.<BR>
Kind of an annoying practical one, and a minor side affect. Not really a nice abstract one.<BR>
And in fact, it implies a sort of use of "INT128".<BR>
<BR>
<BR>
To declare opaque data with a particular alignment.<BR>
<BR>
<BR>
To match an external definition.<BR>
Specifically, jmpbuf.<BR>
Many systems want a 64bit aligned jmpbuf.<BR>
Even some 32bit ones. e.g. ALPHA32_VMS. But it isn't the only one.<BR>
<BR>
There are systems that prefer as high as 128 bit aligned jmpbuf, but I think are ok with less aligned (PPC_LINUX), or not (PA64_HPUX?).<BR>
I'm not able to declare these today.<BR>
<BR>
<BR>
And C doesn't do this necessarily with larger types, but with other syntax.<BR>
I think 32bit Linux/ppc says something like:<BR>
<BR>
<BR>
typedef struct __attribute___(align(128)) { /* 32 is ok, but 128 is ideal */<BR> ...<BR>
} jmpbuf;<BR>
<BR>
Ok, details:<BR>
<BR>
Oh. Maybe I should use "double" for this purpose? I did sometimes. I forgot.<BR>
That solves part of the problem, as much as LONGINT solves.<BR>
<BR>
<BR>
<A href="http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA32_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain">http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA32_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain</A><BR>
(* 200 bytes with 8 byte alignment *)<BR>TYPE jmp_buf = ARRAY [0..24] OF double;<BR><BR>
<BR>
<BR>
<A href="http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PPC_LINUX/Csetjmp.i3?rev=1.10;content-type=text%2Fplain">http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PPC_LINUX/Csetjmp.i3?rev=1.10;content-type=text%2Fplain</A><BR>
(* ideal alignment is 16 bytes but 4 is ok; 8 here *)<BR>TYPE jmp_buf = ARRAY [0..73] OF LONGINT;<BR>
<BR>
<BR>
<BR>
<A href="http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA64_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain">http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/C/PA64_HPUX/Csetjmp.i3?rev=1.3;content-type=text%2Fplain</A><BR>
(* 640 bytes with 16 byte alignment if we can get it, else 8 byte alignment,<BR> which is the best we can ask for (front end internally uses 16 byte alignment) *)<BR>TYPE jmp_buf = ARRAY [0..79] OF double;<BR>
<BR> <BR>
I should use double? Or we should have another way to say this?<BR>
Or, for that matter, as I've suggested, we shouldn't duplicate the information both in Csetjmp.i3 and Target.m3? Target.m3 has available to it arbitrary alignment.<BR>
<BR>
<BR>
Ok, PPC_LINUX and PA32/64_HPUX were the only ones I could find that want >4 alignment on 32bit, or >8 on 64bit. And 8 on 32 you can get with double. I had forgotten about that technique.<BR>
<BR>
<BR>
I think this is at least another good argument for removing the type declaration from Csetjmp.i3, maybe the function too, and putting it only in Target.m3 (Target.m3 currently only declares setjmp, not longjmp).<BR>
<BR>
<BR>
If not a way to declare alignment in the language.<BR>
The thing is, you know, the only need for this is to match external/C definitions, and those definitions are now tremendously more under our control than they used to be, so the need to describe "anything" is reduced.<BR>
<BR>
<BR>
Tony is that at all difficult? Injecting the jmpbuf and longjmp information from Target.m3 instead of in Csetjmp.i3? I'll try to get to it. I'd like to further reduce the volume and "wide distribution" of target-specific data. There's still a lot of duplication and non-centralization.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Thu, 22 Apr 2010 10:55:23 -0400<BR>> From: hendrik@topoi.pooq.com<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] INTEGER<BR>> <BR>> On Thu, Apr 22, 2010 at 02:36:17PM -0400, Tony Hosking wrote:<BR>> > Let me see.<BR>> > <BR>> > The green book definition says the base type of a subrange of INTEGER literals is INTEGER.<BR>> > You say that the base type of a subrange of LONGINT literals is LONGINT.<BR>> > But you say that LONGINT is not a defined type. So, what is the type <BR>> > of a LONGINT literal?<BR>> <BR>> (a) 3849587394875493920398438483929293484L could very well be of type <BR>> 3849587394875493920398438483929293484L..3849587394875493920398438483929293484L<BR>> which is a one-element subtype of LONGINT.<BR>> <BR>> LONGINY is a type. It's just one that's not available directly to the <BR>> programmer. It would not need to have a defined size, if the language <BR>> allowed LONGINT values to occur *only* where an upper bound on <BR>> their size is known, such as by being elements of a subrange.<BR>> <BR>> -- hendrik<BR>> <BR>> > <BR>> > [I think I misunderstood you previously. I had interpreted that you meant LONGINT subranges to have base type INTEGER.]<BR>> > <BR>> > On 22 Apr 2010, at 08:38, hendrik@topoi.pooq.com wrote:<BR>> > <BR>> > > On Thu, Apr 22, 2010 at 11:57:16AM -0400, Tony Hosking wrote:<BR>> > >> But this is bizarre. What type does an element of a subrange of <BR>> > >> LONGINT have if not LONGINT?<BR>> > > <BR>> > > It has LONGINT as a type.<BR>> > > <BR>> > >> If the subrange has a base type of INTEGER then we need a mapping <BR>> > >> between the elements of the subrange and the base INTEGER values.<BR>> > > <BR>> > > Yes. And INTEGER is different from the notion mathematicians have of <BR>> > > integers in that there is a limit on the size of integers. It's a <BR>> > > machine or implementation-dependent limit, and it's imposed for <BR>> > > efficiency reasons, but it's a specific limit just the same.<BR>> > > This limit is precisely what we're up against.<BR>> > > <BR>> > >> But then, values of the LONGINT subrange don't have the same <BR>> > >> representation as their INTEGER counterpart.<BR>> > > <BR>> > > Of course not. If they did have the same representation, there would be <BR>> > > in-range for INTEGERs, and there would be no need to have LONGINT at <BR>> > > all.<BR>> > > <BR>> > > LONGINT is there precisely for the integers that *don't* fit in INTEGER.<BR>> > > <BR>> > >> <BR>> > >> All very odd.<BR>> > > <BR>> > > But dictated by the intended use -- that of having integral ranges<BR>> > > whose bounds are dictated by the problem, not the hardware.<BR>> > > <BR>> > > -- hendrik<BR>> > <BR> </body>
</html>