From jay.krell at cornell.edu Mon Feb 1 08:41:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 07:41:04 +0000 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1264972487.4240.4.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: Let's say I have: TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; TYPE FOOA = ARRAY [0..1] OF FOO; And I have a platform with max_align = 32 and a platform with max_align = 64. One platform will make FOOA be 24 bytes, the other 32. One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. Can that pickle be read/written by the two platforms? And how does the code know/detect the difference? That is, if a platform changed from max_align = 32 to 64, would the pickle code work just as well on the "same" platform as on the "different" platforms? I very recently changed NT386 max_align from 32 to 64, and I believe the remaining active platforms with max_align = 32 should also be 64. It would "only" affect pickles with LONGINT or LONGFLOAT, as well as "lining up" such structs with C. Such alignment shold make us not need the extra "unaligned double" switch on most platforms (some mystery still on some platforms) as well as perhaps be needed for some atomic operations, esp. maybe on LONGINT on 32bit x86. - Jay > From: dragisha at m3w.org > To: rodney_bates at lcwb.coop > Date: Sun, 31 Jan 2010 22:14:47 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > I've not changed my code, that is for sure.... But now I am not sure > some parent type (esp MUTEX here an there) was not changed... I'll take > a look on this again sometime soon and report my findings. > > Thanks for clues. > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > Dragi?a Duri? wrote: > > > I've asked this before, but didn't catch answer: > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> I suggest we can probably get by with platform-independent > > >> packing/alignment settings. > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > does not read that pickle anymore.... > > > > And you are certain your program that tries to read still contains > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > Someone remembers moment when this incompatible changes were made? > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 1 09:11:38 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 1 Feb 2010 03:11:38 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> That shouldn't affect things since the pickler picks apart the structures and ships the individual primitives. Right? On 1 Feb 2010, at 02:41, Jay K wrote: > Let's say I have: > > > TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; > TYPE FOOA = ARRAY [0..1] OF FOO; > > > And I have a platform with max_align = 32 and a platform with max_align = 64. > One platform will make FOOA be 24 bytes, the other 32. > One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. > Can that pickle be read/written by the two platforms? > And how does the code know/detect the difference? > That is, if a platform changed from max_align = 32 to 64, would the pickle code work just > as well on the "same" platform as on the "different" platforms? > > > I very recently changed NT386 max_align from 32 to 64, and I believe > the remaining active platforms with max_align = 32 should also be 64. > It would "only" affect pickles with LONGINT or LONGFLOAT, as well > as "lining up" such structs with C. > > > Such alignment shold make us not need the extra "unaligned double" switch > on most platforms (some mystery still on some platforms) as well as > perhaps be needed for some atomic operations, esp. maybe on > LONGINT on 32bit x86. > > > - Jay > > > > From: dragisha at m3w.org > > To: rodney_bates at lcwb.coop > > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] platform-independent packing/alignment? > > > > I've not changed my code, that is for sure.... But now I am not sure > > some parent type (esp MUTEX here an there) was not changed... I'll take > > a look on this again sometime soon and report my findings. > > > > Thanks for clues. > > > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > > > Dragi?a Duri? wrote: > > > > I've asked this before, but didn't catch answer: > > > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > > >> I suggest we can probably get by with platform-independent > > > >> packing/alignment settings. > > > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > > does not read that pickle anymore.... > > > > > > And you are certain your program that tries to read still contains > > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > > > > Someone remembers moment when this incompatible changes were made? > > -- > > Dragi?a Duri? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Feb 1 09:19:06 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 01 Feb 2010 00:19:06 -0800 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> Message-ID: <20100201081906.583961A2099@async.async.caltech.edu> For what it's worth... I recall someone (Dragisa?) just complained that he was having problems unpickling data structures... I have never had much luck pickling and unpickling MUTEXes, using a few (not very different) M3 compilers. I just leave them out of my pickles. It makes the pickles a lot more compatible across versions. I'm not talking recent CM3 versions here but a variety of old versions. Implementors have seemed to modify MUTEX quite a bit. What's the point of pickling it anyhow? If it's an active mutex the unpickling will surely lead to garbage, if there are wait queues and things.. then you wind up un/pickling Thread structures too. Mika Tony Hosking writes: > >--Apple-Mail-4--1058110347 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=utf-8 > >That shouldn't affect things since the pickler picks apart the = >structures and ships the individual primitives. Right? > >On 1 Feb 2010, at 02:41, Jay K wrote: > >> Let's say I have: >> =20 >> =20 >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; >> TYPE FOOA =3D ARRAY [0..1] OF FOO; >> =20 >> =20 >> And I have a platform with max_align =3D 32 and a platform with = >max_align =3D 64. >> One platform will make FOOA be 24 bytes, the other 32. >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = >won't. >> Can that pickle be read/written by the two platforms? >> And how does the code know/detect the difference? >> That is, if a platform changed from max_align =3D 32 to 64, would the = >pickle code work just >> as well on the "same" platform as on the "different" platforms? >> =20 >> =20 >> I very recently changed NT386 max_align from 32 to 64, and I believe >> the remaining active platforms with max_align =3D 32 should also be = >64. >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well >> as "lining up" such structs with C. >> =20 >> =20 >> Such alignment shold make us not need the extra "unaligned double" = >switch >> on most platforms (some mystery still on some platforms) as well as >> perhaps be needed for some atomic operations, esp. maybe on >> LONGINT on 32bit x86. >> =20 >> =20 >> - Jay >>=20 >> =20 >> > From: dragisha at m3w.org >> > To: rodney_bates at lcwb.coop >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] platform-independent packing/alignment? >> >=20 >> > I've not changed my code, that is for sure.... But now I am not sure >> > some parent type (esp MUTEX here an there) was not changed... I'll = >take >> > a look on this again sometime soon and report my findings. >> >=20 >> > Thanks for clues. >> >=20 >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: >> > >=20 >> > > Dragi=C5=A1a Duri=C4=87 wrote: >> > > > I've asked this before, but didn't catch answer: >> > > >=20 >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: >> > > >> I suggest we can probably get by with platform-independent >> > > >> packing/alignment settings. >> > > >=20 >> > > > Some time ago I've used pickles (CM3) to save some data... My = >program >> > > > does not read that pickle anymore....=20 >> > >=20 >> > > And you are certain your program that tries to read still contains >> > > exact structurally equivalent types to all the types in the = >pickle? >> > >=20 >> > > >=20 >> > > > Someone remembers moment when this incompatible changes were = >made?=20 >> > --=20 >> > Dragi=C5=A1a Duri=C4=87 >> >=20 > > >--Apple-Mail-4--1058110347 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=utf-8 > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >after-white-space; ">That shouldn't affect things since the pickler = >picks apart the structures and ships the individual primitives. = > Right?
>
On 1 Feb 2010, at 02:41, Jay K wrote:

class=3D"Apple-interchange-newline">
class=3D"Apple-style-span" style=3D"border-collapse: separate; = >font-family: Helvetica; font-size: medium; font-style: normal; = >font-variant: normal; font-weight: normal; letter-spacing: normal; = >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; ">
style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = >FOO;
 
 
And I have a platform with max_align = >=3D 32 and a platform with max_align =3D 64.
One platform will = >make FOOA be 24 bytes, the other 32.
  One platform will = >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = >pickle be read/written by the two platforms?
And how does the code = >know/detect the difference?
That is, if a platform changed from = >max_align =3D 32 to 64, would the pickle code work just
as = >well on the "same" platform as on the "different" = >platforms?
 
 
I very recently changed NT386 = >max_align from 32 to 64, and I believe
the remaining active platforms = >with max_align =3D 32 should also be 64.
It would "only" affect = >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = >structs with C.
 
 
Such alignment shold make us not = >need the extra "unaligned double" switch
on most platforms (some = >mystery still on some platforms) as well as
perhaps be needed for = >some atomic operations, esp. maybe on
LONGINT on 32bit = >x86.
 
 
 - Jay

 
> From:class=3D"Apple-converted-space"> href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To:class=3D"Apple-converted-space"> href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC:class=3D"Apple-converted-space"> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = >Subject: Re: [M3devel] platform-independent = >packing/alignment?
>class=3D"Apple-converted-space"> 
> I've not changed = >my code, that is for sure.... But now I am not sure
> some parent = >type (esp MUTEX here an there) was not changed... I'll take
> a = >look on this again sometime soon and report my findings.
>class=3D"Apple-converted-space"> 
> Thanks for = >clues.
> 
> = >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = >> 
> > = >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = >but didn't catch answer:
> > >class=3D"Apple-converted-space"> 
> > > On Sun, = >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = >we can probably get by with platform-independent
> > >> = >packing/alignment settings.
> > >class=3D"Apple-converted-space"> 
> > > Some = >time ago I've used pickles (CM3) to save some data... My program
> = >> > does not read that pickle anymore....class=3D"Apple-converted-space"> 
> >class=3D"Apple-converted-space"> 
> > And you are = >certain your program that tries to read still contains
> > = >exact structurally equivalent types to all the types in the = >pickle?
> >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > > Someone = >remembers moment when this incompatible changes were made?class=3D"Apple-converted-space"> 
> --class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = >Duri=C4=87 <href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
>class=3D"Apple-converted-space"> 
>

= > >--Apple-Mail-4--1058110347-- From dragisha at m3w.org Mon Feb 1 09:41:48 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 01 Feb 2010 09:41:48 +0100 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <20100201081906.583961A2099@async.async.caltech.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> Message-ID: <1265013708.4240.16.camel@faramir.m3w.org> MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that code being same even if changes were made to it's basic structure... Or not... On the second thought, MUTEX is basically fixed, but it's revealations can vary. Thus making it incompatible over pickles/versions. I've not looked at my code/data yet, but MUTEX was only an idea what went... It is OODBMS package, and mutex is not used for persistent data, only for tables/indexes. Thus, problem (at leat for me) remains and it is not pickled MUTEX. On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/plain; > > charset=utf-8 > > > >That shouldn't affect things since the pickler picks apart the = > >structures and ships the individual primitives. Right? > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > >> Let's say I have: > >> =20 > >> =20 > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > >> =20 > >> =20 > >> And I have a platform with max_align =3D 32 and a platform with = > >max_align =3D 64. > >> One platform will make FOOA be 24 bytes, the other 32. > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > >won't. > >> Can that pickle be read/written by the two platforms? > >> And how does the code know/detect the difference? > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > >pickle code work just > >> as well on the "same" platform as on the "different" platforms? > >> =20 > >> =20 > >> I very recently changed NT386 max_align from 32 to 64, and I believe > >> the remaining active platforms with max_align =3D 32 should also be = > >64. > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > >> as "lining up" such structs with C. > >> =20 > >> =20 > >> Such alignment shold make us not need the extra "unaligned double" = > >switch > >> on most platforms (some mystery still on some platforms) as well as > >> perhaps be needed for some atomic operations, esp. maybe on > >> LONGINT on 32bit x86. > >> =20 > >> =20 > >> - Jay > >>=20 > >> =20 > >> > From: dragisha at m3w.org > >> > To: rodney_bates at lcwb.coop > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > >> >=20 > >> > I've not changed my code, that is for sure.... But now I am not sure > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > >take > >> > a look on this again sometime soon and report my findings. > >> >=20 > >> > Thanks for clues. > >> >=20 > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > >> > >=20 > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > >> > > > I've asked this before, but didn't catch answer: > >> > > >=20 > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > >> > > >> I suggest we can probably get by with platform-independent > >> > > >> packing/alignment settings. > >> > > >=20 > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > >program > >> > > > does not read that pickle anymore....=20 > >> > >=20 > >> > > And you are certain your program that tries to read still contains > >> > > exact structurally equivalent types to all the types in the = > >pickle? > >> > >=20 > >> > > >=20 > >> > > > Someone remembers moment when this incompatible changes were = > >made?=20 > >> > --=20 > >> > Dragi=C5=A1a Duri=C4=87 > >> >=20 > > > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/html; > > charset=utf-8 > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > >after-white-space; ">That shouldn't affect things since the pickler = > >picks apart the structures and ships the individual primitives. = > > Right?
> >
On 1 Feb 2010, at 02:41, Jay K wrote:

>class=3D"Apple-interchange-newline">
>class=3D"Apple-style-span" style=3D"border-collapse: separate; = > >font-family: Helvetica; font-size: medium; font-style: normal; = > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > >white-space: normal; widows: 2; word-spacing: 0px; = > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > >auto; -webkit-text-stroke-width: 0px; ">
>style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > >FOO;
 
 
And I have a platform with max_align = > >=3D 32 and a platform with max_align =3D 64.
One platform will = > >make FOOA be 24 bytes, the other 32.
  One platform will = > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > >pickle be read/written by the two platforms?
And how does the code = > >know/detect the difference?
That is, if a platform changed from = > >max_align =3D 32 to 64, would the pickle code work just
as = > >well on the "same" platform as on the "different" = > >platforms?
 
 
I very recently changed NT386 = > >max_align from 32 to 64, and I believe
the remaining active platforms = > >with max_align =3D 32 should also be 64.
It would "only" affect = > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > >structs with C.
 
 
Such alignment shold make us not = > >need the extra "unaligned double" switch
on most platforms (some = > >mystery still on some platforms) as well as
perhaps be needed for = > >some atomic operations, esp. maybe on
LONGINT on 32bit = > >x86.
 
 
 - Jay

 
> From: >class=3D"Apple-converted-space">  >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: >class=3D"Apple-converted-space">  >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: >class=3D"Apple-converted-space">  >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > >Subject: Re: [M3devel] platform-independent = > >packing/alignment?
> >class=3D"Apple-converted-space"> 
> I've not changed = > >my code, that is for sure.... But now I am not sure
> some parent = > >type (esp MUTEX here an there) was not changed... I'll take
> a = > >look on this again sometime soon and report my findings.
> >class=3D"Apple-converted-space"> 
> Thanks for = > >clues.
> 
> = > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > >> 
> > = > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > >but didn't catch answer:
> > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > >we can probably get by with platform-independent
> > >> = > >packing/alignment settings.
> > > >class=3D"Apple-converted-space"> 
> > > Some = > >time ago I've used pickles (CM3) to save some data... My program
> = > >> > does not read that pickle anymore.... >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > And you are = > >certain your program that tries to read still contains
> > = > >exact structurally equivalent types to all the types in the = > >pickle?
> > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > > Someone = > >remembers moment when this incompatible changes were made? >class=3D"Apple-converted-space"> 
> -- >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > >Duri=C4=87 < >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> >class=3D"Apple-converted-space"> 
 >>

= > > > >--Apple-Mail-4--1058110347-- -- Dragi?a Duri? From wagner at elegosoft.com Mon Feb 1 11:52:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 11:52:15 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org> Message-ID: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Quoting Tony Hosking : > Surely we are close. What stability issues are there on the release branch? Jay seems to have been hardworking to bring the release branch up-to-date. The last changes are about a week old now though. See FreeBSD or any other target for a list: http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes On this platform CVSup, db, odbc and m3gdb are still failing/missing: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ CVSup also fails on Linux, 32 and 64 bit: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ Windows shows even more test failures: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ Solaris seems to have some severe problems: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ Darwin, PPC_Linux and OPENBSD haven't been built/tested for month (no servers available) as has FreeBSD4 (I still want to set that up again on one of our machines, but didn't get round till now). So I'd say there's still a lot of tedious work before we can schedule another release package build. Anybody able and willing to fix some of the problems reported above is encouraged to do so. Olaf > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > >> I don't want to be a buzz kill, but it's almost February 2010, and >> 5.8 stable is still not out. Are there still any issues left? >> Anything that can be ignored until after release? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 12:37:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 11:37:39 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: I hadn't looked and hadn't realized. I'll look. I thought things were as about up to date as they would get (no LONGINT on NT386, no Atomic, but "revised LONGINT" on others -- m3front matching current, at least before more atomic changes). There is the cvsup problem I was ignoring. The bug report was good but didn't have e.g. the cvsup file. I'll look at these things. Fwiw, Modula-3 has really been quite stable for like 15 years now, very few changes (too few), very few regressions, but definitely some. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 1 13:13:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 12:13:57 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , , , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com>, Message-ID: The NT386 problems are "path related" and trying to do anything with postgres. I'm look at the others. FreeBSD I would suspect is missing some odbc packages but haven't really looked. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Mon, 1 Feb 2010 11:37:39 +0000 Subject: Re: [M3devel] 5.8 Release? I hadn't looked and hadn't realized. I'll look. I thought things were as about up to date as they would get (no LONGINT on NT386, no Atomic, but "revised LONGINT" on others -- m3front matching current, at least before more atomic changes). There is the cvsup problem I was ignoring. The bug report was good but didn't have e.g. the cvsup file. I'll look at these things. Fwiw, Modula-3 has really been quite stable for like 15 years now, very few changes (too few), very few regressions, but definitely some. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 1 15:54:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 14:54:06 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar to LINUXLIBC, SOLgnu/SOLsun. PPC_DARWIN I can make available too. I'm also still planning on making several more available. Some are already running. Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 1 16:40:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 16:40:23 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: <20100201164023.6vbecip2fwwk0g0c@mail.elegosoft.com> Quoting Jay K : > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > to LINUXLIBC, SOLgnu/SOLsun. > > PPC_DARWIN I can make available too. > > I'm also still planning on making several more available. > > Some are already running. I just reported the status from Hudson. I haven't done anything there recently, so no idea why tests don't run if the servers are available. > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. Only if he allows ssh access from birch.elegosoft.com. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 1 19:23:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 19:23:22 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> Recent commits seem to have made matters worse: http://hudson.modula3.com:8080/ And PPC_DARWIN should now be back online. Olaf Quoting Jay K : > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > to LINUXLIBC, SOLgnu/SOLsun. > > PPC_DARWIN I can make available too. > > I'm also still planning on making several more available. > > Some are already running. > > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. > > - Jay > >> Date: Mon, 1 Feb 2010 11:52:15 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] 5.8 Release? >> >> Quoting Tony Hosking : >> >> > Surely we are close. What stability issues are there on the >> release branch? >> >> Jay seems to have been hardworking to bring the release branch up-to-date. >> The last changes are about a week old now though. See FreeBSD or any other >> target for a list: >> >> >> http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes >> >> On this platform CVSup, db, odbc and m3gdb are still failing/missing: >> >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ >> >> CVSup also fails on Linux, 32 and 64 bit: >> >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ >> >> Windows shows even more test failures: >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ >> >> Solaris seems to have some severe problems: >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ >> >> Darwin, PPC_Linux and OPENBSD haven't been built/tested for month >> (no servers available) as has FreeBSD4 (I still want to set that up again >> on one of our machines, but didn't get round till now). >> >> So I'd say there's still a lot of tedious work before we can schedule >> another release package build. >> >> Anybody able and willing to fix some of the problems reported above >> is encouraged to do so. >> >> Olaf >> >> > Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> > 305 N. University Street | West Lafayette | IN 47907 | USA >> > Office +1 765 494 6001 | Mobile +1 765 427 5484 >> > >> > On 30 Jan 2010, at 19:19, Martin Bishop wrote: >> > >> >> I don't want to be a buzz kill, but it's almost February 2010, and >> >> 5.8 stable is still not out. Are there still any issues left? >> >> Anything that can be ignored until after release? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 20:30:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 19:30:36 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com>, , <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> Message-ID: Sorry, those should already be fixed. - Jay > Date: Mon, 1 Feb 2010 19:23:22 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] 5.8 Release? > > Recent commits seem to have made matters worse: > > http://hudson.modula3.com:8080/ > > > And PPC_DARWIN should now be back online. > > Olaf > > Quoting Jay K : > > > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > > to LINUXLIBC, SOLgnu/SOLsun. > > > > PPC_DARWIN I can make available too. > > > > I'm also still planning on making several more available. > > > > Some are already running. > > > > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. > > > > - Jay > > > >> Date: Mon, 1 Feb 2010 11:52:15 +0100 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] 5.8 Release? > >> > >> Quoting Tony Hosking : > >> > >> > Surely we are close. What stability issues are there on the > >> release branch? > >> > >> Jay seems to have been hardworking to bring the release branch up-to-date. > >> The last changes are about a week old now though. See FreeBSD or any other > >> target for a list: > >> > >> > >> http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > >> > >> On this platform CVSup, db, odbc and m3gdb are still failing/missing: > >> > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > >> > >> CVSup also fails on Linux, 32 and 64 bit: > >> > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > >> > >> Windows shows even more test failures: > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > >> > >> Solaris seems to have some severe problems: > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > >> > >> Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > >> (no servers available) as has FreeBSD4 (I still want to set that up again > >> on one of our machines, but didn't get round till now). > >> > >> So I'd say there's still a lot of tedious work before we can schedule > >> another release package build. > >> > >> Anybody able and willing to fix some of the problems reported above > >> is encouraged to do so. > >> > >> Olaf > >> > >> > Antony Hosking | Associate Professor | Computer Science | Purdue > >> University > >> > 305 N. University Street | West Lafayette | IN 47907 | USA > >> > Office +1 765 494 6001 | Mobile +1 765 427 5484 > >> > > >> > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > >> > > >> >> I don't want to be a buzz kill, but it's almost February 2010, and > >> >> 5.8 stable is still not out. Are there still any issues left? > >> >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Feb 1 20:37:48 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 1 Feb 2010 14:37:48 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1265013708.4240.16.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> <1265013708.4240.16.camel@faramir.m3w.org> Message-ID: For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. Regards, Randy Coleburn -----Original Message----- From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Monday, February 01, 2010 3:42 AM To: Mika Nystrom Cc: m3devel at elegosoft.com Subject: Re: [M3devel] platform-independent packing/alignment? MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that code being same even if changes were made to it's basic structure... Or not... On the second thought, MUTEX is basically fixed, but it's revealations can vary. Thus making it incompatible over pickles/versions. I've not looked at my code/data yet, but MUTEX was only an idea what went... It is OODBMS package, and mutex is not used for persistent data, only for tables/indexes. Thus, problem (at leat for me) remains and it is not pickled MUTEX. On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/plain; > > charset=utf-8 > > > >That shouldn't affect things since the pickler picks apart the = > >structures and ships the individual primitives. Right? > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > >> Let's say I have: > >> =20 > >> =20 > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > >> =20 > >> =20 > >> And I have a platform with max_align =3D 32 and a platform with = > >max_align =3D 64. > >> One platform will make FOOA be 24 bytes, the other 32. > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > >won't. > >> Can that pickle be read/written by the two platforms? > >> And how does the code know/detect the difference? > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > >pickle code work just > >> as well on the "same" platform as on the "different" platforms? > >> =20 > >> =20 > >> I very recently changed NT386 max_align from 32 to 64, and I believe > >> the remaining active platforms with max_align =3D 32 should also be = > >64. > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > >> as "lining up" such structs with C. > >> =20 > >> =20 > >> Such alignment shold make us not need the extra "unaligned double" = > >switch > >> on most platforms (some mystery still on some platforms) as well as > >> perhaps be needed for some atomic operations, esp. maybe on > >> LONGINT on 32bit x86. > >> =20 > >> =20 > >> - Jay > >>=20 > >> =20 > >> > From: dragisha at m3w.org > >> > To: rodney_bates at lcwb.coop > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > >> >=20 > >> > I've not changed my code, that is for sure.... But now I am not sure > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > >take > >> > a look on this again sometime soon and report my findings. > >> >=20 > >> > Thanks for clues. > >> >=20 > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > >> > >=20 > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > >> > > > I've asked this before, but didn't catch answer: > >> > > >=20 > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > >> > > >> I suggest we can probably get by with platform-independent > >> > > >> packing/alignment settings. > >> > > >=20 > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > >program > >> > > > does not read that pickle anymore....=20 > >> > >=20 > >> > > And you are certain your program that tries to read still contains > >> > > exact structurally equivalent types to all the types in the = > >pickle? > >> > >=20 > >> > > >=20 > >> > > > Someone remembers moment when this incompatible changes were = > >made?=20 > >> > --=20 > >> > Dragi=C5=A1a Duri=C4=87 > >> >=20 > > > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/html; > > charset=utf-8 > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > >after-white-space; ">That shouldn't affect things since the pickler = > >picks apart the structures and ships the individual primitives. = > > Right?
> >
On 1 Feb 2010, at 02:41, Jay K wrote:

>class=3D"Apple-interchange-newline">
>class=3D"Apple-style-span" style=3D"border-collapse: separate; = > >font-family: Helvetica; font-size: medium; font-style: normal; = > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > >white-space: normal; widows: 2; word-spacing: 0px; = > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > >auto; -webkit-text-stroke-width: 0px; ">
>style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > >FOO;
 
 
And I have a platform with max_align = > >=3D 32 and a platform with max_align =3D 64.
One platform will = > >make FOOA be 24 bytes, the other 32.
  One platform will = > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > >pickle be read/written by the two platforms?
And how does the code = > >know/detect the difference?
That is, if a platform changed from = > >max_align =3D 32 to 64, would the pickle code work just
as = > >well on the "same" platform as on the "different" = > >platforms?
 
 
I very recently changed NT386 = > >max_align from 32 to 64, and I believe
the remaining active platforms = > >with max_align =3D 32 should also be 64.
It would "only" affect = > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > >structs with C.
 
 
Such alignment shold make us not = > >need the extra "unaligned double" switch
on most platforms (some = > >mystery still on some platforms) as well as
perhaps be needed for = > >some atomic operations, esp. maybe on
LONGINT on 32bit = > >x86.
 
 
 - Jay

 
> From: >class=3D"Apple-converted-space">  >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: >class=3D"Apple-converted-space">  >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: >class=3D"Apple-converted-space">  >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > >Subject: Re: [M3devel] platform-independent = > >packing/alignment?
> >class=3D"Apple-converted-space"> 
> I've not changed = > >my code, that is for sure.... But now I am not sure
> some parent = > >type (esp MUTEX here an there) was not changed... I'll take
> a = > >look on this again sometime soon and report my findings.
> >class=3D"Apple-converted-space"> 
> Thanks for = > >clues.
> 
> = > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > >> 
> > = > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > >but didn't catch answer:
> > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > >we can probably get by with platform-independent
> > >> = > >packing/alignment settings.
> > > >class=3D"Apple-converted-space"> 
> > > Some = > >time ago I've used pickles (CM3) to save some data... My program
> = > >> > does not read that pickle anymore.... >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > And you are = > >certain your program that tries to read still contains
> > = > >exact structurally equivalent types to all the types in the = > >pickle?
> > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > > Someone = > >remembers moment when this incompatible changes were made? >class=3D"Apple-converted-space"> 
> -- >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > >Duri=C4=87 < >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> >class=3D"Apple-converted-space"> 
 >>

= > > > >--Apple-Mail-4--1058110347-- -- Dragi?a Duri? From jay.krell at cornell.edu Mon Feb 1 20:46:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 19:46:38 +0000 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , , <1264972487.4240.4.camel@faramir.m3w.org>, , <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu>, <20100201081906.583961A2099@async.async.caltech.edu>, <1265013708.4240.16.camel@faramir.m3w.org>, Message-ID: You *might* imagine pickling a mutex, held or not, like to "freeze"/"suspend" a running system, possibly to move to another system, where it is "resumed". But in reality, that won't work. If changing alignment/padding won't break pickles, I again suggest that "max_align" be raised to at least 64 for all architectures. So that double and longint are aligned. Or that max_align be thrown out entirely and have the architectures all declare things correctly..which they likely already are. > recreates the MUTEX in the environment of the reading program Just with "NEW(MUTEX)" right? No attempt to put it back in the same state, I assume. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Mon, 1 Feb 2010 14:37:48 -0500 > Subject: Re: [M3devel] platform-independent packing/alignment? > > For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Monday, February 01, 2010 3:42 AM > To: Mika Nystrom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > > On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > > For what it's worth... > > > > I recall someone (Dragisa?) just complained that he was having problems > > unpickling data structures... > > > > I have never had much luck pickling and unpickling MUTEXes, using a few > > (not very different) M3 compilers. I just leave them out of my pickles. > > It makes the pickles a lot more compatible across versions. I'm not > > talking recent CM3 versions here but a variety of old versions. > > Implementors have seemed to modify MUTEX quite a bit. What's the point > > of pickling it anyhow? If it's an active mutex the unpickling will > > surely lead to garbage, if there are wait queues and things.. then you > > wind up un/pickling Thread structures too. > > > > Mika > > > > Tony Hosking writes: > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/plain; > > > charset=utf-8 > > > > > >That shouldn't affect things since the pickler picks apart the = > > >structures and ships the individual primitives. Right? > > > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > > > >> Let's say I have: > > >> =20 > > >> =20 > > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > > >> =20 > > >> =20 > > >> And I have a platform with max_align =3D 32 and a platform with = > > >max_align =3D 64. > > >> One platform will make FOOA be 24 bytes, the other 32. > > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > > >won't. > > >> Can that pickle be read/written by the two platforms? > > >> And how does the code know/detect the difference? > > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > > >pickle code work just > > >> as well on the "same" platform as on the "different" platforms? > > >> =20 > > >> =20 > > >> I very recently changed NT386 max_align from 32 to 64, and I believe > > >> the remaining active platforms with max_align =3D 32 should also be = > > >64. > > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > > >> as "lining up" such structs with C. > > >> =20 > > >> =20 > > >> Such alignment shold make us not need the extra "unaligned double" = > > >switch > > >> on most platforms (some mystery still on some platforms) as well as > > >> perhaps be needed for some atomic operations, esp. maybe on > > >> LONGINT on 32bit x86. > > >> =20 > > >> =20 > > >> - Jay > > >>=20 > > >> =20 > > >> > From: dragisha at m3w.org > > >> > To: rodney_bates at lcwb.coop > > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > > >> >=20 > > >> > I've not changed my code, that is for sure.... But now I am not sure > > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > > >take > > >> > a look on this again sometime soon and report my findings. > > >> >=20 > > >> > Thanks for clues. > > >> >=20 > > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > >> > >=20 > > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > > >> > > > I've asked this before, but didn't catch answer: > > >> > > >=20 > > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> > > >> I suggest we can probably get by with platform-independent > > >> > > >> packing/alignment settings. > > >> > > >=20 > > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > > >program > > >> > > > does not read that pickle anymore....=20 > > >> > >=20 > > >> > > And you are certain your program that tries to read still contains > > >> > > exact structurally equivalent types to all the types in the = > > >pickle? > > >> > >=20 > > >> > > >=20 > > >> > > > Someone remembers moment when this incompatible changes were = > > >made?=20 > > >> > --=20 > > >> > Dragi=C5=A1a Duri=C4=87 > > >> >=20 > > > > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/html; > > > charset=utf-8 > > > > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > > >after-white-space; ">That shouldn't affect things since the pickler = > > >picks apart the structures and ships the individual primitives. = > > > Right?
> > >
On 1 Feb 2010, at 02:41, Jay K wrote:

> >class=3D"Apple-interchange-newline">
> >class=3D"Apple-style-span" style=3D"border-collapse: separate; = > > >font-family: Helvetica; font-size: medium; font-style: normal; = > > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > > >white-space: normal; widows: 2; word-spacing: 0px; = > > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > > >auto; -webkit-text-stroke-width: 0px; ">
> >style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > > >FOO;
 
 
And I have a platform with max_align = > > >=3D 32 and a platform with max_align =3D 64.
One platform will = > > >make FOOA be 24 bytes, the other 32.
  One platform will = > > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > > >pickle be read/written by the two platforms?
And how does the code = > > >know/detect the difference?
That is, if a platform changed from = > > >max_align =3D 32 to 64, would the pickle code work just
as = > > >well on the "same" platform as on the "different" = > > >platforms?
 
 
I very recently changed NT386 = > > >max_align from 32 to 64, and I believe
the remaining active platforms = > > >with max_align =3D 32 should also be 64.
It would "only" affect = > > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > > >structs with C.
 
 
Such alignment shold make us not = > > >need the extra "unaligned double" switch
on most platforms (some = > > >mystery still on some platforms) as well as
perhaps be needed for = > > >some atomic operations, esp. maybe on
LONGINT on 32bit = > > >x86.
 
 
 - Jay

 
> From: > >class=3D"Apple-converted-space">  > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: > >class=3D"Apple-converted-space">  > >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: > >class=3D"Apple-converted-space">  > >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > > >Subject: Re: [M3devel] platform-independent = > > >packing/alignment?
> > >class=3D"Apple-converted-space"> 
> I've not changed = > > >my code, that is for sure.... But now I am not sure
> some parent = > > >type (esp MUTEX here an there) was not changed... I'll take
> a = > > >look on this again sometime soon and report my findings.
> > >class=3D"Apple-converted-space"> 
> Thanks for = > > >clues.
> 
> = > > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > > >> 
> > = > > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > > >but didn't catch answer:
> > > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > > >we can probably get by with platform-independent
> > >> = > > >packing/alignment settings.
> > > > >class=3D"Apple-converted-space"> 
> > > Some = > > >time ago I've used pickles (CM3) to save some data... My program
> = > > >> > does not read that pickle anymore.... > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > And you are = > > >certain your program that tries to read still contains
> > = > > >exact structurally equivalent types to all the types in the = > > >pickle?
> > > >class=3D"Apple-converted-space"> 
> > > > >class=3D"Apple-converted-space"> 
> > > Someone = > > >remembers moment when this incompatible changes were made? > >class=3D"Apple-converted-space"> 
> -- > >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > > >Duri=C4=87 < > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> > >class=3D"Apple-converted-space"> 
 > >>

= > > > > > >--Apple-Mail-4--1058110347-- > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 1 20:52:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 13:52:55 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: <4B673117.5060105@lcwb.coop> Jay K wrote: > Let's say I have: > > > TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; > TYPE FOOA = ARRAY [0..1] OF FOO; > > > And I have a platform with max_align = 32 and a platform with max_align > = 64. > One platform will make FOOA be 24 bytes, the other 32. > One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. > Can that pickle be read/written by the two platforms? > And how does the code know/detect the difference? > That is, if a platform changed from max_align = 32 to 64, would the > pickle code work just > as well on the "same" platform as on the "different" platforms? > Yes, this will work fine. The header of the pickle file has a compact binary encoding of a copy of the RTPacking.T value for the target where the pickle was written. This contains target characteristics like max_align. Reading a pickle compares the RTPacking.T value of the reading machine with that in the pickle header and reconstructs the layout on both machines, then does any necessary conversion. > > I very recently changed NT386 max_align from 32 to 64, and I believe > the remaining active platforms with max_align = 32 should also be 64. > It would "only" affect pickles with LONGINT or LONGFLOAT, as well > as "lining up" such structs with C. > > > Such alignment shold make us not need the extra "unaligned double" switch > on most platforms (some mystery still on some platforms) as well as > perhaps be needed for some atomic operations, esp. maybe on > LONGINT on 32bit x86. > > > - Jay > > > > From: dragisha at m3w.org > > To: rodney_bates at lcwb.coop > > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] platform-independent packing/alignment? > > > > I've not changed my code, that is for sure.... But now I am not sure > > some parent type (esp MUTEX here an there) was not changed... I'll take > > a look on this again sometime soon and report my findings. > > > > Thanks for clues. > > > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > > > Dragi?a Duri? wrote: > > > > I've asked this before, but didn't catch answer: > > > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > > >> I suggest we can probably get by with platform-independent > > > >> packing/alignment settings. > > > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > > does not read that pickle anymore.... > > > > > > And you are certain your program that tries to read still contains > > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > > > > Someone remembers moment when this incompatible changes were made? > > -- > > Dragi?a Duri? > > From rodney_bates at lcwb.coop Mon Feb 1 21:00:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 14:00:51 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <20100201081906.583961A2099@async.async.caltech.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> Message-ID: <4B6732F3.4020601@lcwb.coop> I too have had trouble pickling MUTEXs or subtypes thereof, even when writing and reading on the same target. I think it was some runaway recursion in pickle code, maybe even while writing. I just worked around it by eliminating the MUTEXs from the pickle. But eventually, somebody may want to pickle an elaborate subtype of MUTEX and find it hard to separate them, so we should someday fix this. Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > From rcolebur at SCIRES.COM Mon Feb 1 21:02:49 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 1 Feb 2010 15:02:49 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , , <1264972487.4240.4.camel@faramir.m3w.org>, , <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu>, <20100201081906.583961A2099@async.async.caltech.edu>, <1265013708.4240.16.camel@faramir.m3w.org>, Message-ID: Right, you can't put it back in the same state; you just create a new one. Here is an example showing a case where I had a field named "PrivateMutex" that was embedded in an object that needed to be pickled. TYPE PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; (*|***********************************************************************************) (* Pickle Procedures *) (*|***********************************************************************************) TYPE Special = Pickle.Special OBJECT OVERRIDES write := WriteSpecial; read := ReadSpecial; END; (* Special *) PROCEDURE WriteSpecial (self: Special; <*UNUSED*>ref: REFANY; <*UNUSED*>writer: Pickle.Writer ) RAISES {Pickle.Error, <*NOWARN*>Wr.Failure, Thread.Alerted} = (* Special pickle writer for LiteConfig.PrivateMutex objects. *) BEGIN (* WriteSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN (* omit writing the mutex field *) ELSE RAISE Pickle.Error("LiteConfig.WriteSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END WriteSpecial; PROCEDURE ReadSpecial (self: Special; reader: Pickle.Reader; id: Pickle.RefID ): REFANY RAISES {Pickle.Error, <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = (* Special pickle reader for LiteConfig.PrivateMutex objects. *) BEGIN (* ReadSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN WITH m = NEW(PrivateMutex) DO reader.noteRef(m, id); RETURN m; END; (* with *) ELSE RAISE Pickle.Error("LiteConfig.ReadSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END ReadSpecial; BEGIN (* LiteConfig *) Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); END LiteConfig. From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, February 01, 2010 2:47 PM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] platform-independent packing/alignment? You *might* imagine pickling a mutex, held or not, like to "freeze"/"suspend" a running system, possibly to move to another system, where it is "resumed". But in reality, that won't work. If changing alignment/padding won't break pickles, I again suggest that "max_align" be raised to at least 64 for all architectures. So that double and longint are aligned. Or that max_align be thrown out entirely and have the architectures all declare things correctly..which they likely already are. > recreates the MUTEX in the environment of the reading program Just with "NEW(MUTEX)" right? No attempt to put it back in the same state, I assume. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Mon, 1 Feb 2010 14:37:48 -0500 > Subject: Re: [M3devel] platform-independent packing/alignment? > > For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Monday, February 01, 2010 3:42 AM > To: Mika Nystrom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > > On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > > For what it's worth... > > > > I recall someone (Dragisa?) just complained that he was having problems > > unpickling data structures... > > > > I have never had much luck pickling and unpickling MUTEXes, using a few > > (not very different) M3 compilers. I just leave them out of my pickles. > > It makes the pickles a lot more compatible across versions. I'm not > > talking recent CM3 versions here but a variety of old versions. > > Implementors have seemed to modify MUTEX quite a bit. What's the point > > of pickling it anyhow? If it's an active mutex the unpickling will > > surely lead to garbage, if there are wait queues and things.. then you > > wind up un/pickling Thread structures too. > > > > Mika > > > > Tony Hosking writes: > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/plain; > > > charset=utf-8 > > > > > >That shouldn't affect things since the pickler picks apart the = > > >structures and ships the individual primitives. Right? > > > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > > > >> Let's say I have: > > >> =20 > > >> =20 > > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > > >> =20 > > >> =20 > > >> And I have a platform with max_align =3D 32 and a platform with = > > >max_align =3D 64. > > >> One platform will make FOOA be 24 bytes, the other 32. > > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > > >won't. > > >> Can that pickle be read/written by the two platforms? > > >> And how does the code know/detect the difference? > > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > > >pickle code work just > > >> as well on the "same" platform as on the "different" platforms? > > >> =20 > > >> =20 > > >> I very recently changed NT386 max_align from 32 to 64, and I believe > > >> the remaining active platforms with max_align =3D 32 should also be = > > >64. > > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > > >> as "lining up" such structs with C. > > >> =20 > > >> =20 > > >> Such alignment shold make us not need the extra "unaligned double" = > > >switch > > >> on most platforms (some mystery still on some platforms) as well as > > >> perhaps be needed for some atomic operations, esp. maybe on > > >> LONGINT on 32bit x86. > > >> =20 > > >> =20 > > >> - Jay > > >>=20 > > >> =20 > > >> > From: dragisha at m3w.org > > >> > To: rodney_bates at lcwb.coop > > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > > >> >=20 > > >> > I've not changed my code, that is for sure.... But now I am not sure > > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > > >take > > >> > a look on this again sometime soon and report my findings. > > >> >=20 > > >> > Thanks for clues. > > >> >=20 > > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > >> > >=20 > > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > > >> > > > I've asked this before, but didn't catch answer: > > >> > > >=20 > > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> > > >> I suggest we can probably get by with platform-independent > > >> > > >> packing/alignment settings. > > >> > > >=20 > > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > > >program > > >> > > > does not read that pickle anymore....=20 > > >> > >=20 > > >> > > And you are certain your program that tries to read still contains > > >> > > exact structurally equivalent types to all the types in the = > > >pickle? > > >> > >=20 > > >> > > >=20 > > >> > > > Someone remembers moment when this incompatible changes were = > > >made?=20 > > >> > --=20 > > >> > Dragi=C5=A1a Duri=C4=87 > > >> >=20 > > > > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/html; > > > charset=utf-8 > > > > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > > >after-white-space; ">That shouldn't affect things since the pickler = > > >picks apart the structures and ships the individual primitives. = > > > Right?
> > >
On 1 Feb 2010, at 02:41, Jay K wrote:

> >class=3D"Apple-interchange-newline">
> >class=3D"Apple-style-span" style=3D"border-collapse: separate; = > > >font-family: Helvetica; font-size: medium; font-style: normal; = > > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > > >white-space: normal; widows: 2; word-spacing: 0px; = > > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > > >auto; -webkit-text-stroke-width: 0px; ">
> >style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > > >FOO;
 
 
And I have a platform with max_align = > > >=3D 32 and a platform with max_align =3D 64.
One platform will = > > >make FOOA be 24 bytes, the other 32.
  One platform will = > > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > > >pickle be read/written by the two platforms?
And how does the code = > > >know/detect the difference?
That is, if a platform changed from = > > >max_align =3D 32 to 64, would the pickle code work just
as = > > >well on the "same" platform as on the "different" = > > >platforms?
 
 
I very recently changed NT386 = > > >max_align from 32 to 64, and I believe
the remaining active platforms = > > >with max_align =3D 32 should also be 64.
It would "only" affect = > > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > > >structs with C.
 
 
Such alignment shold make us not = > > >need the extra "unaligned double" switch
on most platforms (some = > > >mystery still on some platforms) as well as
perhaps be needed for = > > >some atomic operations, esp. maybe on
LONGINT on 32bit = > > >x86.
 
 
 - Jay

 
> From: > >class=3D"Apple-converted-space">  > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: > >class=3D"Apple-converted-space">  > >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: > >class=3D"Apple-converted-space">  > >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > > >Subject: Re: [M3devel] platform-independent = > > >packing/alignment?
> > >class=3D"Apple-converted-space"> 
> I've not changed = > > >my code, that is for sure.... But now I am not sure
> some parent = > > >type (esp MUTEX here an there) was not changed... I'll take
> a = > > >look on this again sometime soon and report my findings.
> > >class=3D"Apple-converted-space"> 
> Thanks for = > > >clues.
> 
> = > > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > > >> 
> > = > > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > > >but didn't catch answer:
> > > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > > >we can probably get by with platform-independent
> > >> = > > >packing/alignment settings.
> > > > >class=3D"Apple-converted-space"> 
> > > Some = > > >time ago I've used pickles (CM3) to save some data... My program
> = > > >> > does not read that pickle anymore.... > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > And you are = > > >certain your program that tries to read still contains
> > = > > >exact structurally equivalent types to all the types in the = > > >pickle?
> > > >class=3D"Apple-converted-space"> 
> > > > >class=3D"Apple-converted-space"> 
> > > Someone = > > >remembers moment when this incompatible changes were made? > >class=3D"Apple-converted-space"> 
> -- > >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > > >Duri=C4=87 < > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> > >class=3D"Apple-converted-space"> 
 > >>

= > > > > > >--Apple-Mail-4--1058110347-- > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 1 21:23:53 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 14:23:53 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1265013708.4240.16.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> <1265013708.4240.16.camel@faramir.m3w.org> Message-ID: <4B673859.8070405@lcwb.coop> One thing I recall is that there are about 3 signatures for some builtin types that are hard-coded as constants rather than computed, and pm3 vs. cm3 pickles have them with values differing in some rather bizarre byte-ordering differences. In at least one of them, the order was also inconsistent with the general algorithm used to construct most signatures. As I recall, I fixed cm3 pickles to recognize/read both sets of signature values. So if you are using recent pickle code from cm3, this would not be the cause of your problem, nor would it be if you have not written a pickle in pm3-compiled code and tried to read it in cm3-compiled code. I also recall putting in some better messages when things failed, such as giving the value of an unrecognized signature. Do you get any interesting messages when pickle reading fails? Dragi?a Duri? wrote: > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > From Highjinks at gmx.com Wed Feb 3 00:33:40 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 00:33:40 +0100 (CET) Subject: [M3devel] Shorthand type declarations? Message-ID: <20100202193708.97d69f8c.Highjinks@gmx.com> Alright, I'm finally getting the hang of things. One quick question.. Is there a shorthand for declaring a whole bunch of types as one type? i.e.... TYPE Window, Pixmap, Cursor = unsigned_int; Or something similiar? Doing this TYPE Window = unsigned_int; Pixmap = unsigned_int; Cursor = unsigned_int; etc... Adds up to whole lot of typing.(No pun intended) Any tips would be most welcome. -- Chris From rodney_bates at lcwb.coop Wed Feb 3 04:37:33 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 02 Feb 2010 21:37:33 -0600 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100202193708.97d69f8c.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> Message-ID: <4B68EF7D.7040009@lcwb.coop> Chris wrote: > Alright, I'm finally getting the hang of things. > > One quick question.. > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > TYPE > Window, Pixmap, Cursor = unsigned_int; > > Or something similiar? > > Doing this > TYPE > Window = unsigned_int; > Pixmap = unsigned_int; > Cursor = unsigned_int; > etc... > Adds up to whole lot of typing.(No pun intended) Unfortunately, this is the shortest you can get. I suppose the language designers thought that, while a whole lot of variables with the same type were a likely case: VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , that more than just a few type names that are synonyms for the same type would not be common. You may think me certifiably masochist, but I go the more longhanded way and write: TYPE Window = unsigned_int; TYPE Pixmap = unsigned_int; TYPE Cursor = unsigned_int; , sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, almost every time. > > Any tips would be most welcome. > From jay.krell at cornell.edu Wed Feb 3 06:28:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 05:28:50 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <4B68EF7D.7040009@lcwb.coop> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop> Message-ID: This is not where Modula-3 falls down due to verbosity. Many C and C++ programmers discourage such terseness: int a, b, c(), d(); typedef int T1, T2; preferring: int a; int b; int c(); int d(); typedef int T1; typedef int T2; Where is falls down, perhaps, is not using curly braces. (And perhaps for gyrations needed for safety, see my recent NTObjFile.m3 changes. Can they be safe and not duplicate code, or only one?) My editor is geared toward curly braces and helps using them tremendously. I can't switch editors. I've tried many times. I find the terseness Modula-3 does allow: PROCEDURE(VAR a, b:INTEGER); TYPE A = RECORD c, d: INTEGER:= 0; END. ambiguous. I don't know if a and b are both VAR. I don't know if c and d both have the initializer. I'd prefer to see: PROCEDURE(VAR a: INTEGER; VAR b:INTEGER); TYPE A = RECORD c: INTEGER := 0; d: INTEGER:= 0; END. (and I'm not sure that is equivalent, but I do know what it means.) (newlines omited in RECORD just for *email brevity*: RECORD should have a newline per field!) I would be in favor of removing all these shorthands from the cm3 tree, and maybe even warning about them. But they surely are all well defined if you know the language well. It is meant to be a small language, but goes a bit too far here I think. - Jay > Date: Tue, 2 Feb 2010 21:37:33 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > > > Chris wrote: > > Alright, I'm finally getting the hang of things. > > > > One quick question.. > > > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > > > TYPE > > Window, Pixmap, Cursor = unsigned_int; > > > > Or something similiar? > > > > Doing this > > TYPE > > Window = unsigned_int; > > Pixmap = unsigned_int; > > Cursor = unsigned_int; > > etc... > > Adds up to whole lot of typing.(No pun intended) > > Unfortunately, this is the shortest you can get. I suppose the language designers > thought that, while a whole lot of variables with the same type were a likely > case: > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > that more than just a few type names that are synonyms for the same type would not be common. > > You may think me certifiably masochist, but I go the more longhanded way and write: > > TYPE Window = unsigned_int; > TYPE Pixmap = unsigned_int; > TYPE Cursor = unsigned_int; , > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > almost every time. > > > > > > Any tips would be most welcome. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 3 09:37:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Feb 2010 03:37:52 -0500 Subject: [M3devel] Shorthand type declarations? In-Reply-To: References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop> Message-ID: <6E17449F-8762-4AA0-951A-0D3455432A3F@cs.purdue.edu> On 3 Feb 2010, at 00:28, Jay K wrote: > This is not where Modula-3 falls down due to verbosity. > > > Many C and C++ programmers discourage such terseness: > int a, b, c(), d(); > typedef int T1, T2; > > > preferring: > int a; > int b; > int c(); > int d(); > typedef int T1; > typedef int T2; > > > Where is falls down, perhaps, is not using curly braces. > (And perhaps for gyrations needed for safety, see my recent NTObjFile.m3 changes. > Can they be safe and not duplicate code, or only one?) > > > My editor is geared toward curly braces and helps using them tremendously. > I can't switch editors. I've tried many times. ... emacs... :-) > I find the terseness Modula-3 does allow: > PROCEDURE(VAR a, b:INTEGER); Both are VAR. VAR distributes over the list. > TYPE A = RECORD c, d: INTEGER:= 0; END. They both get 0. := distributes over the list. > ambiguous. > > I don't know if a and b are both VAR. > I don't know if c and d both have the initializer. > I'd prefer to see: > PROCEDURE(VAR a: INTEGER; VAR b:INTEGER); > TYPE A = RECORD c: INTEGER := 0; d: INTEGER:= 0; END. > > > (and I'm not sure that is equivalent, but I do know what it means.) > (newlines omited in RECORD just for *email brevity*: RECORD should have a newline per field!) > > I would be in favor of removing all these shorthands from the cm3 tree, > and maybe even warning about them. But they surely are all well defined > if you know the language well. It is meant to be a small language, > but goes a bit too far here I think. I've never really found this to be the case. Perhaps because I learnt to program in Pascal. > > > - Jay > > > > Date: Tue, 2 Feb 2010 21:37:33 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Shorthand type declarations? > > > > > > > > Chris wrote: > > > Alright, I'm finally getting the hang of things. > > > > > > One quick question.. > > > > > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > > > > > TYPE > > > Window, Pixmap, Cursor = unsigned_int; > > > > > > Or something similiar? > > > > > > Doing this > > > TYPE > > > Window = unsigned_int; > > > Pixmap = unsigned_int; > > > Cursor = unsigned_int; > > > etc... > > > Adds up to whole lot of typing.(No pun intended) > > > > Unfortunately, this is the shortest you can get. I suppose the language designers > > thought that, while a whole lot of variables with the same type were a likely > > case: > > > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > > > that more than just a few type names that are synonyms for the same type would not be common. > > > > You may think me certifiably masochist, but I go the more longhanded way and write: > > > > TYPE Window = unsigned_int; > > TYPE Pixmap = unsigned_int; > > TYPE Cursor = unsigned_int; , > > > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > > almost every time. > > > > > > > > > > Any tips would be most welcome. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Feb 3 09:59:12 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 09:59:12 +0100 (CET) Subject: [M3devel] Shorthand type declarations? In-Reply-To: <4B68EF7D.7040009@lcwb.coop> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> Message-ID: <20100203050242.0a7e924b.Highjinks@gmx.com> On Tue, 02 Feb 2010 21:37:33 -0600 "Rodney M. Bates" wrote: > > > > Unfortunately, this is the shortest you can get. I suppose the language designers > thought that, while a whole lot of variables with the same type were a likely > case: > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > that more than just a few type names that are synonyms for the same type would not be common. > > You may think me certifiably masochist, but I go the more longhanded way and write: > > TYPE Window = unsigned_int; > TYPE Pixmap = unsigned_int; > TYPE Cursor = unsigned_int; , > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > almost every time. > > The reason I asked is because I'm doing the interface for /usr/include/xcb/xproto.h There are a lot of of typedefs in there that are defined as the same base type. I've shortened the Iterator types by using... TYPE T = UNTRACED ROOT OBJECT END; TYPE XCB_Iterator = T OBJECT Rem : INTEGER; Index : INTEGER END; TYPE XCBAtom = unsigned_int; TYPE Atom_Iterator = XCB_Iterator OBJECT Atom_Data : UNTRACED REF XCBAtom; END; But even this is gonna kill me. Heh. xproto.h is a HUGE file. -- Chris From wagner at elegosoft.com Wed Feb 3 09:59:45 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 03 Feb 2010 09:59:45 +0100 Subject: [M3devel] m3gdb build on AMD64_FREEBSD Message-ID: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Any chance to make m3gdb build on 64 bit FreeBSD? This is the only package that's still failing on that platform: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText (search for m3gdb in the listing) A quick look doesn't really enlighten me as to what is wrong... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 3 10:18:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 03 Feb 2010 10:18:14 +0100 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203050242.0a7e924b.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> Message-ID: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Quoting Chris : > On Tue, 02 Feb 2010 21:37:33 -0600 > "Rodney M. Bates" wrote: > >> Unfortunately, this is the shortest you can get. I suppose the >> language designers >> thought that, while a whole lot of variables with the same type >> were a likely >> case: >> >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , >> >> that more than just a few type names that are synonyms for the same >> type would not be common. >> >> You may think me certifiably masochist, but I go the more >> longhanded way and write: >> >> TYPE Window = unsigned_int; >> TYPE Pixmap = unsigned_int; >> TYPE Cursor = unsigned_int; , >> >> sacrificing writeability in favor of readability. (Yes, I repeat >> VAR and CONST too, >> almost every time. > > The reason I asked is because I'm doing the interface for > /usr/include/xcb/xproto.h > > There are a lot of of typedefs in there that are defined as the same > base type. > > I've shortened the Iterator types by using... > > TYPE T = UNTRACED ROOT OBJECT END; > TYPE XCB_Iterator = T OBJECT > Rem : INTEGER; > Index : INTEGER > END; > > TYPE XCBAtom = unsigned_int; > TYPE Atom_Iterator = XCB_Iterator OBJECT > Atom_Data : UNTRACED REF XCBAtom; > END; > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. What exactly is gained by defining all those aliases for unsigned_int? In M3 all the types are structurally equivalent, so you can use a Cursor where a Window would be required etc. It looks like a bit of facelifting to me. And if it's only for readability and proper naming, all those should surely be named Handle, shouldn't they? The same level of abstraction could be achieved by defining just one XProtoHandle as unsigned_int, couldn't it? I think I just have never understood the usefulness of interfaces too large to remember, but that may be a general problem with X... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 3 12:45:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:45:12 +0000 Subject: [M3devel] m3gdb build on AMD64_FREEBSD In-Reply-To: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> References: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Message-ID: I haven't looked but maybe we need a newer gdb? Personally I wish we could output enough information so that regular gdb could work better... Also we shouldn't bother mangling acceptable identifiers when there is no clash.. - Jay > Date: Wed, 3 Feb 2010 09:59:45 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3gdb build on AMD64_FREEBSD > > Any chance to make m3gdb build on 64 bit FreeBSD? > This is the only package that's still failing on that platform: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText > > (search for m3gdb in the listing) > > A quick look doesn't really enlighten me as to what is wrong... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 3 12:55:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:55:22 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: > so you can use a Cursor where a Window would be required etc Win32 does opaque unique types something like: #define DECLARE_HANDLE(foo) struct tag##foo; typedef struct tag##foo* foo; DECLARE_HANDLE(HWND) DECLARE_HANDLE(HCURSOR) DECLARE_HANDLE(HRGN) DECLARE_HANDLE(HPEN) Some of the objects are indeed "bases" of others, but that can't be easily captured. It gets documented and you can cast. And then opaque non-unique is also common: typedef void* HANDLE; That is used for files, events, mutexes, semaphores, processes, threads, etc. And there is a lot of commonality. They all work with CloseHandle, WaitForSingleObject, WaitForMultipleObjects, DuplicateHandle, etc. - Jay > Date: Wed, 3 Feb 2010 10:18:14 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > Quoting Chris : > > > On Tue, 02 Feb 2010 21:37:33 -0600 > > "Rodney M. Bates" wrote: > > > >> Unfortunately, this is the shortest you can get. I suppose the > >> language designers > >> thought that, while a whole lot of variables with the same type > >> were a likely > >> case: > >> > >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > >> > >> that more than just a few type names that are synonyms for the same > >> type would not be common. > >> > >> You may think me certifiably masochist, but I go the more > >> longhanded way and write: > >> > >> TYPE Window = unsigned_int; > >> TYPE Pixmap = unsigned_int; > >> TYPE Cursor = unsigned_int; , > >> > >> sacrificing writeability in favor of readability. (Yes, I repeat > >> VAR and CONST too, > >> almost every time. > > > > The reason I asked is because I'm doing the interface for > > /usr/include/xcb/xproto.h > > > > There are a lot of of typedefs in there that are defined as the same > > base type. > > > > I've shortened the Iterator types by using... > > > > TYPE T = UNTRACED ROOT OBJECT END; > > TYPE XCB_Iterator = T OBJECT > > Rem : INTEGER; > > Index : INTEGER > > END; > > > > TYPE XCBAtom = unsigned_int; > > TYPE Atom_Iterator = XCB_Iterator OBJECT > > Atom_Data : UNTRACED REF XCBAtom; > > END; > > > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. > > What exactly is gained by defining all those aliases for unsigned_int? > In M3 all the types are structurally equivalent, so you can use a Cursor > where a Window would be required etc. It looks like a bit of facelifting > to me. > > And if it's only for readability and proper naming, all those should > surely be named Handle, shouldn't they? > > The same level of abstraction could be achieved by defining just one > XProtoHandle as unsigned_int, couldn't it? > > I think I just have never understood the usefulness of interfaces > too large to remember, but that may be a general problem with X... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 3 12:51:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:51:32 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: Chris many of the X headers these days are generated from XML using Python. Seriously -- you need Python to build X these days. You should look into adding a little to that system for Modula-3. Cloning headers is tedious, therefore error-prone, therefore a recipe for bugs. Please try to avoid it. If you really can't go the XML route, there is also a fork of gcc that is supposed to be adequate for header parsing, and spits out XML. Look for "gccxml" or such. Maybe it is old/dead now? There is also swig, which is a partial C compiler. Not a great idea to attempt. But it is there, you might try it. I'd be far more interested in wrapping Qt than X though... - Jay > Date: Wed, 3 Feb 2010 10:18:14 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > Quoting Chris : > > > On Tue, 02 Feb 2010 21:37:33 -0600 > > "Rodney M. Bates" wrote: > > > >> Unfortunately, this is the shortest you can get. I suppose the > >> language designers > >> thought that, while a whole lot of variables with the same type > >> were a likely > >> case: > >> > >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > >> > >> that more than just a few type names that are synonyms for the same > >> type would not be common. > >> > >> You may think me certifiably masochist, but I go the more > >> longhanded way and write: > >> > >> TYPE Window = unsigned_int; > >> TYPE Pixmap = unsigned_int; > >> TYPE Cursor = unsigned_int; , > >> > >> sacrificing writeability in favor of readability. (Yes, I repeat > >> VAR and CONST too, > >> almost every time. > > > > The reason I asked is because I'm doing the interface for > > /usr/include/xcb/xproto.h > > > > There are a lot of of typedefs in there that are defined as the same > > base type. > > > > I've shortened the Iterator types by using... > > > > TYPE T = UNTRACED ROOT OBJECT END; > > TYPE XCB_Iterator = T OBJECT > > Rem : INTEGER; > > Index : INTEGER > > END; > > > > TYPE XCBAtom = unsigned_int; > > TYPE Atom_Iterator = XCB_Iterator OBJECT > > Atom_Data : UNTRACED REF XCBAtom; > > END; > > > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. > > What exactly is gained by defining all those aliases for unsigned_int? > In M3 all the types are structurally equivalent, so you can use a Cursor > where a Window would be required etc. It looks like a bit of facelifting > to me. > > And if it's only for readability and proper naming, all those should > surely be named Handle, shouldn't they? > > The same level of abstraction could be achieved by defining just one > XProtoHandle as unsigned_int, couldn't it? > > I think I just have never understood the usefulness of interfaces > too large to remember, but that may be a general problem with X... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Feb 3 20:08:05 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 03 Feb 2010 13:08:05 -0600 Subject: [M3devel] m3gdb build on AMD64_FREEBSD In-Reply-To: References: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Message-ID: <4B69C995.4010902@lcwb.coop> Jay K wrote: > I haven't looked but maybe we need a newer gdb? If you mean stock gdb, you can use the latest available. If you mean an m3gdb derived from a later gdb, that has been on my list for a while. Maybe when gdb 7.1 is out (very soon) and I am through moving house and get my old one sold (who knows?) Having done this, I think three times, I can say it will be quit a bit of work, and it looks like there are more/bigger changes to gdb than ever before, especially reverse debugging, which would be really nice. > Personally I wish we could output enough information > so that regular gdb could work better... There is very little room for improvement in just changing/ expanding the debug output produced by the compiler. To get much of anything at all would involve changing the debug info format from stabs (very old, cobbled up, and limited) to dwarf-2 (apparently the best now in use). I am even prepared for the possibility that the latest gdb will have dropped stabs altogether. This is also a big job. I have been thinking about it for a long time. But it still can't do all that much using stock gdb. > Also we shouldn't bother mangling acceptable identifiers when > there is no clash.. Having separate compilation, there are many cases where it would be impossible for the compiler to know whether there are clashes or not. Also, I'm not sure how feasible it would be to remove the uid portion from mangled variable names, given Modula-3's structural type rules. Maybe dwarf-2 would allow it to work. > > - Jay > > > Date: Wed, 3 Feb 2010 09:59:45 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3gdb build on AMD64_FREEBSD > > > > Any chance to make m3gdb build on 64 bit FreeBSD? > > This is the only package that's still failing on that platform: > > > > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText > > > > (search for m3gdb in the listing) > > > > A quick look doesn't really enlighten me as to what is wrong... > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Wed Feb 3 21:49:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 20:49:30 +0000 Subject: [M3devel] NT386 int64/longint Message-ID: I've actually been able to compile a fair amount of code now, and at a very cursory glance, it looks reasonably correct. e.g. all of m3core -- including the long/word stuff and Convert.m3. This is using an approach where I "split" operands and then loop over the parts. Variables become two variables. Registers become two registers. Immediates become two immediates. However I seem unable to get the bookkeeping within the backend correct. I had to remove various asserts. Not great. In some places I believe more asserts are clearly correct, but yet they fail when I put them in. Some of the asserts are suspicous to me and further investigation makes me suspicious of some of the existing code in m3back. But I'm not very confident here. I'd have to demonstrate incorrect codegen before making changes. For example the first releaseall in call_indirect seems wrong. It seems like releaseall should only be called when the virtual stack must be empty. But it always has depth at least one there. The second one seems correct. I think it is also overkill in that it need only release volatile registers. I'm also not sure if the virtual stack should really even be empty there. Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2). Perhaps there are assumptions regarding how the front end works. For example I have various add/mult/div making function calls and that seems to be unexpected. I'm also not sure why in_proc_call is limited to two. And, why that is enforced with an assert instead of a subrange. Perhaps I can model int64/longint mostly as a struct. I'll look into that. Or maybe I can somewhat "start over" with the current approach. What is already commited is very safe and conservative and a useful step, depending on what the end result is. One of the problems with the current approach is that if we zero extend a 32bit cardinal, we waste a register for the upper half zero. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Feb 3 22:10:58 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 22:10:58 +0100 (CET) Subject: [M3devel] Shorthand type declarations? In-Reply-To: References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: <20100203171429.533b2e69.Highjinks@gmx.com> On Wed, 3 Feb 2010 11:51:32 +0000 Jay K wrote: > > Chris many of the X headers these days are generated from XML using Python. > > Seriously -- you need Python to build X these days. > > You should look into adding a little to that system for Modula-3. > > Cloning headers is tedious, therefore error-prone, therefore a recipe for bugs. > > Please try to avoid it. > If you really can't go the XML route, there is also a fork of gcc > > that is supposed to be adequate for header parsing, and spits out XML. > > Look for "gccxml" or such. Maybe it is old/dead now? I've never really done much in the way of autogenerating Interfaces and such. Perhaps now is the time for me to look into it. > > > There is also swig, which is a partial C compiler. > > Not a great idea to attempt. > > But it is there, you might try it. > > > > I'd be far more interested in wrapping Qt than X though... Oh, dont worry, QT will get a binding, as will GTK. If not by me, then someone else will do it. The reason I'm doing this interface to XCB is because that is the way X is moving. Future applications will depend less and less on XLib and more on XCB. Also, I dont use QT, or GTK. There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, wxWindows, etc... I'm starting out with XCB, Cairo/Pango, XKB for X. The OpenGL binding will be updated next, along with it's GLX and GLUT bindings. These are the basic X Libs that lots of other X apps depend on. Then I'll start doing QT/GTK(if someone hasnt already beaten me to it. Nice thing with QT and GTK is that they are in fact cross platform. Therefor I wouldn't classify them as "X Windows" bindings. Just as GUI toolkits. Nice ones at that. Whoa! I've got ALOT of work to do. Be back soon. -- Chris From hendrik at topoi.pooq.com Wed Feb 3 22:51:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 3 Feb 2010 16:51:56 -0500 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203171429.533b2e69.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> <20100203171429.533b2e69.Highjinks@gmx.com> Message-ID: <20100203215156.GA20509@topoi.pooq.com> On Wed, Feb 03, 2010 at 10:10:58PM +0100, Chris wrote: > On Wed, 3 Feb 2010 11:51:32 +0000 > Jay K wrote: > > There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, > wxWindows, etc... wxWindows is more than a UI toolkit; it's a complete environment for writing cross-platform C (or is it C++) programs -- right down to specifying how you have to write your main program. I think Modula 3 already provides a main program on Windows, right? -- hendrik From jay.krell at cornell.edu Wed Feb 3 23:09:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 22:09:45 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203215156.GA20509@topoi.pooq.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com>, , <20100203171429.533b2e69.Highjinks@gmx.com>, <20100203215156.GA20509@topoi.pooq.com> Message-ID: I think that is a lesser concern. I think a larger issue is what the binding should look like and if it can be generated. And if we import the library into our tree (probably not). And then how we configure, like, is the thing on the system. Do we generate the headers in the build? Maybe. That is good in that they match and don't go stale. Bad in that it hurts cross builds. Possibly generate, checkin, and then regenerate if possible and compare to what is checked in. (But now I've digressed to lesser concerns as well. The important part is figuring out what the binding should look like and how to generate it. Less important how often to regenerate it.) Of course Modula-3 provides main. Likely wxWindows doesn't absolutely require special main. Likely any binding can just have you add some function call from your Modula-3 main. Absolute terrible worst case if you can teach the Modula-3 compiler to not provide main. In fact that's not a bad idea for other reasons -- for better interop with existing code. Basically we should have a flag to RTLinker__InitRuntime that specifies if it returns or runs Main__M3(1) or however that works. Or an alternate RTLinker__InitRuntimeEx. wxWindows is C++. There are Python bindings. These libraries often provide cross-platform threading/synchronization, I/O, etc. And sometimes IDEs, right. There are many such efforts. Any binding effort imho could limit itself to just the gui parts. The other parts ok, but I'm suspicious that Modula-3's container/string/i/o/threading libraries aren't so bad/ugly, whereas its GUI library at least looks awful and Olaf says the Win32 port is incomplete, so more work merited there it seems vs. other library parts. - Jay ---------------------------------------- > Date: Wed, 3 Feb 2010 16:51:56 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > On Wed, Feb 03, 2010 at 10:10:58PM +0100, Chris wrote: >> On Wed, 3 Feb 2010 11:51:32 +0000 >> Jay K wrote: >> >> There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, >> wxWindows, etc... > > wxWindows is more than a UI toolkit; it's a complete environment for > writing cross-platform C (or is it C++) programs -- right down to > specifying how you have to write your main program. > > I think Modula 3 already provides a main program on Windows, right? > > -- hendrik From jay.krell at cornell.edu Fri Feb 5 13:21:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Feb 2010 12:21:10 +0000 Subject: [M3devel] NT386 int64/longint Message-ID: nevermind, it's looking much better now. A few more days though. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: NT386 int64/longint Date: Wed, 3 Feb 2010 20:49:30 +0000 I've actually been able to compile a fair amount of code now, and at a very cursory glance, it looks reasonably correct. e.g. all of m3core -- including the long/word stuff and Convert.m3. This is using an approach where I "split" operands and then loop over the parts. Variables become two variables. Registers become two registers. Immediates become two immediates. However I seem unable to get the bookkeeping within the backend correct. I had to remove various asserts. Not great. In some places I believe more asserts are clearly correct, but yet they fail when I put them in. Some of the asserts are suspicous to me and further investigation makes me suspicious of some of the existing code in m3back. But I'm not very confident here. I'd have to demonstrate incorrect codegen before making changes. For example the first releaseall in call_indirect seems wrong. It seems like releaseall should only be called when the virtual stack must be empty. But it always has depth at least one there. The second one seems correct. I think it is also overkill in that it need only release volatile registers. I'm also not sure if the virtual stack should really even be empty there. Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2). Perhaps there are assumptions regarding how the front end works. For example I have various add/mult/div making function calls and that seems to be unexpected. I'm also not sure why in_proc_call is limited to two. And, why that is enforced with an assert instead of a subrange. Perhaps I can model int64/longint mostly as a struct. I'll look into that. Or maybe I can somewhat "start over" with the current approach. What is already commited is very safe and conservative and a useful step, depending on what the end result is. One of the problems with the current approach is that if we zero extend a 32bit cardinal, we waste a register for the upper half zero. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 6 13:29:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Feb 2010 12:29:39 +0000 Subject: [M3devel] front end function about a "virtual stack" Message-ID: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 6 19:07:23 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 6 Feb 2010 13:07:23 -0500 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: References: Message-ID: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: > Tony, can you confirm something? > It's hard to explain. > > > The NT36 backend of course maintains > a bunch of information as to which registers are in use. > > > For example, at the start of the function, it > marks all registers as not in use. > (It always preserves all volatile registers I believe. > Obviously it could do better. It should only > mark non-volatile registers as in use, see > which registers it uses in the function, and > then only preserve/restore the nonvolatile ones > that it uses.) > > > As well when it generates a function call it > marks them as all not in use too. > But in that case, it checks itself. > Again, it is a bit dumb -- nonvolatile registers > would be ok to still be in use. > > > Now, all is ok. > But then, I've introduced function calls where > they weren't before -- multiply, divide, mod etc. > > > Upon generating the call to mod (for example), > I get an assertion failure, because registers > are still in use. In this case it is a nonvolatile > register, but I think that's largely luck. > > > In particular I think the location that > will be stored to after the mod is in a register. > That is reasonable. > You know..as a compiler, given: > *(a + b) = f(); > > > you might generate code to evaluate a + b first, > put it in a (non volatile) register, then call f(), > or you might call f() first. > > > A simpler approach is to call all the functions first, > so you have more easy use of registers. > > > But then imagine > *(a + b) = (c % d); > > > is there a function call in there or not? > It depends. > > > So then my question is, like, when does the > frontend assume a "stack based code generator"'s > stack can/should/will be empty? > Does it endeavor to make it so? > > > That is, is it very reasonable to for the NT386 > backend to assume its stack is empty when > it calls a function, because the front end > colludes to make it so, but then > the front end doesn't do similar for things > like multiply/divide? > > > I can deal with this pretty easily either way. > Around function calls I introduce that weren't > previously there I can save whatever volatile > registers are in use. > > > But I'd like to understand. > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 07:49:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 06:49:11 +0000 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> References: , <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> Message-ID: > But, there have always been calls for mod/div Not on NT386. - Jay Subject: Re: front end function about a "virtual stack" From: hosking at cs.purdue.edu Date: Sat, 6 Feb 2010 13:07:23 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 08:02:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 07:02:24 +0000 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> References: , <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> Message-ID: I think I have this aspect dealt with now. Convert.m3: -----LINE 129 ----- load tv.25[_nDigits] 0 Int.32 Int.32 check_range 0 n:8,x:0,0,0,0,0,0,0,0 64 n:4,x:40,0,0,0,0,0,0,0 2 00000435: 8B5DFC MOV EBX tv.25[_nDigits] 00000438: 83FB40 CMP EBX $64 0000043B: 7600 JBE rel8 L.68 0000043D: B822100000 MOV EAX $4130 00000442: E800000000 CALL L.0 loophole Int.32 Int.32 load_address tv.31[_result] 0 00000447: 8D75AE LEA ESI tv.31[_result] swap Int.32 Addr index_address Int.32 1 0000044A: 03F3 ADD ESI EBX ** result location in ESI * load tv.35[_base] 0 Word.8 Int.32 loophole Int.32 Int.64 0000044C: 33D2 XOR EDX EDX 0000044E: 8A5514 MOV EDX tv.35[_base]:Word.8 00000451: 33FF XOR EDI EDI load tv.34[_value] 0 Int.64 Int.64 swap Int.64 Int.64 mod Int.64 X P call_64 m3_mod64 2 import_procedure m3_mod64 2 Int.64 "__stdcall" p.31[m3_mod64] declare_param * 8 8 Word.64 0 F F 100 tv.201[T$201] 8 declare_param * 8 8 Word.64 0 F F 100 tv.202[T$202] 16 start_call_direct p.31[_m3_mod64 at 16] 0 Int.64 load_stack_param Word.64 1 00000453: 8B4D0C MOV ECX tv.34[_value] 00000456: 8B4510 MOV EAX tv.34[_value]+4 00000459: 50 PUSH EAX 0000045A: 51 PUSH ECX load_stack_param Word.64 0 0000045B: 57 PUSH EDI 0000045C: 52 PUSH EDX declare_temp 4 4 Addr F tv.203[T$203] -92 0000045D: 8975A4 MOV tv.203[T$203] ESI ** ESI saved unnecessarily in temporary to satisfy us ** call_direct p.31[_m3_mod64 at 16] Int.64 00000460: FF1500000000 CALL p.31[_m3_mod64 at 16] loophole Int.64 Int.32 loophole Int.32 Int.32 load_address gv.2[_MM_Convert] 52 00000466: 8D3534000000 LEA ESI gv.2[_MM_Convert]+52 swap Int.32 Addr index_address Int.32 1 0000046C: 03F0 ADD ESI EAX load_indirect 0 Word.8 Int.32 0000046E: 33DB XOR EBX EBX 00000470: 8A5E00 MOV EBX ESI^[0:Word.8] store_indirect 0 Int.32 Word.8 00000473: 8B75A4 MOV ESI tv.203[T$203]:Addr ** ESI refetched from temporary ** free_temp tv.203[T$203] 00000476: 885E00 MOV ESI^[0:Word.8] EBX -----LINE 130 ----- Pretty wasteful. Instead it should just compute the destination when it does the store. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: front end function about a "virtual stack" Date: Sun, 7 Feb 2010 06:49:11 +0000 > But, there have always been calls for mod/div Not on NT386. - Jay Subject: Re: front end function about a "virtual stack" From: hosking at cs.purdue.edu Date: Sat, 6 Feb 2010 13:07:23 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:08:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:08:11 +0000 Subject: [M3devel] initializing LONGINT doesn't work Message-ID: Maybe not fully up to date, Linux/x86: jay at xlin2:~/t$ cat src/Main.m3 MODULE Main; VAR a := 1L; BEGIN END Main. jay at xlin2:~/t$ /cm3/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Main.m3 "../src/Main.m3", line 3: warning: not used (a) "../src/Main.m3", line 1: ** INTERNAL CG ERROR *** unable to stuff bit field val ue?? *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/misc/CG.m3", line 1013 *** Aborted jay at xlin2:~/t$ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:09:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Message-ID: Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:16:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: Message-ID: Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:39:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:39:25 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: , Message-ID: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 16:12:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 15:12:13 +0000 Subject: [M3devel] NT386 longint=64bits In-Reply-To: <20100207150232.B9F282474001@birch.elegosoft.com> References: <20100207150232.B9F282474001@birch.elegosoft.com> Message-ID: LONGINT on NT386 is now 64bits. It could use more testing. See m3-sys\m3tests\src\p2\p227. Add more there. Try it on NT386 and others. Disassemble the output (or use cm3 -debug and look at the *log (not *.log) files in the output directory, very useful). It doesn't run in the automated runs though, yet. There are two known problems: converting between INTEGER and LONGINT doesn't sign extend I'm not sure if LONGINT to INTEGER range checks either. In fact I didn't test any of the range checking, but it layers on top of simple compares. You cannot initialize a global LONGINT to other than 0; this bug is on all platforms. I'm hoping Tony fixes that. I think I need to make a change in m3back for this too though, to use the change I put in m3objfile (append vs. appendBytes). It'd be nifty if the front end could deal with the conversion. Generate the compares to 0, oring with FFFFFFFF00000... But I'll get to before too long either way. There are also obvious missing optimizations, some of which are easily fixed, some are not. In particular, some of the code is in the "wrong" place, such as to miss out on constant folding. Including division by constants. The fix is just to move the code later after constant cases are handled. I'll get to this stuff before too long. There are a few "support" functions. For example 64bit multiply calls out to a function. If you do a 64bit multiply in C, that calls a function too. We call the same function, where applicable. And m3core/src/Csupport/Common/hand.c has a few functions. I'm particularly nervous about extract/insert, but they seem to work. If you find a problem and really must go back to 32bit LONGINT, see the change below in Target.m3. Maybe make it a command line option. - Jay > Date: Sun, 7 Feb 2010 16:02:32 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/02/07 16:02:32 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > and bang: longint is now 64bits on NT386 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 7 19:55:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 13:55:13 -0500 Subject: [M3devel] atomic problem In-Reply-To: References: , Message-ID: <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: > ok, better now, but: > > == package /home/jay/dev2/cm3/m3-sys/m3staloneback == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - > DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in LINUXLIBC6 --- > ignoring ../src/m3overrides > new source -> compiling Main.m3 > -> linking m3back > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_xor_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:16:45 +0000 > Subject: Re: [M3devel] atomic problem > > Probably an out of date m3cg. > I'll see. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:09:57 +0000 > Subject: [M3devel] atomic problem > > Could be I'm out of date or building in the wrong order. > I'll maybe dig into it. > Linux/x86: > > new source -> compiling AtomicWideChar.m3 > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW > ideChar__Load': > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler > error: in expand_expr_real_1, at expr.c:7290 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc > new source -> compiling hand.c > new source -> compiling dtoa.c > new source -> compiling libgcc.c > new source -> compiling RTIOc.c > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 20:08:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 19:08:27 +0000 Subject: [M3devel] atomic problem In-Reply-To: <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> References: , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> Message-ID: It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. We can probably adjust m3cc/m3makefile. The platforms.quake file won't do, since native builds don't use it. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 13:55:13 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 7 20:32:44 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 14:32:44 -0500 Subject: [M3devel] atomic problem In-Reply-To: References: , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> Message-ID: I think -march=native works too assuming you are on a modern x86. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 14:08, Jay K wrote: > It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. > Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. > We can probably adjust m3cc/m3makefile. > The platforms.quake file won't do, since native builds don't use it. > > - Jay > > From: hosking at cs.purdue.edu > Date: Sun, 7 Feb 2010 13:55:13 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] atomic problem > > -march=i686 > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 7 Feb 2010, at 08:39, Jay K wrote: > > ok, better now, but: > > == package /home/jay/dev2/cm3/m3-sys/m3staloneback == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - > DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in LINUXLIBC6 --- > ignoring ../src/m3overrides > new source -> compiling Main.m3 > -> linking m3back > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_xor_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:16:45 +0000 > Subject: Re: [M3devel] atomic problem > > Probably an out of date m3cg. > I'll see. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:09:57 +0000 > Subject: [M3devel] atomic problem > > Could be I'm out of date or building in the wrong order. > I'll maybe dig into it. > Linux/x86: > > new source -> compiling AtomicWideChar.m3 > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW > ideChar__Load': > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler > error: in expand_expr_real_1, at expr.c:7290 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc > new source -> compiling hand.c > new source -> compiling dtoa.c > new source -> compiling libgcc.c > new source -> compiling RTIOc.c > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 00:51:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 23:51:11 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: , , , , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu>, , Message-ID: I don't like such "non-determinism". Granted, it isn't really non-deterministic. I want to know which other machines things will run on, not just have them run on the machine on which they are built. Building things yourself is nice, but not doing it is also nice too. And not doing it on every machine even if you do build it yourself is nice. Which "reminds", or rather "convinces" me..we should just never do native builds in m3cc and m3gdb. We should pass imho what we believe to be the platform, but with carefully chosing which processor. Gotta test like every platform though. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 14:32:44 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem I think -march=native works too assuming you are on a modern x86. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 14:08, Jay K wrote: It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. We can probably adjust m3cc/m3makefile. The platforms.quake file won't do, since native builds don't use it. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 13:55:13 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 00:59:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 23:59:11 +0000 Subject: [M3devel] 386?486?586?686?etc.? Message-ID: Any opinions/counter-opinions on which processors we should support? Presumably it doesn't vary per platform. Like, it wouldn't be Linux/586 and FreeBSD/486 or such. Unless maybe there is clear data about what the kernels support? The atomic stuff is pushing things to i586. I believe before 486 and possibly 386 worked. 686 is probably reasonable. I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. We might even drop "x87" support and use SSE/SSE2/SSE3? (Trolling for work in m3back? :) ) Or make it a different set of platforms? I686_LINUX? I686SSE2_LINUX? etc.? But I don't like such combinatorial work -- supporting more combinations. Maybe, uh, drop all existing 32bit platforms and go with I686_*?? "Darwin" can pretty much imply modern processors. Assuming Apple hardware...granted, I had Darwin/x86 on non-Apple hardware. None of this makes a huge difference. I mean, in that, there's almost no changes that follow from these decisions. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 8 01:11:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 19:11:02 -0500 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: <29775A29-715B-4BD9-8DDA-EBA6235AB931@cs.purdue.edu> We probably should provide pthread-mutex-based atomics for targets that don't support the intrinsic atomics. Initially, I suggest we simply provide stubs that fail for the gcc-intrinsic functions. Thoughts? I doubt there are any older-than-Pentium processors that we need to worry about. On 7 Feb 2010, at 18:59, Jay K wrote: > Any opinions/counter-opinions on which processors we should support? > Presumably it doesn't vary per platform. > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > Unless maybe there is clear data about what the kernels support? > > > The atomic stuff is pushing things to i586. > I believe before 486 and possibly 386 worked. > 686 is probably reasonable. > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. > > > We might even drop "x87" support and use SSE/SSE2/SSE3? > (Trolling for work in m3back? :) ) > Or make it a different set of platforms? > I686_LINUX? > I686SSE2_LINUX? > etc.? > > > But I don't like such combinatorial work -- supporting more combinations. > Maybe, uh, drop all existing 32bit platforms and go with I686_*?? > > > "Darwin" can pretty much imply modern processors. > Assuming Apple hardware...granted, I had Darwin/x86 on non-Apple hardware. > > None of this makes a huge difference. > I mean, in that, there's almost no changes that follow from these decisions. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Feb 8 04:58:48 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 7 Feb 2010 22:58:48 -0500 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: <20100208035847.GB13743@topoi.pooq.com> On Sun, Feb 07, 2010 at 11:59:11PM +0000, Jay K wrote: > > Any opinions/counter-opinions on which processors we should support? > > Presumably it doesn't vary per platform. > > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > > Unless maybe there is clear data about what the kernels support? > > > > > > The atomic stuff is pushing things to i586. > I believe before 486 and possibly 386 worked. > > 686 is probably reasonable. > > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. I'm still running an old 100 MHz Pentium and using it on a daily basis. Debian has dropped support for the 386 with, as far as I know, no complaints. -- hendrik. From jay.krell at cornell.edu Mon Feb 8 15:03:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Feb 2010 14:03:30 +0000 Subject: [M3devel] hand.c to Modula-3? Message-ID: Just a note that hand.c could be mostly/easily be written in Modula-3 instead of C. The main problem is the names. Might be a fun little project for someone. We should also change the gcc backend to use memcmp instead of set_ne/set_eq. Or even the frontend. (There might be an extra efficiency to be had in that a) we don't need -1/0/+1, just a boolean b) we know it is a whole number of ulongs). Probably set_ne/set_eq are rare though. m3back compares to an empty set often, but it is small and the front end implements small sets as a single integer. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 16:22:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Feb 2010 15:22:21 +0000 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: <20100208035847.GB13743@topoi.pooq.com> References: , <20100208035847.GB13743@topoi.pooq.com> Message-ID: Wow. What for? And with Modula-3? What OS? I think Pentium will be ok. I think ultimately, if people really need, we should have separate targets. As I've been saying, like: I386_FREEBSD_USERTHREADS, I586_FREEBSD, etc. Esp. to enable easier "release engineering", such as when we do more cross builds, adding new targets will be cheaper. But we'd want some sort of system where if nobody downloads and installs and minimally tests a release, it is in some low grade classification. Certain ones we'd test automatically, like whatever we have available in Hudson. -Jay > Date: Sun, 7 Feb 2010 22:58:48 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 386?486?586?686?etc.? > > On Sun, Feb 07, 2010 at 11:59:11PM +0000, Jay K wrote: > > > > Any opinions/counter-opinions on which processors we should support? > > > > Presumably it doesn't vary per platform. > > > > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > > > > Unless maybe there is clear data about what the kernels support? > > > > The atomic stuff is pushing things to i586. > > I believe before 486 and possibly 386 worked. > > > > 686 is probably reasonable. > > > > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. > > I'm still running an old 100 MHz Pentium and using it on a daily basis. > > Debian has dropped support for the 386 with, as far as I know, no > complaints. > > -- hendrik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Feb 10 21:15:18 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 10 Feb 2010 21:15:18 +0100 (CET) Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: On Sun, 7 Feb 2010, Jay K wrote: > We might even drop "x87" support and use SSE/SSE2/SSE3? > ?(Trolling for work in m3back? :) ) > ?Or make it a different set of platforms? > ?? I686_LINUX? > ?? I686SSE2_LINUX? > ?? etc.? The SSE's do not support transcendental functions. But they are nice for basic floating point arithmetic, if you rely on the low precision of the IEEE formats. I assume that this is the reason, why LLVM uses SSE instead of FPU instructions where possible. From jay.krell at cornell.edu Thu Feb 11 09:53:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 08:53:08 +0000 Subject: [M3devel] optimizing for size or speed? Message-ID: There are all kinds of equivalent code sequences. For the maintainer of m3back to chose among. Given for example: int F(int a) { return a << 2; } Visual C++ optimizing for size uses: shl eax, 2 ; 3 bytes optimizing for speed gives: add eax, eax ; 2 bytes add eax, eax ; 2 bytes given a << 3, the choices are, obviously: shl eax, 3 ; 3 bytes or add eax, eax add eax, eax add eax, eax 6 bytes, double the size thoughts? I think go for size over speed. Smaller files, less I/O, both in the build and less code to pagein at runtime. At some point higher instruction counts saturate the ability of the processors to "run ahead"? However it might be nice to give the user a choice? But then you invite increased testing cost. Though maybe not too prohibitive. (for shift by one, size/speed both give add eax, eax; I'll do that) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 11 13:03:09 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 11 Feb 2010 07:03:09 -0500 Subject: [M3devel] optimizing for size or speed? In-Reply-To: References: Message-ID: <20100211120309.GB27402@topoi.pooq.com> On Thu, Feb 11, 2010 at 08:53:08AM +0000, Jay K wrote: > > There are all kinds of equivalent code sequences. > For the maintainer of m3back to chose among. In case of doubt, go for size; size all by itself costs time in cache misses, paging, etc. Besides, it's possible to measure space. -- hendrik From jay.krell at cornell.edu Thu Feb 11 13:05:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:05:53 +0000 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) Message-ID: TInt/TWord proposal TInt needs to be a "complete" replacement for INTEGER and LONGINT. Plus overflow checking. Not just for the frontend, but also m3back. TWord needs to be a "complete" replacement for Word and Long. Therefore not likely any overflow checking. But in reality you might need all four: signed with silent overflow signed with nonsilent overflow unsigned with silent overflow unsigned with nonsilent overflow You can provide silent overflow by computing the result and leaving it to the caller to ignore the BOOLEAN or not. However in practise I don't think I needed silent overflow at all. The only places I allow it, I think really I'm confusing TInt with TWord, because TWord doesn't provide the right interface. Settle on bits or bytes for sizes. Enshrine it mostly in the public interface. It maybe already is, granted. But more so -- external users can construct the things. Operations with mixed sizes shall not be allowed. <=== ***** Just as INTEGER, LONGINT, Word, Long don't allow. There would be some conversion functions, granted. SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. Constants Zero, One, MOne, etc. shall probably be replaced with an array of 8 each, or maybe just 1, 2, 4, 8 -- the number of bytes in the size. "M" for "minus" is the wrong term. It should N or Neg or Negative. Something like: TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) TYPE ByteCount = [1..8]; (* wasteful, darn *) CONST Invalid = Target.Int{-1,IntBytes{0,..}}; CONST ZeroBytes = IntBytes{0,..}; CONST OneBytes = IntBytes{1,0,..}; CONST NegativeOneBytes = IntBytes{16_FF,..}; CONST ThirtyTwoBytes = IntBytes{32,0,..}; etc. CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, Invalid, Target.Int{8,ZeroBytes}}; CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, Invalid, Target.Int{8,OneBytes}}; etc. TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] MAYBE as a possible simplification to the user: Introduce InternalTInt which is today's TInt and then: TInt implies Target.Integer.bytes TWord implies Target.Integer.bytes new TLongint implies Target.Longint.bytes new TLong implies Target.Longint.bytes I really thing the short name "Long" is bad. There is no indication of unsignedness in it. It should be ULong or UnsignedLong or LongWord. "Word" is to INTEGER as what is to LONGINT? I don't think Long is the answer. I'll start another thread on this. m3back maintains a stack of mixed types, but I think it works out ok. All that being said, I think what is there works and isn't terrible and we don't need to solve lots of problems here. I do think the variable sizing is a bit of a problem though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:09:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:09:13 +0000 Subject: [M3devel] "Word" is to INTEGER as what is to LONGINT? Message-ID: "Word" is to INTEGER as what is to LONGINT? I don't think Long is a good answer. It is the current answer. "Word" and "INTEGER" are not "related". "Related" might be "UnsignedInteger" or "Integer" or "IntegerOps" or "SilentOverflowInteger" I'm not proposing changing the name "Word". But whatever is the LONGINT replacement...maybe "LongWord" or "UnsignedLong"? I don't think "Long" is the correct answer. Or does "word" not imply "unsigned" or "silent overflow", merely "integer sized"? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:11:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:11:14 +0000 Subject: [M3devel] atomics questions Message-ID: What if some atomic operations aren't available? If none are available, then they can all fallback to one giant lock. But what if some are and some aren't? A lock per type? That fails with like union { short s[2]; int i; } u; and platform has atomic int but not atomic short. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:15:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:15:03 +0000 Subject: [M3devel] use of date and bc in m3tests Message-ID: Anyone: C:\dev2\cm3.2\m3-sys\m3tests\src\m3makefile Please try to remove the uses of date and bc. Thanks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:34:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:34:53 +0000 Subject: [M3devel] replacing hand.c with Modula-3? Message-ID: I see no great reason for hand.c to be in C. It should be easy to rewrite in Modula-3, using the Word interface. The only question really is, what to call things? M3_BUILTIN__set_union, etc.? I think I see M3_BUILTIN somewhere. RTHooks__set_union, etc.? SomethingElse__set_union? SomethingElse__somethingElse while we're at it? M3Set__Union M3Set__Singleton -- probably not even worth being a function M3Set__Intersect etc.? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:41:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:41:12 +0000 Subject: [M3devel] optimizing for size or speed? In-Reply-To: <20100211120309.GB27402@topoi.pooq.com> References: , <20100211120309.GB27402@topoi.pooq.com> Message-ID: cache -- good point I had forgotten, thanks. Still: use the divide instruction, which is smallest, or multiply by reciprocal (which is generally a multiply and a shift) (Given a 32x32=>64 multiply operation. x86 doesn't even have 32x32=>32, only 32x32=>64, I believe.) Any 32bit division by a constant can be optimized this way and every C compiler knows it. multiply by a constant using multiply instruction, or decompose into some adds? The AMD64 optimization guide suggests speed optimizations where they give a sequence for multiplication for every constant up to 32, some are just to use mul. But many are one or two other instructions. Multiply by 5 is: lea eax,[eax+eax*4] Multiply by 10 is: lea eax,[eax+eax*4] add eax,eax The AMD64 manual even advises to inline 64bit shifts by a non-constant. But I can't get Visual C++ to do that. It always calls a function. - Jay > Date: Thu, 11 Feb 2010 07:03:09 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] optimizing for size or speed? > > On Thu, Feb 11, 2010 at 08:53:08AM +0000, Jay K wrote: > > > > There are all kinds of equivalent code sequences. > > For the maintainer of m3back to chose among. > > In case of doubt, go for size; size all by itself costs time in cache > misses, paging, etc. > > Besides, it's possible to measure space. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 14:23:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 13:23:45 +0000 Subject: [M3devel] assertion failure in atomics Message-ID: Tony if you don't have enough to do already: VAR <*NOWARN*>a := 1; <*NOWARN*>b := 2; <*NOWARN*>c := 3; <*NOWARN*>d := 4; <*NOWARN*>A := 5L; <*NOWARN*>B := 6L; <*NOWARN*>C := 7L; <*NOWARN*>D := 8L; bool:BOOLEAN; PROCEDURE Test_AtomicInteger_CompareSwap() = BEGIN bool := AtomicInteger.CompareSwap(a, b, c); END Test_AtomicInteger_CompareSwap; C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 --- building in NT386 --- new source -> compiling Main.m3 "..\Main.m3", line 83: incompatible types (var) *** *** runtime error: *** An array subscript was out of range. *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", line 19 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil tinAtomic\CompareSwap.mg 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 ......... ......... ... more frames ... 1) The test is in error, wrong type on one of the params. 2) This could be specific to using m3back. 3) I'll poke around more. 4) Too bad we don't get line numbers in the stacks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 16:00:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 15:00:39 +0000 Subject: [M3devel] assertion failure in atomics In-Reply-To: References: Message-ID: Type-incorrect code seems to tend to assert. But type-correct code gets through the frontend ok. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 11 Feb 2010 13:23:45 +0000 Subject: [M3devel] assertion failure in atomics Tony if you don't have enough to do already: VAR <*NOWARN*>a := 1; <*NOWARN*>b := 2; <*NOWARN*>c := 3; <*NOWARN*>d := 4; <*NOWARN*>A := 5L; <*NOWARN*>B := 6L; <*NOWARN*>C := 7L; <*NOWARN*>D := 8L; bool:BOOLEAN; PROCEDURE Test_AtomicInteger_CompareSwap() = BEGIN bool := AtomicInteger.CompareSwap(a, b, c); END Test_AtomicInteger_CompareSwap; C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 --- building in NT386 --- new source -> compiling Main.m3 "..\Main.m3", line 83: incompatible types (var) *** *** runtime error: *** An array subscript was out of range. *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", line 19 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil tinAtomic\CompareSwap.mg 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 ......... ......... ... more frames ... 1) The test is in error, wrong type on one of the params. 2) This could be specific to using m3back. 3) I'll poke around more. 4) Too bad we don't get line numbers in the stacks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 11 16:35:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 11 Feb 2010 16:35:43 +0100 Subject: [M3devel] use of date and bc in m3tests In-Reply-To: References: Message-ID: <20100211163543.l5ohnxt6qswcgc84@mail.elegosoft.com> Quoting Jay K : > Anyone: > > C:\dev2\cm3.2\m3-sys\m3tests\src\m3makefile > > Please try to remove the uses of date and bc. > > Thanks. I happend to see this some minutes ago (lots of other unread M3 mails in my box I'm afraid). AFAIK date and bc are only used in the quake code to time the tests. There are several things that can be done: 1. They can be used conditionally, depending on the existence of date and bc on the test system. That should be possible in quake. Of course test time reporting will then not work if they are missing. 2. Somebody can write simple M3 or C programs that will be used instead. Should not be too difficult, but somewhat redundant. 3. Ideally, quake itself should be able to time the execution of procedures and to do simple arithmetic. That would be the best solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Feb 11 17:53:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:53:24 -0500 Subject: [M3devel] atomics questions In-Reply-To: References: Message-ID: <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> On 11 Feb 2010, at 07:11, Jay K wrote: > What if some atomic operations aren't available? > > > If none are available, then they can all fallback to one giant lock. > Correct. > > But what if some are and some aren't? > A lock per type? Yes. Definitely. No unions in M3. > > That fails with like > union { > short s[2]; > int i; > } u; > > > and platform has atomic int but not atomic short. We do have atomic WIDECHARl > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 11 17:52:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:52:12 -0500 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) In-Reply-To: References: Message-ID: Steady on. I have it fixed. CHeckin coming. No need for more. On 11 Feb 2010, at 07:05, Jay K wrote: > TInt/TWord proposal > > > TInt needs to be a "complete" replacement for INTEGER and LONGINT. > Plus overflow checking. > Not just for the frontend, but also m3back. > > > TWord needs to be a "complete" replacement for Word and Long. > Therefore not likely any overflow checking. > > > But in reality you might need all four: > signed with silent overflow > signed with nonsilent overflow > unsigned with silent overflow > unsigned with nonsilent overflow > > > You can provide silent overflow by computing the result > and leaving it to the caller to ignore the BOOLEAN or not. > > > However in practise I don't think I needed silent overflow at all. > The only places I allow it, I think really I'm confusing TInt with TWord, > because TWord doesn't provide the right interface. > > > Settle on bits or bytes for sizes. > Enshrine it mostly in the public interface. > It maybe already is, granted. > But more so -- external users can construct the things. > > > Operations with mixed sizes shall not be allowed. <=== ***** > Just as INTEGER, LONGINT, Word, Long don't allow. > > > There would be some conversion functions, granted. > SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. > > > Constants Zero, One, MOne, etc. shall probably be > replaced with an array of 8 each, or maybe just > 1, 2, 4, 8 -- the number of bytes in the size. > > > "M" for "minus" is the wrong term. > It should N or Neg or Negative. > > > Something like: > TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) > TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) > TYPE ByteCount = [1..8]; (* wasteful, darn *) > > CONST Invalid = Target.Int{-1,IntBytes{0,..}}; > > CONST ZeroBytes = IntBytes{0,..}; > CONST OneBytes = IntBytes{1,0,..}; > CONST NegativeOneBytes = IntBytes{16_FF,..}; > CONST ThirtyTwoBytes = IntBytes{32,0,..}; > etc. > > CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, > Invalid, Target.Int{8,ZeroBytes}}; > > CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, > Invalid, Target.Int{8,OneBytes}}; > etc. > > > TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] > > > MAYBE as a possible simplification to the user: > > Introduce InternalTInt which is today's TInt and then: > TInt implies Target.Integer.bytes > TWord implies Target.Integer.bytes > new TLongint implies Target.Longint.bytes > new TLong implies Target.Longint.bytes > > > I really thing the short name "Long" is bad. > There is no indication of unsignedness in it. > It should be ULong or UnsignedLong or LongWord. > > > "Word" is to INTEGER as what is to LONGINT? > I don't think Long is the answer. > I'll start another thread on this. > > > m3back maintains a stack of mixed types, but I think it works out ok. > > > All that being said, I think what is there works and isn't terrible > and we don't need to solve lots of problems here. > > > I do think the variable sizing is a bit of a problem though. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 11 17:54:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:54:59 -0500 Subject: [M3devel] assertion failure in atomics In-Reply-To: References: Message-ID: I figured we'd shake some of these problems out fairly soon. I need to get the TInt/TWord stuff checked in before I move on this. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Feb 2010, at 08:23, Jay K wrote: > Tony if you don't have enough to do already: > > VAR > <*NOWARN*>a := 1; > <*NOWARN*>b := 2; > <*NOWARN*>c := 3; > <*NOWARN*>d := 4; > <*NOWARN*>A := 5L; > <*NOWARN*>B := 6L; > <*NOWARN*>C := 7L; > <*NOWARN*>D := 8L; > bool:BOOLEAN; > > PROCEDURE Test_AtomicInteger_CompareSwap() = > BEGIN > bool := AtomicInteger.CompareSwap(a, b, c); > END Test_AtomicInteger_CompareSwap; > > > C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 > --- building in NT386 --- > new source -> compiling Main.m3 > "..\Main.m3", line 83: incompatible types (var) > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", > line 19 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil > tinAtomic\CompareSwap.mg > 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 > 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 > 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 > 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 > 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 > 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 > 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 > 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 > 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 > ......... ......... ... more frames ... > > > 1) The test is in error, wrong type on one of the params. > 2) This could be specific to using m3back. > 3) I'll poke around more. > 4) Too bad we don't get line numbers in the stacks. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 23:46:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 22:46:51 +0000 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) In-Reply-To: References: , Message-ID: To be clear, I'm not working on this, was just thinking about it. - Jay Subject: Re: [M3devel] TInt/TWord proposal (at least what I was thinking..) From: hosking at cs.purdue.edu Date: Thu, 11 Feb 2010 11:52:12 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Steady on. I have it fixed. CHeckin coming. No need for more. On 11 Feb 2010, at 07:05, Jay K wrote: TInt/TWord proposal TInt needs to be a "complete" replacement for INTEGER and LONGINT. Plus overflow checking. Not just for the frontend, but also m3back. TWord needs to be a "complete" replacement for Word and Long. Therefore not likely any overflow checking. But in reality you might need all four: signed with silent overflow signed with nonsilent overflow unsigned with silent overflow unsigned with nonsilent overflow You can provide silent overflow by computing the result and leaving it to the caller to ignore the BOOLEAN or not. However in practise I don't think I needed silent overflow at all. The only places I allow it, I think really I'm confusing TInt with TWord, because TWord doesn't provide the right interface. Settle on bits or bytes for sizes. Enshrine it mostly in the public interface. It maybe already is, granted. But more so -- external users can construct the things. Operations with mixed sizes shall not be allowed. <=== ***** Just as INTEGER, LONGINT, Word, Long don't allow. There would be some conversion functions, granted. SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. Constants Zero, One, MOne, etc. shall probably be replaced with an array of 8 each, or maybe just 1, 2, 4, 8 -- the number of bytes in the size. "M" for "minus" is the wrong term. It should N or Neg or Negative. Something like: TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) TYPE ByteCount = [1..8]; (* wasteful, darn *) CONST Invalid = Target.Int{-1,IntBytes{0,..}}; CONST ZeroBytes = IntBytes{0,..}; CONST OneBytes = IntBytes{1,0,..}; CONST NegativeOneBytes = IntBytes{16_FF,..}; CONST ThirtyTwoBytes = IntBytes{32,0,..}; etc. CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, Invalid, Target.Int{8,ZeroBytes}}; CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, Invalid, Target.Int{8,OneBytes}}; etc. TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] MAYBE as a possible simplification to the user: Introduce InternalTInt which is today's TInt and then: TInt implies Target.Integer.bytes TWord implies Target.Integer.bytes new TLongint implies Target.Longint.bytes new TLong implies Target.Longint.bytes I really thing the short name "Long" is bad. There is no indication of unsignedness in it. It should be ULong or UnsignedLong or LongWord. "Word" is to INTEGER as what is to LONGINT? I don't think Long is the answer. I'll start another thread on this. m3back maintains a stack of mixed types, but I think it works out ok. All that being said, I think what is there works and isn't terrible and we don't need to solve lots of problems here. I do think the variable sizing is a bit of a problem though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 09:45:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 08:45:17 +0000 Subject: [M3devel] atomics questions In-Reply-To: <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> References: , <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> Message-ID: loophole allows for union, right? I know there is widechar, point was, if some hypothetical platform without atomic widechar. - Jay From: hosking at cs.purdue.edu Date: Thu, 11 Feb 2010 11:53:24 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomics questions On 11 Feb 2010, at 07:11, Jay K wrote: What if some atomic operations aren't available? If none are available, then they can all fallback to one giant lock. Correct. But what if some are and some aren't? A lock per type? Yes. Definitely. No unions in M3. That fails with like union { short s[2]; int i; } u; and platform has atomic int but not atomic short. We do have atomic WIDECHARl - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 10:17:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 09:17:14 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Message-ID: Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 10:57:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 09:57:08 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: Message-ID: Hm. I think there's a bigger problem here. I think, not sure, but i think compare_exhcange needs to take a "Var", not an address on the stack. See how it is storing the address to the stack and comparing that. Wrong. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 12 Feb 2010 09:17:14 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 15:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 14:20:39 +0000 Subject: [M3devel] m3back atomic current summary Message-ID: "m3back atomics summary" After a while of looking at this, I conclude that the atomics interface has a bunch of functionality that doesn't map all that well to what x86 provides, and vice versa. In particular x86 allows lock mem or reg lock mem xor reg lock mem and reg lock not mem lock neg mem and several others but the requirement of the atomic interface to return the new value makes these not line up. The new value doesn't come back in a register and rereading memory will not be atomic. Now I see why the C compiler's _InterlockedOr and such use _InterlockedCompareExchange in a small loop. Any xchg with a memory operand on x86 is always atomic. fetch_and_op for add/sub can probably be more efficient using xadd. You get back the old value but you can do the add a second time. I understand the point isn't necessarily to expose whatever x86 can do, but also to provide an interface that can be reasonably implemented across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). It's possible the front end (or backend) should notice if the return value is ignored, such as by preceding it with EVAL, and then those can be implemented more efficiently. The NT386 backend does not have the level of sophistication required to do that. I'm torn on even providing this stuff. It's all very tricky to use. However any "systems" language should probobably provide for a portable efficient lock package, that others can then easily use. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 15:26:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 14:26:25 +0000 Subject: [M3devel] m3back atomic current summary In-Reply-To: References: Message-ID: aha, Visual C++ does do this optimization: void __fastcall xInterlockedOr(long* a, long b) { _InterlockedOr(a, b); } long __fastcall yInterlockedOr(long* a, long b) { return _InterlockedOr(a, b); } void __fastcall xInterlockedXor(long* a, long b) { _InterlockedXor(a, b); } long __fastcall yInterlockedXor(long* a, long b) { return _InterlockedXor(a, b); } yelds: ; 1 : void __fastcall xInterlockedOr(long* a, long b) { _InterlockedOr(a, b); } 00000 f0 09 11 lock or DWORD PTR [ecx], edx 00003 c3 ret 0 ; 2 : long __fastcall yInterlockedOr(long* a, long b) { return _InterlockedOr(a, b); } 00010 56 push esi 00011 8b 01 mov eax, DWORD PTR [ecx] $LN3@: 00013 8b f0 mov esi, eax 00015 0b f2 or esi, edx 00017 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 0001b 75 f6 jne SHORT $LN3@ 0001d 5e pop esi 0001e c3 ret 0 ; 3 : void __fastcall xInterlockedXor(long* a, long b) { _InterlockedXor(a, b); } 00020 f0 31 11 lock xor DWORD PTR [ecx], edx ; 4 : long __fastcall yInterlockedXor(long* a, long b) { return _InterlockedXor(a, b); } 00030 56 push esi 00031 8b 01 mov eax, DWORD PTR [ecx] $LN3@: 00033 8b f0 mov esi, eax 00035 33 f2 xor esi, edx 00037 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 0003b 75 f6 jne SHORT $LN3@ 0003d 5e pop esi 0003e c3 ret 0 cool. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Date: Fri, 12 Feb 2010 14:20:39 +0000 Subject: [M3devel] m3back atomic current summary "m3back atomics summary" After a while of looking at this, I conclude that the atomics interface has a bunch of functionality that doesn't map all that well to what x86 provides, and vice versa. In particular x86 allows lock mem or reg lock mem xor reg lock mem and reg lock not mem lock neg mem and several others but the requirement of the atomic interface to return the new value makes these not line up. The new value doesn't come back in a register and rereading memory will not be atomic. Now I see why the C compiler's _InterlockedOr and such use _InterlockedCompareExchange in a small loop. Any xchg with a memory operand on x86 is always atomic. fetch_and_op for add/sub can probably be more efficient using xadd. You get back the old value but you can do the add a second time. I understand the point isn't necessarily to expose whatever x86 can do, but also to provide an interface that can be reasonably implemented across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). It's possible the front end (or backend) should notice if the return value is ignored, such as by preceding it with EVAL, and then those can be implemented more efficiently. The NT386 backend does not have the level of sophistication required to do that. I'm torn on even providing this stuff. It's all very tricky to use. However any "systems" language should probobably provide for a portable efficient lock package, that others can then easily use. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 15:49:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 09:49:14 -0500 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: Message-ID: <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. The C source: int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) { return AO_compare_and_swap_full(addr, *old, new); } generates: .globl _Atomic__CompareSwap_ordered _Atomic__CompareSwap_ordered: LFB526: pushq %rbp LCFI42: movq %rsp, %rbp LCFI43: movq (%rsi), %rax lock; cmpxchgq %rdx, (%rdi); setz %al movsbl %al,%eax leave ret LFE526: .align 4,0x90 On 12 Feb 2010, at 04:17, Jay K wrote: > Tony, currently I have atomic.compare_and_exchange generating e.g.: > > > load_address gv.2[_MM_Main] 56 > 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 > load_address gv.2[_MM_Main] 152 > 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 > load gv.2[_MM_Main] 156 Int.32 Int.32 > compare_exchange Int.32 Int.32 Int.32 > 0000019A: 8BC7 MOV EAX EDI > 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 > declare_temp 4 4 Addr F tv.35[T$35] -4 > 000001A2: 8975FC MOV tv.35[T$35] ESI > 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX > > > This might not be correct, but it is close. > > > Now, the thing is, the eax register is special to lock cmpxchg. > It always holds the comparison value. > > The point is, if cg.compare_exchange took its parameters as > parameters instead of on the stack, it could chose the > right register right away, instead of as above where it > choses the wrong one and then must mov it. > > Easy to change it like that? > > > I realize this is an m3back deficiency. > It does the register allocation too early. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 15:42:04 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 09:42:04 -0500 Subject: [M3devel] atomics questions In-Reply-To: References: , <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> Message-ID: No, the values must have the same BITSIZE or you get an error. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Feb 2010, at 03:45, Jay K wrote: > loophole allows for union, right? > I know there is widechar, point was, if some hypothetical platform without atomic widechar. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 11 Feb 2010 11:53:24 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] atomics questions > > On 11 Feb 2010, at 07:11, Jay K wrote: > > What if some atomic operations aren't available? > > > If none are available, then they can all fallback to one giant lock. > > > Correct. > > > But what if some are and some aren't? > > > > A lock per type? > > Yes. Definitely. No unions in M3. > > > That fails with like > union { > short s[2]; > int i; > } u; > > > and platform has atomic int but not atomic short. > > We do have atomic WIDECHARl > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 16:16:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 10:16:50 -0500 Subject: [M3devel] m3back atomic current summary In-Reply-To: References: Message-ID: <69C6DDBB-3300-4B60-9FDC-E06BAF0A955E@cs.purdue.edu> Jay, I don't understand your issues here. On 12 Feb 2010, at 09:20, Jay K wrote: > "m3back atomics summary" > > After a while of looking at this, I conclude > that the atomics interface has a bunch > of functionality that doesn't map all that > well to what x86 provides, and vice versa. > > > In particular x86 allows > lock mem or reg > lock mem xor reg > lock mem and reg > lock not mem > lock neg mem > and several others > > > but the requirement of the atomic interface > to return the new value makes these not line up. Which new value? There is no *requirement* that CompareSwap return the actual value in the register: The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: > The new value doesn't come back in a register > and rereading memory will not be atomic. Again, I don't understand this. > Now I see why the C compiler's _InterlockedOr and such > use _InterlockedCompareExchange in a small loop. > > > Any xchg with a memory operand on x86 is always atomic. > > > fetch_and_op for add/sub can probably be more efficient using xadd. > You get back the old value but you can do the add a second time. > > > I understand the point isn't necessarily to expose whatever x86 can do, > but also to provide an interface that can be reasonably implemented > across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). > > > It's possible the front end (or backend) should notice if the return value > is ignored, such as by preceding it with EVAL, and then those can be > implemented more efficiently. > The NT386 backend does not have the level of sophistication required to do that. > > > I'm torn on even providing this stuff. > It's all very tricky to use. > However any "systems" language should probobably > provide for a portable efficient lock package, that > others can then easily use. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 18:42:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 17:42:05 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> References: , <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Message-ID: It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack. We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be. We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register. Again, if m3back were multi pass or somehow smarter, it'd be moot. I'll be looking into make it one or both of these maybe sometime soon. - Jay From: hosking at cs.purdue.edu Date: Fri, 12 Feb 2010 09:49:14 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. The C source: int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) { return AO_compare_and_swap_full(addr, *old, new); } generates: .globl _Atomic__CompareSwap_ordered _Atomic__CompareSwap_ordered: LFB526: pushq %rbp LCFI42: movq %rsp, %rbp LCFI43: movq (%rsi), %rax lock; cmpxchgq %rdx, (%rdi); setz %al movsbl %al,%eax leave ret LFE526: .align 4,0x90 On 12 Feb 2010, at 04:17, Jay K wrote: Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 19:35:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 13:35:27 -0500 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: , <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Message-ID: Let's be explicit here. You want compare_exchange to take an explicit Var? For which argument? The memory location being manipulated or the expected value? compare_exchange (t: MType; u: ZType; r: IType; success, failure: MemoryOrder); (* tmp := Mem[s2.A].t; IF (tmp = Mem[s1.A].t) THEN Mem [s2.A].t := s0.u; s2.r := 1; pop(2); ELSE Mem [s1.A].t := tmp; s2.r := 0; pop(2); END; This is permitted to fail spuriously, leaving Mem [s1.A] unchanged. *) So, you want s1 to be a Var or s2? On 12 Feb 2010, at 12:42, Jay K wrote: > It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack. > We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be. > We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register. > > Again, if m3back were multi pass or somehow smarter, it'd be moot. > I'll be looking into make it one or both of these maybe sometime soon. > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 12 Feb 2010 09:49:14 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? > > Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. > > The C source: > > int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) > { return AO_compare_and_swap_full(addr, *old, new); } > > generates: > > .globl _Atomic__CompareSwap_ordered > _Atomic__CompareSwap_ordered: > LFB526: > pushq %rbp > LCFI42: > movq %rsp, %rbp > LCFI43: > movq (%rsi), %rax > lock; cmpxchgq %rdx, (%rdi); setz %al > movsbl %al,%eax > leave > ret > LFE526: > .align 4,0x90 > > > > On 12 Feb 2010, at 04:17, Jay K wrote: > > Tony, currently I have atomic.compare_and_exchange generating e.g.: > > > load_address gv.2[_MM_Main] 56 > 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 > load_address gv.2[_MM_Main] 152 > 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 > load gv.2[_MM_Main] 156 Int.32 Int.32 > compare_exchange Int.32 Int.32 Int.32 > 0000019A: 8BC7 MOV EAX EDI > 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 > declare_temp 4 4 Addr F tv.35[T$35] -4 > 000001A2: 8975FC MOV tv.35[T$35] ESI > 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX > > > This might not be correct, but it is close. > > > Now, the thing is, the eax register is special to lock cmpxchg. > It always holds the comparison value. > > The point is, if cg.compare_exchange took its parameters as > parameters instead of on the stack, it could chose the > right register right away, instead of as above where it > choses the wrong one and then must mov it. > > Easy to change it like that? > > > I realize this is an m3back deficiency. > It does the register allocation too early. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 13 16:25:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 13 Feb 2010 16:25:26 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed Message-ID: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. But I don't seem to be able to upgrade to the current head of the release branch even with the upgrade script: http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console What do I miss? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Feb 14 13:55:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Feb 2010 12:55:42 +0000 Subject: [M3devel] m3back/longint/atomics Message-ID: As far as I know/can remember, longint and atomics should all work now on NT386. Atomics only currently for 32bit types. There are still a few small inefficiencies to maybe deal with. I'll add 64bit shortly and maybe 8 and 16. We should probably add *a lot* more test coverage in p226 and p227. e.g. longint multiply/add/sub/divide, not just insert/extract like I did a bunch of. Still to fix the Win32 m3core/libm3 to not always truncate file sizes. Still maybe to do something about rd/wr...? Still to wonder about NT386/longint support in the release branch? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 15 09:29:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Feb 2010 08:29:07 +0000 Subject: [M3devel] int64 division? Message-ID: Tony, there's something wrong with 64bit division. This program fails on LINUXLIBC6. I fixed it for NT386 (wrong parameter order) but the two are wildly divergent. MODULE Main; PROCEDURE NotConstL(a: LONGINT): LONGINT = BEGIN RETURN a; END NotConstL; BEGIN <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *> <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *> END Main. (gdb) x/200i Main_M3 0x804b03e : push %ebp 0x804b03f : mov %esp,%ebp 0x804b041 : push %ebx 0x804b042 : sub $0x14,%esp 0x804b045 : call 0x804b04a 0x804b04a : pop %ebx 0x804b04b : add $0x3a50a,%ebx 0x804b051 : mov 0x8(%ebp),%eax 0x804b054 : xor $0x1,%eax 0x804b057 : test %al,%al 0x804b059 : jne 0x804b100 0x804b05f : sub $0x8,%esp 0x804b062 : push $0x0 0x804b064 : push $0x1 0x804b066 : call 0x804b024 0x804b06b : add $0x10,%esp 0x804b06e : mov %eax,0xfffffff0(%ebp) 0x804b071 : mov %edx,0xfffffff4(%ebp) 0x804b074 : mov 0xfffffff0(%ebp),%eax 0x804b077 : mov 0xfffffff4(%ebp),%edx 0x804b07a : push $0x80000000 0x804b07f : push $0x0 0x804b081 : push %edx 0x804b082 : push %eax 0x804b0d0 : push %edx 0x804b0d1 : push %eax 0x804b0d2 : call 0x804bbd4 0x804b0d7 : add $0x10,%esp Right here this can't be correct. 64bit results are returned in the edx:eax pair, edx is high, eax low. (32bit results are turned in just eax.) It looks like m3_divL returned the correct value but whatever is happening here is trashing the results. 0x804b0da : mov %eax,%edx 0x804b0dc : sar $0x1f,%edx 0x804b0df : mov %edx,%ecx 0x804b0e1 : xor $0x7fffffff,%ecx 0x804b0e7 : xor $0xffffffff,%eax 0x804b0ea : or %ecx,%eax 0x804b0ec : test %eax,%eax 0x804b0ee : je 0x804b100 0x804b0f0 : sub $0xc,%esp 0x804b0f3 : push $0x140 0x804b0f8 : call 0x804b10b <_m3_fault> 0x804b0fd : add $0x10,%esp 0x804b100 : mov 0xfffffc74(%ebx),%eax 0x804b106 : mov 0xfffffffc(%ebp),%ebx 0x804b109 : leave 0x804b10a : ret 0x804b10b <_m3_fault>: push %ebp 0x804b10c <_m3_fault+1>: mov %esp,%ebp 0x804b10e <_m3_fault+3>: push %ebx I'll dig a bit more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 15 09:39:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Feb 2010 08:39:07 +0000 Subject: [M3devel] int64 division? In-Reply-To: References: Message-ID: Should be ok now. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Mon, 15 Feb 2010 08:29:07 +0000 Subject: [M3devel] int64 division? Tony, there's something wrong with 64bit division. This program fails on LINUXLIBC6. I fixed it for NT386 (wrong parameter order) but the two are wildly divergent. MODULE Main; PROCEDURE NotConstL(a: LONGINT): LONGINT = BEGIN RETURN a; END NotConstL; BEGIN <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *> <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *> END Main. (gdb) x/200i Main_M3 0x804b03e : push %ebp 0x804b03f : mov %esp,%ebp 0x804b041 : push %ebx 0x804b042 : sub $0x14,%esp 0x804b045 : call 0x804b04a 0x804b04a : pop %ebx 0x804b04b : add $0x3a50a,%ebx 0x804b051 : mov 0x8(%ebp),%eax 0x804b054 : xor $0x1,%eax 0x804b057 : test %al,%al 0x804b059 : jne 0x804b100 0x804b05f : sub $0x8,%esp 0x804b062 : push $0x0 0x804b064 : push $0x1 0x804b066 : call 0x804b024 0x804b06b : add $0x10,%esp 0x804b06e : mov %eax,0xfffffff0(%ebp) 0x804b071 : mov %edx,0xfffffff4(%ebp) 0x804b074 : mov 0xfffffff0(%ebp),%eax 0x804b077 : mov 0xfffffff4(%ebp),%edx 0x804b07a : push $0x80000000 0x804b07f : push $0x0 0x804b081 : push %edx 0x804b082 : push %eax 0x804b0d0 : push %edx 0x804b0d1 : push %eax 0x804b0d2 : call 0x804bbd4 0x804b0d7 : add $0x10,%esp Right here this can't be correct. 64bit results are returned in the edx:eax pair, edx is high, eax low. (32bit results are turned in just eax.) It looks like m3_divL returned the correct value but whatever is happening here is trashing the results. 0x804b0da : mov %eax,%edx 0x804b0dc : sar $0x1f,%edx 0x804b0df : mov %edx,%ecx 0x804b0e1 : xor $0x7fffffff,%ecx 0x804b0e7 : xor $0xffffffff,%eax 0x804b0ea : or %ecx,%eax 0x804b0ec : test %eax,%eax 0x804b0ee : je 0x804b100 0x804b0f0 : sub $0xc,%esp 0x804b0f3 : push $0x140 0x804b0f8 : call 0x804b10b <_m3_fault> 0x804b0fd : add $0x10,%esp 0x804b100 : mov 0xfffffc74(%ebx),%eax 0x804b106 : mov 0xfffffffc(%ebp),%ebx 0x804b109 : leave 0x804b10a : ret 0x804b10b <_m3_fault>: push %ebp 0x804b10c <_m3_fault+1>: mov %esp,%ebp 0x804b10e <_m3_fault+3>: push %ebx I'll dig a bit more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 16 15:18:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 15:18:12 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> Message-ID: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Quoting Olaf Wagner : > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > But I don't seem to be able to upgrade to the current head of the > release branch even with the upgrade script: > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > What do I miss? FYI The update to the current release branch tip of 5.8 requires an RC4 build as an intermediate step. It is not possible to update directly from older versions. This has been confirmed on FreeBSD4 and PPC_LINUX. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 16 15:37:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 15:37:26 +0100 Subject: [M3devel] release engineering: RC5 Message-ID: <20100216153726.168giuvpusskw444@mail.elegosoft.com> It took me some time to get the regression testing via Hudson up-to-date again, but it should be OK now. Can we rollout RC5 (which will hopefully become the final release) now? Is anybody still working on changes/fixes for the release? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 16 16:12:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 16:12:52 +0100 Subject: [M3devel] m3back/longint/atomics In-Reply-To: References: Message-ID: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Quoting Jay K : > > As far as I know/can remember, longint and atomics should all work > now on NT386. > > Atomics only currently for 32bit types. > There are still a few small inefficiencies to maybe deal with. > I'll add 64bit shortly and maybe 8 and 16. > > > We should probably add *a lot* more test coverage in p226 and p227. > > e.g. longint multiply/add/sub/divide, not just insert/extract like I > did a bunch of. Any volunteers to increase the test coverage? > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > > Still maybe to do something about rd/wr...? > > Still to wonder about NT386/longint support in the release branch? Should we / will you merge this stuff to the release branch? Or should we release without it? How local are the changes? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 17 02:46:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 01:46:49 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Message-ID: > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 02:44:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 01:44:00 +0000 Subject: [M3devel] m3back/longint/atomics In-Reply-To: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Message-ID: NT386/longint changes are almost entirely in the m3back package. There is also some small easy stuff in m3-libs/m3core/src/Csupport/common/hand.c. It'd be really great if anyone could test any of this and if anyone could review the diff between release and head. Not just me. The changes for longint are quite large, even if local. I can port them, in the case of m3back, just copy, and make sure the atomics stuff doesn't cause problems (it should be unused). There is also a small change in m3front so that longint can be initialized. That affects all platforms. And a small change in m3cc/parse.c for div/mod of longint on non-NT386. I have to test mod yet but my fix probably helps it. It'd be really great if anyone could do anything with this stuff. ie. for now in head, then could easily port to release. We can of course release either way, depending on how satisfied people are with 32bit longint on NT386. i.e. longint isn't useful portably, but it is useful on non-NT386 platforms. - Jay > Date: Tue, 16 Feb 2010 16:12:52 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back/longint/atomics > > Quoting Jay K : > > > > > As far as I know/can remember, longint and atomics should all work > > now on NT386. > > > > Atomics only currently for 32bit types. > > There are still a few small inefficiencies to maybe deal with. > > I'll add 64bit shortly and maybe 8 and 16. > > > > > > We should probably add *a lot* more test coverage in p226 and p227. > > > > e.g. longint multiply/add/sub/divide, not just insert/extract like I > > did a bunch of. > > Any volunteers to increase the test coverage? > > > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > > > > Still maybe to do something about rd/wr...? > > > > Still to wonder about NT386/longint support in the release branch? > > Should we / will you merge this stuff to the release branch? > Or should we release without it? How local are the changes? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 08:54:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Message-ID: I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 08:56:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 07:56:35 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, Message-ID: oops looks like I deleted my fixes. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 09:55:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 08:55:36 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, , , Message-ID: ok should be better now, I only tested LINUXLIBC6 5.4.0 to current. I can look at and fix more later. But this is "controversial" stuff and has to end somewhere. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:56:35 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed oops looks like I deleted my fixes. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 17 11:33:37 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 17 Feb 2010 11:33:37 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, , , Message-ID: <20100217113337.amzp2ojjusgw844k@mail.elegosoft.com> Quoting Jay K : > > ok should be better now, I only tested LINUXLIBC6 5.4.0 to current. > > I can look at and fix more later. > > But this is "controversial" stuff and has to end somewhere. Jay, no need to do more. I didn't mean that you should start fixing immediately; my mail was just to document the fact in the lists. Once 5.8 is out we can forget about older releases, too, I think. Olaf > > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 17 Feb 2010 07:56:35 +0000 > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > > > oops looks like I deleted my fixes. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 17 Feb 2010 07:54:04 +0000 > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > > > I can build current release from LINUXLIBC6 release 5.4.0 now. > Some of the fixes are applicable to PPC_LINUX. > I can test it against an older release. > > I could probably easily make it work back to older versions and more targets. > I had removed some of the workarounds, but they were fairly clean. > Stuff like not using -m32 on older cm3cg, etc. > > You cannot build current m3core/libm3 with old cm3 or old cm3cg. > I used "upgrade.py" which foists current config files on older > compiler, and, you know, doesn't build m3core/libm3 until after it > has a current compiler. > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] FreeBSD4 update on releng branch failed > Date: Wed, 17 Feb 2010 01:46:49 +0000 > > > > > It is not possible to update directly from older versions. > > Maybe nice to "fix". > I'll try to get to it. > > - Jay > > >> Date: Tue, 16 Feb 2010 15:18:12 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] FreeBSD4 update on releng branch failed >> >> Quoting Olaf Wagner : >> >> > Yesterday I've finally added a Hudson slave again for the >> FreeBSD4 platform. >> > But I don't seem to be able to upgrade to the current head of the >> > release branch even with the upgrade script: >> > >> > >> http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console >> > >> > What do I miss? >> >> FYI >> >> The update to the current release branch tip of 5.8 requires an RC4 >> build as an intermediate step. It is not possible to update directly from >> older versions. >> >> This has been confirmed on FreeBSD4 and PPC_LINUX. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 17 12:07:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 11:07:02 +0000 Subject: [M3devel] hand.c : m3_div Message-ID: Tony, presumably one of these will do: C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\tree.def /* Division for integer result that rounds the quotient toward zero. */ DEFTREECODE (TRUNC_DIV_EXPR, "trunc_div_expr", tcc_binary, 2) /* Division for integer result that rounds the quotient toward infinity. */ DEFTREECODE (CEIL_DIV_EXPR, "ceil_div_expr", tcc_binary, 2) /* Division for integer result that rounds toward minus infinity. */ DEFTREECODE (FLOOR_DIV_EXPR, "floor_div_expr", tcc_binary, 2) /* Division for integer result that rounds toward nearest integer. */ DEFTREECODE (ROUND_DIV_EXPR, "round_div_expr", tcc_binary, 2) /* Four kinds of remainder that go with the four kinds of division. */ DEFTREECODE (TRUNC_MOD_EXPR, "trunc_mod_expr", tcc_binary, 2) DEFTREECODE (CEIL_MOD_EXPR, "ceil_mod_expr", tcc_binary, 2) DEFTREECODE (FLOOR_MOD_EXPR, "floor_mod_expr", tcc_binary, 2) DEFTREECODE (ROUND_MOD_EXPR, "round_mod_expr", tcc_binary, 2) I can look into it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 17 15:52:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 17 Feb 2010 09:52:17 -0500 Subject: [M3devel] hand.c : m3_div In-Reply-To: References: Message-ID: <5C81AD48-5F6F-4741-AD07-D7D26CD1DC7B@cs.purdue.edu> Yes, I've wondered that for some time, but never been certain what code they produce.... There's no way to generate the ones we would want from C. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 17 Feb 2010, at 06:07, Jay K wrote: > Tony, presumably one of these will do: > > > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\tree.def > > /* Division for integer result that rounds the quotient toward zero. */ > DEFTREECODE (TRUNC_DIV_EXPR, "trunc_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds the quotient toward infinity. */ > DEFTREECODE (CEIL_DIV_EXPR, "ceil_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds toward minus infinity. */ > DEFTREECODE (FLOOR_DIV_EXPR, "floor_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds toward nearest integer. */ > DEFTREECODE (ROUND_DIV_EXPR, "round_div_expr", tcc_binary, 2) > > /* Four kinds of remainder that go with the four kinds of division. */ > > DEFTREECODE (TRUNC_MOD_EXPR, "trunc_mod_expr", tcc_binary, 2) > DEFTREECODE (CEIL_MOD_EXPR, "ceil_mod_expr", tcc_binary, 2) > DEFTREECODE (FLOOR_MOD_EXPR, "floor_mod_expr", tcc_binary, 2) > DEFTREECODE (ROUND_MOD_EXPR, "round_mod_expr", tcc_binary, 2) > > > I can look into it. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 00:47:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 23:47:11 +0000 Subject: [M3devel] replacing hand.c with Modula-3? Message-ID: ? I have a little more reduction to do here (e.g. remove table or tables, at least the exported NT386-specific one; replace set_eq and ne with memcmp even for m3cg), but stuff will remain. It'd be nifty if Modula-3 functions/variables could be explicitly named for compat but I'll just go ahead and change the names and break compat. We break compat in other ways and it seems ok, unless people object (e.g. I removed m3_div because current backend doesn't generate calls to it, but it could/should be preserved for compat with older binaries). - Jay ________________________________ > From: jay > > > I see no great reason for hand.c to be in C. > > It should be easy to rewrite in Modula-3, using the Word interface. > > The only question really is, what to call things? > > M3_BUILTIN__set_union, etc.? > > I think I see M3_BUILTIN somewhere. > > RTHooks__set_union, etc.? > > SomethingElse__set_union? > > SomethingElse__somethingElse while we're at it? > > > > > M3Set__Union > > M3Set__Singleton -- probably not even worth being a function > > M3Set__Intersect > > etc.? > > > > > > - Jay > From hosking at cs.purdue.edu Thu Feb 18 03:03:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 17 Feb 2010 21:03:33 -0500 Subject: [M3devel] replacing hand.c with Modula-3? In-Reply-To: References: Message-ID: <15D830F3-ACF0-435D-B27B-BC42D2833621@cs.purdue.edu> Let's not get into the compatibility rathole. Better to stay clean w.r.to current builds. On 17 Feb 2010, at 18:47, Jay K wrote: > > ? > > > I have a little more reduction to do here (e.g. remove table or tables, at least the exported NT386-specific one; replace set_eq and ne with memcmp even for m3cg), but stuff will remain. > > > It'd be nifty if Modula-3 functions/variables could be explicitly named for compat but I'll just go ahead and change the names and break compat. We break compat in other ways and it seems ok, unless people object (e.g. I removed m3_div because current backend doesn't generate calls to it, but it could/should be preserved for compat with older binaries). > > > > - Jay > > ________________________________ >> From: jay >> >> >> I see no great reason for hand.c to be in C. >> >> It should be easy to rewrite in Modula-3, using the Word interface. >> >> The only question really is, what to call things? >> >> M3_BUILTIN__set_union, etc.? >> >> I think I see M3_BUILTIN somewhere. >> >> RTHooks__set_union, etc.? >> >> SomethingElse__set_union? >> >> SomethingElse__somethingElse while we're at it? >> >> >> >> >> M3Set__Union >> >> M3Set__Singleton -- probably not even worth being a function >> >> M3Set__Intersect >> >> etc.? >> >> >> >> >> >> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 18 11:45:58 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 11:45:58 +0100 Subject: [M3devel] Auto-discard notification In-Reply-To: References: Message-ID: <20100218114558.rn033djp4wgs0wsg@mail.elegosoft.com> You need to subscribe to the list to be able to post to it. However, I can quickly answer some of your questions: o You need to use the script upgrade.sh or upgrade.py to perform a full core system upgrade from source. This bootstraps the compiler and runtime libraries using an existing compiler and installs everything it has built. "install-cm3-compiler.sh upgrade" will just install a compiler from your workspace. o Failures in the packages odbc, postgres95, and db are most likely due to missing libraries on your system. Just install the needed third party packages for this software with the appropriate tools for your system (e.g. pkg_add, apt-get, ...) and adapt the library paths in the cm3 config files if they still aren't found. Have a look at /usr/local/cm3/bin/cm3.cfg and its includes. o If the packages are missing, that should not be a problem, too, as long as you don't need their functionality. Hope this helps, Olaf Quoting m3devel-bounces at elegosoft.com: > The attached message has been automatically discarded. My CM3 build was getting pretty old, so I decided to re-install from scratch, and came across a number of problems whose solution wasn't obvious. Could someone please confirm that I got the answers right? (This was on a current x86 Linux box.) I installed from the cm3-bin-core tarfile, which gave me a basic m3 compiler and linker. I then tried installing from the cm3-src-all tarfile, with the command: install-cm3-compiler.sh upgrade since I wanted to force a compiler upgrade for various reasons. Should I have used do-cm3-core.sh buildship as well? Could I have used do-cm3-core.sh instead, if I didn't want to rebuild the compiler? I then tried: do-cm3-std.sh buildship which failed on the packages odbc, postgres95, and db (smalldb built correctly). This is where I ran into real problems, since I couldn't find any documentation on the packages to be built, or a way of restarting a failed build. I finally decided that pkginfo.txt was the one, and edited it. Re-running do-cm3-std then got me a working system. Was this the right approach, and does the pkginfo.txt format allow for commenting out lines (I just deleted the successful packages), and if so what is the comment symbol (; ? # ?). Is there an easier way to restart a failed build? Is any of this documented anywhere? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 18 12:26:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 11:26:19 +0000 Subject: [M3devel] other users of TInt Message-ID: I'll get to this soon... == package C:\dev2\cm3.2\m3-sys\m3tools == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling M3Lexer.i3 new source -> compiling M3Lexer.m3 "..\src\M3Lexer.m3", line 123: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 123: incompatible types (i) "..\src\M3Lexer.m3", line 126: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 126: incompatible types (i) "..\src\M3Lexer.m3", line 130: too many actual parameters: TWord.New "..\src\M3Lexer.m3", line 130: incompatible types (i) 6 errors encountered new source -> compiling M3AST.i3 new source -> compiling M3AST.m3 new source -> compiling M3Parse.m3 new source -> compiling M3Scope.i3 new source -> compiling M3Scope.m3 new source -> compiling M3Type.i3 new source -> compiling M3Type.m3 "..\src\M3Type.m3", line 48: unknown qualification '.' (x) "..\src\M3Type.m3", line 48: not enough values specified "..\src\M3Type.m3", line 251: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 251: incompatible types (i) "..\src\M3Type.m3", line 292: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 292: incompatible types (i) 6 errors encountered new source -> compiling M3Const.i3 new source -> compiling M3Builtin.i3 new source -> compiling M3ArrVal.i3 new source -> compiling M3RecVal.i3 new source -> compiling M3SetVal.i3 new source -> compiling M3Const.m3 "..\src\M3Const.m3", line 865: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 865: incompatible types (i) "..\src\M3Const.m3", line 1164: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1164: incompatible types (i) "..\src\M3Const.m3", line 1174: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1174: incompatible types (i) 6 errors encountered new source -> compiling M3SetVal.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 18 12:57:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 12:57:34 +0100 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Message-ID: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> If I understand Jay correctly, it wouldn't be too difficult to bring the m3ack LONGINT changes for Windows into the release branch, but more testing would be needed. Randy, you're the only one I remember offhand who actively uses M3 on Windows except for Jay. Could you have a closer look at it? (Changes are only on the trunk right now.) Or is anybody else here lurking and eager to do some Windows-based tests? If nobody volunteers, I'm afraid we will have to release without 64bit LONGINT on Windows. Olaf Quoting Jay K : > NT386/longint changes are almost entirely in the m3back package. > > There is also some small easy stuff in > m3-libs/m3core/src/Csupport/common/hand.c. > > It'd be really great if anyone could test any of this and if > anyone could review the diff between release and head. > > Not just me. > > The changes for longint are quite large, even if local. > > I can port them, in the case of m3back, just copy, and make sure > the atomics stuff doesn't cause problems (it should be unused). > > There is also a small change in m3front so that longint can be initialized. > That affects all platforms. > > And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > I have to test mod yet but my fix probably helps it. > > It'd be really great if anyone could do anything with this stuff. > ie. for now in head, then could easily port to release. > > We can of course release either way, depending on how satisfied people > are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > is useful on non-NT386 platforms. > > - Jay > >> Date: Tue, 16 Feb 2010 16:12:52 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3back/longint/atomics >> >> Quoting Jay K : >> >> > >> > As far as I know/can remember, longint and atomics should all work >> > now on NT386. >> > >> > Atomics only currently for 32bit types. >> > There are still a few small inefficiencies to maybe deal with. >> > I'll add 64bit shortly and maybe 8 and 16. >> > >> > >> > We should probably add *a lot* more test coverage in p226 and p227. >> > >> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >> > did a bunch of. >> >> Any volunteers to increase the test coverage? >> >> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >> > >> > Still maybe to do something about rd/wr...? >> > >> > Still to wonder about NT386/longint support in the release branch? >> >> Should we / will you merge this stuff to the release branch? >> Or should we release without it? How local are the changes? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Feb 18 12:51:17 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 18 Feb 2010 06:51:17 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> Message-ID: <20100218115116.GA2336@topoi.pooq.com> On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. I'm somewhat interested in getting my programs working on Windows, but I haven't yet installed *anything* on the pristine XP on my netbook. I'm hesitant about connecting it to the net; the only antivirus I have is refraining from using Windows, and it works fairly well(!). As far as I know, I have no way of reinstalling Windows if my Windows is damaged. I/m mostly interested in getting my software into a state where Windows nonprogrammers can use it; I use Linux myself. What would I need to do (from scratch; I'm not a Windows user; I just happened not to delete Windows when I installed Linux)? The machine is A 32-bit intel, and so it just might not be relevant to testing 64-bit LONGINT. -- hendrik From jay.krell at cornell.edu Thu Feb 18 15:11:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:11:33 +0000 Subject: [M3devel] other users of TInt In-Reply-To: References: Message-ID: Sorry, it looks like I was out of sync. Still something wierd to track down.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 18 Feb 2010 11:26:19 +0000 Subject: [M3devel] other users of TInt I'll get to this soon... == package C:\dev2\cm3.2\m3-sys\m3tools == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling M3Lexer.i3 new source -> compiling M3Lexer.m3 "..\src\M3Lexer.m3", line 123: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 123: incompatible types (i) "..\src\M3Lexer.m3", line 126: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 126: incompatible types (i) "..\src\M3Lexer.m3", line 130: too many actual parameters: TWord.New "..\src\M3Lexer.m3", line 130: incompatible types (i) 6 errors encountered new source -> compiling M3AST.i3 new source -> compiling M3AST.m3 new source -> compiling M3Parse.m3 new source -> compiling M3Scope.i3 new source -> compiling M3Scope.m3 new source -> compiling M3Type.i3 new source -> compiling M3Type.m3 "..\src\M3Type.m3", line 48: unknown qualification '.' (x) "..\src\M3Type.m3", line 48: not enough values specified "..\src\M3Type.m3", line 251: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 251: incompatible types (i) "..\src\M3Type.m3", line 292: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 292: incompatible types (i) 6 errors encountered new source -> compiling M3Const.i3 new source -> compiling M3Builtin.i3 new source -> compiling M3ArrVal.i3 new source -> compiling M3RecVal.i3 new source -> compiling M3SetVal.i3 new source -> compiling M3Const.m3 "..\src\M3Const.m3", line 865: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 865: incompatible types (i) "..\src\M3Const.m3", line 1164: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1164: incompatible types (i) "..\src\M3Const.m3", line 1174: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1174: incompatible types (i) 6 errors encountered new source -> compiling M3SetVal.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 15:14:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:14:01 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218115116.GA2336@topoi.pooq.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com>, , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <20100218115116.GA2336@topoi.pooq.com> Message-ID: Henrik, if you won't install anything, then you can't test anything. Modula-3 is not going to break your XP install. Nor is Visual C++. > machine is A 32-bit intel, and so it just might not be relevant to > testing 64-bit LONGINT. False! LONGINT is 64bits on all platforms. We have no 64bit Windows target currently. - Jay > Date: Thu, 18 Feb 2010 06:51:17 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > > If I understand Jay correctly, it wouldn't be too difficult to bring > > the m3ack LONGINT changes for Windows into the release branch, but > > more testing would be needed. > > > > Randy, you're the only one I remember offhand who actively uses M3 > > on Windows except for Jay. Could you have a closer look at it? > > (Changes are only on the trunk right now.) > > > > Or is anybody else here lurking and eager to do some Windows-based tests? > > > > If nobody volunteers, I'm afraid we will have to release without 64bit > > LONGINT on Windows. > > I'm somewhat interested in getting my programs working on Windows, but I > haven't yet installed *anything* on the pristine XP on my netbook. I'm > hesitant about connecting it to the net; the only antivirus I have is > refraining from using Windows, and it works fairly well(!). As far as I > know, I have no way of reinstalling Windows if my Windows is damaged. > > I/m mostly interested in getting my software into a state where Windows > nonprogrammers can use it; I use Linux myself. > > What would I need to do (from scratch; I'm not a Windows user; I just > happened not to delete Windows when I installed Linux)? The > machine is A 32-bit intel, and so it just might not be relevant to > testing 64-bit LONGINT. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 15:21:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:21:37 +0000 Subject: [M3devel] other users of TInt In-Reply-To: References: , Message-ID: > Still something wierd to track down.. typo in test case, oops -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Feb 18 15:26:43 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 18 Feb 2010 09:26:43 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> Message-ID: <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> I can certainly run some tests on Windows. I don't have any code that uses longint, so either someone needs to identify which existing programs I can build and run to do the tests, OR I suppose I can write something if you can give me an idea of how extensive the tests you want. I've been trying to keep my system updated to the latest sources on the main trunk, but I've been swamped lately and I'm afraid I'm a few weeks stale right now. I'll remedy that shortly. Regards, Randy ________________________________ From: Olaf Wagner [wagner at elegosoft.com] Sent: Thursday, February 18, 2010 6:57 AM To: Jay K Cc: m3devel Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics If I understand Jay correctly, it wouldn't be too difficult to bring the m3ack LONGINT changes for Windows into the release branch, but more testing would be needed. Randy, you're the only one I remember offhand who actively uses M3 on Windows except for Jay. Could you have a closer look at it? (Changes are only on the trunk right now.) Or is anybody else here lurking and eager to do some Windows-based tests? If nobody volunteers, I'm afraid we will have to release without 64bit LONGINT on Windows. Olaf Quoting Jay K : > NT386/longint changes are almost entirely in the m3back package. > > There is also some small easy stuff in > m3-libs/m3core/src/Csupport/common/hand.c. > > It'd be really great if anyone could test any of this and if > anyone could review the diff between release and head. > > Not just me. > > The changes for longint are quite large, even if local. > > I can port them, in the case of m3back, just copy, and make sure > the atomics stuff doesn't cause problems (it should be unused). > > There is also a small change in m3front so that longint can be initialized. > That affects all platforms. > > And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > I have to test mod yet but my fix probably helps it. > > It'd be really great if anyone could do anything with this stuff. > ie. for now in head, then could easily port to release. > > We can of course release either way, depending on how satisfied people > are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > is useful on non-NT386 platforms. > > - Jay > >> Date: Tue, 16 Feb 2010 16:12:52 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3back/longint/atomics >> >> Quoting Jay K : >> >> > >> > As far as I know/can remember, longint and atomics should all work >> > now on NT386. >> > >> > Atomics only currently for 32bit types. >> > There are still a few small inefficiencies to maybe deal with. >> > I'll add 64bit shortly and maybe 8 and 16. >> > >> > >> > We should probably add *a lot* more test coverage in p226 and p227. >> > >> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >> > did a bunch of. >> >> Any volunteers to increase the test coverage? >> >> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >> > >> > Still maybe to do something about rd/wr...? >> > >> > Still to wonder about NT386/longint support in the release branch? >> >> Should we / will you merge this stuff to the release branch? >> Or should we release without it? How local are the changes? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Feb 18 15:40:05 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 18 Feb 2010 09:40:05 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218115116.GA2336@topoi.pooq.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <20100218115116.GA2336@topoi.pooq.com> Message-ID: <357B777B-B964-418C-98A8-83AF9F6DB54F@mimectl> Hendrik: You can get a FREE antivirus for Windows from several sources. Microsoft has one, but I use AVG. Here is a link to the AVG download: http://download.cnet.com/AVG-Anti-Virus-Free-Edition/3000-2239_4-10320142.html?part=dl-10044820&subj=dl&tag=button&cdlPid=11014801 I don't think installing CM3 will "damage" your system. You will need some sort of C compiler/linker though because there is some C code that gets compiled and cm3 doesn't come with its own linker. I use the FREE Microsoft Visual Studio C++ 2008 Express Edition. Here is a link to the download: http://www.microsoft.com/express/downloads/#2008-Visual-CPP I have some scripts in cm3/scripts/dev/windows that may be useful to you on Windows. If you just want to get a working cm3 on your windows system, I could build you a minimal (or a full) distribution and ZIP it up and send to you. Then you would just unzip to a folder, say C:\cm3. There is nothing to "install" here that can mess up your registry. You will still need the Visual C++ Express to get the Microsoft Linker if you want to build any new programs. Regards, Randy ________________________________ From: hendrik at topoi.pooq.com [hendrik at topoi.pooq.com] Sent: Thursday, February 18, 2010 6:51 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. I'm somewhat interested in getting my programs working on Windows, but I haven't yet installed *anything* on the pristine XP on my netbook. I'm hesitant about connecting it to the net; the only antivirus I have is refraining from using Windows, and it works fairly well(!). As far as I know, I have no way of reinstalling Windows if my Windows is damaged. I/m mostly interested in getting my software into a state where Windows nonprogrammers can use it; I use Linux myself. What would I need to do (from scratch; I'm not a Windows user; I just happened not to delete Windows when I installed Linux)? The machine is A 32-bit intel, and so it just might not be relevant to testing 64-bit LONGINT. -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 18 15:34:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 18 Feb 2010 09:34:02 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: References: <20100218115116.GA2336@topoi.pooq.com> Message-ID: <20100218143402.GA12076@topoi.pooq.com> On Thu, Feb 18, 2010 at 02:14:01PM +0000, Jay K wrote: > > Henrik, if you won't install anything, then you can't test anything. > > Modula-3 is not going to break your XP install. > > Nor is Visual C++. I'm not afraid of Modula 3 or Visual C++. I'm worried about the stuff I might encounter while wanfering the net wondering what it is I have to do. Randy's reply will probably get me started. > > > > > machine is A 32-bit intel, and so it just might not be relevant to > > testing 64-bit LONGINT. > > > False! > > LONGINT is 64bits on all platforms. > > We have no 64bit Windows target currently. Ah. I've heard of a 64-bit Windows. Evidently not relevant to us now. -- hendrik From wagner at elegosoft.com Thu Feb 18 17:20:56 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 17:20:56 +0100 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> Message-ID: <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> Quoting "Coleburn, Randy" : > I can certainly run some tests on Windows. > > I don't have any code that uses longint, so either someone needs to > identify which existing programs I can build and run to do the > tests, OR I suppose I can write something if you can give me an idea > of how extensive the tests you want. This sounds good! Some things that come to mind for LONGINT immeditately: o standard integer arithmetic (+, -, *, DIV, MOD) at runtime, with and without overflows etc. o constant declarations o constant expressions o assignability (should be rather strict; I'd have to check the mail archive for the details) o pickles It would be great if you could add some tests to m3tests that are valid on all platforms. I expect that some should already be in place, but haven't checked yet... Hm, a quick search for longint in http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ for example doesn't find anything. Has nobody added any LONGINT test yet? Probably I'm looking for the wrong string... A complete regression with cm3 and other programs you may have available would be great, too, just to make sure that the backend changes don't break any old functionality. Olaf > > I've been trying to keep my system updated to the latest sources on > the main trunk, but I've been swamped lately and I'm afraid I'm a > few weeks stale right now. I'll remedy that shortly. > > Regards, > Randy > > ________________________________ > From: Olaf Wagner [wagner at elegosoft.com] > Sent: Thursday, February 18, 2010 6:57 AM > To: Jay K > Cc: m3devel > Subject: [M3devel] More testing needed for m3back, was: RE: > m3back/longint/atomics > > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. > > Olaf > > Quoting Jay K : > >> NT386/longint changes are almost entirely in the m3back package. >> >> There is also some small easy stuff in >> m3-libs/m3core/src/Csupport/common/hand.c. >> >> It'd be really great if anyone could test any of this and if >> anyone could review the diff between release and head. >> >> Not just me. >> >> The changes for longint are quite large, even if local. >> >> I can port them, in the case of m3back, just copy, and make sure >> the atomics stuff doesn't cause problems (it should be unused). >> >> There is also a small change in m3front so that longint can be initialized. >> That affects all platforms. >> >> And a small change in m3cc/parse.c for div/mod of longint on non-NT386. >> I have to test mod yet but my fix probably helps it. >> >> It'd be really great if anyone could do anything with this stuff. >> ie. for now in head, then could easily port to release. >> >> We can of course release either way, depending on how satisfied people >> are with 32bit longint on NT386. i.e. longint isn't useful portably, but it >> is useful on non-NT386 platforms. >> >> - Jay >> >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3back/longint/atomics >>> >>> Quoting Jay K : >>> >>> > >>> > As far as I know/can remember, longint and atomics should all work >>> > now on NT386. >>> > >>> > Atomics only currently for 32bit types. >>> > There are still a few small inefficiencies to maybe deal with. >>> > I'll add 64bit shortly and maybe 8 and 16. >>> > >>> > >>> > We should probably add *a lot* more test coverage in p226 and p227. >>> > >>> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >>> > did a bunch of. >>> >>> Any volunteers to increase the test coverage? >>> >>> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >>> > >>> > Still maybe to do something about rd/wr...? >>> > >>> > Still to wonder about NT386/longint support in the release branch? >>> >>> Should we / will you merge this stuff to the release branch? >>> Or should we release without it? How local are the changes? >>> >>> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 18 22:26:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 21:26:19 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> References: , , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com>, , , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl>, <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> Message-ID: I added some testing, found/fixed bugs in the gcc backend (initializing constants, division). They should be in the automated tests already. However don't let this stop you from doing everything/anything you can think of. I didn't do all that much and you can save time and get more done by not worrying about the duplication. Pickles I didn't do anything with at all, so if you really want to avoid/delay duplication, start with them. - Jay > Date: Thu, 18 Feb 2010 17:20:56 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Quoting "Coleburn, Randy" : > > > I can certainly run some tests on Windows. > > > > I don't have any code that uses longint, so either someone needs to > > identify which existing programs I can build and run to do the > > tests, OR I suppose I can write something if you can give me an idea > > of how extensive the tests you want. > > This sounds good! > > Some things that come to mind for LONGINT immeditately: > > o standard integer arithmetic (+, -, *, DIV, MOD) at runtime, > with and without overflows etc. > o constant declarations > o constant expressions > o assignability (should be rather strict; I'd have to check the mail > archive for the details) > o pickles > > It would be great if you could add some tests to m3tests that are > valid on all platforms. I expect that some should already be in place, > but haven't checked yet... > > Hm, a quick search for longint in > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > for example doesn't find anything. Has nobody added any LONGINT > test yet? Probably I'm looking for the wrong string... > > A complete regression with cm3 and other programs you may have available > would be great, too, just to make sure that the backend changes > don't break any old functionality. > > Olaf > > > > > I've been trying to keep my system updated to the latest sources on > > the main trunk, but I've been swamped lately and I'm afraid I'm a > > few weeks stale right now. I'll remedy that shortly. > > > > Regards, > > Randy > > > > ________________________________ > > From: Olaf Wagner [wagner at elegosoft.com] > > Sent: Thursday, February 18, 2010 6:57 AM > > To: Jay K > > Cc: m3devel > > Subject: [M3devel] More testing needed for m3back, was: RE: > > m3back/longint/atomics > > > > If I understand Jay correctly, it wouldn't be too difficult to bring > > the m3ack LONGINT changes for Windows into the release branch, but > > more testing would be needed. > > > > Randy, you're the only one I remember offhand who actively uses M3 > > on Windows except for Jay. Could you have a closer look at it? > > (Changes are only on the trunk right now.) > > > > Or is anybody else here lurking and eager to do some Windows-based tests? > > > > If nobody volunteers, I'm afraid we will have to release without 64bit > > LONGINT on Windows. > > > > Olaf > > > > Quoting Jay K : > > > >> NT386/longint changes are almost entirely in the m3back package. > >> > >> There is also some small easy stuff in > >> m3-libs/m3core/src/Csupport/common/hand.c. > >> > >> It'd be really great if anyone could test any of this and if > >> anyone could review the diff between release and head. > >> > >> Not just me. > >> > >> The changes for longint are quite large, even if local. > >> > >> I can port them, in the case of m3back, just copy, and make sure > >> the atomics stuff doesn't cause problems (it should be unused). > >> > >> There is also a small change in m3front so that longint can be initialized. > >> That affects all platforms. > >> > >> And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > >> I have to test mod yet but my fix probably helps it. > >> > >> It'd be really great if anyone could do anything with this stuff. > >> ie. for now in head, then could easily port to release. > >> > >> We can of course release either way, depending on how satisfied people > >> are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > >> is useful on non-NT386 platforms. > >> > >> - Jay > >> > >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] m3back/longint/atomics > >>> > >>> Quoting Jay K : > >>> > >>> > > >>> > As far as I know/can remember, longint and atomics should all work > >>> > now on NT386. > >>> > > >>> > Atomics only currently for 32bit types. > >>> > There are still a few small inefficiencies to maybe deal with. > >>> > I'll add 64bit shortly and maybe 8 and 16. > >>> > > >>> > > >>> > We should probably add *a lot* more test coverage in p226 and p227. > >>> > > >>> > e.g. longint multiply/add/sub/divide, not just insert/extract like I > >>> > did a bunch of. > >>> > >>> Any volunteers to increase the test coverage? > >>> > >>> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > >>> > > >>> > Still maybe to do something about rd/wr...? > >>> > > >>> > Still to wonder about NT386/longint support in the release branch? > >>> > >>> Should we / will you merge this stuff to the release branch? > >>> Or should we release without it? How local are the changes? > >>> > >>> Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 19 04:07:36 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 03:07:36 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <683477.25152.qm@web23602.mail.ird.yahoo.com> Hi all: great news to hear about a release coming soon, but how about testing NT386GNU or derivatives of it, would be hard to set up (I might try a friend's machine). As I understood that was a great port to new Modula-3 programmers coming into the M3 world from win world. This doesn't have the all packages but is this a must to give have a check to release this port? Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 ? Is there any chance to bring those platforms in final release? Any difficulties to start trying that? Thanks in advance --- El jue, 18/2/10, Jay K escribi?: > De: Jay K > Asunto: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Olaf" , "m3devel" > Fecha: jueves, 18 de febrero, 2010 16:26 > > > > > > I added some testing, found/fixed bugs in the gcc > backend (initializing constants, division). > > They should be in the automated tests already. > > However don't let this stop you from doing > everything/anything you can think of. > > I didn't do all that much and you can save time and get > more done by not worrying > > about the duplication. > > Pickles I didn't do anything with at all, so if you > really want to avoid/delay duplication, > > start with them. > > > > - Jay > > > > Date: Thu, 18 Feb 2010 17:20:56 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > > > Quoting "Coleburn, Randy" > : > > > > > I can certainly run some tests on Windows. > > > > > > I don't have any code that uses longint, so > either someone needs to > > > identify which existing programs I can build and > run to do the > > > tests, OR I suppose I can write something if you > can give me an idea > > > of how extensive the tests you want. > > > > This sounds good! > > > > Some things that come to mind for LONGINT > immeditately: > > > > o standard integer arithmetic (+, -, *, DIV, MOD) at > runtime, > > with and without overflows etc. > > o constant declarations > > o constant expressions > > o assignability (should be rather strict; I'd have > to check the mail > > archive for the details) > > o pickles > > > > It would be great if you could add some tests to > m3tests that are > > valid on all platforms. I expect that some should > already be in place, > > but haven't checked yet... > > > > Hm, a quick search for longint in > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > > for example doesn't find anything. Has nobody > added any LONGINT > > test yet? Probably I'm looking for the wrong > string... > > > > A complete regression with cm3 and other programs you > may have available > > would be great, too, just to make sure that the > backend changes > > don't break any old functionality. > > > > Olaf > > > > > > > > I've been trying to keep my system updated to > the latest sources on > > > the main trunk, but I've been swamped lately > and I'm afraid I'm a > > > few weeks stale right now. I'll remedy that > shortly. > > > > > > Regards, > > > Randy > > > > > > ________________________________ > > > From: Olaf Wagner [wagner at elegosoft.com] > > > Sent: Thursday, February 18, 2010 6:57 AM > > > To: Jay K > > > Cc: m3devel > > > Subject: [M3devel] More testing needed for > m3back, was: RE: > > > m3back/longint/atomics > > > > > > If I understand Jay correctly, it wouldn't be > too difficult to bring > > > the m3ack LONGINT changes for Windows into the > release branch, but > > > more testing would be needed. > > > > > > Randy, you're the only one I remember offhand > who actively uses M3 > > > on Windows except for Jay. Could you have a > closer look at it? > > > (Changes are only on the trunk right now.) > > > > > > Or is anybody else here lurking and eager to do > some Windows-based tests? > > > > > > If nobody volunteers, I'm afraid we will have > to release without 64bit > > > LONGINT on Windows. > > > > > > Olaf > > > > > > Quoting Jay K : > > > > > >> NT386/longint changes are almost entirely in > the m3back package. > > >> > > >> There is also some small easy stuff in > > >> m3-libs/m3core/src/Csupport/common/hand.c. > > >> > > >> It'd be really great if anyone could test > any of this and if > > >> anyone could review the diff between release > and head. > > >> > > >> Not just me. > > >> > > >> The changes for longint are quite large, even > if local. > > >> > > >> I can port them, in the case of m3back, just > copy, and make sure > > >> the atomics stuff doesn't cause problems > (it should be unused). > > >> > > >> There is also a small change in m3front so > that longint can be initialized. > > >> That affects all platforms. > > >> > > >> And a small change in m3cc/parse.c for > div/mod of longint on non-NT386. > > >> I have to test mod yet but my fix probably > helps it. > > >> > > >> It'd be really great if anyone could do > anything with this stuff. > > >> ie. for now in head, then could easily port > to release. > > >> > > >> We can of course release either way, > depending on how satisfied people > > >> are with 32bit longint on NT386. i.e. longint > isn't useful portably, but it > > >> is useful on non-NT386 platforms. > > >> > > >> - Jay > > >> > > >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 > > >>> From: wagner at elegosoft.com > > >>> To: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] > m3back/longint/atomics > > >>> > > >>> Quoting Jay K > : > > >>> > > >>> > > > >>> > As far as I know/can remember, > longint and atomics should all work > > >>> > now on NT386. > > >>> > > > >>> > Atomics only currently for 32bit > types. > > >>> > There are still a few small > inefficiencies to maybe deal with. > > >>> > I'll add 64bit shortly and maybe > 8 and 16. > > >>> > > > >>> > > > >>> > We should probably add *a lot* more > test coverage in p226 and p227. > > >>> > > > >>> > e.g. longint > multiply/add/sub/divide, not just insert/extract like I > > >>> > did a bunch of. > > >>> > > >>> Any volunteers to increase the test > coverage? > > >>> > > >>> > Still to fix the Win32 m3core/libm3 > to not always truncate file sizes. > > >>> > > > >>> > Still maybe to do something about > rd/wr...? > > >>> > > > >>> > Still to wonder about NT386/longint > support in the release branch? > > >>> > > >>> Should we / will you merge this stuff to > the release branch? > > >>> Or should we release without it? How > local are the changes? > > >>> > > >>> Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 fax: +49 30 23 45 86 95 > > > > http://www.elegosoft.com | > > > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB > 77719 | USt-IdNr: DE163214194 > > > > > > > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > From jay.krell at cornell.edu Fri Feb 19 05:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 04:54:03 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <683477.25152.qm@web23602.mail.ird.yahoo.com> References: , <683477.25152.qm@web23602.mail.ird.yahoo.com> Message-ID: https://projects.elego.de/cm3/ticket/1080 can you provide the cvsup configuration file? Thanks. Can you try building with user threads and see if it occurs? Or on another platform? This is definitely something we want to look into. NT386GNU is there and worked for me, but it is slow. It had 64bit longint way ahead of NT386, but NT386 is there now. There is also NT386MINGNU. More testing definitely appreciated. Thanks, - Jay ---------------------------------------- > Date: Fri, 19 Feb 2010 03:07:36 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi all: > great news to hear about a release coming soon, but how about testing NT386GNU or derivatives of it, would be hard to set up (I might try a friend's machine). > As I understood that was a great port to new Modula-3 programmers coming into the M3 world from win world. This doesn't have the all packages but is this a must to give have a check to release this port? > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 ? > Is there any chance to bring those platforms in final release? > Any difficulties to start trying that? > Thanks in advance > > --- El jue, 18/2/10, Jay K escribi?: > >> De: Jay K >> Asunto: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics >> Para: "Olaf" , "m3devel" >> Fecha: jueves, 18 de febrero, 2010 16:26 >> >> >> >> >> >> I added some testing, found/fixed bugs in the gcc >> backend (initializing constants, division). >> >> They should be in the automated tests already. >> >> However don't let this stop you from doing >> everything/anything you can think of. >> >> I didn't do all that much and you can save time and get >> more done by not worrying >> >> about the duplication. >> >> Pickles I didn't do anything with at all, so if you >> really want to avoid/delay duplication, >> >> start with them. >> >> >> >> - Jay >> >> >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] More testing needed for m3back, >> was: RE: m3back/longint/atomics >>> >>> Quoting "Coleburn, Randy" >> : >>> >>>> I can certainly run some tests on Windows. >>>> >>>> I don't have any code that uses longint, so >> either someone needs to >>>> identify which existing programs I can build and >> run to do the >>>> tests, OR I suppose I can write something if you >> can give me an idea >>>> of how extensive the tests you want. >>> >>> This sounds good! >>> >>> Some things that come to mind for LONGINT >> immeditately: >>> >>> o standard integer arithmetic (+, -, *, DIV, MOD) at >> runtime, >>> with and without overflows etc. >>> o constant declarations >>> o constant expressions >>> o assignability (should be rather strict; I'd have >> to check the mail >>> archive for the details) >>> o pickles >>> >>> It would be great if you could add some tests to >> m3tests that are >>> valid on all platforms. I expect that some should >> already be in place, >>> but haven't checked yet... >>> >>> Hm, a quick search for longint in >>> >>> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ >>> >>> for example doesn't find anything. Has nobody >> added any LONGINT >>> test yet? Probably I'm looking for the wrong >> string... >>> >>> A complete regression with cm3 and other programs you >> may have available >>> would be great, too, just to make sure that the >> backend changes >>> don't break any old functionality. >>> >>> Olaf >>> >>>> >>>> I've been trying to keep my system updated to >> the latest sources on >>>> the main trunk, but I've been swamped lately >> and I'm afraid I'm a >>>> few weeks stale right now. I'll remedy that >> shortly. >>>> >>>> Regards, >>>> Randy >>>> >>>> ________________________________ >>>> From: Olaf Wagner [wagner at elegosoft.com] >>>> Sent: Thursday, February 18, 2010 6:57 AM >>>> To: Jay K >>>> Cc: m3devel >>>> Subject: [M3devel] More testing needed for >> m3back, was: RE: >>>> m3back/longint/atomics >>>> >>>> If I understand Jay correctly, it wouldn't be >> too difficult to bring >>>> the m3ack LONGINT changes for Windows into the >> release branch, but >>>> more testing would be needed. >>>> >>>> Randy, you're the only one I remember offhand >> who actively uses M3 >>>> on Windows except for Jay. Could you have a >> closer look at it? >>>> (Changes are only on the trunk right now.) >>>> >>>> Or is anybody else here lurking and eager to do >> some Windows-based tests? >>>> >>>> If nobody volunteers, I'm afraid we will have >> to release without 64bit >>>> LONGINT on Windows. >>>> >>>> Olaf >>>> >>>> Quoting Jay K : >>>> >>>>> NT386/longint changes are almost entirely in >> the m3back package. >>>>> >>>>> There is also some small easy stuff in >>>>> m3-libs/m3core/src/Csupport/common/hand.c. >>>>> >>>>> It'd be really great if anyone could test >> any of this and if >>>>> anyone could review the diff between release >> and head. >>>>> >>>>> Not just me. >>>>> >>>>> The changes for longint are quite large, even >> if local. >>>>> >>>>> I can port them, in the case of m3back, just >> copy, and make sure >>>>> the atomics stuff doesn't cause problems >> (it should be unused). >>>>> >>>>> There is also a small change in m3front so >> that longint can be initialized. >>>>> That affects all platforms. >>>>> >>>>> And a small change in m3cc/parse.c for >> div/mod of longint on non-NT386. >>>>> I have to test mod yet but my fix probably >> helps it. >>>>> >>>>> It'd be really great if anyone could do >> anything with this stuff. >>>>> ie. for now in head, then could easily port >> to release. >>>>> >>>>> We can of course release either way, >> depending on how satisfied people >>>>> are with 32bit longint on NT386. i.e. longint >> isn't useful portably, but it >>>>> is useful on non-NT386 platforms. >>>>> >>>>> - Jay >>>>> >>>>>> Date: Tue, 16 Feb 2010 16:12:52 +0100 >>>>>> From: wagner at elegosoft.com >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] >> m3back/longint/atomics >>>>>> >>>>>> Quoting Jay K >> : >>>>>> >>>>>>> >>>>>>> As far as I know/can remember, >> longint and atomics should all work >>>>>>> now on NT386. >>>>>>> >>>>>>> Atomics only currently for 32bit >> types. >>>>>>> There are still a few small >> inefficiencies to maybe deal with. >>>>>>> I'll add 64bit shortly and maybe >> 8 and 16. >>>>>>> >>>>>>> >>>>>>> We should probably add *a lot* more >> test coverage in p226 and p227. >>>>>>> >>>>>>> e.g. longint >> multiply/add/sub/divide, not just insert/extract like I >>>>>>> did a bunch of. >>>>>> >>>>>> Any volunteers to increase the test >> coverage? >>>>>> >>>>>>> Still to fix the Win32 m3core/libm3 >> to not always truncate file sizes. >>>>>>> >>>>>>> Still maybe to do something about >> rd/wr...? >>>>>>> >>>>>>> Still to wonder about NT386/longint >> support in the release branch? >>>>>> >>>>>> Should we / will you merge this stuff to >> the release branch? >>>>>> Or should we release without it? How >> local are the changes? >>>>>> >>>>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >> 869 fax: +49 30 23 45 86 95 >>>> >> http://www.elegosoft.com | >> >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | USt-IdNr: DE163214194 >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 >> fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf >> Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >>> >> >> > > > From dabenavidesd at yahoo.es Fri Feb 19 07:20:10 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 06:20:10 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <621322.72118.qm@web23603.mail.ird.yahoo.com> HI: thanks for answering so fast! Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup more or less it makes you to do cvsupd -b /diska/cvsup/base/ which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: (First command and executing after it the client with .sup file given there in the web page) % telnet 192.168.0.3 5999 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. OK 17 0 2009-07-20 14:06:34 CVSup server ready Connection closed by foreign host. (After, second command it doesn't wait anything or if some client request, it just finish like this) % telnet 192.168.0.3 5999 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. Connection closed by foreign host. % pwd seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. (m3gdb) file LINUXLIBC6/cvsupd Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (m3gdb) break src/Main.m3:BecomeDaemon No source file named src/Main.m3. Make breakpoint pending on future shared library load? (y or [n]) y Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log (m3gdb) set follow-fork-mode child (m3gdb) run Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log Signal Stop Print Pass to program Description SIG64 No No Yes Real-time event 64 [Thread debugging using libthread_db enabled] [Nuevo LWP 5074] [Nuevo Thread -1221278032 (LWP 5074)] In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. Thanks in advance, --- El jue, 18/2/10, Jay K escribi?: > De: Jay K > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Daniel (M3)" , "Olaf" , "m3devel" > Fecha: jueves, 18 de febrero, 2010 23:54 > > https://projects.elego.de/cm3/ticket/1080 > can you provide the cvsup configuration file? Thanks. > Can you try building with user threads and see if it > occurs? > Or on another platform? > > > This is definitely something we want to look into. > > > NT386GNU is there and worked for me, but it is slow. > It had 64bit longint way ahead of NT386, but NT386 is there > now. > There is also NT386MINGNU. > > > More testing definitely appreciated. > > > Thanks, > - Jay > > > ---------------------------------------- > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > From: dabenavidesd at yahoo.es > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > To: wagner at elegosoft.com; > m3devel at elegosoft.com; > jay.krell at cornell.edu > > > > Hi all: > > great news to hear about a release coming soon, but > how about testing NT386GNU or derivatives of it, would be > hard to set up (I might try a friend's machine). > > As I understood that was a great port to new Modula-3 > programmers coming into the M3 world from win world. This > doesn't have the all packages but is this a must to give > have a check to release this port? > > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 > ? > > Is there any chance to bring those platforms in final > release? > > Any difficulties to start trying that? > > Thanks in advance > > > > --- El jue, 18/2/10, Jay K escribi?: > > > >> De: Jay K > >> Asunto: Re: [M3devel] More testing needed for > m3back, was: RE: m3back/longint/atomics > >> Para: "Olaf" , "m3devel" > >> Fecha: jueves, 18 de febrero, 2010 16:26 > >> > >> > >> > >> > >> > >> I added some testing, found/fixed bugs in the gcc > >> backend (initializing constants, division). > >> > >> They should be in the automated tests already. > >> > >> However don't let this stop you from doing > >> everything/anything you can think of. > >> > >> I didn't do all that much and you can save time > and get > >> more done by not worrying > >> > >> about the duplication. > >> > >> Pickles I didn't do anything with at all, so if > you > >> really want to avoid/delay duplication, > >> > >> start with them. > >> > >> > >> > >> - Jay > >> > >> > >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] More testing needed for > m3back, > >> was: RE: m3back/longint/atomics > >>> > >>> Quoting "Coleburn, Randy" > >> : > >>> > >>>> I can certainly run some tests on > Windows. > >>>> > >>>> I don't have any code that uses longint, > so > >> either someone needs to > >>>> identify which existing programs I can > build and > >> run to do the > >>>> tests, OR I suppose I can write something > if you > >> can give me an idea > >>>> of how extensive the tests you want. > >>> > >>> This sounds good! > >>> > >>> Some things that come to mind for LONGINT > >> immeditately: > >>> > >>> o standard integer arithmetic (+, -, *, DIV, > MOD) at > >> runtime, > >>> with and without overflows etc. > >>> o constant declarations > >>> o constant expressions > >>> o assignability (should be rather strict; I'd > have > >> to check the mail > >>> archive for the details) > >>> o pickles > >>> > >>> It would be great if you could add some tests > to > >> m3tests that are > >>> valid on all platforms. I expect that some > should > >> already be in place, > >>> but haven't checked yet... > >>> > >>> Hm, a quick search for longint in > >>> > >>> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > >>> > >>> for example doesn't find anything. Has nobody > >> added any LONGINT > >>> test yet? Probably I'm looking for the wrong > >> string... > >>> > >>> A complete regression with cm3 and other > programs you > >> may have available > >>> would be great, too, just to make sure that > the > >> backend changes > >>> don't break any old functionality. > >>> > >>> Olaf > >>> > >>>> > >>>> I've been trying to keep my system updated > to > >> the latest sources on > >>>> the main trunk, but I've been swamped > lately > >> and I'm afraid I'm a > >>>> few weeks stale right now. I'll remedy > that > >> shortly. > >>>> > >>>> Regards, > >>>> Randy > >>>> > >>>> ________________________________ > >>>> From: Olaf Wagner [wagner at elegosoft.com] > >>>> Sent: Thursday, February 18, 2010 6:57 AM > >>>> To: Jay K > >>>> Cc: m3devel > >>>> Subject: [M3devel] More testing needed > for > >> m3back, was: RE: > >>>> m3back/longint/atomics > >>>> > >>>> If I understand Jay correctly, it wouldn't > be > >> too difficult to bring > >>>> the m3ack LONGINT changes for Windows into > the > >> release branch, but > >>>> more testing would be needed. > >>>> > >>>> Randy, you're the only one I remember > offhand > >> who actively uses M3 > >>>> on Windows except for Jay. Could you have > a > >> closer look at it? > >>>> (Changes are only on the trunk right > now.) > >>>> > >>>> Or is anybody else here lurking and eager > to do > >> some Windows-based tests? > >>>> > >>>> If nobody volunteers, I'm afraid we will > have > >> to release without 64bit > >>>> LONGINT on Windows. > >>>> > >>>> Olaf > >>>> > >>>> Quoting Jay K : > >>>> > >>>>> NT386/longint changes are almost > entirely in > >> the m3back package. > >>>>> > >>>>> There is also some small easy stuff > in > >>>>> > m3-libs/m3core/src/Csupport/common/hand.c. > >>>>> > >>>>> It'd be really great if anyone could > test > >> any of this and if > >>>>> anyone could review the diff between > release > >> and head. > >>>>> > >>>>> Not just me. > >>>>> > >>>>> The changes for longint are quite > large, even > >> if local. > >>>>> > >>>>> I can port them, in the case of > m3back, just > >> copy, and make sure > >>>>> the atomics stuff doesn't cause > problems > >> (it should be unused). > >>>>> > >>>>> There is also a small change in > m3front so > >> that longint can be initialized. > >>>>> That affects all platforms. > >>>>> > >>>>> And a small change in m3cc/parse.c > for > >> div/mod of longint on non-NT386. > >>>>> I have to test mod yet but my fix > probably > >> helps it. > >>>>> > >>>>> It'd be really great if anyone could > do > >> anything with this stuff. > >>>>> ie. for now in head, then could easily > port > >> to release. > >>>>> > >>>>> We can of course release either way, > >> depending on how satisfied people > >>>>> are with 32bit longint on NT386. i.e. > longint > >> isn't useful portably, but it > >>>>> is useful on non-NT386 platforms. > >>>>> > >>>>> - Jay > >>>>> > >>>>>> Date: Tue, 16 Feb 2010 16:12:52 > +0100 > >>>>>> From: wagner at elegosoft.com > >>>>>> To: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] > >> m3back/longint/atomics > >>>>>> > >>>>>> Quoting Jay K > >> : > >>>>>> > >>>>>>> > >>>>>>> As far as I know/can > remember, > >> longint and atomics should all work > >>>>>>> now on NT386. > >>>>>>> > >>>>>>> Atomics only currently for > 32bit > >> types. > >>>>>>> There are still a few small > >> inefficiencies to maybe deal with. > >>>>>>> I'll add 64bit shortly and > maybe > >> 8 and 16. > >>>>>>> > >>>>>>> > >>>>>>> We should probably add *a lot* > more > >> test coverage in p226 and p227. > >>>>>>> > >>>>>>> e.g. longint > >> multiply/add/sub/divide, not just insert/extract > like I > >>>>>>> did a bunch of. > >>>>>> > >>>>>> Any volunteers to increase the > test > >> coverage? > >>>>>> > >>>>>>> Still to fix the Win32 > m3core/libm3 > >> to not always truncate file sizes. > >>>>>>> > >>>>>>> Still maybe to do something > about > >> rd/wr...? > >>>>>>> > >>>>>>> Still to wonder about > NT386/longint > >> support in the release branch? > >>>>>> > >>>>>> Should we / will you merge this > stuff to > >> the release branch? > >>>>>> Or should we release without it? > How > >> local are the changes? > >>>>>> > >>>>>> Olaf > >>>> -- > >>>> Olaf Wagner -- elego Software Solutions > GmbH > >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 > >> Berlin, Germany > >>>> phone: +49 30 23 45 86 96 mobile: +49 177 > 2345 > >> 869 fax: +49 30 23 45 86 95 > >>>> > >> http://www.elegosoft.com | > >> > >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > >>>> Handelregister: Amtsgericht Charlottenburg > HRB > >> 77719 | USt-IdNr: DE163214194 > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > Berlin, > >> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 > >> fax: +49 30 23 45 86 95 > >>> http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf > >> Wagner | Sitz: Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > >> USt-IdNr: DE163214194 > >>> > >> > >> > > > > > > > > > From jay.krell at cornell.edu Fri Feb 19 09:50:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 08:50:36 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <621322.72118.qm@web23603.mail.ird.yahoo.com> References: , <621322.72118.qm@web23603.mail.ird.yahoo.com> Message-ID: - Our system isn't multithreaded enough to benefit from multicore. There are too many globals. Modula-3 allows for and takes advantage of programmers writing "separate headers" in the fashion that all C/C++ programmers do anyway (but which the C/C++ compiler can't take advantage of, but instead parses over and over and over) but it doesn't discourage you to have interfaces that merely manage globals. We might be able to win with a coarse grained parallelism: multiple processes instead of threads - Cygwin is so slow, and has been for so long, I have no hope for it getting much better. Maybe the gcc Makefiles won't create so many processes at some point. It does work to an impressive degree, but is also very slow. NT386 has always been very fast. The other Posix systems are getting better, my newer Intel Mac is closer in speed to NT386 than older PPC Mac. But NT386 is still much faster (on old machine). - to build with user threads, you have tweak m3-libs/m3core/src/threads.quake and build the whole system -- BUT you don't need a new compiler Just: edit that file cd $CVSROOT/scripts/python ./do-cm3-std.py realclean ./do-cm3-std.py buildship I again really strongly suggest we should either: - have multiple platforms, so there are regular builds, people can just install I386_LINUX_USERTHREADS, I386_FREEBSD_USERTHREADS, etc. - make it an @M3 option You cannot just drop in a replacement m3core.so. The types aren't sufficiently the same. - Jay ---------------------------------------- > Date: Fri, 19 Feb 2010 06:20:10 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > HI: > thanks for answering so fast! > Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. > First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup > > more or less it makes you to do > cvsupd -b /diska/cvsup/base/ > which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) > Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: > > (First command and executing after it the client with .sup file given there in the web page) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > OK 17 0 2009-07-20 14:06:34 CVSup server ready > Connection closed by foreign host. > > (After, second command it doesn't wait anything or if some client request, it just finish like this) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > > > Connection closed by foreign host. > % pwd > > > seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. > (m3gdb) file LINUXLIBC6/cvsupd > Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) break src/Main.m3:BecomeDaemon > No source file named src/Main.m3. > Make breakpoint pending on future shared library load? (y or [n]) y > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > (m3gdb) set follow-fork-mode child > (m3gdb) run > Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > Signal Stop Print Pass to program Description > SIG64 No No Yes Real-time event 64 > [Thread debugging using libthread_db enabled] > [Nuevo LWP 5074] > [Nuevo Thread -1221278032 (LWP 5074)] > > > In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. > I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. > > About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. > > Thanks in advance, > > --- El jue, 18/2/10, Jay K escribi?: > >> De: Jay K >> Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics >> Para: "Daniel (M3)" , "Olaf" , "m3devel" >> Fecha: jueves, 18 de febrero, 2010 23:54 >> >> https://projects.elego.de/cm3/ticket/1080 >> can you provide the cvsup configuration file? Thanks. >> Can you try building with user threads and see if it >> occurs? >> Or on another platform? >> >> >> This is definitely something we want to look into. >> >> >> NT386GNU is there and worked for me, but it is slow. >> It had 64bit longint way ahead of NT386, but NT386 is there >> now. >> There is also NT386MINGNU. >> >> >> More testing definitely appreciated. >> >> >> Thanks, >> - Jay >> >> >> ---------------------------------------- >>> Date: Fri, 19 Feb 2010 03:07:36 +0000 >>> From: dabenavidesd at yahoo.es >>> Subject: Re: [M3devel] More testing needed for m3back, >> was: RE: m3back/longint/atomics >>> To: wagner at elegosoft.com; >> m3devel at elegosoft.com; >> jay.krell at cornell.edu >>> >>> Hi all: >>> great news to hear about a release coming soon, but >> how about testing NT386GNU or derivatives of it, would be >> hard to set up (I might try a friend's machine). >>> As I understood that was a great port to new Modula-3 >> programmers coming into the M3 world from win world. This >> doesn't have the all packages but is this a must to give >> have a check to release this port? >>> Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 >> ? >>> Is there any chance to bring those platforms in final >> release? >>> Any difficulties to start trying that? >>> Thanks in advance >>> >>> --- El jue, 18/2/10, Jay K escribi?: >>> >>>> De: Jay K >>>> Asunto: Re: [M3devel] More testing needed for >> m3back, was: RE: m3back/longint/atomics >>>> Para: "Olaf" , "m3devel" >>>> Fecha: jueves, 18 de febrero, 2010 16:26 >>>> >>>> >>>> >>>> >>>> >>>> I added some testing, found/fixed bugs in the gcc >>>> backend (initializing constants, division). >>>> >>>> They should be in the automated tests already. >>>> >>>> However don't let this stop you from doing >>>> everything/anything you can think of. >>>> >>>> I didn't do all that much and you can save time >> and get >>>> more done by not worrying >>>> >>>> about the duplication. >>>> >>>> Pickles I didn't do anything with at all, so if >> you >>>> really want to avoid/delay duplication, >>>> >>>> start with them. >>>> >>>> >>>> >>>> - Jay >>>> >>>> >>>>> Date: Thu, 18 Feb 2010 17:20:56 +0100 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] More testing needed for >> m3back, >>>> was: RE: m3back/longint/atomics >>>>> >>>>> Quoting "Coleburn, Randy" >>>> : >>>>> >>>>>> I can certainly run some tests on >> Windows. >>>>>> >>>>>> I don't have any code that uses longint, >> so >>>> either someone needs to >>>>>> identify which existing programs I can >> build and >>>> run to do the >>>>>> tests, OR I suppose I can write something >> if you >>>> can give me an idea >>>>>> of how extensive the tests you want. >>>>> >>>>> This sounds good! >>>>> >>>>> Some things that come to mind for LONGINT >>>> immeditately: >>>>> >>>>> o standard integer arithmetic (+, -, *, DIV, >> MOD) at >>>> runtime, >>>>> with and without overflows etc. >>>>> o constant declarations >>>>> o constant expressions >>>>> o assignability (should be rather strict; I'd >> have >>>> to check the mail >>>>> archive for the details) >>>>> o pickles >>>>> >>>>> It would be great if you could add some tests >> to >>>> m3tests that are >>>>> valid on all platforms. I expect that some >> should >>>> already be in place, >>>>> but haven't checked yet... >>>>> >>>>> Hm, a quick search for longint in >>>>> >>>>> >>>> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ >>>>> >>>>> for example doesn't find anything. Has nobody >>>> added any LONGINT >>>>> test yet? Probably I'm looking for the wrong >>>> string... >>>>> >>>>> A complete regression with cm3 and other >> programs you >>>> may have available >>>>> would be great, too, just to make sure that >> the >>>> backend changes >>>>> don't break any old functionality. >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> I've been trying to keep my system updated >> to >>>> the latest sources on >>>>>> the main trunk, but I've been swamped >> lately >>>> and I'm afraid I'm a >>>>>> few weeks stale right now. I'll remedy >> that >>>> shortly. >>>>>> >>>>>> Regards, >>>>>> Randy >>>>>> >>>>>> ________________________________ >>>>>> From: Olaf Wagner [wagner at elegosoft.com] >>>>>> Sent: Thursday, February 18, 2010 6:57 AM >>>>>> To: Jay K >>>>>> Cc: m3devel >>>>>> Subject: [M3devel] More testing needed >> for >>>> m3back, was: RE: >>>>>> m3back/longint/atomics >>>>>> >>>>>> If I understand Jay correctly, it wouldn't >> be >>>> too difficult to bring >>>>>> the m3ack LONGINT changes for Windows into >> the >>>> release branch, but >>>>>> more testing would be needed. >>>>>> >>>>>> Randy, you're the only one I remember >> offhand >>>> who actively uses M3 >>>>>> on Windows except for Jay. Could you have >> a >>>> closer look at it? >>>>>> (Changes are only on the trunk right >> now.) >>>>>> >>>>>> Or is anybody else here lurking and eager >> to do >>>> some Windows-based tests? >>>>>> >>>>>> If nobody volunteers, I'm afraid we will >> have >>>> to release without 64bit >>>>>> LONGINT on Windows. >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting Jay K : >>>>>> >>>>>>> NT386/longint changes are almost >> entirely in >>>> the m3back package. >>>>>>> >>>>>>> There is also some small easy stuff >> in >>>>>>> >> m3-libs/m3core/src/Csupport/common/hand.c. >>>>>>> >>>>>>> It'd be really great if anyone could >> test >>>> any of this and if >>>>>>> anyone could review the diff between >> release >>>> and head. >>>>>>> >>>>>>> Not just me. >>>>>>> >>>>>>> The changes for longint are quite >> large, even >>>> if local. >>>>>>> >>>>>>> I can port them, in the case of >> m3back, just >>>> copy, and make sure >>>>>>> the atomics stuff doesn't cause >> problems >>>> (it should be unused). >>>>>>> >>>>>>> There is also a small change in >> m3front so >>>> that longint can be initialized. >>>>>>> That affects all platforms. >>>>>>> >>>>>>> And a small change in m3cc/parse.c >> for >>>> div/mod of longint on non-NT386. >>>>>>> I have to test mod yet but my fix >> probably >>>> helps it. >>>>>>> >>>>>>> It'd be really great if anyone could >> do >>>> anything with this stuff. >>>>>>> ie. for now in head, then could easily >> port >>>> to release. >>>>>>> >>>>>>> We can of course release either way, >>>> depending on how satisfied people >>>>>>> are with 32bit longint on NT386. i.e. >> longint >>>> isn't useful portably, but it >>>>>>> is useful on non-NT386 platforms. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>>> Date: Tue, 16 Feb 2010 16:12:52 >> +0100 >>>>>>>> From: wagner at elegosoft.com >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] >>>> m3back/longint/atomics >>>>>>>> >>>>>>>> Quoting Jay K >>>> : >>>>>>>> >>>>>>>>> >>>>>>>>> As far as I know/can >> remember, >>>> longint and atomics should all work >>>>>>>>> now on NT386. >>>>>>>>> >>>>>>>>> Atomics only currently for >> 32bit >>>> types. >>>>>>>>> There are still a few small >>>> inefficiencies to maybe deal with. >>>>>>>>> I'll add 64bit shortly and >> maybe >>>> 8 and 16. >>>>>>>>> >>>>>>>>> >>>>>>>>> We should probably add *a lot* >> more >>>> test coverage in p226 and p227. >>>>>>>>> >>>>>>>>> e.g. longint >>>> multiply/add/sub/divide, not just insert/extract >> like I >>>>>>>>> did a bunch of. >>>>>>>> >>>>>>>> Any volunteers to increase the >> test >>>> coverage? >>>>>>>> >>>>>>>>> Still to fix the Win32 >> m3core/libm3 >>>> to not always truncate file sizes. >>>>>>>>> >>>>>>>>> Still maybe to do something >> about >>>> rd/wr...? >>>>>>>>> >>>>>>>>> Still to wonder about >> NT386/longint >>>> support in the release branch? >>>>>>>> >>>>>>>> Should we / will you merge this >> stuff to >>>> the release branch? >>>>>>>> Or should we release without it? >> How >>>> local are the changes? >>>>>>>> >>>>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions >> GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, >> 13355 >>>> Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 >>>> 869 fax: +49 30 23 45 86 95 >>>>>> >>>> http://www.elegosoft.com | >>>> >>>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg >> HRB >>>> 77719 | USt-IdNr: DE163214194 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, >>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >> 869 >>>> fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf >>>> Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | >>>> USt-IdNr: DE163214194 >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From jay.krell at cornell.edu Fri Feb 19 11:43:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 10:43:02 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <621322.72118.qm@web23603.mail.ird.yahoo.com> References: , <621322.72118.qm@web23603.mail.ird.yahoo.com> Message-ID: Daniel, if you really last tried this in 2008, please try again. I'm not sure we had cvsup in our tree in 2008 though. Even if you tried it in 2009, try again? http://aivwiki.alma.cl/index.php/Installing_CVSup points to a particular non-current Modula-3 and a particular cvsup. We have cvsup in our tree now. Which did you use? Please try ours. -Jay > Date: Fri, 19 Feb 2010 06:20:10 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > HI: > thanks for answering so fast! > Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. > First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup > > more or less it makes you to do > cvsupd -b /diska/cvsup/base/ > which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) > Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: > > (First command and executing after it the client with .sup file given there in the web page) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > OK 17 0 2009-07-20 14:06:34 CVSup server ready > Connection closed by foreign host. > > (After, second command it doesn't wait anything or if some client request, it just finish like this) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > > > Connection closed by foreign host. > % pwd > > > seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. > (m3gdb) file LINUXLIBC6/cvsupd > Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) break src/Main.m3:BecomeDaemon > No source file named src/Main.m3. > Make breakpoint pending on future shared library load? (y or [n]) y > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > (m3gdb) set follow-fork-mode child > (m3gdb) run > Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > Signal Stop Print Pass to program Description > SIG64 No No Yes Real-time event 64 > [Thread debugging using libthread_db enabled] > [Nuevo LWP 5074] > [Nuevo Thread -1221278032 (LWP 5074)] > > > In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. > I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. > > About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. > > Thanks in advance, > > --- El jue, 18/2/10, Jay K escribi?: > > > De: Jay K > > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Para: "Daniel (M3)" , "Olaf" , "m3devel" > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > https://projects.elego.de/cm3/ticket/1080 > > can you provide the cvsup configuration file? Thanks. > > Can you try building with user threads and see if it > > occurs? > > Or on another platform? > > > > > > This is definitely something we want to look into. > > > > > > NT386GNU is there and worked for me, but it is slow. > > It had 64bit longint way ahead of NT386, but NT386 is there > > now. > > There is also NT386MINGNU. > > > > > > More testing definitely appreciated. > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > From: dabenavidesd at yahoo.es > > > Subject: Re: [M3devel] More testing needed for m3back, > > was: RE: m3back/longint/atomics > > > To: wagner at elegosoft.com; > > m3devel at elegosoft.com; > > jay.krell at cornell.edu > > > > > > Hi all: > > > great news to hear about a release coming soon, but > > how about testing NT386GNU or derivatives of it, would be > > hard to set up (I might try a friend's machine). > > > As I understood that was a great port to new Modula-3 > > programmers coming into the M3 world from win world. This > > doesn't have the all packages but is this a must to give > > have a check to release this port? > > > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 > > ? > > > Is there any chance to bring those platforms in final > > release? > > > Any difficulties to start trying that? > > > Thanks in advance > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > >> De: Jay K > > >> Asunto: Re: [M3devel] More testing needed for > > m3back, was: RE: m3back/longint/atomics > > >> Para: "Olaf" , "m3devel" > > >> Fecha: jueves, 18 de febrero, 2010 16:26 > > >> > > >> > > >> > > >> > > >> > > >> I added some testing, found/fixed bugs in the gcc > > >> backend (initializing constants, division). > > >> > > >> They should be in the automated tests already. > > >> > > >> However don't let this stop you from doing > > >> everything/anything you can think of. > > >> > > >> I didn't do all that much and you can save time > > and get > > >> more done by not worrying > > >> > > >> about the duplication. > > >> > > >> Pickles I didn't do anything with at all, so if > > you > > >> really want to avoid/delay duplication, > > >> > > >> start with them. > > >> > > >> > > >> > > >> - Jay > > >> > > >> > > >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 > > >>> From: wagner at elegosoft.com > > >>> To: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] More testing needed for > > m3back, > > >> was: RE: m3back/longint/atomics > > >>> > > >>> Quoting "Coleburn, Randy" > > >> : > > >>> > > >>>> I can certainly run some tests on > > Windows. > > >>>> > > >>>> I don't have any code that uses longint, > > so > > >> either someone needs to > > >>>> identify which existing programs I can > > build and > > >> run to do the > > >>>> tests, OR I suppose I can write something > > if you > > >> can give me an idea > > >>>> of how extensive the tests you want. > > >>> > > >>> This sounds good! > > >>> > > >>> Some things that come to mind for LONGINT > > >> immeditately: > > >>> > > >>> o standard integer arithmetic (+, -, *, DIV, > > MOD) at > > >> runtime, > > >>> with and without overflows etc. > > >>> o constant declarations > > >>> o constant expressions > > >>> o assignability (should be rather strict; I'd > > have > > >> to check the mail > > >>> archive for the details) > > >>> o pickles > > >>> > > >>> It would be great if you could add some tests > > to > > >> m3tests that are > > >>> valid on all platforms. I expect that some > > should > > >> already be in place, > > >>> but haven't checked yet... > > >>> > > >>> Hm, a quick search for longint in > > >>> > > >>> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > >>> > > >>> for example doesn't find anything. Has nobody > > >> added any LONGINT > > >>> test yet? Probably I'm looking for the wrong > > >> string... > > >>> > > >>> A complete regression with cm3 and other > > programs you > > >> may have available > > >>> would be great, too, just to make sure that > > the > > >> backend changes > > >>> don't break any old functionality. > > >>> > > >>> Olaf > > >>> > > >>>> > > >>>> I've been trying to keep my system updated > > to > > >> the latest sources on > > >>>> the main trunk, but I've been swamped > > lately > > >> and I'm afraid I'm a > > >>>> few weeks stale right now. I'll remedy > > that > > >> shortly. > > >>>> > > >>>> Regards, > > >>>> Randy > > >>>> > > >>>> ________________________________ > > >>>> From: Olaf Wagner [wagner at elegosoft.com] > > >>>> Sent: Thursday, February 18, 2010 6:57 AM > > >>>> To: Jay K > > >>>> Cc: m3devel > > >>>> Subject: [M3devel] More testing needed > > for > > >> m3back, was: RE: > > >>>> m3back/longint/atomics > > >>>> > > >>>> If I understand Jay correctly, it wouldn't > > be > > >> too difficult to bring > > >>>> the m3ack LONGINT changes for Windows into > > the > > >> release branch, but > > >>>> more testing would be needed. > > >>>> > > >>>> Randy, you're the only one I remember > > offhand > > >> who actively uses M3 > > >>>> on Windows except for Jay. Could you have > > a > > >> closer look at it? > > >>>> (Changes are only on the trunk right > > now.) > > >>>> > > >>>> Or is anybody else here lurking and eager > > to do > > >> some Windows-based tests? > > >>>> > > >>>> If nobody volunteers, I'm afraid we will > > have > > >> to release without 64bit > > >>>> LONGINT on Windows. > > >>>> > > >>>> Olaf > > >>>> > > >>>> Quoting Jay K : > > >>>> > > >>>>> NT386/longint changes are almost > > entirely in > > >> the m3back package. > > >>>>> > > >>>>> There is also some small easy stuff > > in > > >>>>> > > m3-libs/m3core/src/Csupport/common/hand.c. > > >>>>> > > >>>>> It'd be really great if anyone could > > test > > >> any of this and if > > >>>>> anyone could review the diff between > > release > > >> and head. > > >>>>> > > >>>>> Not just me. > > >>>>> > > >>>>> The changes for longint are quite > > large, even > > >> if local. > > >>>>> > > >>>>> I can port them, in the case of > > m3back, just > > >> copy, and make sure > > >>>>> the atomics stuff doesn't cause > > problems > > >> (it should be unused). > > >>>>> > > >>>>> There is also a small change in > > m3front so > > >> that longint can be initialized. > > >>>>> That affects all platforms. > > >>>>> > > >>>>> And a small change in m3cc/parse.c > > for > > >> div/mod of longint on non-NT386. > > >>>>> I have to test mod yet but my fix > > probably > > >> helps it. > > >>>>> > > >>>>> It'd be really great if anyone could > > do > > >> anything with this stuff. > > >>>>> ie. for now in head, then could easily > > port > > >> to release. > > >>>>> > > >>>>> We can of course release either way, > > >> depending on how satisfied people > > >>>>> are with 32bit longint on NT386. i.e. > > longint > > >> isn't useful portably, but it > > >>>>> is useful on non-NT386 platforms. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>>>> Date: Tue, 16 Feb 2010 16:12:52 > > +0100 > > >>>>>> From: wagner at elegosoft.com > > >>>>>> To: m3devel at elegosoft.com > > >>>>>> Subject: Re: [M3devel] > > >> m3back/longint/atomics > > >>>>>> > > >>>>>> Quoting Jay K > > >> : > > >>>>>> > > >>>>>>> > > >>>>>>> As far as I know/can > > remember, > > >> longint and atomics should all work > > >>>>>>> now on NT386. > > >>>>>>> > > >>>>>>> Atomics only currently for > > 32bit > > >> types. > > >>>>>>> There are still a few small > > >> inefficiencies to maybe deal with. > > >>>>>>> I'll add 64bit shortly and > > maybe > > >> 8 and 16. > > >>>>>>> > > >>>>>>> > > >>>>>>> We should probably add *a lot* > > more > > >> test coverage in p226 and p227. > > >>>>>>> > > >>>>>>> e.g. longint > > >> multiply/add/sub/divide, not just insert/extract > > like I > > >>>>>>> did a bunch of. > > >>>>>> > > >>>>>> Any volunteers to increase the > > test > > >> coverage? > > >>>>>> > > >>>>>>> Still to fix the Win32 > > m3core/libm3 > > >> to not always truncate file sizes. > > >>>>>>> > > >>>>>>> Still maybe to do something > > about > > >> rd/wr...? > > >>>>>>> > > >>>>>>> Still to wonder about > > NT386/longint > > >> support in the release branch? > > >>>>>> > > >>>>>> Should we / will you merge this > > stuff to > > >> the release branch? > > >>>>>> Or should we release without it? > > How > > >> local are the changes? > > >>>>>> > > >>>>>> Olaf > > >>>> -- > > >>>> Olaf Wagner -- elego Software Solutions > > GmbH > > >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, > > 13355 > > >> Berlin, Germany > > >>>> phone: +49 30 23 45 86 96 mobile: +49 177 > > 2345 > > >> 869 fax: +49 30 23 45 86 95 > > >>>> > > >> http://www.elegosoft.com | > > >> > > >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > >>>> Handelregister: Amtsgericht Charlottenburg > > HRB > > >> 77719 | USt-IdNr: DE163214194 > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Olaf Wagner -- elego Software Solutions GmbH > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > > Berlin, > > >> Germany > > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 > > 869 > > >> fax: +49 30 23 45 86 95 > > >>> http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf > > >> Wagner | Sitz: Berlin > > >>> Handelregister: Amtsgericht Charlottenburg HRB > > 77719 | > > >> USt-IdNr: DE163214194 > > >>> > > >> > > >> > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 19 15:04:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 19 Feb 2010 15:04:50 +0100 Subject: [M3devel] Reliable CM3 builds, was: Re: Auto-discard notification / CM3 build In-Reply-To: <20100219135528.2061552yxuem8800@webmail.netcom.co.uk> References: <20100218114558.rn033djp4wgs0wsg@mail.elegosoft.com> <20100219135528.2061552yxuem8800@webmail.netcom.co.uk> Message-ID: <20100219150450.jh85hsh5skkc04ko@mail.elegosoft.com> Quoting cwr at netcom.co.uk: > Quoting Olaf Wagner : > >> You need to subscribe to the list to be able to post to it. > > Oh well, I was hoping to set up a reliable automatic build process > for CM2, but it looks as if that's not possible. Thanks anyway. I don't really follow you here. If you're talking about CM3, the Hudson continuous integration of the current release branch has been working well for several months now: http://hudson.modula3.com:8080/ I'd call that automatic reliable build process :-) Of course there are problems now and then, but they usually are fixed quickly. The Hudson resources will be retargeted at the main line trunk as soon as the release is finally complete. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Fri Feb 19 16:08:04 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 15:08:04 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <168033.59265.qm@web23601.mail.ird.yahoo.com> Hi: Thanks for your answer. Yes, I tried it in late 2008 as in the web page resulted. Then on mid 2009 with cm3's tree cvsup. I was thinking in a command line switch like to cm3 -DNO_PTHREADS (or cm3 -DUSER_THREADS). Does something like that exist? Yes, I will try it building again to see where it gets with current (cvs release ranch). Do you know which branch I should use cvs like cvs tag release_branch_cm3_5_8 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 ? Thanks in advance, --- El vie, 19/2/10, Jay K escribi?: > De: Jay K > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Daniel (M3)" , "Olaf" , "m3devel" > Fecha: viernes, 19 de febrero, 2010 05:43 > > > > > > Daniel, if you really last tried this in 2008, please > try again. > > I'm not sure we had cvsup in our tree in 2008 though. > > Even if you tried it in 2009, try again? > > http://aivwiki.alma.cl/index.php/Installing_CVSup > points to a particular non-current Modula-3 and a particular > cvsup. > > We have cvsup in our tree now. Which did you use? Please > try ours. > > > > -Jay > > > > Date: Fri, 19 Feb 2010 06:20:10 +0000 > > From: dabenavidesd at yahoo.es > > To: wagner at elegosoft.com; m3devel at elegosoft.com; > jay.krell at cornell.edu > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > > > HI: > > thanks for answering so fast! > > Well, more or less I tried to understand what was > happening on cvsup LINUXLIBC6 on late 2008 quickly and half > a year ago more carefully. > > First I tried with system level threads and the first > connection worked to retrieve files as I remember in this > example case: > http://aivwiki.alma.cl/index.php/Installing_CVSup > > > > more or less it makes you to do > > cvsupd -b /diska/cvsup/base/ > > which works for first client login as is written in > the web page (that happened in my late 2008 try seeing the > above url case as pointed by the person who tried and > reported this at that time) > > Then you had to use background command to cvsupd > (where I think the problem appears but not in the first > process, but in the forked, if forked or in both) > copying/pasting the two commands from the url of case above > mentioned > > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > > This doesn't work (for me in both tries) and the > reason is the problem is when the process forks so there > might somehow a "small" error because process > forked won't work as expectedly (I don't even if it > dies on system) or if and runtime error is given. I just > grabbed this output from terminal: > > > > (First command and executing after it the client with > .sup file given there in the web page) > > % telnet 192.168.0.3 5999 > > Trying 192.168.0.3... > > Connected to 192.168.0.3. > > Escape character is '^]'. > > OK 17 0 2009-07-20 14:06:34 CVSup server ready > > Connection closed by foreign host. > > > > (After, second command it doesn't wait anything or > if some client request, it just finish like this) > > % telnet 192.168.0.3 5999 > > Trying 192.168.0.3... > > Connected to 192.168.0.3. > > Escape character is '^]'. > > > > > > Connection closed by foreign host. > > % pwd > > > > > > seeing docs from and now not found > http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > > Directorio de trabajo > /home/test/code/cm3-cvs/m3-tools/cvsup/server. > > (m3gdb) file LINUXLIBC6/cvsupd > > Reading symbols from > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > > Using host libthread_db library > "/lib/tls/i686/cmov/libthread_db.so.1". > > > > (m3gdb) break src/Main.m3:BecomeDaemon > > No source file named src/Main.m3. > > Make breakpoint pending on future shared library load? > (y or [n]) y > > > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) > pendiente. > > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 > -l /home/test/code/cvsup/log > > (m3gdb) set follow-fork-mode child > > (m3gdb) run > > Starting program: > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd > -b /home/test/code/cvsup/base/ -C 5 -l > /home/test/code/cvsup/log > > Signal Stop Print Pass to program Description > > SIG64 No No Yes Real-time event 64 > > [Thread debugging using libthread_db enabled] > > [Nuevo LWP 5074] > > [Nuevo Thread -1221278032 (LWP 5074)] > > > > > > In the above m3gdb session I did last year a session > on it; I didn't find quite easy to follow track of > forked process to see the stacks of the forked process, I > didn't tried too hard. But I know gdb has a feature to > allow you doing that, but I merely looked into gdb docs > quickly, and thinking it now I should retry to see if m3gdb > could get these days into that. Hints here or some advise > would be appreciated, perhaps Rodney has a better idea of > status of this feature on current m3gdb. > > I don't know how to build with user-level threads, > first I think I must recompile from bootstrap switched to > user-level threads, right? I would appreciate any help on > how to do that. > > > > About the case of NT386GNU and alternatives, I expect > this tools gets optimized over the time more and more, which > is the case for other platforms systems, current multi-core > machines shows the speed up as you might have compared in > over all compile time with older systems (wouldn't be a > bad idea to grab those statistics from m3quake) to compare > results in M3 terms and probably in over-all process if > possible. There could be a similar performance or at least a > constant reduction in number of seconds each time it gets a > better platform. > > > > Thanks in advance, > > > > --- El jue, 18/2/10, Jay K > escribi?: > > > > > De: Jay K > > > Asunto: RE: [M3devel] More testing needed for > m3back, was: RE: m3back/longint/atomics > > > Para: "Daniel (M3)" > , "Olaf" > , "m3devel" > > > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > > > https://projects.elego.de/cm3/ticket/1080 > > > can you provide the cvsup configuration file? > Thanks. > > > Can you try building with user threads and see if > it > > > occurs? > > > Or on another platform? > > > > > > > > > This is definitely something we want to look > into. > > > > > > > > > NT386GNU is there and worked for me, but it is > slow. > > > It had 64bit longint way ahead of NT386, but > NT386 is there > > > now. > > > There is also NT386MINGNU. > > > > > > > > > More testing definitely appreciated. > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > > From: dabenavidesd at yahoo.es > > > > Subject: Re: [M3devel] More testing needed > for m3back, > > > was: RE: m3back/longint/atomics > > > > To: wagner at elegosoft.com; > > > m3devel at elegosoft.com; > > > jay.krell at cornell.edu > > > > > > > > Hi all: > > > > great news to hear about a release coming > soon, but > > > how about testing NT386GNU or derivatives of it, > would be > > > hard to set up (I might try a friend's > machine). > > > > As I understood that was a great port to new > Modula-3 > > > programmers coming into the M3 world from win > world. This > > > doesn't have the all packages but is this a > must to give > > > have a check to release this port? > > > > Any news from cvsup ticket #1080 > https://projects.elego.de/cm3/ticket/1080 > > > ? > > > > Is there any chance to bring those platforms > in final > > > release? > > > > Any difficulties to start trying that? > > > > Thanks in advance > > > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > > > >> De: Jay K > > > >> Asunto: Re: [M3devel] More testing > needed for > > > m3back, was: RE: m3back/longint/atomics > > > >> Para: "Olaf" , > "m3devel" > > > >> Fecha: jueves, 18 de febrero, 2010 > 16:26 > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> I added some testing, found/fixed bugs > in the gcc > > > >> backend (initializing constants, > division). > > > >> > > > >> They should be in the automated tests > already. > > > >> > > > >> However don't let this stop you from > doing > > > >> everything/anything you can think of. > > > >> > > > >> I didn't do all that much and you > can save time > > > and get > > > >> more done by not worrying > > > >> > > > >> about the duplication. > > > >> > > > >> Pickles I didn't do anything with at > all, so if > > > you > > > >> really want to avoid/delay duplication, > > > >> > > > >> start with them. > > > >> > > > >> > > > >> > > > >> - Jay > > > >> > > > >> > > > >>> Date: Thu, 18 Feb 2010 17:20:56 > +0100 > > > >>> From: wagner at elegosoft.com > > > >>> To: m3devel at elegosoft.com > > > >>> Subject: Re: [M3devel] More testing > needed for > > > m3back, > > > >> was: RE: m3back/longint/atomics > > > >>> > > > >>> Quoting "Coleburn, Randy" > > > >> : > > > >>> > > > >>>> I can certainly run some tests > on > > > Windows. > > > >>>> > > > >>>> I don't have any code that > uses longint, > > > so > > > >> either someone needs to > > > >>>> identify which existing programs > I can > > > build and > > > >> run to do the > > > >>>> tests, OR I suppose I can write > something > > > if you > > > >> can give me an idea > > > >>>> of how extensive the tests you > want. > > > >>> > > > >>> This sounds good! > > > >>> > > > >>> Some things that come to mind for > LONGINT > > > >> immeditately: > > > >>> > > > >>> o standard integer arithmetic (+, -, > *, DIV, > > > MOD) at > > > >> runtime, > > > >>> with and without overflows etc. > > > >>> o constant declarations > > > >>> o constant expressions > > > >>> o assignability (should be rather > strict; I'd > > > have > > > >> to check the mail > > > >>> archive for the details) > > > >>> o pickles > > > >>> > > > >>> It would be great if you could add > some tests > > > to > > > >> m3tests that are > > > >>> valid on all platforms. I expect > that some > > > should > > > >> already be in place, > > > >>> but haven't checked yet... > > > >>> > > > >>> Hm, a quick search for longint in > > > >>> > > > >>> > > > >> > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > >>> > > > >>> for example doesn't find > anything. Has nobody > > > >> added any LONGINT > > > >>> test yet? Probably I'm looking > for the wrong > > > >> string... > > > >>> > > > >>> A complete regression with cm3 and > other > > > programs you > > > >> may have available > > > >>> would be great, too, just to make > sure that > > > the > > > >> backend changes > > > >>> don't break any old > functionality. > > > >>> > > > >>> Olaf > > > >>> > > > >>>> > > > >>>> I've been trying to keep my > system updated > > > to > > > >> the latest sources on > > > >>>> the main trunk, but I've > been swamped > > > lately > > > >> and I'm afraid I'm a > > > >>>> few weeks stale right now. > I'll remedy > > > that > > > >> shortly. > > > >>>> > > > >>>> Regards, > > > >>>> Randy > > > >>>> > > > >>>> > ________________________________ > > > >>>> From: Olaf Wagner > [wagner at elegosoft.com] > > > >>>> Sent: Thursday, February 18, > 2010 6:57 AM > > > >>>> To: Jay K > > > >>>> Cc: m3devel > > > >>>> Subject: [M3devel] More testing > needed > > > for > > > >> m3back, was: RE: > > > >>>> m3back/longint/atomics > > > >>>> > > > >>>> If I understand Jay correctly, > it wouldn't > > > be > > > >> too difficult to bring > > > >>>> the m3ack LONGINT changes for > Windows into > > > the > > > >> release branch, but > > > >>>> more testing would be needed. > > > >>>> > > > >>>> Randy, you're the only one I > remember > > > offhand > > > >> who actively uses M3 > > > >>>> on Windows except for Jay. Could > you have > > > a > > > >> closer look at it? > > > >>>> (Changes are only on the trunk > right > > > now.) > > > >>>> > > > >>>> Or is anybody else here lurking > and eager > > > to do > > > >> some Windows-based tests? > > > >>>> > > > >>>> If nobody volunteers, I'm > afraid we will > > > have > > > >> to release without 64bit > > > >>>> LONGINT on Windows. > > > >>>> > > > >>>> Olaf > > > >>>> > > > >>>> Quoting Jay K : > > > >>>> > > > >>>>> NT386/longint changes are > almost > > > entirely in > > > >> the m3back package. > > > >>>>> > > > >>>>> There is also some small > easy stuff > > > in > > > >>>>> > > > m3-libs/m3core/src/Csupport/common/hand.c. > > > >>>>> > > > >>>>> It'd be really great if > anyone could > > > test > > > >> any of this and if > > > >>>>> anyone could review the diff > between > > > release > > > >> and head. > > > >>>>> > > > >>>>> Not just me. > > > >>>>> > > > >>>>> The changes for longint are > quite > > > large, even > > > >> if local. > > > >>>>> > > > >>>>> I can port them, in the case > of > > > m3back, just > > > >> copy, and make sure > > > >>>>> the atomics stuff > doesn't cause > > > problems > > > >> (it should be unused). > > > >>>>> > > > >>>>> There is also a small change > in > > > m3front so > > > >> that longint can be initialized. > > > >>>>> That affects all platforms. > > > >>>>> > > > >>>>> And a small change in > m3cc/parse.c > > > for > > > >> div/mod of longint on non-NT386. > > > >>>>> I have to test mod yet but > my fix > > > probably > > > >> helps it. > > > >>>>> > > > >>>>> It'd be really great if > anyone could > > > do > > > >> anything with this stuff. > > > >>>>> ie. for now in head, then > could easily > > > port > > > >> to release. > > > >>>>> > > > >>>>> We can of course release > either way, > > > >> depending on how satisfied people > > > >>>>> are with 32bit longint on > NT386. i.e. > > > longint > > > >> isn't useful portably, but it > > > >>>>> is useful on non-NT386 > platforms. > > > >>>>> > > > >>>>> - Jay > > > >>>>> > > > >>>>>> Date: Tue, 16 Feb 2010 > 16:12:52 > > > +0100 > > > >>>>>> From: > wagner at elegosoft.com > > > >>>>>> To: > m3devel at elegosoft.com > > > >>>>>> Subject: Re: [M3devel] > > > >> m3back/longint/atomics > > > >>>>>> > > > >>>>>> Quoting Jay K > > > >> : > > > >>>>>> > > > >>>>>>> > > > >>>>>>> As far as I > know/can > > > remember, > > > >> longint and atomics should all work > > > >>>>>>> now on NT386. > > > >>>>>>> > > > >>>>>>> Atomics only > currently for > > > 32bit > > > >> types. > > > >>>>>>> There are still a > few small > > > >> inefficiencies to maybe deal with. > > > >>>>>>> I'll add 64bit > shortly and > > > maybe > > > >> 8 and 16. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> We should probably > add *a lot* > > > more > > > >> test coverage in p226 and p227. > > > >>>>>>> > > > >>>>>>> e.g. longint > > > >> multiply/add/sub/divide, not just > insert/extract > > > like I > > > >>>>>>> did a bunch of. > > > >>>>>> > > > >>>>>> Any volunteers to > increase the > > > test > > > >> coverage? > > > >>>>>> > > > >>>>>>> Still to fix the > Win32 > > > m3core/libm3 > > > >> to not always truncate file sizes. > > > >>>>>>> > > > >>>>>>> Still maybe to do > something > > > about > > > >> rd/wr...? > > > >>>>>>> > > > >>>>>>> Still to wonder > about > > > NT386/longint > > > >> support in the release branch? > > > >>>>>> > > > >>>>>> Should we / will you > merge this > > > stuff to > > > >> the release branch? > > > >>>>>> Or should we release > without it? > > > How > > > >> local are the changes? > > > >>>>>> > > > >>>>>> Olaf > > > >>>> -- > > > >>>> Olaf Wagner -- elego Software > Solutions > > > GmbH > > > >>>> Gustav-Meyer-Allee 25 / Geb?ude > 12, > > > 13355 > > > >> Berlin, Germany > > > >>>> phone: +49 30 23 45 86 96 > mobile: +49 177 > > > 2345 > > > >> 869 fax: +49 30 23 45 86 95 > > > >>>> > > > >> http://www.elegosoft.com | > > > >> > > > >>>> Gesch?ftsf?hrer: Olaf Wagner | > Sitz: > > > Berlin > > > >>>> Handelregister: Amtsgericht > Charlottenburg > > > HRB > > > >> 77719 | USt-IdNr: DE163214194 > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> Olaf Wagner -- elego Software > Solutions GmbH > > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 > > > Berlin, > > > >> Germany > > > >>> phone: +49 30 23 45 86 96 mobile: > +49 177 2345 > > > 869 > > > >> fax: +49 30 23 45 86 95 > > > >>> http://www.elegosoft.com | > > > Gesch?ftsf?hrer: Olaf > > > >> Wagner | Sitz: Berlin > > > >>> Handelregister: Amtsgericht > Charlottenburg HRB > > > 77719 | > > > >> USt-IdNr: DE163214194 > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jay.krell at cornell.edu Fri Feb 19 22:08:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 21:08:47 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <168033.59265.qm@web23601.mail.ird.yahoo.com> References: , <168033.59265.qm@web23601.mail.ird.yahoo.com> Message-ID: Either head or release_branch_cm3_5_8. Something like cm3 -DNO-PTHREADS should work, yes. My scripts/python doesn't accept extra switches though. You could edit that into them, or use the *.sh files. Or edit m3-libs\m3core\src\thread.quake as I said. Thanks, - Jay > Date: Fri, 19 Feb 2010 15:08:04 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Hi: > Thanks for your answer. Yes, I tried it in late 2008 as in the web page resulted. Then on mid 2009 with cm3's tree cvsup. > I was thinking in a command line switch like to cm3 -DNO_PTHREADS (or cm3 -DUSER_THREADS). Does something like that exist? > Yes, I will try it building again to see where it gets with current (cvs release ranch). Do you know which branch I should use cvs like > cvs tag release_branch_cm3_5_8 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 ? > > > Thanks in advance, > > --- El vie, 19/2/10, Jay K escribi?: > > > De: Jay K > > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Para: "Daniel (M3)" , "Olaf" , "m3devel" > > Fecha: viernes, 19 de febrero, 2010 05:43 > > > > > > > > > > > > Daniel, if you really last tried this in 2008, please > > try again. > > > > I'm not sure we had cvsup in our tree in 2008 though. > > > > Even if you tried it in 2009, try again? > > > > http://aivwiki.alma.cl/index.php/Installing_CVSup > > points to a particular non-current Modula-3 and a particular > > cvsup. > > > > We have cvsup in our tree now. Which did you use? Please > > try ours. > > > > > > > > -Jay > > > > > > > Date: Fri, 19 Feb 2010 06:20:10 +0000 > > > From: dabenavidesd at yahoo.es > > > To: wagner at elegosoft.com; m3devel at elegosoft.com; > > jay.krell at cornell.edu > > > Subject: Re: [M3devel] More testing needed for m3back, > > was: RE: m3back/longint/atomics > > > > > > HI: > > > thanks for answering so fast! > > > Well, more or less I tried to understand what was > > happening on cvsup LINUXLIBC6 on late 2008 quickly and half > > a year ago more carefully. > > > First I tried with system level threads and the first > > connection worked to retrieve files as I remember in this > > example case: > > http://aivwiki.alma.cl/index.php/Installing_CVSup > > > > > > more or less it makes you to do > > > cvsupd -b /diska/cvsup/base/ > > > which works for first client login as is written in > > the web page (that happened in my late 2008 try seeing the > > above url case as pointed by the person who tried and > > reported this at that time) > > > Then you had to use background command to cvsupd > > (where I think the problem appears but not in the first > > process, but in the forked, if forked or in both) > > copying/pasting the two commands from the url of case above > > mentioned > > > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > > > This doesn't work (for me in both tries) and the > > reason is the problem is when the process forks so there > > might somehow a "small" error because process > > forked won't work as expectedly (I don't even if it > > dies on system) or if and runtime error is given. I just > > grabbed this output from terminal: > > > > > > (First command and executing after it the client with > > .sup file given there in the web page) > > > % telnet 192.168.0.3 5999 > > > Trying 192.168.0.3... > > > Connected to 192.168.0.3. > > > Escape character is '^]'. > > > OK 17 0 2009-07-20 14:06:34 CVSup server ready > > > Connection closed by foreign host. > > > > > > (After, second command it doesn't wait anything or > > if some client request, it just finish like this) > > > % telnet 192.168.0.3 5999 > > > Trying 192.168.0.3... > > > Connected to 192.168.0.3. > > > Escape character is '^]'. > > > > > > > > > Connection closed by foreign host. > > > % pwd > > > > > > > > > seeing docs from and now not found > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > > > > > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > > > Directorio de trabajo > > /home/test/code/cm3-cvs/m3-tools/cvsup/server. > > > (m3gdb) file LINUXLIBC6/cvsupd > > > Reading symbols from > > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > > > Using host libthread_db library > > "/lib/tls/i686/cmov/libthread_db.so.1". > > > > > > (m3gdb) break src/Main.m3:BecomeDaemon > > > No source file named src/Main.m3. > > > Make breakpoint pending on future shared library load? > > (y or [n]) y > > > > > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) > > pendiente. > > > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 > > -l /home/test/code/cvsup/log > > > (m3gdb) set follow-fork-mode child > > > (m3gdb) run > > > Starting program: > > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd > > -b /home/test/code/cvsup/base/ -C 5 -l > > /home/test/code/cvsup/log > > > Signal Stop Print Pass to program Description > > > SIG64 No No Yes Real-time event 64 > > > [Thread debugging using libthread_db enabled] > > > [Nuevo LWP 5074] > > > [Nuevo Thread -1221278032 (LWP 5074)] > > > > > > > > > In the above m3gdb session I did last year a session > > on it; I didn't find quite easy to follow track of > > forked process to see the stacks of the forked process, I > > didn't tried too hard. But I know gdb has a feature to > > allow you doing that, but I merely looked into gdb docs > > quickly, and thinking it now I should retry to see if m3gdb > > could get these days into that. Hints here or some advise > > would be appreciated, perhaps Rodney has a better idea of > > status of this feature on current m3gdb. > > > I don't know how to build with user-level threads, > > first I think I must recompile from bootstrap switched to > > user-level threads, right? I would appreciate any help on > > how to do that. > > > > > > About the case of NT386GNU and alternatives, I expect > > this tools gets optimized over the time more and more, which > > is the case for other platforms systems, current multi-core > > machines shows the speed up as you might have compared in > > over all compile time with older systems (wouldn't be a > > bad idea to grab those statistics from m3quake) to compare > > results in M3 terms and probably in over-all process if > > possible. There could be a similar performance or at least a > > constant reduction in number of seconds each time it gets a > > better platform. > > > > > > Thanks in advance, > > > > > > --- El jue, 18/2/10, Jay K > > escribi?: > > > > > > > De: Jay K > > > > Asunto: RE: [M3devel] More testing needed for > > m3back, was: RE: m3back/longint/atomics > > > > Para: "Daniel (M3)" > > , "Olaf" > > , "m3devel" > > > > > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > > > > > https://projects.elego.de/cm3/ticket/1080 > > > > can you provide the cvsup configuration file? > > Thanks. > > > > Can you try building with user threads and see if > > it > > > > occurs? > > > > Or on another platform? > > > > > > > > > > > > This is definitely something we want to look > > into. > > > > > > > > > > > > NT386GNU is there and worked for me, but it is > > slow. > > > > It had 64bit longint way ahead of NT386, but > > NT386 is there > > > > now. > > > > There is also NT386MINGNU. > > > > > > > > > > > > More testing definitely appreciated. > > > > > > > > > > > > Thanks, > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > > > From: dabenavidesd at yahoo.es > > > > > Subject: Re: [M3devel] More testing needed > > for m3back, > > > > was: RE: m3back/longint/atomics > > > > > To: wagner at elegosoft.com; > > > > m3devel at elegosoft.com; > > > > jay.krell at cornell.edu > > > > > > > > > > Hi all: > > > > > great news to hear about a release coming > > soon, but > > > > how about testing NT386GNU or derivatives of it, > > would be > > > > hard to set up (I might try a friend's > > machine). > > > > > As I understood that was a great port to new > > Modula-3 > > > > programmers coming into the M3 world from win > > world. This > > > > doesn't have the all packages but is this a > > must to give > > > > have a check to release this port? > > > > > Any news from cvsup ticket #1080 > > https://projects.elego.de/cm3/ticket/1080 > > > > ? > > > > > Is there any chance to bring those platforms > > in final > > > > release? > > > > > Any difficulties to start trying that? > > > > > Thanks in advance > > > > > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > > > > > >> De: Jay K > > > > >> Asunto: Re: [M3devel] More testing > > needed for > > > > m3back, was: RE: m3back/longint/atomics > > > > >> Para: "Olaf" , > > "m3devel" > > > > >> Fecha: jueves, 18 de febrero, 2010 > > 16:26 > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> I added some testing, found/fixed bugs > > in the gcc > > > > >> backend (initializing constants, > > division). > > > > >> > > > > >> They should be in the automated tests > > already. > > > > >> > > > > >> However don't let this stop you from > > doing > > > > >> everything/anything you can think of. > > > > >> > > > > >> I didn't do all that much and you > > can save time > > > > and get > > > > >> more done by not worrying > > > > >> > > > > >> about the duplication. > > > > >> > > > > >> Pickles I didn't do anything with at > > all, so if > > > > you > > > > >> really want to avoid/delay duplication, > > > > >> > > > > >> start with them. > > > > >> > > > > >> > > > > >> > > > > >> - Jay > > > > >> > > > > >> > > > > >>> Date: Thu, 18 Feb 2010 17:20:56 > > +0100 > > > > >>> From: wagner at elegosoft.com > > > > >>> To: m3devel at elegosoft.com > > > > >>> Subject: Re: [M3devel] More testing > > needed for > > > > m3back, > > > > >> was: RE: m3back/longint/atomics > > > > >>> > > > > >>> Quoting "Coleburn, Randy" > > > > >> : > > > > >>> > > > > >>>> I can certainly run some tests > > on > > > > Windows. > > > > >>>> > > > > >>>> I don't have any code that > > uses longint, > > > > so > > > > >> either someone needs to > > > > >>>> identify which existing programs > > I can > > > > build and > > > > >> run to do the > > > > >>>> tests, OR I suppose I can write > > something > > > > if you > > > > >> can give me an idea > > > > >>>> of how extensive the tests you > > want. > > > > >>> > > > > >>> This sounds good! > > > > >>> > > > > >>> Some things that come to mind for > > LONGINT > > > > >> immeditately: > > > > >>> > > > > >>> o standard integer arithmetic (+, -, > > *, DIV, > > > > MOD) at > > > > >> runtime, > > > > >>> with and without overflows etc. > > > > >>> o constant declarations > > > > >>> o constant expressions > > > > >>> o assignability (should be rather > > strict; I'd > > > > have > > > > >> to check the mail > > > > >>> archive for the details) > > > > >>> o pickles > > > > >>> > > > > >>> It would be great if you could add > > some tests > > > > to > > > > >> m3tests that are > > > > >>> valid on all platforms. I expect > > that some > > > > should > > > > >> already be in place, > > > > >>> but haven't checked yet... > > > > >>> > > > > >>> Hm, a quick search for longint in > > > > >>> > > > > >>> > > > > >> > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > > >>> > > > > >>> for example doesn't find > > anything. Has nobody > > > > >> added any LONGINT > > > > >>> test yet? Probably I'm looking > > for the wrong > > > > >> string... > > > > >>> > > > > >>> A complete regression with cm3 and > > other > > > > programs you > > > > >> may have available > > > > >>> would be great, too, just to make > > sure that > > > > the > > > > >> backend changes > > > > >>> don't break any old > > functionality. > > > > >>> > > > > >>> Olaf > > > > >>> > > > > >>>> > > > > >>>> I've been trying to keep my > > system updated > > > > to > > > > >> the latest sources on > > > > >>>> the main trunk, but I've > > been swamped > > > > lately > > > > >> and I'm afraid I'm a > > > > >>>> few weeks stale right now. > > I'll remedy > > > > that > > > > >> shortly. > > > > >>>> > > > > >>>> Regards, > > > > >>>> Randy > > > > >>>> > > > > >>>> > > ________________________________ > > > > >>>> From: Olaf Wagner > > [wagner at elegosoft.com] > > > > >>>> Sent: Thursday, February 18, > > 2010 6:57 AM > > > > >>>> To: Jay K > > > > >>>> Cc: m3devel > > > > >>>> Subject: [M3devel] More testing > > needed > > > > for > > > > >> m3back, was: RE: > > > > >>>> m3back/longint/atomics > > > > >>>> > > > > >>>> If I understand Jay correctly, > > it wouldn't > > > > be > > > > >> too difficult to bring > > > > >>>> the m3ack LONGINT changes for > > Windows into > > > > the > > > > >> release branch, but > > > > >>>> more testing would be needed. > > > > >>>> > > > > >>>> Randy, you're the only one I > > remember > > > > offhand > > > > >> who actively uses M3 > > > > >>>> on Windows except for Jay. Could > > you have > > > > a > > > > >> closer look at it? > > > > >>>> (Changes are only on the trunk > > right > > > > now.) > > > > >>>> > > > > >>>> Or is anybody else here lurking > > and eager > > > > to do > > > > >> some Windows-based tests? > > > > >>>> > > > > >>>> If nobody volunteers, I'm > > afraid we will > > > > have > > > > >> to release without 64bit > > > > >>>> LONGINT on Windows. > > > > >>>> > > > > >>>> Olaf > > > > >>>> > > > > >>>> Quoting Jay K : > > > > >>>> > > > > >>>>> NT386/longint changes are > > almost > > > > entirely in > > > > >> the m3back package. > > > > >>>>> > > > > >>>>> There is also some small > > easy stuff > > > > in > > > > >>>>> > > > > m3-libs/m3core/src/Csupport/common/hand.c. > > > > >>>>> > > > > >>>>> It'd be really great if > > anyone could > > > > test > > > > >> any of this and if > > > > >>>>> anyone could review the diff > > between > > > > release > > > > >> and head. > > > > >>>>> > > > > >>>>> Not just me. > > > > >>>>> > > > > >>>>> The changes for longint are > > quite > > > > large, even > > > > >> if local. > > > > >>>>> > > > > >>>>> I can port them, in the case > > of > > > > m3back, just > > > > >> copy, and make sure > > > > >>>>> the atomics stuff > > doesn't cause > > > > problems > > > > >> (it should be unused). > > > > >>>>> > > > > >>>>> There is also a small change > > in > > > > m3front so > > > > >> that longint can be initialized. > > > > >>>>> That affects all platforms. > > > > >>>>> > > > > >>>>> And a small change in > > m3cc/parse.c > > > > for > > > > >> div/mod of longint on non-NT386. > > > > >>>>> I have to test mod yet but > > my fix > > > > probably > > > > >> helps it. > > > > >>>>> > > > > >>>>> It'd be really great if > > anyone could > > > > do > > > > >> anything with this stuff. > > > > >>>>> ie. for now in head, then > > could easily > > > > port > > > > >> to release. > > > > >>>>> > > > > >>>>> We can of course release > > either way, > > > > >> depending on how satisfied people > > > > >>>>> are with 32bit longint on > > NT386. i.e. > > > > longint > > > > >> isn't useful portably, but it > > > > >>>>> is useful on non-NT386 > > platforms. > > > > >>>>> > > > > >>>>> - Jay > > > > >>>>> > > > > >>>>>> Date: Tue, 16 Feb 2010 > > 16:12:52 > > > > +0100 > > > > >>>>>> From: > > wagner at elegosoft.com > > > > >>>>>> To: > > m3devel at elegosoft.com > > > > >>>>>> Subject: Re: [M3devel] > > > > >> m3back/longint/atomics > > > > >>>>>> > > > > >>>>>> Quoting Jay K > > > > >> : > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> As far as I > > know/can > > > > remember, > > > > >> longint and atomics should all work > > > > >>>>>>> now on NT386. > > > > >>>>>>> > > > > >>>>>>> Atomics only > > currently for > > > > 32bit > > > > >> types. > > > > >>>>>>> There are still a > > few small > > > > >> inefficiencies to maybe deal with. > > > > >>>>>>> I'll add 64bit > > shortly and > > > > maybe > > > > >> 8 and 16. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> We should probably > > add *a lot* > > > > more > > > > >> test coverage in p226 and p227. > > > > >>>>>>> > > > > >>>>>>> e.g. longint > > > > >> multiply/add/sub/divide, not just > > insert/extract > > > > like I > > > > >>>>>>> did a bunch of. > > > > >>>>>> > > > > >>>>>> Any volunteers to > > increase the > > > > test > > > > >> coverage? > > > > >>>>>> > > > > >>>>>>> Still to fix the > > Win32 > > > > m3core/libm3 > > > > >> to not always truncate file sizes. > > > > >>>>>>> > > > > >>>>>>> Still maybe to do > > something > > > > about > > > > >> rd/wr...? > > > > >>>>>>> > > > > >>>>>>> Still to wonder > > about > > > > NT386/longint > > > > >> support in the release branch? > > > > >>>>>> > > > > >>>>>> Should we / will you > > merge this > > > > stuff to > > > > >> the release branch? > > > > >>>>>> Or should we release > > without it? > > > > How > > > > >> local are the changes? > > > > >>>>>> > > > > >>>>>> Olaf > > > > >>>> -- > > > > >>>> Olaf Wagner -- elego Software > > Solutions > > > > GmbH > > > > >>>> Gustav-Meyer-Allee 25 / Geb?ude > > 12, > > > > 13355 > > > > >> Berlin, Germany > > > > >>>> phone: +49 30 23 45 86 96 > > mobile: +49 177 > > > > 2345 > > > > >> 869 fax: +49 30 23 45 86 95 > > > > >>>> > > > > >> http://www.elegosoft.com | > > > > >> > > > > >>>> Gesch?ftsf?hrer: Olaf Wagner | > > Sitz: > > > > Berlin > > > > >>>> Handelregister: Amtsgericht > > Charlottenburg > > > > HRB > > > > >> 77719 | USt-IdNr: DE163214194 > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> -- > > > > >>> Olaf Wagner -- elego Software > > Solutions GmbH > > > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, > > 13355 > > > > Berlin, > > > > >> Germany > > > > >>> phone: +49 30 23 45 86 96 mobile: > > +49 177 2345 > > > > 869 > > > > >> fax: +49 30 23 45 86 95 > > > > >>> http://www.elegosoft.com | > > > > Gesch?ftsf?hrer: Olaf > > > > >> Wagner | Sitz: Berlin > > > > >>> Handelregister: Amtsgericht > > Charlottenburg HRB > > > > 77719 | > > > > >> USt-IdNr: DE163214194 > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 11:31:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 10:31:06 +0000 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int Message-ID: 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. Or TInt/TWord/.i3/.m3, since they know deeply about it. Having m3back know about them seems a bit off. Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. This is a minor dilemna though. 2) Are you sure having a fixed precision of 8 bytes is correct here? More generally are you sure TInt has the right interface? How does one check for overflow within the precision one cares about? I think I know. I think Chop should return a boolean, as to if the value fits. For that matter, have SignedChop and UnsignedChop. Or TInt.Chop and TWord.Chop. TInt.Chop is already SignedChop. Do the math in 64bits, if that overflows, then overflow. And then truncate to whatever, and that can overflow too. This is related to "you all have convinced me that overflow isn't all that important really, but range checking is". So you in sense defer the overflow. You don't do the complete overflow check at Add or whatever, but then you do a range check converting to a small size. But hm. This will skip "intermediate overflow". Does that matter? 1 billion * 8 / 8 Should that overflow in 32bits? Well, easy enough, do the chop after each operation. I said "defer", but it is brief. 1B * 8 / 8 isn't written as 1* 8 / 8 convert to 32bits but rather 1B * 8 convert to 32bits => failure here / 8 convert to 32bits ? 3) Related to #2. Where should RightShift insert zeros? I guess you chop first, and then it works. Proposed something like: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = CONST extension = 0; VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; But I have to back to your version of m3back and try these out. Very speculative at the moment. Could also leave the data alone upon failure, trivially related to previous: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); BEGIN FOR i := n TO LAST(Int) DO IF r[i] # extension THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := extension; END; RETURN TRUE; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO IF r[i] # 0 THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := 0; END; return TRUE; END Chop; I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. I'd prefer TInt.UnsignedChop and TInt.SignedChop. Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 11:39:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 10:39:13 +0000 Subject: [M3devel] diff -c vs. diff -u Message-ID: For the record, I don't like diff -c. In particular the use of "!" to show a changed line, without showing what was there before. diff -u and plain diff seem better. (Sometimes plain diff is superior, like if there is an unordered list of things, context doesn't matter.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 12:28:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 11:28:18 +0000 Subject: [M3devel] diffs in checkin comments Message-ID: I know I started this, and I'm still undecided, but, right now, the diffs in comments makes it hard to scroll through history, too much distance between versions. e.g. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3 It would be super duper nice if the m3commit mail automatically included the (unified) diffs though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 12:52:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 11:52:21 +0000 Subject: [M3devel] calling conventions (small proposal) Message-ID: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 21 13:34:51 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Feb 2010 13:34:51 +0100 Subject: [M3devel] LONGCARD, release branch... Message-ID: <1266755691.5451.1.camel@faramir.m3w.org> I would like to build release branch from sources.... Where can I get cm3-bin-min which knows about LONGCARD? -- Dragi?a Duri? From jay.krell at cornell.edu Sun Feb 21 13:57:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 12:57:57 +0000 Subject: [M3devel] LONGCARD, release branch... In-Reply-To: <1266755691.5451.1.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> Message-ID: You shouldn't need it. Really. Again. do this: Get almost any old release. I recently used 5.4 on LINUXLIBC6. Maybe that was with head instead of release. cd scripts/python ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py buildship skipgcc - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 21 Feb 2010 13:34:51 +0100 > Subject: [M3devel] LONGCARD, release branch... > > I would like to build release branch from sources.... Where can I get > cm3-bin-min which knows about LONGCARD? > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 14:33:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 13:33:40 +0000 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int Message-ID: I *suspect* the "real" "big" problem is that left and right shift and "plain" shift should take a size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Subject: opacity of Target.Int, overflow of Target.Int Date: Sun, 21 Feb 2010 10:31:06 +0000 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. Or TInt/TWord/.i3/.m3, since they know deeply about it. Having m3back know about them seems a bit off. Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. This is a minor dilemna though. 2) Are you sure having a fixed precision of 8 bytes is correct here? More generally are you sure TInt has the right interface? How does one check for overflow within the precision one cares about? I think I know. I think Chop should return a boolean, as to if the value fits. For that matter, have SignedChop and UnsignedChop. Or TInt.Chop and TWord.Chop. TInt.Chop is already SignedChop. Do the math in 64bits, if that overflows, then overflow. And then truncate to whatever, and that can overflow too. This is related to "you all have convinced me that overflow isn't all that important really, but range checking is". So you in sense defer the overflow. You don't do the complete overflow check at Add or whatever, but then you do a range check converting to a small size. But hm. This will skip "intermediate overflow". Does that matter? 1 billion * 8 / 8 Should that overflow in 32bits? Well, easy enough, do the chop after each operation. I said "defer", but it is brief. 1B * 8 / 8 isn't written as 1* 8 / 8 convert to 32bits but rather 1B * 8 convert to 32bits => failure here / 8 convert to 32bits ? 3) Related to #2. Where should RightShift insert zeros? I guess you chop first, and then it works. Proposed something like: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = CONST extension = 0; VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; But I have to back to your version of m3back and try these out. Very speculative at the moment. Could also leave the data alone upon failure, trivially related to previous: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); BEGIN FOR i := n TO LAST(Int) DO IF r[i] # extension THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := extension; END; RETURN TRUE; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO IF r[i] # 0 THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := 0; END; return TRUE; END Chop; I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. I'd prefer TInt.UnsignedChop and TInt.SignedChop. Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 21 16:17:05 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Feb 2010 16:17:05 +0100 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: References: <1266755691.5451.1.camel@faramir.m3w.org> Message-ID: <1266765425.5451.9.camel@faramir.m3w.org> Can you PLEASE enable other people to use this system, TOO. As we once used it, before all this moving-target-****?????? PLEASE, I just need minimal compiler runtime so I can use STANDARD scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT and RECODE every single time you found it INTERESTING and FUNNY to CHANGE ALL OVER????!!! And I thought I am INSIDE of this development process. Do we really think other people will not be bored by our change-it-all-again-and-again games??? Do I have to spend some fixed weekly time on this list so I won't miss LATEST and GREATEST IDEAS and PRACTICES? Sorry for all this "screaming" but I am really dissapointed to see all this changed AGAIN! What do you people think potentital users of this systems are?? And what measure of torturing people are ready to endure along the way? On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: > ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py > buildship skipgcc -- Dragi?a Duri? From hosking at cs.purdue.edu Sun Feb 21 20:23:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:23:20 -0500 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int In-Reply-To: References: Message-ID: <5637ACC9-D874-48B4-8071-2B1D3375DE7C@cs.purdue.edu> On 21 Feb 2010, at 05:31, Jay K wrote: > 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. > Or TInt/TWord/.i3/.m3, since they know deeply about it. > Having m3back know about them seems a bit off. > Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. > This is a minor dilemna though. Yeah, but it doesn't need to be totally opaque does it? An array of sign-extended bytes in little-endian order seems pretty general. You don't even need to specify the length of the array. I actually contemplated having TInt take open arrays of arbitrary length, with the result array length indicating the precision desired, but didn't do that just to maintain a simple implementation. > 2) Are you sure having a fixed precision of 8 bytes is correct here? There is nothing to stop it having more precision. In fact, increasing the size shouldn't affect any client code (so long as it uses appropriate array constructors to fill the sign in to the end, and performs bounds-checking to results to the desired precision, as well as checking the return values for potential overflow in whatever precision is implemented by TInt). > More generally are you sure TInt has the right interface? > How does one check for overflow within the precision one cares about? Bounds check. > I think I know. > I think Chop should return a boolean, as to if the value fits. No, because you may choose to ignore the high bits yet still want to sign-extend from the precision desired. That is exactly what I do for word operations in the front-end. > For that matter, have SignedChop and UnsignedChop. You should not need these. > Or TInt.Chop and TWord.Chop. What do you need TWord.Chop for. For example, TWord.And(val, Target.Word.max) gives me just the bits I need for a Word.Size full value. Take a look at the (relatively small number of) changes I made to the front-end to do the appropriate checks and conversions. > TInt.Chop is already SignedChop. > > Do the math in 64bits, if that overflows, then overflow. > And then truncate to whatever, and that can overflow too. > This is related to "you all have convinced me that overflow isn't > all that important really, but range checking is". > So you in sense defer the overflow. You don't do the complete > overflow check at Add or whatever, but then you do a range > check converting to a small size. > > But hm. This will skip "intermediate overflow". Does that matter? > 1 billion * 8 / 8 > > > Should that overflow in 32bits? > > > Well, easy enough, do the chop after each operation. > I said "defer", but it is brief. > 1B * 8 / 8 > isn't written as > 1* 8 / 8 > convert to 32bits > > but rather > 1B * 8 > convert to 32bits > => failure here > / 8 > convert to 32bits > > ? > > > 3) Related to #2. > Where should RightShift insert zeros? > I guess you chop first, and then it works. > > > Proposed something like: > > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > CONST extension = 0; > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > > > But I have to back to your version of m3back and try these out. > Very speculative at the moment. > > Could also leave the data alone upon failure, trivially related to previous: > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # extension THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := extension; > END; > RETURN TRUE; > END Chop; > > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # 0 THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := 0; > END; > return TRUE; > END Chop; > > > I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. > I'd prefer TInt.UnsignedChop and TInt.SignedChop. > Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. > > > Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". > (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 20:24:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:24:12 -0500 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int In-Reply-To: References: Message-ID: <3F542805-0277-4334-BBD2-11D33231D22F@cs.purdue.edu> On 21 Feb 2010, at 08:33, Jay K wrote: > I *suspect* the "real" "big" problem is that left and right shift and "plain" shift should take a size. No! Simply mask the bits you want and perform the shift right, or shift left and mask the result. Easy! > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: opacity of Target.Int, overflow of Target.Int > Date: Sun, 21 Feb 2010 10:31:06 +0000 > > 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. > Or TInt/TWord/.i3/.m3, since they know deeply about it. > Having m3back know about them seems a bit off. > Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. > This is a minor dilemna though. > > > 2) Are you sure having a fixed precision of 8 bytes is correct here? > More generally are you sure TInt has the right interface? > How does one check for overflow within the precision one cares about? > I think I know. > I think Chop should return a boolean, as to if the value fits. > For that matter, have SignedChop and UnsignedChop. > Or TInt.Chop and TWord.Chop. > TInt.Chop is already SignedChop. > > Do the math in 64bits, if that overflows, then overflow. > And then truncate to whatever, and that can overflow too. > This is related to "you all have convinced me that overflow isn't > all that important really, but range checking is". > So you in sense defer the overflow. You don't do the complete > overflow check at Add or whatever, but then you do a range > check converting to a small size. > > But hm. This will skip "intermediate overflow". Does that matter? > 1 billion * 8 / 8 > > > Should that overflow in 32bits? > > > Well, easy enough, do the chop after each operation. > I said "defer", but it is brief. > 1B * 8 / 8 > isn't written as > 1* 8 / 8 > convert to 32bits > > but rather > 1B * 8 > convert to 32bits > => failure here > / 8 > convert to 32bits > > ? > > > 3) Related to #2. > Where should RightShift insert zeros? > I guess you chop first, and then it works. > > > Proposed something like: > > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > CONST extension = 0; > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > > > But I have to back to your version of m3back and try these out. > Very speculative at the moment. > > Could also leave the data alone upon failure, trivially related to previous: > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # extension THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := extension; > END; > RETURN TRUE; > END Chop; > > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # 0 THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := 0; > END; > return TRUE; > END Chop; > > > I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. > I'd prefer TInt.UnsignedChop and TInt.SignedChop. > Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. > > > Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". > (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 20:30:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:30:50 -0500 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <1266765425.5451.9.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> <1266765425.5451.9.camel@faramir.m3w.org> Message-ID: <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> Hi Dragisa, I too am a luddite and have never used any of Jay's scripts. I even still have essentially the same *old* monolithic config files on my system. Here is the general strategy. Take an old release. Compile and ship the following in order... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *old* libraries (m3core, libm3, sysutils). Now, compile and ship new libraries using the new compiler... m3core libm3 sysutils And build a new compiler against the new libraries... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *new* libraries. You should now be able to rebuild everything using the new compiler. Hope this helps! -- Tony (PS Let me know if you have any problems with this. I have a feeling there are some tweaks I have made to the m3makefiles to make this go through smoothly.) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 21 Feb 2010, at 10:17, Dragi?a Duri? wrote: > Can you PLEASE enable other people to use this system, TOO. As we once > used it, before all this moving-target-****?????? > > PLEASE, I just need minimal compiler runtime so I can use STANDARD > scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT > and RECODE every single time you found it INTERESTING and FUNNY to > CHANGE ALL OVER????!!! > > And I thought I am INSIDE of this development process. Do we really > think other people will not be bored by our > change-it-all-again-and-again games??? Do I have to spend some fixed > weekly time on this list so I won't miss LATEST and GREATEST IDEAS and > PRACTICES? > > Sorry for all this "screaming" but I am really dissapointed to see all > this changed AGAIN! What do you people think potentital users of this > systems are?? And what measure of torturing people are ready to endure > along the way? > > > On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: >> ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py >> buildship skipgcc > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 21 21:09:28 2010 From: darko at darko.org (Darko) Date: Mon, 22 Feb 2010 07:09:28 +1100 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:09:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:09:28 +0000 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> References: <1266755691.5451.1.camel@faramir.m3w.org>, , <1266765425.5451.9.camel@faramir.m3w.org>, <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> Message-ID: Dragisa, I didn't change or break anything here. You can use the older upgrade.sh, or you can do what Tony said. None of the options seem to be well known, neither mine nor the old ways. I find Tony's steps long and tedious, so much so that he made some mistakes below (sysutils isn't in old releases, so needs to be in the first pass (and the second pass), m3cc is needed at some point). Obviously others did too, as they where automated first in the *.sh files. Who can remember that order? I just made it all easier, automated, portable, maintainable. And I did it years ago. For some definition of easier/automated/portable/maintable. To me .sh is not maintainable, and .py is more portable -- I'd rather depend on Python than Cygwin. Writing .sh that works across Linux, *BSD, Solaris, seems to be quite a battle. I can't remember all the rules for "how to write portable .sh" (see the Autoconf documentation), and I witness Olaf struggle with that too, I can hardly grasp the .sh language in the first place, and I suspect it is "overly string based", in the genre of severely flawed languages like cmd and Tcl. (Look at what '{' and '}' mean in Tcl. They aren't lexically scoping, as they appear to be, they are actually a string escape mechanism.) However I still don't have OpenBSD/mips64 Python, and I use *.sh there (haven't been there in a while, small probably with libffi). The automated builds use mostly *.sh, though making the .msis and .debs use Python. Given a system - not written in C - with necessary circular dependencies - that doesn't use make/autoconf Not necessarily bad things any of them (circular dependencies are just unavoidable), it's never going to be among the easiest to build. Since I do occasionally go back to old releases, and find running cminstall annoying, I've made the current config files compatible with older releases. The .py scripts do upgrade them first. Where .sh probably doesn't. We do provide prebuilt binaries, just that I don't always know where to get them esp. up to date ones. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 14:30:50 -0500 To: dragisha at m3w.org CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] LONGCARD, release branch... A R G H Hi Dragisa, I too am a luddite and have never used any of Jay's scripts. I even still have essentially the same *old* monolithic config files on my system. Here is the general strategy. Take an old release. Compile and ship the following in order... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *old* libraries (m3core, libm3, sysutils). Now, compile and ship new libraries using the new compiler... m3core libm3 sysutils And build a new compiler against the new libraries... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *new* libraries. You should now be able to rebuild everything using the new compiler. Hope this helps! -- Tony (PS Let me know if you have any problems with this. I have a feeling there are some tweaks I have made to the m3makefiles to make this go through smoothly.) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 21 Feb 2010, at 10:17, Dragi?a Duri? wrote: Can you PLEASE enable other people to use this system, TOO. As we once used it, before all this moving-target-****?????? PLEASE, I just need minimal compiler runtime so I can use STANDARD scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT and RECODE every single time you found it INTERESTING and FUNNY to CHANGE ALL OVER????!!! And I thought I am INSIDE of this development process. Do we really think other people will not be bored by our change-it-all-again-and-again games??? Do I have to spend some fixed weekly time on this list so I won't miss LATEST and GREATEST IDEAS and PRACTICES? Sorry for all this "screaming" but I am really dissapointed to see all this changed AGAIN! What do you people think potentital users of this systems are?? And what measure of torturing people are ready to endure along the way? On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py buildship skipgcc -- Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:16:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:16:38 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Message-ID: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 21:54:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 15:54:13 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> Message-ID: <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 21 21:51:07 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 21 Feb 2010 15:51:07 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> Message-ID: <20100221205107.GD17113@topoi.pooq.com> On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the > NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl The first time I read this, I think I misunderstood. Presumably you don't mean that *all* platforms should ignore. You mean that NT386/I386_CYGWIN/etc. should still interpret them? -- hendrik From hosking at cs.purdue.edu Sun Feb 21 22:42:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 16:42:06 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Message-ID: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:47:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:47:31 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <20100221205107.GD17113@topoi.pooq.com> References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <20100221205107.GD17113@topoi.pooq.com> Message-ID: Right, of course. - Jay > Date: Sun, 21 Feb 2010 15:51:07 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] calling conventions (small proposal) > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > > > 1) All platforms should accept, but silently ignore, the > > NT386/I386_CYGWIN/etc. calling conventions: > > at least __stdcall, and __cdecl > > The first time I read this, I think I misunderstood. Presumably you > don't mean that *all* platforms should ignore. You mean that > NT386/I386_CYGWIN/etc. should still interpret them? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:48:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:48:31 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Message-ID: Its meaning varies per platform. On platforms it changes the calling convention. On other platforms it means do nothing. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:42:06 -0500 CC: darko at darko.org; m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 22:52:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 16:52:20 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> Message-ID: The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage some. >> >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. Besides, as long as no platform uses >> the same name to mean multiple things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 21 22:47:58 2010 From: darko at darko.org (Darko) Date: Mon, 22 Feb 2010 08:47:58 +1100 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Message-ID: <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 10:52:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 09:52:21 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 22 15:39:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Feb 2010 15:39:11 +0100 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <1266765425.5451.9.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> <1266765425.5451.9.camel@faramir.m3w.org> Message-ID: <20100222153911.chn7guy1w4gs00s0@mail.elegosoft.com> Quoting Dragi?a Duri? : > Can you PLEASE enable other people to use this system, TOO. As we once > used it, before all this moving-target-****?????? > > PLEASE, I just need minimal compiler runtime so I can use STANDARD > scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT > and RECODE every single time you found it INTERESTING and FUNNY to > CHANGE ALL OVER????!!! > > And I thought I am INSIDE of this development process. Do we really > think other people will not be bored by our > change-it-all-again-and-again games??? Do I have to spend some fixed > weekly time on this list so I won't miss LATEST and GREATEST IDEAS and > PRACTICES? > > Sorry for all this "screaming" but I am really dissapointed to see all > this changed AGAIN! What do you people think potentital users of this > systems are?? And what measure of torturing people are ready to endure > along the way? Hi Dragisha, I don't think that anything has changed or become broken recently regarding the cm3 build, too. If you want to avoid the tedious upgrade path, you can always find some recent executables in the Hudson jobs' workspaces. They only follow the release branch currently though. For example, look at http://hudson.modula3.com:8080/job/cm3-build-LINUXLIBC6/ws/cm3/m3-sys/cm3/LINUXLIBC6/ for the Linux 32 bit platform. If the build isn't in progress right when you look, you should find the last built cm3 there. Of course you can do that for other target platforms, too, as long as the servers are up. I haven't started building RC5 yet, as more testing is going on for the 64 bit LONGINT changes in the integrated Windows backend. So there is no `official' package giving you the latest state as you seem to require. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 22 15:43:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Feb 2010 15:43:50 +0100 Subject: [M3devel] diffs in checkin comments In-Reply-To: References: Message-ID: <20100222154350.npvj1ypb4kokcows@mail.elegosoft.com> Quoting Jay K : > I know I started this, and I'm still undecided, but, right now, the > diffs in comments makes it hard to scroll through history, too much > distance between versions. e.g. > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3 Well, yes, actually diffs are derivable information and shouldn't be stored in the change log. > It would be super duper nice if the m3commit mail automatically > included the (unified) diffs though. Jay, I haven't got the time, but we would need to adapt one of the Perl scripts in the CVSROOT of cm3 to do that. I don't know how difficult it would be (and won't try as I'm not really good in Perl and haven't got the time right now), but a decent Perl hacker should be able to do the job quickly ;-) Any volunteers? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 22 17:01:57 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 11:01:57 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 22:10:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 21:10:08 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Message-ID: >> But why would you have platform-dependent pragmas in code that is not platform-dependent? example of mostly portable + pragma: ? hand.c: ? #if !defined(_MSC_VER) && !defined(__stdcall) #define __stdcall /* nothing */ #endif ? void __stdcall set_singleton ANSI(( ulong a, ulong* s)) KR((a, s) ulong a; ulong* s;) { ulong a_word = a / SET_GRAIN; ulong a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } ? (gcc on Windows #defines __stdcall to __attribute__(something)) ? Not the best example -- this function doesn't seem well motivated. We probably need a CG.i3 function to do div and mod in one go, since the processors usually expose that. Though this case is with a constant power of two, so.. And m3front would be a little pressed to notice the opportunity? - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 11:01:57 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 22:31:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 21:31:04 +0000 Subject: [M3devel] "pragmas being ignorable" In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: > I thought that was the point of pragmas, that the compiler could freely ignore them and that they > did not involve the correctness of the program. This confuses me. I'm not sure I see the line between having important meaning and having ignorable meaning. Is it like, they affect only codegen and diagnostics but not front end type/semantic analysis? Like "inline" and "nowarn"? <* asserts *> definitely change the behavior of a program. But I guess "behavior" and "correctness" are different? A "correct" program will never fail an assert, therefore removing them from a "correct" program makes no difference? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 22 23:45:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 17:45:12 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Message-ID: This is C code... On 22 Feb 2010, at 16:10, Jay K wrote: > >> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a constant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different than "ign! ore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, ! as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 22 23:46:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 17:46:14 -0500 Subject: [M3devel] "pragmas being ignorable" In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: <69ACB693-C6BA-4165-B901-F82F3FCBAD4E@cs.purdue.edu> On 22 Feb 2010, at 16:31, Jay K wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they > > did not involve the correctness of the program. > > This confuses me. I'm not sure I see the line between having > important meaning and having ignorable meaning. > Is it like, they affect only codegen and diagnostics but not > front end type/semantic analysis? Like "inline" and "nowarn"? Yes. > <* asserts *> definitely change the behavior of a program. > But I guess "behavior" and "correctness" are different? Asserts are benign so long as the program never violates the assertion. > A "correct" program will never fail an assert, therefore > removing them from a "correct" program makes no difference? Correct! And there is a compiler flag that lets you compile with assertions turned off... > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 23:59:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 22:59:36 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , Message-ID: There is an analog to Modula-3. Setting the calling convention on platforms that have them. "Doing nothing" on others. - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 17:45:12 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) This is C code... On 22 Feb 2010, at 16:10, Jay K wrote: >> But why would you have platform-dependent pragmas in code that is not platform-dependent? example of mostly portable + pragma: ? hand.c: ? #if !defined(_MSC_VER) && !defined(__stdcall) #define __stdcall /* nothing */ #endif ? void __stdcall set_singleton ANSI(( ulong a, ulong* s)) KR((a, s) ulong a; ulong* s;) { ulong a_word = a / SET_GRAIN; ulong a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } ? (gcc on Windows #defines __stdcall to __attribute__(something)) ? Not the best example -- this function doesn't seem well motivated. We probably need a CG.i3 function to do div and mod in one go, since the processors usually expose that. Though this case is with a constant power of two, so.. And m3front would be a little pressed to notice the opportunity? - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 11:01:57 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ign! ore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gr! atuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. ! Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, ! as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 23 02:05:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 20:05:46 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , Message-ID: <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? Again, I am very wary of platform-dependent pragmas in supposedly portable code! Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 17:59, Jay K wrote: > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > > >> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Feb 23 02:20:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 01:20:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> References: , ,,<8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , ,,<79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, ,,, ,,<477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, ,,<6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , ,,, ,,, , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> Message-ID: Two parts (sort of). 1) We do have what you describe -- __stdcall C code that Modula-3 calls. And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. I hope to get rid of that duplication. Later rather than earlier. 2) I want to write Modula-3 code that is __stdcall. We already have this, in platform specific code, e.g. the parameter to CreateThread. However I want to write code that is "otherwise" portable. In particular the replacements for hand.c Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:05:46 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > > > So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? > Again, I am very wary of platform-dependent pragmas in supposedly portable code! > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 17:59, Jay K wrote: > > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > >>> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > > From hosking at cs.purdue.edu Tue Feb 23 03:11:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 21:11:27 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> Message-ID: Why would Modula-3 coded versions of hand.c need calling conventions? They are Modula-3 code which will use the standard Modula-3 calling convention to call from Modula-3! On 22 Feb 2010, at 20:20, Jay K wrote: > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> From jay.krell at cornell.edu Tue Feb 23 03:27:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 02:27:40 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , ,,<8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , ,,<79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, ,,, ,,<477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, ,,<6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , ,,, ,,, , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> , Message-ID: > the standard Modula-3 calling convention I'm not sure I'm happy with the standard Modula-3 calling convention. It isn't the smaller one. - Jay ---------------------------------------- > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 21:11:27 -0500 > CC: m3devel at elegosoft.com; darko at darko.org > To: jay.krell at cornell.edu > > Why would Modula-3 coded versions of hand.c need calling conventions? They are Modula-3 code which will use the standard Modula-3 calling convention to call from Modula-3! > > > On 22 Feb 2010, at 20:20, Jay K wrote: > >> >> Two parts (sort of). >> >> >> 1) >> We do have what you describe -- __stdcall C code that Modula-3 calls. >> And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. >> I hope to get rid of that duplication. Later rather than earlier. >> >> >> >> 2) >> I want to write Modula-3 code that is __stdcall. >> We already have this, in platform specific code, e.g. the parameter to CreateThread. >> However I want to write code that is "otherwise" portable. >> In particular the replacements for hand.c >> >> >> Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. >> >> >> >> 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). >> >> >> 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. >> >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 20:05:46 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> >>> >>> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >>> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 22 Feb 2010, at 17:59, Jay K wrote: >>> >>> There is an analog to Modula-3. >>> Setting the calling convention on platforms that have them. >>> "Doing nothing" on others. >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 17:45:12 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> This is C code... >>> >>> On 22 Feb 2010, at 16:10, Jay K wrote: >>> >>>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> >>> example of mostly portable + pragma: >>> >>> ? >>> hand.c: >>> ? >>> #if !defined(_MSC_VER) && !defined(__stdcall) >>> #define __stdcall /* nothing */ >>> #endif >>> ? >>> void __stdcall set_singleton >>> ANSI(( ulong a, ulong* s)) >>> KR((a, s) ulong a; ulong* s;) >>> { >>> ulong a_word = a / SET_GRAIN; >>> ulong a_bit = a % SET_GRAIN; >>> s[a_word] |= (1UL << a_bit); >>> } >>> ? >>> >>> (gcc on Windows #defines __stdcall to __attribute__(something)) >>> ? >>> >>> Not the best example -- this function doesn't seem well motivated. >>> We probably need a CG.i3 function to do div and mod in one go, since >>> the processors usually expose that. >>> Though this case is with a co! nstant power of two, so.. >>> And m3front would be a little pressed to notice the opportunity? >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 11:01:57 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> Pragmas should never give errors. >>> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 22 Feb 2010, at 04:52, Jay K wrote: >>> >>> I wouldn't mind >>> - an error >>> - or a way to mark a pragma as needing an error vs. being ok with a warning >>> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >>> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >>> the syntax is, but there is a legitimate need to note calling conventions, >>> a syntax is already in use. I'd rather not invent a new syntax. >>> >>> >>> The word "ignore" isn't relevant. >>> Sorry if I was confusing. >>> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >>> but that most platforms interpret them as doing nothing. >>> The pragmas already exist. >>> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 16:52:20 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> The compiler does continue to compile having warned that the pragma has no meaning. >>> >>> So, yes, they are ignored, but I want a warning. >>> >>> I even want a warning if I write <**>. >>> >>> >>> On 21 Feb 2010, at 16:47, Darko wrote: >>> >>> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >>> >>> >>> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >>> >>> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >>> >>> On 21 Feb 2010, at 16:16, Jay K wrote: >>> >>> To be clear, I don't propose ignoring all unrecognized pragmas. >>> Just calling conventions. >>> You could interpret it as: >>> The pragmas *are* recognized, on all targets, but they have no meaning on most. >>> The meaning is "do nothing". >>> >>> >>> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >>> with I386_NT source. And they all mean nothing. This lets people maintain >>> one portable code base, and they *don't* even need to do so much as: >>> #ifndef _X86_ >>> #define __stdcall /* nothing */ >>> #define __cdecl /* nothing */ >>> #define __fastcall /* nothing */ >>> #endif >>> >>> >>> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >>> The rest are a pointless proliferation of synonyms. >>> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >>> a few minutes, that's not the issue). >>> >>> >>> Separate file would work, but I'd really rather stuff be all together. >>> Once you separate things, one version goes stale. >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 15:54:13 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> Accepting and silently ignoring sounds very dangerous! >>> >>> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >>> >>> Silence is deadly! >>> >>> On 21 Feb 2010, at 15:09, Darko wrote: >>> >>> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >>> >>> >>> >>> On 21/02/2010, at 10:52 PM, Jay K wrote: >>> >>> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >>> at least __stdcall, and __cdecl >>> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >>> >>> This is a very small change. >>> >>> >>> This is will allow: >>> a) possibly merging the two nearly identical OpenGL.i3 files >>> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >>> I intend to that for hand.c's replacement, soon. >>> >>> >>> Maybe experiment as to the perf. >>> __stdcall is supposed to be faster, because the code is smaller. >>> But __cdecl might be able to compete by using stores to the stack instead of pushes? >>> I'd have to see how that compares in size, and it does increase stack usage som! e. >>> ! >>> >>> Probably not worth large scale experimenting/changing, but maybe nice to mark >>> new functions/interfaces as __stdcall (see next point). >>> >>> >>> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >>> what with all the C<=>Modula-3 transitions. And not worth it given other >>> more valuable work to do. >>> >>> >>> 2) The calling convention pragmas should be allowed on an interface, to set >>> the default for an interface. >>> >>> 2b) and I guess as well on a module, for unexported functions >>> >>> I assert that other than __stdcall and __cdecl on NT386, nothing else is >>> particularly interesting here. There is __fastcall, maybe interesting. >>> It has different meanings to different compilers. >>> I'd rather keep this all fairly constrained. >>> >>> No other platform has more than one calling convention, so this doesn't >>> have be to further generalized. B! esides, ! as long as no platform uses >>> the same name to mean multipl e things, ok. >>> Mac68K Classic? >>> Mac68K CFM? >>> Win16? >>> MS-DOS? >>> >>> >>> (I did recently acquire a working Mac68K, as well it is easily >>> run on a modern PPC Mac; far down the list, but...) >>> >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > From darko at darko.org Tue Feb 23 05:03:55 2010 From: darko at darko.org (Darko) Date: Tue, 23 Feb 2010 15:03:55 +1100 Subject: [M3devel] calling conventions (small proposal) Message-ID: Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? -original message- Subject: RE: [M3devel] calling conventions (small proposal) From: Jay K Date: 23/02/2010 12:20 pm Two parts (sort of). 1) We do have what you describe -- __stdcall C code that Modula-3 calls. And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. I hope to get rid of that duplication. Later rather than earlier. 2) I want to write Modula-3 code that is __stdcall. We already have this, in platform specific code, e.g. the parameter to CreateThread. However I want to write code that is "otherwise" portable. In particular the replacements for hand.c Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:05:46 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > > > So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? > Again, I am very wary of platform-dependent pragmas in supposedly portable code! > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 17:59, Jay K wrote: > > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > >>> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > > From jay.krell at cornell.edu Tue Feb 23 05:37:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 04:37:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: You mean like: module("foo") module_calling_convention("foo", "__stdcall") % default calling convention for module foo or calling_convention("foocall", "__stdcall") calling_convention("barcall", "__cdecl") foo.m3: <*foocall*> PROCEDURE Foo()... <*barcall*> PROCEDURE Bar()... Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. The integration of quake and Modula-3..like.. "confuses" me. That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. If I look for analogies however..in C and C++ you can do something like easily enough Makefile: !if WIN32 CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl !else CFLAGS=-DFOOCALL= -DBARCALL= !endif so maybe not a bad idea? To repeat myself, we already have the following valid working syntax, on NT386: foo.i3 <*__stdcall*> PROCEDURE Foo()... foo.m3 <*__stdcall*> PROCEDURE Foo()... They have to match I believe. Of course the procedure doesn't necessarily occur in the .i3 file. My proposal is two part. 1) Accept the existing syntax on all platforms. The interpretion is "do nothing" on most platforms. 2) Allow the existing pragmas on interface/module also: <*__stdcall*> INTERFACE Foo... <*__stdcall*> MODULE Foo... #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. #2 allows for less repetition. This will let me use the possibly more efficient non-default calling convention for hand.c replacement. And possibly avoid having two nearly identical OpenGL.i3 files. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 15:03:55 +1100 > > Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 12:20 pm > > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> > From darko at darko.org Tue Feb 23 07:44:01 2010 From: darko at darko.org (Darko) Date: Tue, 23 Feb 2010 17:44:01 +1100 Subject: [M3devel] calling conventions (small proposal) Message-ID: Calling convention is almost a linking issue it seems pretty good idea to move it to the makefile somehow since it reduces portability otherwise -original message- Subject: RE: [M3devel] calling conventions (small proposal) From: Jay K Date: 23/02/2010 3:37 pm You mean like: module("foo") module_calling_convention("foo", "__stdcall") % default calling convention for module foo or calling_convention("foocall", "__stdcall") calling_convention("barcall", "__cdecl") foo.m3: <*foocall*> PROCEDURE Foo()... <*barcall*> PROCEDURE Bar()... Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. The integration of quake and Modula-3..like.. "confuses" me. That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. If I look for analogies however..in C and C++ you can do something like easily enough Makefile: !if WIN32 CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl !else CFLAGS=-DFOOCALL= -DBARCALL= !endif so maybe not a bad idea? To repeat myself, we already have the following valid working syntax, on NT386: foo.i3 <*__stdcall*> PROCEDURE Foo()... foo.m3 <*__stdcall*> PROCEDURE Foo()... They have to match I believe. Of course the procedure doesn't necessarily occur in the .i3 file. My proposal is two part. 1) Accept the existing syntax on all platforms. The interpretion is "do nothing" on most platforms. 2) Allow the existing pragmas on interface/module also: <*__stdcall*> INTERFACE Foo... <*__stdcall*> MODULE Foo... #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. #2 allows for less repetition. This will let me use the possibly more efficient non-default calling convention for hand.c replacement. And possibly avoid having two nearly identical OpenGL.i3 files. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 15:03:55 +1100 > > Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 12:20 pm > > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> > From jay.krell at cornell.edu Tue Feb 23 08:33:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 07:33:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: I don't understand. Assuming there are precious few calling conventions in the world, beyond 1 per platform, it seems fine as I propose. Oh, I think I see what you mean though. If you imagine multiple platforms with multiple calling conventions, then you'd want to intercede one portable name that is then redefined on a per-platform basis? My proposal either assumes there is one (set of) platform with any calling conventions (the same ones) OR, at least, that the names don't overlap across platforms with different meaning. That is, NT386 has __stcall, __cdecl. I write: INTERFACE Foo; <*__stdcall*>PROCEDURE Bar(); then future platform WIERD comes along and it has a calling convention "wierdcall". In this unlikely hypothetical world, I'd propose you write: <*wierdcall*><*__stdcall*>PROCEDURE Bar(); All platforms would be taught to recognize the pragma wierdcall, and the interpretation would be to do nothing except for target WIERD. The problem becomes if target WIERD has conventions, say, wierdcall and __stdcall, and you want __stcall on NT386 but wierdcall on WIERD. Then the above is ambiguous. But you could repair the unlikely problem after the fact, by using longer/diferent names when clashes come along. We'd stomp on __stdcall today for NT386, because it has been around a long time and is likely to remain unique. If WIERD comes along later with __stdcall, ok, we'd just call it weird__stdcall, and you'd write: <*wierd__stdcall*><*__stdcall*>PROCEDURE Foo(); ? If you wrote <*wierdcall__stdcall*><*wierdcall*>PROCEDURE Foo(); that would be an error, at least when targeting target WIERD. Just as, today, I hope, <*__stdcall*><*__cdecl*>PROCEDURE Foo() is an error. This is *slightly* complicated -- the long term hypothetical proposal is that multiple calling convension pragmas be allowed, depending on what exactly they are. Again remember that it is highly unusual for any platform to have multiple calling conventions, so this "problem" is not likely to grow. Does ARM have serious issues here? I know they have all kinds of execution modes. But I think Debian, for example, has two ARM platforms, and one calling convention each. ? Again, minimal is 1) allow existing NT386 syntax on all targets 2) possibly allow existing NT386 procedure pragma on modules/interfaces Is your desire to annotate something with "FOOCALL" and then experiment in m3makefile with mapping FOOCALL to one convention or another? And it would be multiple files, so the terseness of an interface/module pragma is not terse enough, it'd be too much to copy/paste? I can see that scenario. Can we at least agree on my #1, maybe my #2, and extend it after that? #1 is about two lines of change. I'll do it pretty soon. I just haven't gotten to it yet. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 17:44:01 +1100 > > Calling convention is almost a linking issue it seems pretty good idea to move it to the makefile somehow since it reduces portability otherwise > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 3:37 pm > > > You mean like: > > > module("foo") > module_calling_convention("foo", "__stdcall") > % default calling convention for module foo > > > or > calling_convention("foocall", "__stdcall") > calling_convention("barcall", "__cdecl") > > > foo.m3: > <*foocall*> PROCEDURE Foo()... > <*barcall*> PROCEDURE Bar()... > > > Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. > > > The integration of quake and Modula-3..like.. "confuses" me. > That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. > > If I look for analogies however..in C and C++ you can do something like easily enough > Makefile: > !if WIN32 > CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl > !else > CFLAGS=-DFOOCALL= -DBARCALL= > !endif > > > so maybe not a bad idea? > > > > > To repeat myself, we already have the following valid working syntax, on NT386: > > > foo.i3 > <*__stdcall*> PROCEDURE Foo()... > > foo.m3 > <*__stdcall*> PROCEDURE Foo()... > > They have to match I believe. > Of course the procedure doesn't necessarily occur in the .i3 file. > > > My proposal is two part. > > 1) Accept the existing syntax on all platforms. > The interpretion is "do nothing" on most platforms. > > > 2) Allow the existing pragmas on interface/module also: > > <*__stdcall*> INTERFACE Foo... > > <*__stdcall*> MODULE Foo... > > > #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. > > > #2 allows for less repetition. > > > This will let me use the possibly more efficient non-default calling convention for hand.c replacement. > > > And possibly avoid having two nearly identical OpenGL.i3 files. > > > - Jay > > > ---------------------------------------- >> From: darko at darko.org >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] calling conventions (small proposal) >> Date: Tue, 23 Feb 2010 15:03:55 +1100 >> >> Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? >> >> -original message- >> Subject: RE: [M3devel] calling conventions (small proposal) >> From: Jay K >> Date: 23/02/2010 12:20 pm >> >> >> Two parts (sort of). >> >> >> 1) >> We do have what you describe -- __stdcall C code that Modula-3 calls. >> And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. >> I hope to get rid of that duplication. Later rather than earlier. >> >> >> >> 2) >> I want to write Modula-3 code that is __stdcall. >> We already have this, in platform specific code, e.g. the parameter to CreateThread. >> However I want to write code that is "otherwise" portable. >> In particular the replacements for hand.c >> >> >> Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. >> >> >> >> 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). >> >> >> 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. >> >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 20:05:46 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> >>> >>> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >>> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 22 Feb 2010, at 17:59, Jay K wrote: >>> >>> There is an analog to Modula-3. >>> Setting the calling convention on platforms that have them. >>> "Doing nothing" on others. >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 17:45:12 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> This is C code... >>> >>> On 22 Feb 2010, at 16:10, Jay K wrote: >>> >>>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> >>> example of mostly portable + pragma: >>> >>> ? >>> hand.c: >>> ? >>> #if !defined(_MSC_VER) && !defined(__stdcall) >>> #define __stdcall /* nothing */ >>> #endif >>> ? >>> void __stdcall set_singleton >>> ANSI(( ulong a, ulong* s)) >>> KR((a, s) ulong a; ulong* s;) >>> { >>> ulong a_word = a / SET_GRAIN; >>> ulong a_bit = a % SET_GRAIN; >>> s[a_word] |= (1UL << a_bit); >>> } >>> ? >>> >>> (gcc on Windows #defines __stdcall to __attribute__(something)) >>> ? >>> >>> Not the best example -- this function doesn't seem well motivated. >>> We probably need a CG.i3 function to do div and mod in one go, since >>> the processors usually expose that. >>> Though this case is with a co! nstant power of two, so.. >>> And m3front would be a little pressed to notice the opportunity? >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 11:01:57 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> Pragmas should never give errors. >>> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 22 Feb 2010, at 04:52, Jay K wrote: >>> >>> I wouldn't mind >>> - an error >>> - or a way to mark a pragma as needing an error vs. being ok with a warning >>> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >>> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >>> the syntax is, but there is a legitimate need to note calling conventions, >>> a syntax is already in use. I'd rather not invent a new syntax. >>> >>> >>> The word "ignore" isn't relevant. >>> Sorry if I was confusing. >>> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >>> but that most platforms interpret them as doing nothing. >>> The pragmas already exist. >>> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 16:52:20 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> The compiler does continue to compile having warned that the pragma has no meaning. >>> >>> So, yes, they are ignored, but I want a warning. >>> >>> I even want a warning if I write <**>. >>> >>> >>> On 21 Feb 2010, at 16:47, Darko wrote: >>> >>> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >>> >>> >>> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >>> >>> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >>> >>> On 21 Feb 2010, at 16:16, Jay K wrote: >>> >>> To be clear, I don't propose ignoring all unrecognized pragmas. >>> Just calling conventions. >>> You could interpret it as: >>> The pragmas *are* recognized, on all targets, but they have no meaning on most. >>> The meaning is "do nothing". >>> >>> >>> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >>> with I386_NT source. And they all mean nothing. This lets people maintain >>> one portable code base, and they *don't* even need to do so much as: >>> #ifndef _X86_ >>> #define __stdcall /* nothing */ >>> #define __cdecl /* nothing */ >>> #define __fastcall /* nothing */ >>> #endif >>> >>> >>> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >>> The rest are a pointless proliferation of synonyms. >>> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >>> a few minutes, that's not the issue). >>> >>> >>> Separate file would work, but I'd really rather stuff be all together. >>> Once you separate things, one version goes stale. >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 15:54:13 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> Accepting and silently ignoring sounds very dangerous! >>> >>> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >>> >>> Silence is deadly! >>> >>> On 21 Feb 2010, at 15:09, Darko wrote: >>> >>> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >>> >>> >>> >>> On 21/02/2010, at 10:52 PM, Jay K wrote: >>> >>> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >>> at least __stdcall, and __cdecl >>> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >>> >>> This is a very small change. >>> >>> >>> This is will allow: >>> a) possibly merging the two nearly identical OpenGL.i3 files >>> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >>> I intend to that for hand.c's replacement, soon. >>> >>> >>> Maybe experiment as to the perf. >>> __stdcall is supposed to be faster, because the code is smaller. >>> But __cdecl might be able to compete by using stores to the stack instead of pushes? >>> I'd have to see how that compares in size, and it does increase stack usage som! e. >>> ! >>> >>> Probably not worth large scale experimenting/changing, but maybe nice to mark >>> new functions/interfaces as __stdcall (see next point). >>> >>> >>> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >>> what with all the C<=>Modula-3 transitions. And not worth it given other >>> more valuable work to do. >>> >>> >>> 2) The calling convention pragmas should be allowed on an interface, to set >>> the default for an interface. >>> >>> 2b) and I guess as well on a module, for unexported functions >>> >>> I assert that other than __stdcall and __cdecl on NT386, nothing else is >>> particularly interesting here. There is __fastcall, maybe interesting. >>> It has different meanings to different compilers. >>> I'd rather keep this all fairly constrained. >>> >>> No other platform has more than one calling convention, so this doesn't >>> have be to further generalized. B! esides, ! as long as no platform uses >>> the same name to mean multipl e things, ok. >>> Mac68K Classic? >>> Mac68K CFM? >>> Win16? >>> MS-DOS? >>> >>> >>> (I did recently acquire a working Mac68K, as well it is easily >>> run on a modern PPC Mac; far down the list, but...) >>> >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > From hendrik at topoi.pooq.com Tue Feb 23 19:19:38 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 23 Feb 2010 13:19:38 -0500 Subject: [M3devel] Style question about error messages Message-ID: <20100223181937.GA22300@topoi.pooq.com> Somewhere in my program after it has trued and failed to read the input file, I have the code Wr.PutText(Stdio.stderr, "No input file.\n"); Now presumably this message could be more detailed, but that's not waht I'm asking. What happens to me when I compile this code is the warning: "../src/Main.m3", line 63: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure Now presumably this is an indication that I ought to wrap the whole thing in a TRY clause. But what am I supposed to do if the attempt to produce an error message fails? Write an error message? What have other people done in this situation? --hendrik From hosking at cs.purdue.edu Tue Feb 23 20:15:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Feb 2010 14:15:32 -0500 Subject: [M3devel] Style question about error messages In-Reply-To: <20100223181937.GA22300@topoi.pooq.com> References: <20100223181937.GA22300@topoi.pooq.com> Message-ID: You can just record that exception as fatal in that code block with the <*FATAL Thread.Alerted*> pragma. On 23 Feb 2010, at 13:19, hendrik at topoi.pooq.com wrote: > Somewhere in my program after it has trued and failed to read the > input file, I have the code > > Wr.PutText(Stdio.stderr, "No input file.\n"); > > Now presumably this message could be more detailed, but that's not waht > I'm asking. What happens to me when I compile this code is the warning: > > "../src/Main.m3", line 63: warning: potentially unhandled exceptions: > Thread.Alerted, Wr.Failure > > Now presumably this is an indication that I ought to wrap the whole > thing in a TRY clause. But what am I supposed to do if the attempt to > produce an error message fails? Write an error message? > > What have other people done in this situation? > > --hendrik From rcolebur at SCIRES.COM Tue Feb 23 22:05:57 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 23 Feb 2010 16:05:57 -0500 Subject: [M3devel] Style question about error messages In-Reply-To: References: <20100223181937.GA22300@topoi.pooq.com> Message-ID: Hendrik: I have run into this situation also. If you have code that runs on multiple platforms, you have to think through the best way to handle. For example, code might work differently say between Unix and Windows. Indeed, if you have a Windows GUI mode program and try to write to stdout there is some magic that is used to allocate a console writer on the fly. Also, if you know you aren't using Alerts, you might be ok using the FATAL pragma as Tony suggests, but then for Wr.Failure you may want to take a different course. Also, depending on your program, you may want to trap both of these so you can clean up any other resource use before terminating the program. If you want more specifics, I can dig into some of my code for examples. Regards, Randy -----Original Message----- From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Tuesday, February 23, 2010 2:16 PM To: hendrik at topoi.pooq.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Style question about error messages You can just record that exception as fatal in that code block with the <*FATAL Thread.Alerted*> pragma. On 23 Feb 2010, at 13:19, hendrik at topoi.pooq.com wrote: > Somewhere in my program after it has trued and failed to read the > input file, I have the code > > Wr.PutText(Stdio.stderr, "No input file.\n"); > > Now presumably this message could be more detailed, but that's not waht > I'm asking. What happens to me when I compile this code is the warning: > > "../src/Main.m3", line 63: warning: potentially unhandled exceptions: > Thread.Alerted, Wr.Failure > > Now presumably this is an indication that I ought to wrap the whole > thing in a TRY clause. But what am I supposed to do if the attempt to > produce an error message fails? Write an error message? > > What have other people done in this situation? > > --hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. From jay.krell at cornell.edu Wed Feb 24 00:14:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 23:14:51 +0000 Subject: [M3devel] hand.c/set_singleton? Message-ID: I think hand.c is worth shrinking. And converting where easy to Modula-3. Agreed? It is "exercise" at least -- learn and get comfortable making changes, as long as they don't make anything worse. With that in mind, any hints on this: void set_singleton(size_t a, size_t* s) { size_t a_word = a / SET_GRAIN; size_t a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } Leave it alone? It works, not worth changing? Deal with it in m3front? In parse.c? I changed m3back to generate a bts instruction, which achieves "all four" operations in one instruction -- div (shift), mod (and), shift, or. The semantic mapping seems to be 100%. If set_singleton were a common operation, which I doubt, it seems like a major gain. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 00:33:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 23:33:29 +0000 Subject: [M3devel] AMD64_LINUX/Tinderbox Message-ID: AMD64_LINUX seems stuck in m3core's use of LONGCARD. Presumably a problem in Tinderbox, not the actual cm3 code. Maybe because there is only one job instead of two? Please fix? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 24 04:33:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Feb 2010 22:33:54 -0500 Subject: [M3devel] hand.c/set_singleton? In-Reply-To: References: Message-ID: We don't want this in m3front. On 23 Feb 2010, at 18:14, Jay K wrote: > I think hand.c is worth shrinking. > And converting where easy to Modula-3. > Agreed? > It is "exercise" at least -- learn and get comfortable making changes, as long as they don't make anything worse. > > > With that in mind, any hints on this: > > > void set_singleton(size_t a, size_t* s) > { > size_t a_word = a / SET_GRAIN; > size_t a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > > > Leave it alone? It works, not worth changing? > Deal with it in m3front? > In parse.c? > > > I changed m3back to generate a bts instruction, which achieves "all four" operations in one instruction -- div (shift), mod (and), shift, or. The semantic mapping seems to be 100%. If set_singleton were a common operation, which I doubt, it seems like a major gain. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 24 11:01:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 24 Feb 2010 11:01:30 +0100 Subject: [M3devel] AMD64_LINUX/Tinderbox In-Reply-To: References: Message-ID: <20100224110130.a810t555sgccoksg@mail.elegosoft.com> Quoting Jay K : > AMD64_LINUX seems stuck in m3core's use of LONGCARD. Sorry, I didn't notice this; I'm rather focused on Hudson and the release branch. > Presumably a problem in Tinderbox, not the actual cm3 code. > > Maybe because there is only one job instead of two? Well, yes. There is no old release for platform AMD64_LINUX, so the release-build job cannot run :-/ We should probably change the lastok-build job script to perform an upgrade in case of a failure. We wouldn't notice the incompatible change any more then though. > Please fix? I'll have a look at the scripts, perhaps tonight. I'd rather complete the release, use Hudson for the trunk then and disable the tinderbox job on birch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 24 13:41:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 12:41:12 +0000 Subject: [M3devel] portable/less portable test variations Message-ID: I'd like to write tests that, given different command line parameters, will either output totally portable results, or only somewhat portable, where "somewhat" probably means either portable to particular wordsize or portable to wordsize+endian. Worst case, completely platform specific. We'd have 1, 3, or 5 checked in expected results. Or possibly 1+n (portable + n platforms). This case is less useful, because it takes away the ability to compare, e.g. LINUXLIBC6 to NT386. The test would run twice, with and without the command line option. I guess it is about as much work to implement as to describe, but I've let it drag out. I have tests that would benefit from this. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 14:15:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 13:15:06 +0000 Subject: [M3devel] RTHook.Set* or RTSet.*? Message-ID: Again, I think hand.c's should largely be moved to Modula-3 code. e.g. all the "set_*" functions. (rough uncompiled unfinished) proposal #1 aka "RTHooks". premise: If the compiler generates calls to it, it ought to be in RTHooks. RTHooks.i3 TYPE Set = UNTRACED REF Word.T TYPE SetBoolean = Word.T; (* a full 32 or 64 bits; C would have returned at least 32 *) TYPE SetSize = CARDINAL; (* probably too much layering *) TYPE SetIndex = CARDINAL; (* probably too much layering *) CONST SetTRUE = 1; CONST SetFALSE = 0; PROCEDURE SetMember(set: Set; element: SetIndex): SetBoolean; (* SetTRUE IFF element IN set, else SetFALSE *) PROCEDURE SetUnion(inA, inB, out: Set; setSize: SetSize); (* out := inA + inB *) PROCEDURE SetIntersection(inA, inB, out: Set; setSize: SetSize); (* out := inA * inB *) PROCEDURE SetDifference(inA, inB, out: Set; setSize: SetSize); (* out := inA - inB *) PROCEDURE SetSymmetricDifference(inA, inB, out: Set; setSize: SetSize); (* out := inA xor inB *) PROCEDURE SetGE(inA, inB: Set; setSize: SetSize): SetBoolean; (* ... *) or longer SetGreaterOrEqual? etc. MODULE RTSet (m3-libs/m3core/src/runtime/common/RTSet.m3) EXPORTS RTHooks; ... You might also say: PROCEDURE SetMember(VAR set: Word.T; element: SetIndex): SetBoolean; esp. e.g. on the outputs. and to capture the invalidity of NULL? (rough uncompiled unfinished) proposal #2 aka "RTSet" premise: It seems right. RTSet.i3: (m3-libs/m3ore/src/runtime/common/RTSet.i3, or m3-libs/m3core/src/set?) It seems prudent to keep the "RT" prefix for global namespace reasons. It seems "RT" implies "runtime" directory though. I'd worry that calling it just Set.i3 could clash with other code. Notice that the existing names in hand.c cannot clash with any Modula-3 code, due to the single underscore. Perhaps perhaps perhaps this is a great reason to leave this all alone, because using C enables chosing identifiers in a separate namespace?? TYPE T = UNTRACED REF Word.T TYPE Boolean = Word.T; (* a full 32 or 64 bits; C would have returned at least 32 *) TYPE Size = CARDINAL; (* probably too much layering *) TYPE Index = CARDINAL; (* probably too much layering *) CONST True = 1; CONST False = 0; PROCEDURE Member aka In(set: T; element: Index): Boolean; (* True IFF element IN set, else False *) PROCEDURE Union aka Plus(inA, inB, out: T; size: Size); (* out := inA + inB *) PROCEDURE Intersect aka Intersection aka Times(inA, inB, out: T; size: Size); (* out := inA * inB *) PROCEDURE Difference aka Sub aka Subtract(inA, inB, out: T; size: Size); (* out := inA - inB *) PROCEDURE SymmetricDifference aka Xor(inA, inB, out: T; size: Size); (* out := inA xor inB *) PROCEDURE GE(inA, inB: T; size: Size): Boolean; (* ... *) etc. I'm undecided on the names. But I think I prefer: Union, Intersect, Difference, SymmetricDifference, Member, GE, EQ, NE, LT, LE, GT. It definitely looks nicer to put things in RTSet. (Assuming people believe "name scoping" is a good idea. There are counter arguments -- one flat global namespace is more conducive to search...) But the precedent of putting "everthing" in RTHooks seem clear. Though it is violated by hand.c..because it doesn't matter. You could declare them as extern in RTHooks.i3 and it wouldn't make any difference. The names are "never" referenced by Modula-3 code. Well, ok, m3back.m3 has the strings. I guess I'll do whittle at it a little more before doing this -- remove the tables, at least the NT386 exported ones. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 14:41:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 13:41:15 +0000 Subject: [M3devel] TInt.ToInt overflow In-Reply-To: References: <20100222225722.056AE2474001@birch.elegosoft.com>, ,,,,<48085E62-6C4C-4ECD-B1CB-F94CE7C5B10E@cs.purdue.edu>, , , , , , , , , , , , , <6A1F915C-A970-4485-8293-9E523DB278BA@cs.purdue.edu>, , , , <72B5DA75-B33A-4414-9E14-6625FA5816FB@cs.purdue.edu>, , <09B1E13B-15E0-452B-83E7-1F976049793C@cs.purdue.edu>, , Message-ID: Tony, it looks like basically all/many negative values are representeded as large positive values. Something is chopping the sign maybe? Here are the errors I get compiling m3core if I don't "ignore" overflow from TInt.ToInt. (for values that are under Integer.Word32.max). It isn't always clear how the source traffics in these numbers. I could get callstacks if it really helps. "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocStats.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 452: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 463: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 464: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 471: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 549: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 550: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 555: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 558: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 561: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 566: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 569: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 574: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 577: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 592: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 593: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 801: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 952: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 964: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 970: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1016: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1071: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1077: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1089: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1090: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1092: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1094: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1186: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1208: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1209: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1242: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immdiate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1702: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1724: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2056: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2257: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2259: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2365: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2386: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2398: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2418: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2420: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2425: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2442: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2482: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2498: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2520: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2525: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2541: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2543: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2697: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 78: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 79: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 86: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 87: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 99: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 81: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 82: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 89: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 96: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 101: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 103: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 108: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 119: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 "..\src\convert\Convert.m3", line 496: pushOp: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 "..\src\convert\Convert.m3", line 503: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: RE: [M3commit] CVS Update: cm3 Date: Tue, 23 Feb 2010 23:08:32 +0000 I'll have to show you where the values are coming from. I don't know offhand. Could be from m3back, or m3front, I don't know. This stuff largely is runnable/testable from arbitrary hosts. cd scripts/python ./do-cm3-std.py realclean NT386 ./do-cm3-std.py buildship NT386 to get the data we are interested in, would want to change this code e.g.: C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386): IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN Note that most of the uses of ToInt in m3back don't do that, e.g.: IF shiftCount.loc = OLoc.imm THEN IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm)); END; ins.imsize := 1; And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday. But some are not, I didn't go here randomly. bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value. - Jay From: hosking at cs.purdue.edu Date: Tue, 23 Feb 2010 14:00:07 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 I guess I am uncertain what it is you are trying to achieve. The Modula-3 frontend never generates unsigned integers. Everything is signed. If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes. On 23 Feb 2010, at 13:15, Jay K wrote: So we need TWord.ToBytes? - Jay From: hosking at cs.purdue.edu Date: Tue, 23 Feb 2010 12:39:49 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3commit] CVS Update: cm3 Actually, on second thought, of course it cannot be fixed. The signed value 128 *does* require 2 bytes to represent. (char)128 == -128. (short)128 == 128. These TInt functions should be interpreted as having C arithmetic semantics. On 23 Feb 2010, at 08:35, Tony Hosking wrote: That can be fixed... On 22 Feb 2010, at 21:30, Jay K wrote: ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte? I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad. - Jay ---------------------------------------- From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 21:10:10 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 On 22 Feb 2010, at 20:30, Jay K wrote: I'm still a bit leary of Chop and ToBytes. Chop is just the same as a C cast. i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1. ToBytes simply returns the significant bytes. I *suspect* we need a bit more in TWord to make this all hold together. I don't see the need. I think this speaks to confusion on your part... Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.) I don't entirely ignore ToInt's boolean. I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error. I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise. Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such. (I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.) What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it. And then rewriting hand.c in Modula-3. And then other stuff. ..Jay ________________________________ From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 20:03:03 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 P.S. The assumption is that results from operations that overflow should be discarded. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 20:01, Tony Hosking wrote: Jay, If you want that behavior, just do: TInt.Chop(x, BYTESIZE(INTEGER), x); TInt.ToInt(x, i) On 22 Feb 2010, at 23:57, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/02/22 23:57:21 Modified files: cm3/m3-sys/m3back/src/: M3BackInt.m3 Log message: remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 24 15:43:18 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 24 Feb 2010 09:43:18 -0500 Subject: [M3devel] TInt.ToInt overflow In-Reply-To: References: <20100222225722.056AE2474001@birch.elegosoft.com>, , , , , <48085E62-6C4C-4ECD-B1CB-F94CE7C5B10E@cs.purdue.edu>, , , , , , , , , , , , , <6A1F915C-A970-4485-8293-9E523DB278BA@cs.purdue.edu>, , , , <72B5DA75-B33A-4414-9E14-6625FA5816FB@cs.purdue.edu>, , <09B1E13B-15E0-452B-83E7-1F976049793C@cs.purdue.edu>, , Message-ID: <9635E921-3B9F-4A95-B4BC-0ACBCCE36D3A@cs.purdue.edu> I suspect that your backend code is not obeying the type conversions in the CG code. Here is line 202 from RTAllocator -- it has a lot of conversions (with implied sign extension). Does this give any clues? -----LINE 202 ----- declare_temp 4 4 Struct T v.159 load_integer Int.32 0 load v.159 0 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 0 1 store v.159 0 Int.32 Word.8 load v.67 0 Addr Addr load_indirect 0 Int.32 Int.32 check_range Int.32 0 1048575 1 load v.159 0 Word.32 Int.32 swap Int.32 Int.32 insert_mn Int.32 1 20 store v.159 0 Int.32 Word.32 load_integer Int.32 1 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 5 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 6 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 7 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 0 1 store v.159 3 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 1 1 store v.159 3 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 2 6 store v.159 3 Int.32 Word.8 load v.65 0 Addr Addr load_integer Int.32 4 index_address Int.32 -1 load_address v.159 0 copy 1 Int.32 F On 24 Feb 2010, at 08:41, Jay K wrote: > Tony, it looks like basically all/many negative values are representeded as large positive values. > Something is chopping the sign maybe? > Here are the errors I get compiling m3core if I don't "ignore" overflow from TInt.ToInt. > (for values that are under Integer.Word32.max). > It isn't always clear how the source traffics in these numbers. I could get callstacks if it really helps. > > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocStats.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 452: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 463: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 464: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 471: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 549: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 550: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 555: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 558: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 561: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 566: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 569: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 574: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 577: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 592: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 593: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 801: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 952: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 964: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 970: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1016: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1071: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1077: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1089: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1090: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1092: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1094: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1186: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1208: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1209: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1242: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immdiate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1702: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1724: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2056: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2257: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2259: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2365: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2386: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2398: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2418: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2420: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2425: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2442: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2482: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2498: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2520: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2525: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2541: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2543: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2697: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 78: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 79: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 86: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 87: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 99: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 81: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 82: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 89: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 96: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 101: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 103: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 108: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 119: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 > "..\src\convert\Convert.m3", line 496: pushOp: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 > "..\src\convert\Convert.m3", line 503: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Tue, 23 Feb 2010 23:08:32 +0000 > > I'll have to show you where the values are coming from. I don't know offhand. > Could be from m3back, or m3front, I don't know. > > This stuff largely is runnable/testable from arbitrary hosts. > cd scripts/python > ./do-cm3-std.py realclean NT386 > ./do-cm3-std.py buildship NT386 > > > to get the data we are interested in, would want to change this code e.g.: > > > C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386): IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN > > > Note that most of the uses of ToInt in m3back don't do that, e.g.: > > > IF shiftCount.loc = OLoc.imm THEN > IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN > t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm)); > END; > ins.imsize := 1; > > > And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday. > But some are not, I didn't go here randomly. > bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Tue, 23 Feb 2010 14:00:07 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I guess I am uncertain what it is you are trying to achieve. The Modula-3 frontend never generates unsigned integers. Everything is signed. If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes. > > > On 23 Feb 2010, at 13:15, Jay K wrote: > > So we need TWord.ToBytes? > > - Jay > > From: hosking at cs.purdue.edu > Date: Tue, 23 Feb 2010 12:39:49 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3commit] CVS Update: cm3 > > Actually, on second thought, of course it cannot be fixed. The signed value 128 *does* require 2 bytes to represent. (char)128 == -128. (short)128 == 128. > These TInt functions should be interpreted as having C arithmetic semantics. > > On 23 Feb 2010, at 08:35, Tony Hosking wrote: > > That can be fixed... > > On 22 Feb 2010, at 21:30, Jay K wrote: > > > ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte? > I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad. > > > - Jay > > > ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 21:10:10 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On 22 Feb 2010, at 20:30, Jay K wrote: > > I'm still a bit leary of Chop and ToBytes. > > Chop is just the same as a C cast. > i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1. > > ToBytes simply returns the significant bytes. > > I *suspect* we need a bit more in TWord to make this all hold together. > > I don't see the need. I think this speaks to confusion on your part... > > Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.) > > > I don't entirely ignore ToInt's boolean. > I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error. > > > I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise. > > > Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such. > (I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.) > > > What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it. > > > And then rewriting hand.c in Modula-3. > > > And then other stuff. > > > ..Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:03:03 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > P.S. The assumption is that results from operations that overflow should be discarded. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 20:01, Tony Hosking wrote: > > Jay, If you want that behavior, just do: > > TInt.Chop(x, BYTESIZE(INTEGER), x); > TInt.ToInt(x, i) > > On 22 Feb 2010, at 23:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/02/22 23:57:21 > > Modified files: > cm3/m3-sys/m3back/src/: M3BackInt.m3 > > Log message: > remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord) > > > > > > > > From jay.krell at cornell.edu Thu Feb 25 14:24:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Feb 2010 13:24:14 +0000 Subject: [M3devel] TInt/TWord/m3back Message-ID: Tony, it should now be much closer to your intent. I grant maybe the constants are misplaced, and I should try again to use ToBytes. I'm worried though. It used to be I could do: TInt.Add(Int{4,FF,FF,FF,7}, One) and be told it overflowed, in 4 bytes of precision. Now it'll just do it in 8 and no overflow. And chop always succeeds. Maybe: PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = BEGIN IF And (r [n-1], SignMask) = 0 THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; END; RETURN TRUE; END CheckChop; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 25 18:20:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 12:20:49 -0500 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: References: Message-ID: <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. On 25 Feb 2010, at 08:24, Jay K wrote: > Tony, it should now be much closer to your intent. > I grant maybe the constants are misplaced, and I should try again to use ToBytes. > > > I'm worried though. > It used to be I could do: > > > TInt.Add(Int{4,FF,FF,FF,7}, One) > and be told it overflowed, in 4 bytes of precision. You must check explicitly that there is no overflow. This is easy enough. TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) > Now it'll just do it in 8 and no overflow. > > > And chop always succeeds. > > Maybe: > > > PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = > BEGIN > IF And (r [n-1], SignMask) = 0 > THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; > ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; > END; > RETURN TRUE; > END CheckChop; > > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 00:18:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Feb 2010 23:18:38 +0000 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> References: , <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> Message-ID: Ok, I think maybe I should go back to the version where the type carries precision and each function is a small wrapper over TInt where I extend, call TInt, and then checked truncate. Or at least call TInt and checked truncate, maybe no need for extend. Something like that. That will still leave the hard work in TInt. I had hoped TInt could do "everything" for me. It is a little disappointing -- it was for doing "target math", which is what I want, but now it is just for doing 64bit math on any host. Probably should be called Int64.. On the other hand, m3back historically just did host INTEGER math, no overflow checks. So maybe ok asis. Adding the overflow checks found overflow in user source though, so I think a good thing. I'll probably just go back a day or so, as described, where each function in M3BackInt/M3BackWord is about one line. No need for th TInt/TWord changes then, even though they were acceptable. - Jay From: hosking at cs.purdue.edu Date: Thu, 25 Feb 2010 12:20:49 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] TInt/TWord/m3back This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. On 25 Feb 2010, at 08:24, Jay K wrote: Tony, it should now be much closer to your intent. I grant maybe the constants are misplaced, and I should try again to use ToBytes. I'm worried though. It used to be I could do: TInt.Add(Int{4,FF,FF,FF,7}, One) and be told it overflowed, in 4 bytes of precision. You must check explicitly that there is no overflow. This is easy enough. TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) Now it'll just do it in 8 and no overflow. And chop always succeeds. Maybe: PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = BEGIN IF And (r [n-1], SignMask) = 0 THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; END; RETURN TRUE; END CheckChop; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 01:06:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 00:06:28 +0000 Subject: [M3devel] TInt/TWord/specified precision Message-ID: Tony, the TInt/TWord cleanup cost me a lot of time, and still more to do. They used to provide target math to a specified precision. Now always to a fixed large precision. Historically M3back did host math, no overflow checking. It "had" to change, at least to split Target.Int into two host integers, in order to accomodate 64bit integers, but preferably to sometimes keep them together to do constant folding. (Arguably 64bit integer support initially only from 64bit host, then have working LONGINT, then use LONGINT, but no.) Adding overflow checking at the same time caught actual borderline bugs in user code -- code that depended on silent overflow. m3front won't catch those I guess because it never? folds constants? Maybe it should be willing to do so as long as there is no overflow, and then if it is hits overflow, back off and generate code to do the work? But also warn? I'm left very much desiring the functionaly that TInt did have. I have a few options. M3BackInt as it recently was, a thin layer over TInt. The constants could remain in TInt. Introducing TIntN, which is TInt but with n=specified precision, at runtime (Not TInt8, TInt32, just one TIntN that adapts at runtime, just like TInt used to do). The only difference between TIntN and M3BackInt is the name and location. It would be in m3middle. Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, and SignExtend and ZeroExtend that give a source precision. These functions would exist either way, just in TIntN, TWordN, or TInt. But I think still useful to wrap the type in a type that carries the precision. Now, also, I wonder if TInt, with its lost functionality, should be renamed, say to TInt64 or Int64? TInt used to do more and it was a little more complicated but useful. Are you sure it shouldn't go back to how it was? If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, if it keeps the individual layers thinner, simpler, easier to get correct. Doesn't analogy to TFloat suggest it was better before? TFloat doesn't support just one large precision type, it supports parameterizing itself in order to simulate various floating types. Granted, I haven't looked at what all it provides and I don't believe m3back folds constant float math at compile time, but it could. At least stuff not dependent on various "modes". 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. I'd have to think a bit, but it's probably something like floating constants with the same exponent and a mantissa that holds the full value can be folded. Bunch of examples is that if I convert a bunch of 32bit integers to double and do only add and subtract, it can all be folded at compile time. Multiplication and division cannot in general be done, though sometimes. Comparison to the same set can be done. Anyway, my current best idea is to introduce TIntN, TWordN, but I have a while to think about it before I do anything. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 26 03:44:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 21:44:40 -0500 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: References: , <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> Message-ID: <8CAB3AD8-444C-4BB0-956A-73D24C6C237C@cs.purdue.edu> But TInt will do what you want. You just need to check bounds. TInt does mean "target INTEGER": is the way one does arithmetic on a host that doesn't support the range of the target. You cannot do constant folding safely without checking for overflow otherwise you violate the intent of the language (i.e., that some targets might check for overflow...) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 25 Feb 2010, at 18:18, Jay K wrote: > Ok, I think maybe I should go back to the version where the type carries precision and each function is a small wrapper over TInt where I extend, call TInt, and then checked truncate. > Or at least call TInt and checked truncate, maybe no need for extend. > Something like that. > > > That will still leave the hard work in TInt. > > > I had hoped TInt could do "everything" for me. > It is a little disappointing -- it was for doing "target math", which is what I want, but now it is just for doing 64bit math on any host. Probably should be called Int64.. > > > On the other hand, m3back historically just did host INTEGER math, no overflow checks. So maybe ok asis. > Adding the overflow checks found overflow in user source though, so I think a good thing. > I'll probably just go back a day or so, as described, where each function in M3BackInt/M3BackWord is about one line. No need for th TInt/TWord changes then, even though they were acceptable. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 25 Feb 2010 12:20:49 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/m3back > > This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. > > On 25 Feb 2010, at 08:24, Jay K wrote: > > Tony, it should now be much closer to your intent. > I grant maybe the constants are misplaced, and I should try again to use ToBytes. > > > I'm worried though. > It used to be I could do: > > > TInt.Add(Int{4,FF,FF,FF,7}, One) > and be told it overflowed, in 4 bytes of precision. > > You must check explicitly that there is no overflow. This is easy enough. > > TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) > > Now it'll just do it in 8 and no overflow. > > > And chop always succeeds. > > Maybe: > > > PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = > BEGIN > IF And (r [n-1], SignMask) = 0 > THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; > ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; > END; > RETURN TRUE; > END CheckChop; > > ? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 26 03:48:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 21:48:11 -0500 Subject: [M3devel] TInt/TWord/specified precision In-Reply-To: References: Message-ID: The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed, m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold. I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard. I do not want to complicate TInt any more than it is now. On 25 Feb 2010, at 19:06, Jay K wrote: > Tony, the TInt/TWord cleanup cost me a lot of time, and > still more to do. > > > They used to provide target math to a specified precision. > > > Now always to a fixed large precision. > > > Historically M3back did host math, no overflow checking. > It "had" to change, at least to split Target.Int into > two host integers, in order to accomodate 64bit integers, > but preferably to sometimes keep them together to do constant folding. > (Arguably 64bit integer support initially only from 64bit host, > then have working LONGINT, then use LONGINT, but no.) > > > Adding overflow checking at the same time caught actual > borderline bugs in user code -- code that depended on silent overflow. > > > m3front won't catch those I guess because it never? folds constants? > Maybe it should be willing to do so as long as there is no overflow, > and then if it is hits overflow, back off and generate code to do the work? > But also warn? > > > I'm left very much desiring the functionaly that TInt did have. > > > I have a few options. > M3BackInt as it recently was, a thin layer over TInt. > The constants could remain in TInt. > > > Introducing TIntN, which is TInt but with n=specified precision, > at runtime (Not TInt8, TInt32, just one TIntN that adapts > at runtime, just like TInt used to do). > > > The only difference between TIntN and M3BackInt is the name and location. > It would be in m3middle. > > > Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, > and SignExtend and ZeroExtend that give a source precision. > These functions would exist either way, just in TIntN, TWordN, or TInt. > > > But I think still useful to wrap the type in a type that carries the precision. > > > Now, also, I wonder if TInt, with its lost functionality, should > be renamed, say to TInt64 or Int64? > > > TInt used to do more and it was a little more complicated but useful. > Are you sure it shouldn't go back to how it was? > If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, > if it keeps the individual layers thinner, simpler, easier to get correct. > > > Doesn't analogy to TFloat suggest it was better before? > > TFloat doesn't support just one large precision type, it supports > parameterizing itself in order to simulate various floating types. > Granted, I haven't looked at what all it provides and I don't believe > m3back folds constant float math at compile time, but it could. > At least stuff not dependent on various "modes". > 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. > I'd have to think a bit, but it's probably something like floating > constants with the same exponent and a mantissa that holds > the full value can be folded. Bunch of examples is that if I > convert a bunch of 32bit integers to double and do only > add and subtract, it can all be folded at compile time. > Multiplication and division cannot in general be done, though sometimes. > Comparison to the same set can be done. > > > Anyway, my current best idea is to introduce TIntN, TWordN, but I have > a while to think about it before I do anything. > > - Jay > From jay.krell at cornell.edu Fri Feb 26 11:41:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 10:41:05 +0000 Subject: [M3devel] TInt/TWord/specified precision In-Reply-To: References: , Message-ID: If I have to a range check after basically every single operation, if I can never just call Add, but always Add and then Something, that merits a better type/interface/implementation that does that for me. I was thinking maybe the check is at "chop time", but that would allow things like LAST(INTEGER) + 1 - 1 to work, and they probably should not, even if arguably they should. I think currently I let this through. I think the previous M3BackInt.m3 shall be TIntN.m3. I'll proceed that way. - Jay > From: hosking at cs.purdue.edu > Date: Thu, 25 Feb 2010 21:48:11 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/specified precision > > The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed, > > m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold. > > I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard. > > I do not want to complicate TInt any more than it is now. > > On 25 Feb 2010, at 19:06, Jay K wrote: > > > Tony, the TInt/TWord cleanup cost me a lot of time, and > > still more to do. > > > > > > They used to provide target math to a specified precision. > > > > > > Now always to a fixed large precision. > > > > > > Historically M3back did host math, no overflow checking. > > It "had" to change, at least to split Target.Int into > > two host integers, in order to accomodate 64bit integers, > > but preferably to sometimes keep them together to do constant folding. > > (Arguably 64bit integer support initially only from 64bit host, > > then have working LONGINT, then use LONGINT, but no.) > > > > > > Adding overflow checking at the same time caught actual > > borderline bugs in user code -- code that depended on silent overflow. > > > > > > m3front won't catch those I guess because it never? folds constants? > > Maybe it should be willing to do so as long as there is no overflow, > > and then if it is hits overflow, back off and generate code to do the work? > > But also warn? > > > > > > I'm left very much desiring the functionaly that TInt did have. > > > > > > I have a few options. > > M3BackInt as it recently was, a thin layer over TInt. > > The constants could remain in TInt. > > > > > > Introducing TIntN, which is TInt but with n=specified precision, > > at runtime (Not TInt8, TInt32, just one TIntN that adapts > > at runtime, just like TInt used to do). > > > > > > The only difference between TIntN and M3BackInt is the name and location. > > It would be in m3middle. > > > > > > Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, > > and SignExtend and ZeroExtend that give a source precision. > > These functions would exist either way, just in TIntN, TWordN, or TInt. > > > > > > But I think still useful to wrap the type in a type that carries the precision. > > > > > > Now, also, I wonder if TInt, with its lost functionality, should > > be renamed, say to TInt64 or Int64? > > > > > > TInt used to do more and it was a little more complicated but useful. > > Are you sure it shouldn't go back to how it was? > > If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, > > if it keeps the individual layers thinner, simpler, easier to get correct. > > > > > > Doesn't analogy to TFloat suggest it was better before? > > > > TFloat doesn't support just one large precision type, it supports > > parameterizing itself in order to simulate various floating types. > > Granted, I haven't looked at what all it provides and I don't believe > > m3back folds constant float math at compile time, but it could. > > At least stuff not dependent on various "modes". > > 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. > > I'd have to think a bit, but it's probably something like floating > > constants with the same exponent and a mantissa that holds > > the full value can be folded. Bunch of examples is that if I > > convert a bunch of 32bit integers to double and do only > > add and subtract, it can all be folded at compile time. > > Multiplication and division cannot in general be done, though sometimes. > > Comparison to the same set can be done. > > > > > > Anyway, my current best idea is to introduce TIntN, TWordN, but I have > > a while to think about it before I do anything. > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 13:59:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 12:59:54 +0000 Subject: [M3devel] examples Message-ID: I think the release branch is missing the change to move examples. Update it? (I say this based on differences in the scripts.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 05:48:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 04:48:36 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> Message-ID: Tony, I just don't understand what is wrong with TIntN, TWordN. They are what TInt/TWord did for a long time after all. ? Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Fri, 26 Feb 2010 19:51:15 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > On 26 Feb 2010, at 13:48, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/02/26 13:48:34 >> >> Modified files: >> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >> Wrx86.i3 Wrx86.m3 m3makefile >> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >> TWordN.i3 TWordN.m3 Target.i3 >> Target.m3 m3makefile >> Removed files: >> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >> M3BackWord.m3 >> >> Log message: >> introduce type Target.IntN which is Int plus a precision >> just like the old Target.Int >> (previously M3BackInt.Int) >> >> make TIntN and TWordN support it >> they are just thin wrappers over TInt, TWord >> previously named M3BackInt, M3BackWord >> >> add small amount of support to TInt: >> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >> These could, if desired, go into their only users: TIntN, TWordN. >> (with the understanding that that Target.Int is "revealed" to them.) >> >> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >> >> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >> This is "just" additions. >> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >> (A little unsatisfactory that N is bytes instead of bits.) >> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >> >> While at it, in TIntN, rename things slightly: >> FromInt => FromHostInteger >> ToInt => ToHostInteger >> >> "Int" is "Target.Int" >> "HostInteger" is "INTEGER" >> >> again, TInt/TWord/m3front/m3middle not much affected. >> >> One fishy/uncertain thing in all of this, something to test out, is cross builds >> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >> really need INTEGER to be 4 bytes throughout m3back? >> (I know that mklib has little endian dependency.) > From hosking at cs.purdue.edu Sat Feb 27 07:16:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 01:16:32 -0500 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> Message-ID: <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> The solution is not to push upstream into m3middle. I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. -- T On 26 Feb 2010, at 23:48, Jay K wrote: > > Tony, I just don't understand what is wrong with TIntN, TWordN. > They are what TInt/TWord did for a long time after all. ? > Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Fri, 26 Feb 2010 19:51:15 -0500 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >> >> On 26 Feb 2010, at 13:48, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>> Wrx86.i3 Wrx86.m3 m3makefile >>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>> TWordN.i3 TWordN.m3 Target.i3 >>> Target.m3 m3makefile >>> Removed files: >>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>> M3BackWord.m3 >>> >>> Log message: >>> introduce type Target.IntN which is Int plus a precision >>> just like the old Target.Int >>> (previously M3BackInt.Int) >>> >>> make TIntN and TWordN support it >>> they are just thin wrappers over TInt, TWord >>> previously named M3BackInt, M3BackWord >>> >>> add small amount of support to TInt: >>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>> These could, if desired, go into their only users: TIntN, TWordN. >>> (with the understanding that that Target.Int is "revealed" to them.) >>> >>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>> >>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>> This is "just" additions. >>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>> (A little unsatisfactory that N is bytes instead of bits.) >>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>> >>> While at it, in TIntN, rename things slightly: >>> FromInt => FromHostInteger >>> ToInt => ToHostInteger >>> >>> "Int" is "Target.Int" >>> "HostInteger" is "INTEGER" >>> >>> again, TInt/TWord/m3front/m3middle not much affected. >>> >>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>> really need INTEGER to be 4 bytes throughout m3back? >>> (I know that mklib has little endian dependency.) >> From jay.krell at cornell.edu Sat Feb 27 08:34:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 07:34:52 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> Message-ID: > As I understand it your stuff in m3back is mostly working. > I took a look at the code there and I see a number of issues Tony, I don't know of anything that isn't working. Please let me know. All 64bit operations should work. atomic32 should work. Not yet atomic8/16/64, soon. Oh there is an alignment issue once atomic64 is there. It's present on other platforms too, for different reasons (incorrect max_align). Thanks, - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 01:16:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > The solution is not to push upstream into m3middle. > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > -- T > > On 26 Feb 2010, at 23:48, Jay K wrote: > >> >> Tony, I just don't understand what is wrong with TIntN, TWordN. >> They are what TInt/TWord did for a long time after all. ? >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Fri, 26 Feb 2010 19:51:15 -0500 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >>> >>> On 26 Feb 2010, at 13:48, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>>> Wrx86.i3 Wrx86.m3 m3makefile >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>>> TWordN.i3 TWordN.m3 Target.i3 >>>> Target.m3 m3makefile >>>> Removed files: >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>>> M3BackWord.m3 >>>> >>>> Log message: >>>> introduce type Target.IntN which is Int plus a precision >>>> just like the old Target.Int >>>> (previously M3BackInt.Int) >>>> >>>> make TIntN and TWordN support it >>>> they are just thin wrappers over TInt, TWord >>>> previously named M3BackInt, M3BackWord >>>> >>>> add small amount of support to TInt: >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>>> These could, if desired, go into their only users: TIntN, TWordN. >>>> (with the understanding that that Target.Int is "revealed" to them.) >>>> >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>>> >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>>> This is "just" additions. >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>>> (A little unsatisfactory that N is bytes instead of bits.) >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>>> >>>> While at it, in TIntN, rename things slightly: >>>> FromInt => FromHostInteger >>>> ToInt => ToHostInteger >>>> >>>> "Int" is "Target.Int" >>>> "HostInteger" is "INTEGER" >>>> >>>> again, TInt/TWord/m3front/m3middle not much affected. >>>> >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>>> really need INTEGER to be 4 bytes throughout m3back? >>>> (I know that mklib has little endian dependency.) >>> > From jay.krell at cornell.edu Sat Feb 27 13:24:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 12:24:30 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, Message-ID: And now again it doesn't work. new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\Codex86.m3", line 430 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f310 0x466a46 immOp1 + 0x475 in ..\src\Codex86.m3 0x12f400 0x467108 immOp + 0x662 in ..\src\Codex86.m3 0x12f444 0x47d5c7 doimm + 0x255 in ..\src\Stackx86.m3 0x12f470 0x43ff5e if_false + 0x222 in ..\src\M3x86.m3 0x12f49c 0x64138b if_false + 0x101 in ..\src\M3CG_Check.m3 0x12f4c8 0x501a8f If_false + 0xa8 in ..\src\misc\CG.m3 0x12f4e8 0x5c2466 PrepNoBranch + 0x66 in ..\src\exprs\Expr.m3 0x12f510 0x5c1e3e PrepBranch + 0xcc in ..\src\exprs\Expr.m3 0x12f564 0x5e4392 Compile + 0x104 in ..\src\stmts\IfStmt.m3 0x12f594 0x536610 Compile + 0x63 in ..\src\stmts\Stmt.m3 ......... ......... ... more frames ... *** execution of [, ] failed *** I'm going to move m3back to how it was, but leave m3middle alone. With TIntN still in m3back. I skimmed through most of your changes and they seemed ok, but I'll have to apply them slowly/piecemeal and see which work. - Jay > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 07:34:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > > > As I understand it your stuff in m3back is mostly working. > > I took a look at the code there and I see a number of issues > > > Tony, I don't know of anything that isn't working. > Please let me know. > All 64bit operations should work. atomic32 should work. > Not yet atomic8/16/64, soon. > Oh there is an alignment issue once atomic64 is there. > It's present on other platforms too, for different reasons (incorrect max_align). > > > Thanks, > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 01:16:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > The solution is not to push upstream into m3middle. > > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > > > -- T > > > > On 26 Feb 2010, at 23:48, Jay K wrote: > > > >> > >> Tony, I just don't understand what is wrong with TIntN, TWordN. > >> They are what TInt/TWord did for a long time after all. ? > >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>> > >>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>> TWordN.i3 TWordN.m3 Target.i3 > >>>> Target.m3 m3makefile > >>>> Removed files: > >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>> M3BackWord.m3 > >>>> > >>>> Log message: > >>>> introduce type Target.IntN which is Int plus a precision > >>>> just like the old Target.Int > >>>> (previously M3BackInt.Int) > >>>> > >>>> make TIntN and TWordN support it > >>>> they are just thin wrappers over TInt, TWord > >>>> previously named M3BackInt, M3BackWord > >>>> > >>>> add small amount of support to TInt: > >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>> > >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>> > >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>> This is "just" additions. > >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>> > >>>> While at it, in TIntN, rename things slightly: > >>>> FromInt => FromHostInteger > >>>> ToInt => ToHostInteger > >>>> > >>>> "Int" is "Target.Int" > >>>> "HostInteger" is "INTEGER" > >>>> > >>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>> > >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>> really need INTEGER to be 4 bytes throughout m3back? > >>>> (I know that mklib has little endian dependency.) > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 17:10:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 11:10:32 -0500 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> Message-ID: Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. On 27 Feb 2010, at 02:34, Jay K wrote: > >> As I understand it your stuff in m3back is mostly working. >> I took a look at the code there and I see a number of issues > > > Tony, I don't know of anything that isn't working. > Please let me know. > All 64bit operations should work. atomic32 should work. > Not yet atomic8/16/64, soon. > Oh there is an alignment issue once atomic64 is there. > It's present on other platforms too, for different reasons (incorrect max_align). > > > Thanks, > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 27 Feb 2010 01:16:32 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] TInt/TWord/N >> >> The solution is not to push upstream into m3middle. >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. >> >> -- T >> >> On 26 Feb 2010, at 23:48, Jay K wrote: >> >>> >>> Tony, I just don't understand what is wrong with TIntN, TWordN. >>> They are what TInt/TWord did for a long time after all. ? >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 >>>> To: jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >>>> >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>>>> >>>>> Modified files: >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>>>> Wrx86.i3 Wrx86.m3 m3makefile >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>>>> TWordN.i3 TWordN.m3 Target.i3 >>>>> Target.m3 m3makefile >>>>> Removed files: >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>>>> M3BackWord.m3 >>>>> >>>>> Log message: >>>>> introduce type Target.IntN which is Int plus a precision >>>>> just like the old Target.Int >>>>> (previously M3BackInt.Int) >>>>> >>>>> make TIntN and TWordN support it >>>>> they are just thin wrappers over TInt, TWord >>>>> previously named M3BackInt, M3BackWord >>>>> >>>>> add small amount of support to TInt: >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>>>> These could, if desired, go into their only users: TIntN, TWordN. >>>>> (with the understanding that that Target.Int is "revealed" to them.) >>>>> >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>>>> >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>>>> This is "just" additions. >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>>>> (A little unsatisfactory that N is bytes instead of bits.) >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>>>> >>>>> While at it, in TIntN, rename things slightly: >>>>> FromInt => FromHostInteger >>>>> ToInt => ToHostInteger >>>>> >>>>> "Int" is "Target.Int" >>>>> "HostInteger" is "INTEGER" >>>>> >>>>> again, TInt/TWord/m3front/m3middle not much affected. >>>>> >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>>>> really need INTEGER to be 4 bytes throughout m3back? >>>>> (I know that mklib has little endian dependency.) >>>> >> From jay.krell at cornell.edu Sat Feb 27 20:11:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 19:11:18 +0000 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , Message-ID: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 20:54:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 14:54:40 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , Message-ID: P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 21:50:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 20:50:40 +0000 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , ,,<7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, ,,, , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , Message-ID: > Target.Int values would always be interpreted based on their associated type They kind of mostly are? Except..I mean..you know..I bury a size in them, which is a step. But the signnedness is not buried in them and I might get that wrong sometimes. It is often, you know, the operation and not the type. "Shift is always unsigned." But Add isn't. But with "half range cardinals", I'm not sure it matters. 16_40000000 * 2 overflows the same for INTEGER and CARDINAL LAST(INTEGER) + 1 ditto. Some operations do vary and they are handled correctly I think: abs, mul, div. Actually this is somewhat wrong: signed and unsigned multiplication I don't think needs to vary the way it does. They are the same in the lower bits. The compiler doesn't need to be so picky I believe. In particular, in the following C: int F1(int a, int b) { return a * b; } unsigned F2(unsigned a, unsigned b) { return a * b; } __int64 F3(int a, int b) { return a * (__int64)b; } unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } only one of them does unsigned multiplication, the last. (and notice that it does it inline with one instruction; something our compiler will be harder pressed to do given the lack of mixed operations! but you could leave it to a smart optimizer) > Is64, IsWord, IsInt, Target.FloatType In familiar territory (C and C++), I like switches because they "evaluate simultaneously", at least however the compiler can figure it. That is: if foo == 1 else if foo == 2 else if foo == 3 else if foo == 4 else if foo == 5 unless the compiler is very smart is always go to penalize 5 comparisons for "5", plus the compiler might assume I'm meaning to optimize the earlier cases as being more common, but then I have to worry about the ordering to get the common cases earlier whereas if I write switch (foo) case 1: ... case 2: ... case 3: ... case 4: ... case 5: ... I'll let the compiler chose between table lookup, linear search, binary search. "table lookup" being "simultaneous evaluation", binary search being nice I also don't like "if ladders" because if I'm stepping through unoptimized code line by line, it is tedious. [mostly omitted aside: I go out of my way when writing command line parsers in C to have a switch statement instead of an if/elseif/elseif ladder] However In Modula-3, I've gotten warnings when I miss cases, so there is overhead of always writing "else". Partly this because I don't know Modula-3 well. The use of FloatType[type] was already there, and it is good to have equivalence classes to reduce the number of cases listed and allow for more to be added later, "silently". I also don't like "data based interfaces", I prefer function calls, that's why Is64 instead of is foo IN Types64. (but FloatType[type] was already there) Granted, I lament the lack of inlining in m3back. I'm worried about nomenclature if/when this is extended to 64bit architectures. I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. I think I just drifted away from using TInt.Min/Max{8,16,32,64}. I'll see if any uses remain. Eh maybe just: C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); Some places were in extract/insert, and looked wrong. Yes definitely more eyes on m3back appreciated. Heck more eyes on cm3 appreciated! We have way too few. :( There were many style changes along with making things not work. I didn't want to sift through it all so I put it all back. Now to ponder sifting through it more slowly from a working baseline. Also I often favor mvar.mvar_type over mvar.type, so I can plain text search for mvar_type, and not just "type". I realize that you can't throw out all contexta all the time, but, there is something to be said for flatter namespaces. Nothing scales like plain text search. No language aware search work adequately. Let alone the matter of existance of languages x tools. I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. I would certainly be ok with TypeIsFloat to make it more consistently function call based, thoug I know I put in some cases too -- for the "simultaneous evaluation" property. - Jay From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 14:54:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] max_align P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 22:24:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 16:24:41 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , Message-ID: <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> On 27 Feb 2010, at 15:50, Jay K wrote: > > Target.Int values would always be interpreted based on their associated type > > > They kind of mostly are? > Except..I mean..you know..I bury a size in them, which is a step. No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: add Int.32 the semantics are: take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. e.g., in C, (int)a + (int)b So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! > But the signnedness is not buried in them and I might get that wrong sometimes. > It is often, you know, the operation and not the type. > "Shift is always unsigned." > But Add isn't. > But with "half range cardinals", I'm not sure it matters. > 16_40000000 * 2 overflows the same for INTEGER and CARDINAL > LAST(INTEGER) + 1 ditto. > > > Some operations do vary and they are handled correctly I think: abs, mul, div. > Actually this is somewhat wrong: signed and unsigned multiplication I don't think > needs to vary the way it does. They are the same in the lower bits. > The compiler doesn't need to be so picky I believe. In particular, in the following C: > int F1(int a, int b) { return a * b; } > unsigned F2(unsigned a, unsigned b) { return a * b; } > __int64 F3(int a, int b) { return a * (__int64)b; } > unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } > > > only one of them does unsigned multiplication, the last. > (and notice that it does it inline with one instruction; something > our compiler will be harder pressed to do given the lack of mixed operations! > but you could leave it to a smart optimizer) > > > > Is64, IsWord, IsInt, Target.FloatType > > > In familiar territory (C and C++), > I like switches because they "evaluate simultaneously", at least however the compiler can figure it. > > > That is: > > > if foo == 1 > else if foo == 2 > else if foo == 3 > else if foo == 4 > else if foo == 5 > > unless the compiler is very smart is always go to penalize 5 comparisons for "5", > plus the compiler might assume I'm meaning to optimize the earlier cases > as being more common, but then I have to worry about the ordering > to get the common cases earlier whereas > if I write > switch (foo) > case 1: ... > case 2: ... > case 3: ... > case 4: ... > case 5: ... > > > I'll let the compiler chose between table lookup, linear search, binary search. > "table lookup" being "simultaneous evaluation", binary search being nice > > > I also don't like "if ladders" because if I'm stepping through unoptimized > code line by line, it is tedious. > [mostly omitted aside: I go out of my way when writing command line > parsers in C to have a switch statement instead of an if/elseif/elseif ladder] > > > However > In Modula-3, I've gotten warnings when I miss cases, so there is overhead > of always writing "else". > Partly this because I don't know Modula-3 well. You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. > The use of FloatType[type] was already there, and it is good > to have equivalence classes to reduce the number of cases listed > and allow for more to be added later, "silently". Again, with CASE you can still select for those, without having a cascade of IF. > > I also don't like "data based interfaces", I prefer function calls, > that's why Is64 instead of is foo IN Types64. > (but FloatType[type] was already there) > Granted, I lament the lack of inlining in m3back. Function call is overkill. Use the types! > I'm worried about nomenclature if/when this is extended to 64bit architectures. > I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. > I think I just drifted away from using TInt.Min/Max{8,16,32,64}. The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. > I'll see if any uses remain. > Eh maybe just: > C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); > > > Some places were in extract/insert, and looked wrong. > > > Yes definitely more eyes on m3back appreciated. > Heck more eyes on cm3 appreciated! We have way too few. :( > There were many style changes along with making things not work. > I didn't want to sift through it all so I put it all back. > Now to ponder sifting through it more slowly from a working baseline. > > > Also I often favor mvar.mvar_type over mvar.type, so I can plain text > search for mvar_type, and not just "type". I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). > I realize that you can't throw out all contexta all the time, but, > there is something to be said for flatter namespaces. > Nothing scales like plain text search. > No language aware search work adequately. > Let alone the matter of existance of languages x tools. > > > I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. > I would certainly be ok with TypeIsFloat to make it more consistently function call based, > thoug I know I put in some cases too -- for the "simultaneous evaluation" property. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 14:54:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] max_align > > P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 27 Feb 2010, at 14:11, Jay K wrote: > > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 23:12:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 22:12:21 +0000 Subject: [M3devel] max_align In-Reply-To: <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , ,,<7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, ,,, , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , , <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> Message-ID: ok..I'll maybe reply more later. But what does it mean to load_int(type1, value1) load_int(type2, value2) add(type3) It seems like both the values and the operations have types. I do try to consider all types, with "ELSE <* ASSERT FALSE *>", be it an if ladder or a switch. Perhaps that is too little thought? I admit, ZType, IType, AType, etc., I can't keep them straight. I "know" that floats are handled specially by m3back and so I can ignore them in most code and that the backend traffics only rarely in 8 or 16 bit types, so the four most interesting types are Int32, Int64, Word32, Word64. As well, since my agenda is currently 64bit longint, I just need to add word64/int64 to the existing paths. (m3back is so geared against int8/word8/int16/word16 that it takes special pain to widen all function results, lest they be generated by a C compiler, and the historical command indict the C compiler's behavior, I edited out the subjectivity; and the 8 bits produced by setccop are always immediately widened; I have to revisit that soon, I think the code can be much better. That is part of the evidence to what it traffics in.) - Jay Subject: Re: [M3devel] max_align From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 16:24:41 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 27 Feb 2010, at 15:50, Jay K wrote: > Target.Int values would always be interpreted based on their associated type They kind of mostly are? Except..I mean..you know..I bury a size in them, which is a step. No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: add Int.32 the semantics are: take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. e.g., in C, (int)a + (int)b So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! But the signnedness is not buried in them and I might get that wrong sometimes. It is often, you know, the operation and not the type. "Shift is always unsigned." But Add isn't. But with "half range cardinals", I'm not sure it matters. 16_40000000 * 2 overflows the same for INTEGER and CARDINAL LAST(INTEGER) + 1 ditto. Some operations do vary and they are handled correctly I think: abs, mul, div. Actually this is somewhat wrong: signed and unsigned multiplication I don't think needs to vary the way it does. They are the same in the lower bits. The compiler doesn't need to be so picky I believe. In particular, in the following C: int F1(int a, int b) { return a * b; } unsigned F2(unsigned a, unsigned b) { return a * b; } __int64 F3(int a, int b) { return a * (__int64)b; } unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } only one of them does unsigned multiplication, the last. (and notice that it does it inline with one instruction; something our compiler will be harder pressed to do given the lack of mixed operations! but you could leave it to a smart optimizer) > Is64, IsWord, IsInt, Target.FloatType In familiar territory (C and C++), I like switches because they "evaluate simultaneously", at least however the compiler can figure it. That is: if foo == 1 else if foo == 2 else if foo == 3 else if foo == 4 else if foo == 5 unless the compiler is very smart is always go to penalize 5 comparisons for "5", plus the compiler might assume I'm meaning to optimize the earlier cases as being more common, but then I have to worry about the ordering to get the common cases earlier whereas if I write switch (foo) case 1: ... case 2: ... case 3: ... case 4: ... case 5: ... I'll let the compiler chose between table lookup, linear search, binary search. "table lookup" being "simultaneous evaluation", binary search being nice I also don't like "if ladders" because if I'm stepping through unoptimized code line by line, it is tedious. [mostly omitted aside: I go out of my way when writing command line parsers in C to have a switch statement instead of an if/elseif/elseif ladder] However In Modula-3, I've gotten warnings when I miss cases, so there is overhead of always writing "else". Partly this because I don't know Modula-3 well. You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. The use of FloatType[type] was already there, and it is good to have equivalence classes to reduce the number of cases listed and allow for more to be added later, "silently". Again, with CASE you can still select for those, without having a cascade of IF. I also don't like "data based interfaces", I prefer function calls, that's why Is64 instead of is foo IN Types64. (but FloatType[type] was already there) Granted, I lament the lack of inlining in m3back. Function call is overkill. Use the types! I'm worried about nomenclature if/when this is extended to 64bit architectures. I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. I think I just drifted away from using TInt.Min/Max{8,16,32,64}. The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. I'll see if any uses remain. Eh maybe just: C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); Some places were in extract/insert, and looked wrong. Yes definitely more eyes on m3back appreciated. Heck more eyes on cm3 appreciated! We have way too few. :( There were many style changes along with making things not work. I didn't want to sift through it all so I put it all back. Now to ponder sifting through it more slowly from a working baseline. Also I often favor mvar.mvar_type over mvar.type, so I can plain text search for mvar_type, and not just "type". I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). I realize that you can't throw out all contexta all the time, but, there is something to be said for flatter namespaces. Nothing scales like plain text search. No language aware search work adequately. Let alone the matter of existance of languages x tools. I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. I would certainly be ok with TypeIsFloat to make it more consistently function call based, thoug I know I put in some cases too -- for the "simultaneous evaluation" property. - Jay From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 14:54:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] max_align P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 27 23:52:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 27 Feb 2010 23:52:50 +0100 Subject: [M3devel] examples In-Reply-To: References: Message-ID: <20100227235250.mbm07ehhwsokskg4@mail.elegosoft.com> Quoting Jay K : > > I think the release branch is missing the change to move examples. > > Update it? Yes, please do. Olaf > (I say this based on differences in the scripts.) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 28 00:08:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 18:08:07 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , , <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> Message-ID: <21DE2D25-A591-4E8E-AF8C-0E050CE471D4@cs.purdue.edu> On 27 Feb 2010, at 17:12, Jay K wrote: > ok..I'll maybe reply more later. > > > But what does it mean to > > > load_int(type1, value1) Take value, cast to type1 (may involve sign extend from low bits/truncation of high bits), push on stack. > load_int(type2, value2) Take value, cast to type2 (may involve sign extend from low bits/truncation of high bits), push on stack. > add(type3) Add values on stack, interpreted as type3 (perhaps sign extended/truncated), with result of type3. > It seems like both the values and the operations have types. The types say how the bits of the operands are to be interpreted. > I do try to consider all types, with "ELSE <* ASSERT FALSE *>", be it an if ladder or a switch. > Perhaps that is too little thought? > I admit, ZType, IType, AType, etc., I can't keep them straight. > I "know" that floats are handled specially by m3back and so I can ignore them in most code > and that the backend traffics only rarely in 8 or 16 bit types, so the four most interesting > types are Int32, Int64, Word32, Word64. Correct. > As well, since my agenda is currently 64bit longint, I just need to add word64/int64 to > the existing paths. Right. > (m3back is so geared against int8/word8/int16/word16 that it takes special pain > to widen all function results, lest they be generated by a C compiler, and the > historical command indict the C compiler's behavior, I edited out the subjectivity; > and the 8 bits produced by setccop are always > immediately widened; I have to revisit that soon, I think the code can be much better. > That is part of the evidence to what it traffics in.) Yes, the front-end never usually generates stack values of 8/16 bits. All integer operations are in the 32/64-bit types. > > > - Jay > > > Subject: Re: [M3devel] max_align > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 16:24:41 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > On 27 Feb 2010, at 15:50, Jay K wrote: > > > Target.Int values would always be interpreted based on their associated type > > > They kind of mostly are? > Except..I mean..you know..I bury a size in them, which is a step. > > No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: > > add Int.32 > > the semantics are: > > take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. > > e.g., in C, (int)a + (int)b > > So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. > > I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! > > But the signnedness is not buried in them and I might get that wrong sometimes. > It is often, you know, the operation and not the type. > "Shift is always unsigned." > But Add isn't. > But with "half range cardinals", I'm not sure it matters. > 16_40000000 * 2 overflows the same for INTEGER and CARDINAL > LAST(INTEGER) + 1 ditto. > > > Some operations do vary and they are handled correctly I think: abs, mul, div. > Actually this is somewhat wrong: signed and unsigned multiplication I don't think > needs to vary the way it does. They are the same in the lower bits. > The compiler doesn't need to be so picky I believe. In particular, in the following C: > int F1(int a, int b) { return a * b; } > unsigned F2(unsigned a, unsigned b) { return a * b; } > __int64 F3(int a, int b) { return a * (__int64)b; } > unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } > > > only one of them does unsigned multiplication, the last. > (and notice that it does it inline with one instruction; something > our compiler will be harder pressed to do given the lack of mixed operations! > but you could leave it to a smart optimizer) > > > > Is64, IsWord, IsInt, Target.FloatType > > > In familiar territory (C and C++), > I like switches because they "evaluate simultaneously", at least however the compiler can figure it. > > > That is: > > > if foo == 1 > else if foo == 2 > else if foo == 3 > else if foo == 4 > else if foo == 5 > > unless the compiler is very smart is always go to penalize 5 comparisons for "5", > plus the compiler might assume I'm meaning to optimize the earlier cases > as being more common, but then I have to worry about the ordering > to get the common cases earlier whereas > if I write > switch (foo) > case 1: ... > case 2: ... > case 3: ... > case 4: ... > case 5: ... > > > I'll let the compiler chose between table lookup, linear search, binary search. > "table lookup" being "simultaneous evaluation", binary search being nice > > > I also don't like "if ladders" because if I'm stepping through unoptimized > code line by line, it is tedious. > [mostly omitted aside: I go out of my way when writing command line > parsers in C to have a switch statement instead of an if/elseif/elseif ladder] > > > However > In Modula-3, I've gotten warnings when I miss cases, so there is overhead > of always writing "else". > Partly this because I don't know Modula-3 well. > > You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. > > The use of FloatType[type] was already there, and it is good > to have equivalence classes to reduce the number of cases listed > and allow for more to be added later, "silently". > > Again, with CASE you can still select for those, without having a cascade of IF. > > > I also don't like "data based interfaces", I prefer function calls, > that's why Is64 instead of is foo IN Types64. > (but FloatType[type] was already there) > Granted, I lament the lack of inlining in m3back. > > Function call is overkill. Use the types! > > I'm worried about nomenclature if/when this is extended to 64bit architectures. > I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. > > No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. > > I think I just drifted away from using TInt.Min/Max{8,16,32,64}. > > The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. > > I'll see if any uses remain. > Eh maybe just: > C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); > > > Some places were in extract/insert, and looked wrong. > > > Yes definitely more eyes on m3back appreciated. > Heck more eyes on cm3 appreciated! We have way too few. :( > There were many style changes along with making things not work. > I didn't want to sift through it all so I put it all back. > Now to ponder sifting through it more slowly from a working baseline. > > > Also I often favor mvar.mvar_type over mvar.type, so I can plain text > search for mvar_type, and not just "type". > > I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). > > I realize that you can't throw out all contexta all the time, but, > there is something to be said for flatter namespaces. > Nothing scales like plain text search. > No language aware search work adequately. > Let alone the matter of existance of languages x tools. > > > I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. > I would certainly be ok with TypeIsFloat to make it more consistently function call based, > thoug I know I put in some cases too -- for the "simultaneous evaluation" property. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 14:54:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] max_align > > P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 27 Feb 2010, at 14:11, Jay K wrote: > > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 28 09:56:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 28 Feb 2010 08:56:08 +0000 Subject: [M3devel] r_test, pr_test, pb_test Message-ID: Olaf, I think pr_test and pb_test are cryptic, and there is no explanation what "pr" and "pb" stand for (as opposed to p_test, e_test, c_test, which have comment). I propose run_flags_test build_flags_test or program_with_run_flags program_with_build_flags program_with_compiler_flags or somesuch. I'm guessing "r" means "run flags", "b" means "build flags. I'll probably do something here very soon, since I'm adding another type of test. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 28 10:54:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 28 Feb 2010 09:54:44 +0000 Subject: [M3devel] portable/less portable test variations Message-ID: I commited something here. The function in m3tests/m3makefile is "mixed_portability_test". p227 uses it. The test can be run with no parameters, in which case the output is "fully portable" (the same on all targets) and the output is compared with the "unadorned" stdout.pgm, etc. And it can be run with the flag -include-less-portable-output, in which case we probe for, e.g.: stdout.pgm32 stdout.pgm-little_endian32 stdout.pgm-little_endian (or "64" or "big") The automated tests will run both variations. As well, the preexisting recent default was to probe, as we had a few cases that needed "stdout.pgm64". We should clean this up so those are called out specifically. This way, e.g. PPC can be compared to SPARC, I386_* can be compared amongst each other, with more coverage than might be had if just all platforms compared against all platforms and the coverage constrained. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: portable/less portable test variations Date: Wed, 24 Feb 2010 12:41:12 +0000 I'd like to write tests that, given different command line parameters, will either output totally portable results, or only somewhat portable, where "somewhat" probably means either portable to particular wordsize or portable to wordsize+endian. Worst case, completely platform specific. We'd have 1, 3, or 5 checked in expected results. Or possibly 1+n (portable + n platforms). This case is less useful, because it takes away the ability to compare, e.g. LINUXLIBC6 to NT386. The test would run twice, with and without the command line option. I guess it is about as much work to implement as to describe, but I've let it drag out. I have tests that would benefit from this. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 28 12:55:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 28 Feb 2010 12:55:38 +0100 Subject: [M3devel] r_test, pr_test, pb_test In-Reply-To: References: Message-ID: <20100228125538.29yb34mrs4wsoo4o@mail.elegosoft.com> Quoting Jay K : > Olaf, I think pr_test and pb_test are cryptic, and there is > no explanation what "pr" and "pb" stand for (as opposed > to p_test, e_test, c_test, which have comment). > > I propose > > run_flags_test > build_flags_test > > or > > program_with_run_flags > program_with_build_flags > program_with_compiler_flags > > or somesuch. > > I'm guessing "r" means "run flags", "b" means "build flags. > > I'll probably do something here very soon, since I'm adding another > type of test. Yes. I must have forgotten to document it better. They are there to run a program or its build with additional flags or options. You can easily see their use at the test instances though: pr_test ("p2", "p213", "runtime arguments: @M3paranoidgc", "@M3paranoidgc") pr_test ("p2", "p214", "runtime arguments: @M3noincremental", "@M3noincremental") pr_test ("p2", "p215", "runtime arguments: @M3nogenerational", "@M3nogenerational") pr_test ("p2", "p216", "runtime arguments: @M3nogc", "@M3nogc") pb_test ("p2", "p217", ".M3SHIP program", "-no-m3ship-resolution") pb_test ("p2", "p218", ".M3SHIP Program", "-no-m3ship-resolution") pb_test ("p2", "p219", ".M3SHIP Program group-writable", "-no-m3ship-resolution -group-writable") pb_test ("p2", "p220", ".M3SHIP library", "-no-m3ship-resolution") pb_test ("p2", "p221", ".M3SHIP Library", "-no-m3ship-resolution") pb_test ("p2", "p222", ".M3SHIP Library", "-no-m3ship-resolution -group-writable") % The following test won't run until FSUtils.RmRec() is fixed %pb_test ("p2", "p223", ".M3SHIP Library", "-no-m3ship-resolution -group-writable") Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 08:41:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 07:41:04 +0000 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1264972487.4240.4.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: Let's say I have: TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; TYPE FOOA = ARRAY [0..1] OF FOO; And I have a platform with max_align = 32 and a platform with max_align = 64. One platform will make FOOA be 24 bytes, the other 32. One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. Can that pickle be read/written by the two platforms? And how does the code know/detect the difference? That is, if a platform changed from max_align = 32 to 64, would the pickle code work just as well on the "same" platform as on the "different" platforms? I very recently changed NT386 max_align from 32 to 64, and I believe the remaining active platforms with max_align = 32 should also be 64. It would "only" affect pickles with LONGINT or LONGFLOAT, as well as "lining up" such structs with C. Such alignment shold make us not need the extra "unaligned double" switch on most platforms (some mystery still on some platforms) as well as perhaps be needed for some atomic operations, esp. maybe on LONGINT on 32bit x86. - Jay > From: dragisha at m3w.org > To: rodney_bates at lcwb.coop > Date: Sun, 31 Jan 2010 22:14:47 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > I've not changed my code, that is for sure.... But now I am not sure > some parent type (esp MUTEX here an there) was not changed... I'll take > a look on this again sometime soon and report my findings. > > Thanks for clues. > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > Dragi?a Duri? wrote: > > > I've asked this before, but didn't catch answer: > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> I suggest we can probably get by with platform-independent > > >> packing/alignment settings. > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > does not read that pickle anymore.... > > > > And you are certain your program that tries to read still contains > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > Someone remembers moment when this incompatible changes were made? > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 1 09:11:38 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 1 Feb 2010 03:11:38 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> That shouldn't affect things since the pickler picks apart the structures and ships the individual primitives. Right? On 1 Feb 2010, at 02:41, Jay K wrote: > Let's say I have: > > > TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; > TYPE FOOA = ARRAY [0..1] OF FOO; > > > And I have a platform with max_align = 32 and a platform with max_align = 64. > One platform will make FOOA be 24 bytes, the other 32. > One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. > Can that pickle be read/written by the two platforms? > And how does the code know/detect the difference? > That is, if a platform changed from max_align = 32 to 64, would the pickle code work just > as well on the "same" platform as on the "different" platforms? > > > I very recently changed NT386 max_align from 32 to 64, and I believe > the remaining active platforms with max_align = 32 should also be 64. > It would "only" affect pickles with LONGINT or LONGFLOAT, as well > as "lining up" such structs with C. > > > Such alignment shold make us not need the extra "unaligned double" switch > on most platforms (some mystery still on some platforms) as well as > perhaps be needed for some atomic operations, esp. maybe on > LONGINT on 32bit x86. > > > - Jay > > > > From: dragisha at m3w.org > > To: rodney_bates at lcwb.coop > > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] platform-independent packing/alignment? > > > > I've not changed my code, that is for sure.... But now I am not sure > > some parent type (esp MUTEX here an there) was not changed... I'll take > > a look on this again sometime soon and report my findings. > > > > Thanks for clues. > > > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > > > Dragi?a Duri? wrote: > > > > I've asked this before, but didn't catch answer: > > > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > > >> I suggest we can probably get by with platform-independent > > > >> packing/alignment settings. > > > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > > does not read that pickle anymore.... > > > > > > And you are certain your program that tries to read still contains > > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > > > > Someone remembers moment when this incompatible changes were made? > > -- > > Dragi?a Duri? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Feb 1 09:19:06 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 01 Feb 2010 00:19:06 -0800 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> Message-ID: <20100201081906.583961A2099@async.async.caltech.edu> For what it's worth... I recall someone (Dragisa?) just complained that he was having problems unpickling data structures... I have never had much luck pickling and unpickling MUTEXes, using a few (not very different) M3 compilers. I just leave them out of my pickles. It makes the pickles a lot more compatible across versions. I'm not talking recent CM3 versions here but a variety of old versions. Implementors have seemed to modify MUTEX quite a bit. What's the point of pickling it anyhow? If it's an active mutex the unpickling will surely lead to garbage, if there are wait queues and things.. then you wind up un/pickling Thread structures too. Mika Tony Hosking writes: > >--Apple-Mail-4--1058110347 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=utf-8 > >That shouldn't affect things since the pickler picks apart the = >structures and ships the individual primitives. Right? > >On 1 Feb 2010, at 02:41, Jay K wrote: > >> Let's say I have: >> =20 >> =20 >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; >> TYPE FOOA =3D ARRAY [0..1] OF FOO; >> =20 >> =20 >> And I have a platform with max_align =3D 32 and a platform with = >max_align =3D 64. >> One platform will make FOOA be 24 bytes, the other 32. >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = >won't. >> Can that pickle be read/written by the two platforms? >> And how does the code know/detect the difference? >> That is, if a platform changed from max_align =3D 32 to 64, would the = >pickle code work just >> as well on the "same" platform as on the "different" platforms? >> =20 >> =20 >> I very recently changed NT386 max_align from 32 to 64, and I believe >> the remaining active platforms with max_align =3D 32 should also be = >64. >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well >> as "lining up" such structs with C. >> =20 >> =20 >> Such alignment shold make us not need the extra "unaligned double" = >switch >> on most platforms (some mystery still on some platforms) as well as >> perhaps be needed for some atomic operations, esp. maybe on >> LONGINT on 32bit x86. >> =20 >> =20 >> - Jay >>=20 >> =20 >> > From: dragisha at m3w.org >> > To: rodney_bates at lcwb.coop >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] platform-independent packing/alignment? >> >=20 >> > I've not changed my code, that is for sure.... But now I am not sure >> > some parent type (esp MUTEX here an there) was not changed... I'll = >take >> > a look on this again sometime soon and report my findings. >> >=20 >> > Thanks for clues. >> >=20 >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: >> > >=20 >> > > Dragi=C5=A1a Duri=C4=87 wrote: >> > > > I've asked this before, but didn't catch answer: >> > > >=20 >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: >> > > >> I suggest we can probably get by with platform-independent >> > > >> packing/alignment settings. >> > > >=20 >> > > > Some time ago I've used pickles (CM3) to save some data... My = >program >> > > > does not read that pickle anymore....=20 >> > >=20 >> > > And you are certain your program that tries to read still contains >> > > exact structurally equivalent types to all the types in the = >pickle? >> > >=20 >> > > >=20 >> > > > Someone remembers moment when this incompatible changes were = >made?=20 >> > --=20 >> > Dragi=C5=A1a Duri=C4=87 >> >=20 > > >--Apple-Mail-4--1058110347 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=utf-8 > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >after-white-space; ">That shouldn't affect things since the pickler = >picks apart the structures and ships the individual primitives. = > Right?
>
On 1 Feb 2010, at 02:41, Jay K wrote:

class=3D"Apple-interchange-newline">
class=3D"Apple-style-span" style=3D"border-collapse: separate; = >font-family: Helvetica; font-size: medium; font-style: normal; = >font-variant: normal; font-weight: normal; letter-spacing: normal; = >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; ">
style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = >FOO;
 
 
And I have a platform with max_align = >=3D 32 and a platform with max_align =3D 64.
One platform will = >make FOOA be 24 bytes, the other 32.
  One platform will = >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = >pickle be read/written by the two platforms?
And how does the code = >know/detect the difference?
That is, if a platform changed from = >max_align =3D 32 to 64, would the pickle code work just
as = >well on the "same" platform as on the "different" = >platforms?
 
 
I very recently changed NT386 = >max_align from 32 to 64, and I believe
the remaining active platforms = >with max_align =3D 32 should also be 64.
It would "only" affect = >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = >structs with C.
 
 
Such alignment shold make us not = >need the extra "unaligned double" switch
on most platforms (some = >mystery still on some platforms) as well as
perhaps be needed for = >some atomic operations, esp. maybe on
LONGINT on 32bit = >x86.
 
 
 - Jay

 
> From:class=3D"Apple-converted-space"> href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To:class=3D"Apple-converted-space"> href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC:class=3D"Apple-converted-space"> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = >Subject: Re: [M3devel] platform-independent = >packing/alignment?
>class=3D"Apple-converted-space"> 
> I've not changed = >my code, that is for sure.... But now I am not sure
> some parent = >type (esp MUTEX here an there) was not changed... I'll take
> a = >look on this again sometime soon and report my findings.
>class=3D"Apple-converted-space"> 
> Thanks for = >clues.
> 
> = >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = >> 
> > = >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = >but didn't catch answer:
> > >class=3D"Apple-converted-space"> 
> > > On Sun, = >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = >we can probably get by with platform-independent
> > >> = >packing/alignment settings.
> > >class=3D"Apple-converted-space"> 
> > > Some = >time ago I've used pickles (CM3) to save some data... My program
> = >> > does not read that pickle anymore....class=3D"Apple-converted-space"> 
> >class=3D"Apple-converted-space"> 
> > And you are = >certain your program that tries to read still contains
> > = >exact structurally equivalent types to all the types in the = >pickle?
> >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > > Someone = >remembers moment when this incompatible changes were made?class=3D"Apple-converted-space"> 
> --class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = >Duri=C4=87 <href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
>class=3D"Apple-converted-space"> 
>

= > >--Apple-Mail-4--1058110347-- From dragisha at m3w.org Mon Feb 1 09:41:48 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 01 Feb 2010 09:41:48 +0100 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <20100201081906.583961A2099@async.async.caltech.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> Message-ID: <1265013708.4240.16.camel@faramir.m3w.org> MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that code being same even if changes were made to it's basic structure... Or not... On the second thought, MUTEX is basically fixed, but it's revealations can vary. Thus making it incompatible over pickles/versions. I've not looked at my code/data yet, but MUTEX was only an idea what went... It is OODBMS package, and mutex is not used for persistent data, only for tables/indexes. Thus, problem (at leat for me) remains and it is not pickled MUTEX. On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/plain; > > charset=utf-8 > > > >That shouldn't affect things since the pickler picks apart the = > >structures and ships the individual primitives. Right? > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > >> Let's say I have: > >> =20 > >> =20 > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > >> =20 > >> =20 > >> And I have a platform with max_align =3D 32 and a platform with = > >max_align =3D 64. > >> One platform will make FOOA be 24 bytes, the other 32. > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > >won't. > >> Can that pickle be read/written by the two platforms? > >> And how does the code know/detect the difference? > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > >pickle code work just > >> as well on the "same" platform as on the "different" platforms? > >> =20 > >> =20 > >> I very recently changed NT386 max_align from 32 to 64, and I believe > >> the remaining active platforms with max_align =3D 32 should also be = > >64. > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > >> as "lining up" such structs with C. > >> =20 > >> =20 > >> Such alignment shold make us not need the extra "unaligned double" = > >switch > >> on most platforms (some mystery still on some platforms) as well as > >> perhaps be needed for some atomic operations, esp. maybe on > >> LONGINT on 32bit x86. > >> =20 > >> =20 > >> - Jay > >>=20 > >> =20 > >> > From: dragisha at m3w.org > >> > To: rodney_bates at lcwb.coop > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > >> >=20 > >> > I've not changed my code, that is for sure.... But now I am not sure > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > >take > >> > a look on this again sometime soon and report my findings. > >> >=20 > >> > Thanks for clues. > >> >=20 > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > >> > >=20 > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > >> > > > I've asked this before, but didn't catch answer: > >> > > >=20 > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > >> > > >> I suggest we can probably get by with platform-independent > >> > > >> packing/alignment settings. > >> > > >=20 > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > >program > >> > > > does not read that pickle anymore....=20 > >> > >=20 > >> > > And you are certain your program that tries to read still contains > >> > > exact structurally equivalent types to all the types in the = > >pickle? > >> > >=20 > >> > > >=20 > >> > > > Someone remembers moment when this incompatible changes were = > >made?=20 > >> > --=20 > >> > Dragi=C5=A1a Duri=C4=87 > >> >=20 > > > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/html; > > charset=utf-8 > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > >after-white-space; ">That shouldn't affect things since the pickler = > >picks apart the structures and ships the individual primitives. = > > Right?
> >
On 1 Feb 2010, at 02:41, Jay K wrote:

>class=3D"Apple-interchange-newline">
>class=3D"Apple-style-span" style=3D"border-collapse: separate; = > >font-family: Helvetica; font-size: medium; font-style: normal; = > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > >white-space: normal; widows: 2; word-spacing: 0px; = > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > >auto; -webkit-text-stroke-width: 0px; ">
>style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > >FOO;
 
 
And I have a platform with max_align = > >=3D 32 and a platform with max_align =3D 64.
One platform will = > >make FOOA be 24 bytes, the other 32.
  One platform will = > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > >pickle be read/written by the two platforms?
And how does the code = > >know/detect the difference?
That is, if a platform changed from = > >max_align =3D 32 to 64, would the pickle code work just
as = > >well on the "same" platform as on the "different" = > >platforms?
 
 
I very recently changed NT386 = > >max_align from 32 to 64, and I believe
the remaining active platforms = > >with max_align =3D 32 should also be 64.
It would "only" affect = > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > >structs with C.
 
 
Such alignment shold make us not = > >need the extra "unaligned double" switch
on most platforms (some = > >mystery still on some platforms) as well as
perhaps be needed for = > >some atomic operations, esp. maybe on
LONGINT on 32bit = > >x86.
 
 
 - Jay

 
> From: >class=3D"Apple-converted-space">  >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: >class=3D"Apple-converted-space">  >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: >class=3D"Apple-converted-space">  >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > >Subject: Re: [M3devel] platform-independent = > >packing/alignment?
> >class=3D"Apple-converted-space"> 
> I've not changed = > >my code, that is for sure.... But now I am not sure
> some parent = > >type (esp MUTEX here an there) was not changed... I'll take
> a = > >look on this again sometime soon and report my findings.
> >class=3D"Apple-converted-space"> 
> Thanks for = > >clues.
> 
> = > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > >> 
> > = > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > >but didn't catch answer:
> > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > >we can probably get by with platform-independent
> > >> = > >packing/alignment settings.
> > > >class=3D"Apple-converted-space"> 
> > > Some = > >time ago I've used pickles (CM3) to save some data... My program
> = > >> > does not read that pickle anymore.... >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > And you are = > >certain your program that tries to read still contains
> > = > >exact structurally equivalent types to all the types in the = > >pickle?
> > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > > Someone = > >remembers moment when this incompatible changes were made? >class=3D"Apple-converted-space"> 
> -- >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > >Duri=C4=87 < >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> >class=3D"Apple-converted-space"> 
 >>

= > > > >--Apple-Mail-4--1058110347-- -- Dragi?a Duri? From wagner at elegosoft.com Mon Feb 1 11:52:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 11:52:15 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org> Message-ID: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Quoting Tony Hosking : > Surely we are close. What stability issues are there on the release branch? Jay seems to have been hardworking to bring the release branch up-to-date. The last changes are about a week old now though. See FreeBSD or any other target for a list: http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes On this platform CVSup, db, odbc and m3gdb are still failing/missing: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ CVSup also fails on Linux, 32 and 64 bit: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ Windows shows even more test failures: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ Solaris seems to have some severe problems: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ Darwin, PPC_Linux and OPENBSD haven't been built/tested for month (no servers available) as has FreeBSD4 (I still want to set that up again on one of our machines, but didn't get round till now). So I'd say there's still a lot of tedious work before we can schedule another release package build. Anybody able and willing to fix some of the problems reported above is encouraged to do so. Olaf > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > >> I don't want to be a buzz kill, but it's almost February 2010, and >> 5.8 stable is still not out. Are there still any issues left? >> Anything that can be ignored until after release? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 12:37:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 11:37:39 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: I hadn't looked and hadn't realized. I'll look. I thought things were as about up to date as they would get (no LONGINT on NT386, no Atomic, but "revised LONGINT" on others -- m3front matching current, at least before more atomic changes). There is the cvsup problem I was ignoring. The bug report was good but didn't have e.g. the cvsup file. I'll look at these things. Fwiw, Modula-3 has really been quite stable for like 15 years now, very few changes (too few), very few regressions, but definitely some. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 1 13:13:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 12:13:57 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , , , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com>, Message-ID: The NT386 problems are "path related" and trying to do anything with postgres. I'm look at the others. FreeBSD I would suspect is missing some odbc packages but haven't really looked. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Mon, 1 Feb 2010 11:37:39 +0000 Subject: Re: [M3devel] 5.8 Release? I hadn't looked and hadn't realized. I'll look. I thought things were as about up to date as they would get (no LONGINT on NT386, no Atomic, but "revised LONGINT" on others -- m3front matching current, at least before more atomic changes). There is the cvsup problem I was ignoring. The bug report was good but didn't have e.g. the cvsup file. I'll look at these things. Fwiw, Modula-3 has really been quite stable for like 15 years now, very few changes (too few), very few regressions, but definitely some. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 1 15:54:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 14:54:06 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar to LINUXLIBC, SOLgnu/SOLsun. PPC_DARWIN I can make available too. I'm also still planning on making several more available. Some are already running. Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 1 16:40:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 16:40:23 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: <20100201164023.6vbecip2fwwk0g0c@mail.elegosoft.com> Quoting Jay K : > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > to LINUXLIBC, SOLgnu/SOLsun. > > PPC_DARWIN I can make available too. > > I'm also still planning on making several more available. > > Some are already running. I just reported the status from Hudson. I haven't done anything there recently, so no idea why tests don't run if the servers are available. > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. Only if he allows ssh access from birch.elegosoft.com. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 1 19:23:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 19:23:22 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> Recent commits seem to have made matters worse: http://hudson.modula3.com:8080/ And PPC_DARWIN should now be back online. Olaf Quoting Jay K : > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > to LINUXLIBC, SOLgnu/SOLsun. > > PPC_DARWIN I can make available too. > > I'm also still planning on making several more available. > > Some are already running. > > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. > > - Jay > >> Date: Mon, 1 Feb 2010 11:52:15 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] 5.8 Release? >> >> Quoting Tony Hosking : >> >> > Surely we are close. What stability issues are there on the >> release branch? >> >> Jay seems to have been hardworking to bring the release branch up-to-date. >> The last changes are about a week old now though. See FreeBSD or any other >> target for a list: >> >> >> http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes >> >> On this platform CVSup, db, odbc and m3gdb are still failing/missing: >> >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ >> >> CVSup also fails on Linux, 32 and 64 bit: >> >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ >> >> Windows shows even more test failures: >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ >> >> Solaris seems to have some severe problems: >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ >> >> Darwin, PPC_Linux and OPENBSD haven't been built/tested for month >> (no servers available) as has FreeBSD4 (I still want to set that up again >> on one of our machines, but didn't get round till now). >> >> So I'd say there's still a lot of tedious work before we can schedule >> another release package build. >> >> Anybody able and willing to fix some of the problems reported above >> is encouraged to do so. >> >> Olaf >> >> > Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> > 305 N. University Street | West Lafayette | IN 47907 | USA >> > Office +1 765 494 6001 | Mobile +1 765 427 5484 >> > >> > On 30 Jan 2010, at 19:19, Martin Bishop wrote: >> > >> >> I don't want to be a buzz kill, but it's almost February 2010, and >> >> 5.8 stable is still not out. Are there still any issues left? >> >> Anything that can be ignored until after release? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 20:30:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 19:30:36 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com>, , <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> Message-ID: Sorry, those should already be fixed. - Jay > Date: Mon, 1 Feb 2010 19:23:22 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] 5.8 Release? > > Recent commits seem to have made matters worse: > > http://hudson.modula3.com:8080/ > > > And PPC_DARWIN should now be back online. > > Olaf > > Quoting Jay K : > > > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > > to LINUXLIBC, SOLgnu/SOLsun. > > > > PPC_DARWIN I can make available too. > > > > I'm also still planning on making several more available. > > > > Some are already running. > > > > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. > > > > - Jay > > > >> Date: Mon, 1 Feb 2010 11:52:15 +0100 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] 5.8 Release? > >> > >> Quoting Tony Hosking : > >> > >> > Surely we are close. What stability issues are there on the > >> release branch? > >> > >> Jay seems to have been hardworking to bring the release branch up-to-date. > >> The last changes are about a week old now though. See FreeBSD or any other > >> target for a list: > >> > >> > >> http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > >> > >> On this platform CVSup, db, odbc and m3gdb are still failing/missing: > >> > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > >> > >> CVSup also fails on Linux, 32 and 64 bit: > >> > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > >> > >> Windows shows even more test failures: > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > >> > >> Solaris seems to have some severe problems: > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > >> > >> Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > >> (no servers available) as has FreeBSD4 (I still want to set that up again > >> on one of our machines, but didn't get round till now). > >> > >> So I'd say there's still a lot of tedious work before we can schedule > >> another release package build. > >> > >> Anybody able and willing to fix some of the problems reported above > >> is encouraged to do so. > >> > >> Olaf > >> > >> > Antony Hosking | Associate Professor | Computer Science | Purdue > >> University > >> > 305 N. University Street | West Lafayette | IN 47907 | USA > >> > Office +1 765 494 6001 | Mobile +1 765 427 5484 > >> > > >> > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > >> > > >> >> I don't want to be a buzz kill, but it's almost February 2010, and > >> >> 5.8 stable is still not out. Are there still any issues left? > >> >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Feb 1 20:37:48 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 1 Feb 2010 14:37:48 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1265013708.4240.16.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> <1265013708.4240.16.camel@faramir.m3w.org> Message-ID: For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. Regards, Randy Coleburn -----Original Message----- From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Monday, February 01, 2010 3:42 AM To: Mika Nystrom Cc: m3devel at elegosoft.com Subject: Re: [M3devel] platform-independent packing/alignment? MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that code being same even if changes were made to it's basic structure... Or not... On the second thought, MUTEX is basically fixed, but it's revealations can vary. Thus making it incompatible over pickles/versions. I've not looked at my code/data yet, but MUTEX was only an idea what went... It is OODBMS package, and mutex is not used for persistent data, only for tables/indexes. Thus, problem (at leat for me) remains and it is not pickled MUTEX. On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/plain; > > charset=utf-8 > > > >That shouldn't affect things since the pickler picks apart the = > >structures and ships the individual primitives. Right? > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > >> Let's say I have: > >> =20 > >> =20 > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > >> =20 > >> =20 > >> And I have a platform with max_align =3D 32 and a platform with = > >max_align =3D 64. > >> One platform will make FOOA be 24 bytes, the other 32. > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > >won't. > >> Can that pickle be read/written by the two platforms? > >> And how does the code know/detect the difference? > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > >pickle code work just > >> as well on the "same" platform as on the "different" platforms? > >> =20 > >> =20 > >> I very recently changed NT386 max_align from 32 to 64, and I believe > >> the remaining active platforms with max_align =3D 32 should also be = > >64. > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > >> as "lining up" such structs with C. > >> =20 > >> =20 > >> Such alignment shold make us not need the extra "unaligned double" = > >switch > >> on most platforms (some mystery still on some platforms) as well as > >> perhaps be needed for some atomic operations, esp. maybe on > >> LONGINT on 32bit x86. > >> =20 > >> =20 > >> - Jay > >>=20 > >> =20 > >> > From: dragisha at m3w.org > >> > To: rodney_bates at lcwb.coop > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > >> >=20 > >> > I've not changed my code, that is for sure.... But now I am not sure > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > >take > >> > a look on this again sometime soon and report my findings. > >> >=20 > >> > Thanks for clues. > >> >=20 > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > >> > >=20 > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > >> > > > I've asked this before, but didn't catch answer: > >> > > >=20 > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > >> > > >> I suggest we can probably get by with platform-independent > >> > > >> packing/alignment settings. > >> > > >=20 > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > >program > >> > > > does not read that pickle anymore....=20 > >> > >=20 > >> > > And you are certain your program that tries to read still contains > >> > > exact structurally equivalent types to all the types in the = > >pickle? > >> > >=20 > >> > > >=20 > >> > > > Someone remembers moment when this incompatible changes were = > >made?=20 > >> > --=20 > >> > Dragi=C5=A1a Duri=C4=87 > >> >=20 > > > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/html; > > charset=utf-8 > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > >after-white-space; ">That shouldn't affect things since the pickler = > >picks apart the structures and ships the individual primitives. = > > Right?
> >
On 1 Feb 2010, at 02:41, Jay K wrote:

>class=3D"Apple-interchange-newline">
>class=3D"Apple-style-span" style=3D"border-collapse: separate; = > >font-family: Helvetica; font-size: medium; font-style: normal; = > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > >white-space: normal; widows: 2; word-spacing: 0px; = > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > >auto; -webkit-text-stroke-width: 0px; ">
>style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > >FOO;
 
 
And I have a platform with max_align = > >=3D 32 and a platform with max_align =3D 64.
One platform will = > >make FOOA be 24 bytes, the other 32.
  One platform will = > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > >pickle be read/written by the two platforms?
And how does the code = > >know/detect the difference?
That is, if a platform changed from = > >max_align =3D 32 to 64, would the pickle code work just
as = > >well on the "same" platform as on the "different" = > >platforms?
 
 
I very recently changed NT386 = > >max_align from 32 to 64, and I believe
the remaining active platforms = > >with max_align =3D 32 should also be 64.
It would "only" affect = > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > >structs with C.
 
 
Such alignment shold make us not = > >need the extra "unaligned double" switch
on most platforms (some = > >mystery still on some platforms) as well as
perhaps be needed for = > >some atomic operations, esp. maybe on
LONGINT on 32bit = > >x86.
 
 
 - Jay

 
> From: >class=3D"Apple-converted-space">  >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: >class=3D"Apple-converted-space">  >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: >class=3D"Apple-converted-space">  >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > >Subject: Re: [M3devel] platform-independent = > >packing/alignment?
> >class=3D"Apple-converted-space"> 
> I've not changed = > >my code, that is for sure.... But now I am not sure
> some parent = > >type (esp MUTEX here an there) was not changed... I'll take
> a = > >look on this again sometime soon and report my findings.
> >class=3D"Apple-converted-space"> 
> Thanks for = > >clues.
> 
> = > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > >> 
> > = > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > >but didn't catch answer:
> > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > >we can probably get by with platform-independent
> > >> = > >packing/alignment settings.
> > > >class=3D"Apple-converted-space"> 
> > > Some = > >time ago I've used pickles (CM3) to save some data... My program
> = > >> > does not read that pickle anymore.... >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > And you are = > >certain your program that tries to read still contains
> > = > >exact structurally equivalent types to all the types in the = > >pickle?
> > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > > Someone = > >remembers moment when this incompatible changes were made? >class=3D"Apple-converted-space"> 
> -- >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > >Duri=C4=87 < >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> >class=3D"Apple-converted-space"> 
 >>

= > > > >--Apple-Mail-4--1058110347-- -- Dragi?a Duri? From jay.krell at cornell.edu Mon Feb 1 20:46:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 19:46:38 +0000 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , , <1264972487.4240.4.camel@faramir.m3w.org>, , <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu>, <20100201081906.583961A2099@async.async.caltech.edu>, <1265013708.4240.16.camel@faramir.m3w.org>, Message-ID: You *might* imagine pickling a mutex, held or not, like to "freeze"/"suspend" a running system, possibly to move to another system, where it is "resumed". But in reality, that won't work. If changing alignment/padding won't break pickles, I again suggest that "max_align" be raised to at least 64 for all architectures. So that double and longint are aligned. Or that max_align be thrown out entirely and have the architectures all declare things correctly..which they likely already are. > recreates the MUTEX in the environment of the reading program Just with "NEW(MUTEX)" right? No attempt to put it back in the same state, I assume. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Mon, 1 Feb 2010 14:37:48 -0500 > Subject: Re: [M3devel] platform-independent packing/alignment? > > For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Monday, February 01, 2010 3:42 AM > To: Mika Nystrom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > > On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > > For what it's worth... > > > > I recall someone (Dragisa?) just complained that he was having problems > > unpickling data structures... > > > > I have never had much luck pickling and unpickling MUTEXes, using a few > > (not very different) M3 compilers. I just leave them out of my pickles. > > It makes the pickles a lot more compatible across versions. I'm not > > talking recent CM3 versions here but a variety of old versions. > > Implementors have seemed to modify MUTEX quite a bit. What's the point > > of pickling it anyhow? If it's an active mutex the unpickling will > > surely lead to garbage, if there are wait queues and things.. then you > > wind up un/pickling Thread structures too. > > > > Mika > > > > Tony Hosking writes: > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/plain; > > > charset=utf-8 > > > > > >That shouldn't affect things since the pickler picks apart the = > > >structures and ships the individual primitives. Right? > > > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > > > >> Let's say I have: > > >> =20 > > >> =20 > > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > > >> =20 > > >> =20 > > >> And I have a platform with max_align =3D 32 and a platform with = > > >max_align =3D 64. > > >> One platform will make FOOA be 24 bytes, the other 32. > > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > > >won't. > > >> Can that pickle be read/written by the two platforms? > > >> And how does the code know/detect the difference? > > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > > >pickle code work just > > >> as well on the "same" platform as on the "different" platforms? > > >> =20 > > >> =20 > > >> I very recently changed NT386 max_align from 32 to 64, and I believe > > >> the remaining active platforms with max_align =3D 32 should also be = > > >64. > > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > > >> as "lining up" such structs with C. > > >> =20 > > >> =20 > > >> Such alignment shold make us not need the extra "unaligned double" = > > >switch > > >> on most platforms (some mystery still on some platforms) as well as > > >> perhaps be needed for some atomic operations, esp. maybe on > > >> LONGINT on 32bit x86. > > >> =20 > > >> =20 > > >> - Jay > > >>=20 > > >> =20 > > >> > From: dragisha at m3w.org > > >> > To: rodney_bates at lcwb.coop > > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > > >> >=20 > > >> > I've not changed my code, that is for sure.... But now I am not sure > > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > > >take > > >> > a look on this again sometime soon and report my findings. > > >> >=20 > > >> > Thanks for clues. > > >> >=20 > > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > >> > >=20 > > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > > >> > > > I've asked this before, but didn't catch answer: > > >> > > >=20 > > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> > > >> I suggest we can probably get by with platform-independent > > >> > > >> packing/alignment settings. > > >> > > >=20 > > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > > >program > > >> > > > does not read that pickle anymore....=20 > > >> > >=20 > > >> > > And you are certain your program that tries to read still contains > > >> > > exact structurally equivalent types to all the types in the = > > >pickle? > > >> > >=20 > > >> > > >=20 > > >> > > > Someone remembers moment when this incompatible changes were = > > >made?=20 > > >> > --=20 > > >> > Dragi=C5=A1a Duri=C4=87 > > >> >=20 > > > > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/html; > > > charset=utf-8 > > > > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > > >after-white-space; ">That shouldn't affect things since the pickler = > > >picks apart the structures and ships the individual primitives. = > > > Right?
> > >
On 1 Feb 2010, at 02:41, Jay K wrote:

> >class=3D"Apple-interchange-newline">
> >class=3D"Apple-style-span" style=3D"border-collapse: separate; = > > >font-family: Helvetica; font-size: medium; font-style: normal; = > > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > > >white-space: normal; widows: 2; word-spacing: 0px; = > > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > > >auto; -webkit-text-stroke-width: 0px; ">
> >style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > > >FOO;
 
 
And I have a platform with max_align = > > >=3D 32 and a platform with max_align =3D 64.
One platform will = > > >make FOOA be 24 bytes, the other 32.
  One platform will = > > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > > >pickle be read/written by the two platforms?
And how does the code = > > >know/detect the difference?
That is, if a platform changed from = > > >max_align =3D 32 to 64, would the pickle code work just
as = > > >well on the "same" platform as on the "different" = > > >platforms?
 
 
I very recently changed NT386 = > > >max_align from 32 to 64, and I believe
the remaining active platforms = > > >with max_align =3D 32 should also be 64.
It would "only" affect = > > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > > >structs with C.
 
 
Such alignment shold make us not = > > >need the extra "unaligned double" switch
on most platforms (some = > > >mystery still on some platforms) as well as
perhaps be needed for = > > >some atomic operations, esp. maybe on
LONGINT on 32bit = > > >x86.
 
 
 - Jay

 
> From: > >class=3D"Apple-converted-space">  > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: > >class=3D"Apple-converted-space">  > >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: > >class=3D"Apple-converted-space">  > >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > > >Subject: Re: [M3devel] platform-independent = > > >packing/alignment?
> > >class=3D"Apple-converted-space"> 
> I've not changed = > > >my code, that is for sure.... But now I am not sure
> some parent = > > >type (esp MUTEX here an there) was not changed... I'll take
> a = > > >look on this again sometime soon and report my findings.
> > >class=3D"Apple-converted-space"> 
> Thanks for = > > >clues.
> 
> = > > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > > >> 
> > = > > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > > >but didn't catch answer:
> > > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > > >we can probably get by with platform-independent
> > >> = > > >packing/alignment settings.
> > > > >class=3D"Apple-converted-space"> 
> > > Some = > > >time ago I've used pickles (CM3) to save some data... My program
> = > > >> > does not read that pickle anymore.... > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > And you are = > > >certain your program that tries to read still contains
> > = > > >exact structurally equivalent types to all the types in the = > > >pickle?
> > > >class=3D"Apple-converted-space"> 
> > > > >class=3D"Apple-converted-space"> 
> > > Someone = > > >remembers moment when this incompatible changes were made? > >class=3D"Apple-converted-space"> 
> -- > >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > > >Duri=C4=87 < > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> > >class=3D"Apple-converted-space"> 
 > >>

= > > > > > >--Apple-Mail-4--1058110347-- > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 1 20:52:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 13:52:55 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: <4B673117.5060105@lcwb.coop> Jay K wrote: > Let's say I have: > > > TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; > TYPE FOOA = ARRAY [0..1] OF FOO; > > > And I have a platform with max_align = 32 and a platform with max_align > = 64. > One platform will make FOOA be 24 bytes, the other 32. > One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. > Can that pickle be read/written by the two platforms? > And how does the code know/detect the difference? > That is, if a platform changed from max_align = 32 to 64, would the > pickle code work just > as well on the "same" platform as on the "different" platforms? > Yes, this will work fine. The header of the pickle file has a compact binary encoding of a copy of the RTPacking.T value for the target where the pickle was written. This contains target characteristics like max_align. Reading a pickle compares the RTPacking.T value of the reading machine with that in the pickle header and reconstructs the layout on both machines, then does any necessary conversion. > > I very recently changed NT386 max_align from 32 to 64, and I believe > the remaining active platforms with max_align = 32 should also be 64. > It would "only" affect pickles with LONGINT or LONGFLOAT, as well > as "lining up" such structs with C. > > > Such alignment shold make us not need the extra "unaligned double" switch > on most platforms (some mystery still on some platforms) as well as > perhaps be needed for some atomic operations, esp. maybe on > LONGINT on 32bit x86. > > > - Jay > > > > From: dragisha at m3w.org > > To: rodney_bates at lcwb.coop > > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] platform-independent packing/alignment? > > > > I've not changed my code, that is for sure.... But now I am not sure > > some parent type (esp MUTEX here an there) was not changed... I'll take > > a look on this again sometime soon and report my findings. > > > > Thanks for clues. > > > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > > > Dragi?a Duri? wrote: > > > > I've asked this before, but didn't catch answer: > > > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > > >> I suggest we can probably get by with platform-independent > > > >> packing/alignment settings. > > > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > > does not read that pickle anymore.... > > > > > > And you are certain your program that tries to read still contains > > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > > > > Someone remembers moment when this incompatible changes were made? > > -- > > Dragi?a Duri? > > From rodney_bates at lcwb.coop Mon Feb 1 21:00:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 14:00:51 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <20100201081906.583961A2099@async.async.caltech.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> Message-ID: <4B6732F3.4020601@lcwb.coop> I too have had trouble pickling MUTEXs or subtypes thereof, even when writing and reading on the same target. I think it was some runaway recursion in pickle code, maybe even while writing. I just worked around it by eliminating the MUTEXs from the pickle. But eventually, somebody may want to pickle an elaborate subtype of MUTEX and find it hard to separate them, so we should someday fix this. Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > From rcolebur at SCIRES.COM Mon Feb 1 21:02:49 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 1 Feb 2010 15:02:49 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , , <1264972487.4240.4.camel@faramir.m3w.org>, , <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu>, <20100201081906.583961A2099@async.async.caltech.edu>, <1265013708.4240.16.camel@faramir.m3w.org>, Message-ID: Right, you can't put it back in the same state; you just create a new one. Here is an example showing a case where I had a field named "PrivateMutex" that was embedded in an object that needed to be pickled. TYPE PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; (*|***********************************************************************************) (* Pickle Procedures *) (*|***********************************************************************************) TYPE Special = Pickle.Special OBJECT OVERRIDES write := WriteSpecial; read := ReadSpecial; END; (* Special *) PROCEDURE WriteSpecial (self: Special; <*UNUSED*>ref: REFANY; <*UNUSED*>writer: Pickle.Writer ) RAISES {Pickle.Error, <*NOWARN*>Wr.Failure, Thread.Alerted} = (* Special pickle writer for LiteConfig.PrivateMutex objects. *) BEGIN (* WriteSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN (* omit writing the mutex field *) ELSE RAISE Pickle.Error("LiteConfig.WriteSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END WriteSpecial; PROCEDURE ReadSpecial (self: Special; reader: Pickle.Reader; id: Pickle.RefID ): REFANY RAISES {Pickle.Error, <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = (* Special pickle reader for LiteConfig.PrivateMutex objects. *) BEGIN (* ReadSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN WITH m = NEW(PrivateMutex) DO reader.noteRef(m, id); RETURN m; END; (* with *) ELSE RAISE Pickle.Error("LiteConfig.ReadSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END ReadSpecial; BEGIN (* LiteConfig *) Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); END LiteConfig. From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, February 01, 2010 2:47 PM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] platform-independent packing/alignment? You *might* imagine pickling a mutex, held or not, like to "freeze"/"suspend" a running system, possibly to move to another system, where it is "resumed". But in reality, that won't work. If changing alignment/padding won't break pickles, I again suggest that "max_align" be raised to at least 64 for all architectures. So that double and longint are aligned. Or that max_align be thrown out entirely and have the architectures all declare things correctly..which they likely already are. > recreates the MUTEX in the environment of the reading program Just with "NEW(MUTEX)" right? No attempt to put it back in the same state, I assume. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Mon, 1 Feb 2010 14:37:48 -0500 > Subject: Re: [M3devel] platform-independent packing/alignment? > > For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Monday, February 01, 2010 3:42 AM > To: Mika Nystrom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > > On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > > For what it's worth... > > > > I recall someone (Dragisa?) just complained that he was having problems > > unpickling data structures... > > > > I have never had much luck pickling and unpickling MUTEXes, using a few > > (not very different) M3 compilers. I just leave them out of my pickles. > > It makes the pickles a lot more compatible across versions. I'm not > > talking recent CM3 versions here but a variety of old versions. > > Implementors have seemed to modify MUTEX quite a bit. What's the point > > of pickling it anyhow? If it's an active mutex the unpickling will > > surely lead to garbage, if there are wait queues and things.. then you > > wind up un/pickling Thread structures too. > > > > Mika > > > > Tony Hosking writes: > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/plain; > > > charset=utf-8 > > > > > >That shouldn't affect things since the pickler picks apart the = > > >structures and ships the individual primitives. Right? > > > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > > > >> Let's say I have: > > >> =20 > > >> =20 > > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > > >> =20 > > >> =20 > > >> And I have a platform with max_align =3D 32 and a platform with = > > >max_align =3D 64. > > >> One platform will make FOOA be 24 bytes, the other 32. > > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > > >won't. > > >> Can that pickle be read/written by the two platforms? > > >> And how does the code know/detect the difference? > > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > > >pickle code work just > > >> as well on the "same" platform as on the "different" platforms? > > >> =20 > > >> =20 > > >> I very recently changed NT386 max_align from 32 to 64, and I believe > > >> the remaining active platforms with max_align =3D 32 should also be = > > >64. > > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > > >> as "lining up" such structs with C. > > >> =20 > > >> =20 > > >> Such alignment shold make us not need the extra "unaligned double" = > > >switch > > >> on most platforms (some mystery still on some platforms) as well as > > >> perhaps be needed for some atomic operations, esp. maybe on > > >> LONGINT on 32bit x86. > > >> =20 > > >> =20 > > >> - Jay > > >>=20 > > >> =20 > > >> > From: dragisha at m3w.org > > >> > To: rodney_bates at lcwb.coop > > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > > >> >=20 > > >> > I've not changed my code, that is for sure.... But now I am not sure > > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > > >take > > >> > a look on this again sometime soon and report my findings. > > >> >=20 > > >> > Thanks for clues. > > >> >=20 > > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > >> > >=20 > > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > > >> > > > I've asked this before, but didn't catch answer: > > >> > > >=20 > > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> > > >> I suggest we can probably get by with platform-independent > > >> > > >> packing/alignment settings. > > >> > > >=20 > > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > > >program > > >> > > > does not read that pickle anymore....=20 > > >> > >=20 > > >> > > And you are certain your program that tries to read still contains > > >> > > exact structurally equivalent types to all the types in the = > > >pickle? > > >> > >=20 > > >> > > >=20 > > >> > > > Someone remembers moment when this incompatible changes were = > > >made?=20 > > >> > --=20 > > >> > Dragi=C5=A1a Duri=C4=87 > > >> >=20 > > > > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/html; > > > charset=utf-8 > > > > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > > >after-white-space; ">That shouldn't affect things since the pickler = > > >picks apart the structures and ships the individual primitives. = > > > Right?
> > >
On 1 Feb 2010, at 02:41, Jay K wrote:

> >class=3D"Apple-interchange-newline">
> >class=3D"Apple-style-span" style=3D"border-collapse: separate; = > > >font-family: Helvetica; font-size: medium; font-style: normal; = > > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > > >white-space: normal; widows: 2; word-spacing: 0px; = > > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > > >auto; -webkit-text-stroke-width: 0px; ">
> >style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > > >FOO;
 
 
And I have a platform with max_align = > > >=3D 32 and a platform with max_align =3D 64.
One platform will = > > >make FOOA be 24 bytes, the other 32.
  One platform will = > > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > > >pickle be read/written by the two platforms?
And how does the code = > > >know/detect the difference?
That is, if a platform changed from = > > >max_align =3D 32 to 64, would the pickle code work just
as = > > >well on the "same" platform as on the "different" = > > >platforms?
 
 
I very recently changed NT386 = > > >max_align from 32 to 64, and I believe
the remaining active platforms = > > >with max_align =3D 32 should also be 64.
It would "only" affect = > > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > > >structs with C.
 
 
Such alignment shold make us not = > > >need the extra "unaligned double" switch
on most platforms (some = > > >mystery still on some platforms) as well as
perhaps be needed for = > > >some atomic operations, esp. maybe on
LONGINT on 32bit = > > >x86.
 
 
 - Jay

 
> From: > >class=3D"Apple-converted-space">  > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: > >class=3D"Apple-converted-space">  > >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: > >class=3D"Apple-converted-space">  > >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > > >Subject: Re: [M3devel] platform-independent = > > >packing/alignment?
> > >class=3D"Apple-converted-space"> 
> I've not changed = > > >my code, that is for sure.... But now I am not sure
> some parent = > > >type (esp MUTEX here an there) was not changed... I'll take
> a = > > >look on this again sometime soon and report my findings.
> > >class=3D"Apple-converted-space"> 
> Thanks for = > > >clues.
> 
> = > > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > > >> 
> > = > > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > > >but didn't catch answer:
> > > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > > >we can probably get by with platform-independent
> > >> = > > >packing/alignment settings.
> > > > >class=3D"Apple-converted-space"> 
> > > Some = > > >time ago I've used pickles (CM3) to save some data... My program
> = > > >> > does not read that pickle anymore.... > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > And you are = > > >certain your program that tries to read still contains
> > = > > >exact structurally equivalent types to all the types in the = > > >pickle?
> > > >class=3D"Apple-converted-space"> 
> > > > >class=3D"Apple-converted-space"> 
> > > Someone = > > >remembers moment when this incompatible changes were made? > >class=3D"Apple-converted-space"> 
> -- > >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > > >Duri=C4=87 < > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> > >class=3D"Apple-converted-space"> 
 > >>

= > > > > > >--Apple-Mail-4--1058110347-- > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 1 21:23:53 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 14:23:53 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1265013708.4240.16.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> <1265013708.4240.16.camel@faramir.m3w.org> Message-ID: <4B673859.8070405@lcwb.coop> One thing I recall is that there are about 3 signatures for some builtin types that are hard-coded as constants rather than computed, and pm3 vs. cm3 pickles have them with values differing in some rather bizarre byte-ordering differences. In at least one of them, the order was also inconsistent with the general algorithm used to construct most signatures. As I recall, I fixed cm3 pickles to recognize/read both sets of signature values. So if you are using recent pickle code from cm3, this would not be the cause of your problem, nor would it be if you have not written a pickle in pm3-compiled code and tried to read it in cm3-compiled code. I also recall putting in some better messages when things failed, such as giving the value of an unrecognized signature. Do you get any interesting messages when pickle reading fails? Dragi?a Duri? wrote: > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > From Highjinks at gmx.com Wed Feb 3 00:33:40 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 00:33:40 +0100 (CET) Subject: [M3devel] Shorthand type declarations? Message-ID: <20100202193708.97d69f8c.Highjinks@gmx.com> Alright, I'm finally getting the hang of things. One quick question.. Is there a shorthand for declaring a whole bunch of types as one type? i.e.... TYPE Window, Pixmap, Cursor = unsigned_int; Or something similiar? Doing this TYPE Window = unsigned_int; Pixmap = unsigned_int; Cursor = unsigned_int; etc... Adds up to whole lot of typing.(No pun intended) Any tips would be most welcome. -- Chris From rodney_bates at lcwb.coop Wed Feb 3 04:37:33 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 02 Feb 2010 21:37:33 -0600 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100202193708.97d69f8c.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> Message-ID: <4B68EF7D.7040009@lcwb.coop> Chris wrote: > Alright, I'm finally getting the hang of things. > > One quick question.. > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > TYPE > Window, Pixmap, Cursor = unsigned_int; > > Or something similiar? > > Doing this > TYPE > Window = unsigned_int; > Pixmap = unsigned_int; > Cursor = unsigned_int; > etc... > Adds up to whole lot of typing.(No pun intended) Unfortunately, this is the shortest you can get. I suppose the language designers thought that, while a whole lot of variables with the same type were a likely case: VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , that more than just a few type names that are synonyms for the same type would not be common. You may think me certifiably masochist, but I go the more longhanded way and write: TYPE Window = unsigned_int; TYPE Pixmap = unsigned_int; TYPE Cursor = unsigned_int; , sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, almost every time. > > Any tips would be most welcome. > From jay.krell at cornell.edu Wed Feb 3 06:28:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 05:28:50 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <4B68EF7D.7040009@lcwb.coop> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop> Message-ID: This is not where Modula-3 falls down due to verbosity. Many C and C++ programmers discourage such terseness: int a, b, c(), d(); typedef int T1, T2; preferring: int a; int b; int c(); int d(); typedef int T1; typedef int T2; Where is falls down, perhaps, is not using curly braces. (And perhaps for gyrations needed for safety, see my recent NTObjFile.m3 changes. Can they be safe and not duplicate code, or only one?) My editor is geared toward curly braces and helps using them tremendously. I can't switch editors. I've tried many times. I find the terseness Modula-3 does allow: PROCEDURE(VAR a, b:INTEGER); TYPE A = RECORD c, d: INTEGER:= 0; END. ambiguous. I don't know if a and b are both VAR. I don't know if c and d both have the initializer. I'd prefer to see: PROCEDURE(VAR a: INTEGER; VAR b:INTEGER); TYPE A = RECORD c: INTEGER := 0; d: INTEGER:= 0; END. (and I'm not sure that is equivalent, but I do know what it means.) (newlines omited in RECORD just for *email brevity*: RECORD should have a newline per field!) I would be in favor of removing all these shorthands from the cm3 tree, and maybe even warning about them. But they surely are all well defined if you know the language well. It is meant to be a small language, but goes a bit too far here I think. - Jay > Date: Tue, 2 Feb 2010 21:37:33 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > > > Chris wrote: > > Alright, I'm finally getting the hang of things. > > > > One quick question.. > > > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > > > TYPE > > Window, Pixmap, Cursor = unsigned_int; > > > > Or something similiar? > > > > Doing this > > TYPE > > Window = unsigned_int; > > Pixmap = unsigned_int; > > Cursor = unsigned_int; > > etc... > > Adds up to whole lot of typing.(No pun intended) > > Unfortunately, this is the shortest you can get. I suppose the language designers > thought that, while a whole lot of variables with the same type were a likely > case: > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > that more than just a few type names that are synonyms for the same type would not be common. > > You may think me certifiably masochist, but I go the more longhanded way and write: > > TYPE Window = unsigned_int; > TYPE Pixmap = unsigned_int; > TYPE Cursor = unsigned_int; , > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > almost every time. > > > > > > Any tips would be most welcome. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 3 09:37:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Feb 2010 03:37:52 -0500 Subject: [M3devel] Shorthand type declarations? In-Reply-To: References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop> Message-ID: <6E17449F-8762-4AA0-951A-0D3455432A3F@cs.purdue.edu> On 3 Feb 2010, at 00:28, Jay K wrote: > This is not where Modula-3 falls down due to verbosity. > > > Many C and C++ programmers discourage such terseness: > int a, b, c(), d(); > typedef int T1, T2; > > > preferring: > int a; > int b; > int c(); > int d(); > typedef int T1; > typedef int T2; > > > Where is falls down, perhaps, is not using curly braces. > (And perhaps for gyrations needed for safety, see my recent NTObjFile.m3 changes. > Can they be safe and not duplicate code, or only one?) > > > My editor is geared toward curly braces and helps using them tremendously. > I can't switch editors. I've tried many times. ... emacs... :-) > I find the terseness Modula-3 does allow: > PROCEDURE(VAR a, b:INTEGER); Both are VAR. VAR distributes over the list. > TYPE A = RECORD c, d: INTEGER:= 0; END. They both get 0. := distributes over the list. > ambiguous. > > I don't know if a and b are both VAR. > I don't know if c and d both have the initializer. > I'd prefer to see: > PROCEDURE(VAR a: INTEGER; VAR b:INTEGER); > TYPE A = RECORD c: INTEGER := 0; d: INTEGER:= 0; END. > > > (and I'm not sure that is equivalent, but I do know what it means.) > (newlines omited in RECORD just for *email brevity*: RECORD should have a newline per field!) > > I would be in favor of removing all these shorthands from the cm3 tree, > and maybe even warning about them. But they surely are all well defined > if you know the language well. It is meant to be a small language, > but goes a bit too far here I think. I've never really found this to be the case. Perhaps because I learnt to program in Pascal. > > > - Jay > > > > Date: Tue, 2 Feb 2010 21:37:33 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Shorthand type declarations? > > > > > > > > Chris wrote: > > > Alright, I'm finally getting the hang of things. > > > > > > One quick question.. > > > > > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > > > > > TYPE > > > Window, Pixmap, Cursor = unsigned_int; > > > > > > Or something similiar? > > > > > > Doing this > > > TYPE > > > Window = unsigned_int; > > > Pixmap = unsigned_int; > > > Cursor = unsigned_int; > > > etc... > > > Adds up to whole lot of typing.(No pun intended) > > > > Unfortunately, this is the shortest you can get. I suppose the language designers > > thought that, while a whole lot of variables with the same type were a likely > > case: > > > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > > > that more than just a few type names that are synonyms for the same type would not be common. > > > > You may think me certifiably masochist, but I go the more longhanded way and write: > > > > TYPE Window = unsigned_int; > > TYPE Pixmap = unsigned_int; > > TYPE Cursor = unsigned_int; , > > > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > > almost every time. > > > > > > > > > > Any tips would be most welcome. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Feb 3 09:59:12 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 09:59:12 +0100 (CET) Subject: [M3devel] Shorthand type declarations? In-Reply-To: <4B68EF7D.7040009@lcwb.coop> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> Message-ID: <20100203050242.0a7e924b.Highjinks@gmx.com> On Tue, 02 Feb 2010 21:37:33 -0600 "Rodney M. Bates" wrote: > > > > Unfortunately, this is the shortest you can get. I suppose the language designers > thought that, while a whole lot of variables with the same type were a likely > case: > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > that more than just a few type names that are synonyms for the same type would not be common. > > You may think me certifiably masochist, but I go the more longhanded way and write: > > TYPE Window = unsigned_int; > TYPE Pixmap = unsigned_int; > TYPE Cursor = unsigned_int; , > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > almost every time. > > The reason I asked is because I'm doing the interface for /usr/include/xcb/xproto.h There are a lot of of typedefs in there that are defined as the same base type. I've shortened the Iterator types by using... TYPE T = UNTRACED ROOT OBJECT END; TYPE XCB_Iterator = T OBJECT Rem : INTEGER; Index : INTEGER END; TYPE XCBAtom = unsigned_int; TYPE Atom_Iterator = XCB_Iterator OBJECT Atom_Data : UNTRACED REF XCBAtom; END; But even this is gonna kill me. Heh. xproto.h is a HUGE file. -- Chris From wagner at elegosoft.com Wed Feb 3 09:59:45 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 03 Feb 2010 09:59:45 +0100 Subject: [M3devel] m3gdb build on AMD64_FREEBSD Message-ID: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Any chance to make m3gdb build on 64 bit FreeBSD? This is the only package that's still failing on that platform: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText (search for m3gdb in the listing) A quick look doesn't really enlighten me as to what is wrong... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 3 10:18:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 03 Feb 2010 10:18:14 +0100 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203050242.0a7e924b.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> Message-ID: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Quoting Chris : > On Tue, 02 Feb 2010 21:37:33 -0600 > "Rodney M. Bates" wrote: > >> Unfortunately, this is the shortest you can get. I suppose the >> language designers >> thought that, while a whole lot of variables with the same type >> were a likely >> case: >> >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , >> >> that more than just a few type names that are synonyms for the same >> type would not be common. >> >> You may think me certifiably masochist, but I go the more >> longhanded way and write: >> >> TYPE Window = unsigned_int; >> TYPE Pixmap = unsigned_int; >> TYPE Cursor = unsigned_int; , >> >> sacrificing writeability in favor of readability. (Yes, I repeat >> VAR and CONST too, >> almost every time. > > The reason I asked is because I'm doing the interface for > /usr/include/xcb/xproto.h > > There are a lot of of typedefs in there that are defined as the same > base type. > > I've shortened the Iterator types by using... > > TYPE T = UNTRACED ROOT OBJECT END; > TYPE XCB_Iterator = T OBJECT > Rem : INTEGER; > Index : INTEGER > END; > > TYPE XCBAtom = unsigned_int; > TYPE Atom_Iterator = XCB_Iterator OBJECT > Atom_Data : UNTRACED REF XCBAtom; > END; > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. What exactly is gained by defining all those aliases for unsigned_int? In M3 all the types are structurally equivalent, so you can use a Cursor where a Window would be required etc. It looks like a bit of facelifting to me. And if it's only for readability and proper naming, all those should surely be named Handle, shouldn't they? The same level of abstraction could be achieved by defining just one XProtoHandle as unsigned_int, couldn't it? I think I just have never understood the usefulness of interfaces too large to remember, but that may be a general problem with X... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 3 12:45:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:45:12 +0000 Subject: [M3devel] m3gdb build on AMD64_FREEBSD In-Reply-To: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> References: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Message-ID: I haven't looked but maybe we need a newer gdb? Personally I wish we could output enough information so that regular gdb could work better... Also we shouldn't bother mangling acceptable identifiers when there is no clash.. - Jay > Date: Wed, 3 Feb 2010 09:59:45 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3gdb build on AMD64_FREEBSD > > Any chance to make m3gdb build on 64 bit FreeBSD? > This is the only package that's still failing on that platform: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText > > (search for m3gdb in the listing) > > A quick look doesn't really enlighten me as to what is wrong... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 3 12:55:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:55:22 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: > so you can use a Cursor where a Window would be required etc Win32 does opaque unique types something like: #define DECLARE_HANDLE(foo) struct tag##foo; typedef struct tag##foo* foo; DECLARE_HANDLE(HWND) DECLARE_HANDLE(HCURSOR) DECLARE_HANDLE(HRGN) DECLARE_HANDLE(HPEN) Some of the objects are indeed "bases" of others, but that can't be easily captured. It gets documented and you can cast. And then opaque non-unique is also common: typedef void* HANDLE; That is used for files, events, mutexes, semaphores, processes, threads, etc. And there is a lot of commonality. They all work with CloseHandle, WaitForSingleObject, WaitForMultipleObjects, DuplicateHandle, etc. - Jay > Date: Wed, 3 Feb 2010 10:18:14 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > Quoting Chris : > > > On Tue, 02 Feb 2010 21:37:33 -0600 > > "Rodney M. Bates" wrote: > > > >> Unfortunately, this is the shortest you can get. I suppose the > >> language designers > >> thought that, while a whole lot of variables with the same type > >> were a likely > >> case: > >> > >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > >> > >> that more than just a few type names that are synonyms for the same > >> type would not be common. > >> > >> You may think me certifiably masochist, but I go the more > >> longhanded way and write: > >> > >> TYPE Window = unsigned_int; > >> TYPE Pixmap = unsigned_int; > >> TYPE Cursor = unsigned_int; , > >> > >> sacrificing writeability in favor of readability. (Yes, I repeat > >> VAR and CONST too, > >> almost every time. > > > > The reason I asked is because I'm doing the interface for > > /usr/include/xcb/xproto.h > > > > There are a lot of of typedefs in there that are defined as the same > > base type. > > > > I've shortened the Iterator types by using... > > > > TYPE T = UNTRACED ROOT OBJECT END; > > TYPE XCB_Iterator = T OBJECT > > Rem : INTEGER; > > Index : INTEGER > > END; > > > > TYPE XCBAtom = unsigned_int; > > TYPE Atom_Iterator = XCB_Iterator OBJECT > > Atom_Data : UNTRACED REF XCBAtom; > > END; > > > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. > > What exactly is gained by defining all those aliases for unsigned_int? > In M3 all the types are structurally equivalent, so you can use a Cursor > where a Window would be required etc. It looks like a bit of facelifting > to me. > > And if it's only for readability and proper naming, all those should > surely be named Handle, shouldn't they? > > The same level of abstraction could be achieved by defining just one > XProtoHandle as unsigned_int, couldn't it? > > I think I just have never understood the usefulness of interfaces > too large to remember, but that may be a general problem with X... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 3 12:51:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:51:32 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: Chris many of the X headers these days are generated from XML using Python. Seriously -- you need Python to build X these days. You should look into adding a little to that system for Modula-3. Cloning headers is tedious, therefore error-prone, therefore a recipe for bugs. Please try to avoid it. If you really can't go the XML route, there is also a fork of gcc that is supposed to be adequate for header parsing, and spits out XML. Look for "gccxml" or such. Maybe it is old/dead now? There is also swig, which is a partial C compiler. Not a great idea to attempt. But it is there, you might try it. I'd be far more interested in wrapping Qt than X though... - Jay > Date: Wed, 3 Feb 2010 10:18:14 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > Quoting Chris : > > > On Tue, 02 Feb 2010 21:37:33 -0600 > > "Rodney M. Bates" wrote: > > > >> Unfortunately, this is the shortest you can get. I suppose the > >> language designers > >> thought that, while a whole lot of variables with the same type > >> were a likely > >> case: > >> > >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > >> > >> that more than just a few type names that are synonyms for the same > >> type would not be common. > >> > >> You may think me certifiably masochist, but I go the more > >> longhanded way and write: > >> > >> TYPE Window = unsigned_int; > >> TYPE Pixmap = unsigned_int; > >> TYPE Cursor = unsigned_int; , > >> > >> sacrificing writeability in favor of readability. (Yes, I repeat > >> VAR and CONST too, > >> almost every time. > > > > The reason I asked is because I'm doing the interface for > > /usr/include/xcb/xproto.h > > > > There are a lot of of typedefs in there that are defined as the same > > base type. > > > > I've shortened the Iterator types by using... > > > > TYPE T = UNTRACED ROOT OBJECT END; > > TYPE XCB_Iterator = T OBJECT > > Rem : INTEGER; > > Index : INTEGER > > END; > > > > TYPE XCBAtom = unsigned_int; > > TYPE Atom_Iterator = XCB_Iterator OBJECT > > Atom_Data : UNTRACED REF XCBAtom; > > END; > > > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. > > What exactly is gained by defining all those aliases for unsigned_int? > In M3 all the types are structurally equivalent, so you can use a Cursor > where a Window would be required etc. It looks like a bit of facelifting > to me. > > And if it's only for readability and proper naming, all those should > surely be named Handle, shouldn't they? > > The same level of abstraction could be achieved by defining just one > XProtoHandle as unsigned_int, couldn't it? > > I think I just have never understood the usefulness of interfaces > too large to remember, but that may be a general problem with X... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Feb 3 20:08:05 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 03 Feb 2010 13:08:05 -0600 Subject: [M3devel] m3gdb build on AMD64_FREEBSD In-Reply-To: References: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Message-ID: <4B69C995.4010902@lcwb.coop> Jay K wrote: > I haven't looked but maybe we need a newer gdb? If you mean stock gdb, you can use the latest available. If you mean an m3gdb derived from a later gdb, that has been on my list for a while. Maybe when gdb 7.1 is out (very soon) and I am through moving house and get my old one sold (who knows?) Having done this, I think three times, I can say it will be quit a bit of work, and it looks like there are more/bigger changes to gdb than ever before, especially reverse debugging, which would be really nice. > Personally I wish we could output enough information > so that regular gdb could work better... There is very little room for improvement in just changing/ expanding the debug output produced by the compiler. To get much of anything at all would involve changing the debug info format from stabs (very old, cobbled up, and limited) to dwarf-2 (apparently the best now in use). I am even prepared for the possibility that the latest gdb will have dropped stabs altogether. This is also a big job. I have been thinking about it for a long time. But it still can't do all that much using stock gdb. > Also we shouldn't bother mangling acceptable identifiers when > there is no clash.. Having separate compilation, there are many cases where it would be impossible for the compiler to know whether there are clashes or not. Also, I'm not sure how feasible it would be to remove the uid portion from mangled variable names, given Modula-3's structural type rules. Maybe dwarf-2 would allow it to work. > > - Jay > > > Date: Wed, 3 Feb 2010 09:59:45 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3gdb build on AMD64_FREEBSD > > > > Any chance to make m3gdb build on 64 bit FreeBSD? > > This is the only package that's still failing on that platform: > > > > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText > > > > (search for m3gdb in the listing) > > > > A quick look doesn't really enlighten me as to what is wrong... > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Wed Feb 3 21:49:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 20:49:30 +0000 Subject: [M3devel] NT386 int64/longint Message-ID: I've actually been able to compile a fair amount of code now, and at a very cursory glance, it looks reasonably correct. e.g. all of m3core -- including the long/word stuff and Convert.m3. This is using an approach where I "split" operands and then loop over the parts. Variables become two variables. Registers become two registers. Immediates become two immediates. However I seem unable to get the bookkeeping within the backend correct. I had to remove various asserts. Not great. In some places I believe more asserts are clearly correct, but yet they fail when I put them in. Some of the asserts are suspicous to me and further investigation makes me suspicious of some of the existing code in m3back. But I'm not very confident here. I'd have to demonstrate incorrect codegen before making changes. For example the first releaseall in call_indirect seems wrong. It seems like releaseall should only be called when the virtual stack must be empty. But it always has depth at least one there. The second one seems correct. I think it is also overkill in that it need only release volatile registers. I'm also not sure if the virtual stack should really even be empty there. Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2). Perhaps there are assumptions regarding how the front end works. For example I have various add/mult/div making function calls and that seems to be unexpected. I'm also not sure why in_proc_call is limited to two. And, why that is enforced with an assert instead of a subrange. Perhaps I can model int64/longint mostly as a struct. I'll look into that. Or maybe I can somewhat "start over" with the current approach. What is already commited is very safe and conservative and a useful step, depending on what the end result is. One of the problems with the current approach is that if we zero extend a 32bit cardinal, we waste a register for the upper half zero. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Feb 3 22:10:58 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 22:10:58 +0100 (CET) Subject: [M3devel] Shorthand type declarations? In-Reply-To: References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: <20100203171429.533b2e69.Highjinks@gmx.com> On Wed, 3 Feb 2010 11:51:32 +0000 Jay K wrote: > > Chris many of the X headers these days are generated from XML using Python. > > Seriously -- you need Python to build X these days. > > You should look into adding a little to that system for Modula-3. > > Cloning headers is tedious, therefore error-prone, therefore a recipe for bugs. > > Please try to avoid it. > If you really can't go the XML route, there is also a fork of gcc > > that is supposed to be adequate for header parsing, and spits out XML. > > Look for "gccxml" or such. Maybe it is old/dead now? I've never really done much in the way of autogenerating Interfaces and such. Perhaps now is the time for me to look into it. > > > There is also swig, which is a partial C compiler. > > Not a great idea to attempt. > > But it is there, you might try it. > > > > I'd be far more interested in wrapping Qt than X though... Oh, dont worry, QT will get a binding, as will GTK. If not by me, then someone else will do it. The reason I'm doing this interface to XCB is because that is the way X is moving. Future applications will depend less and less on XLib and more on XCB. Also, I dont use QT, or GTK. There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, wxWindows, etc... I'm starting out with XCB, Cairo/Pango, XKB for X. The OpenGL binding will be updated next, along with it's GLX and GLUT bindings. These are the basic X Libs that lots of other X apps depend on. Then I'll start doing QT/GTK(if someone hasnt already beaten me to it. Nice thing with QT and GTK is that they are in fact cross platform. Therefor I wouldn't classify them as "X Windows" bindings. Just as GUI toolkits. Nice ones at that. Whoa! I've got ALOT of work to do. Be back soon. -- Chris From hendrik at topoi.pooq.com Wed Feb 3 22:51:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 3 Feb 2010 16:51:56 -0500 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203171429.533b2e69.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> <20100203171429.533b2e69.Highjinks@gmx.com> Message-ID: <20100203215156.GA20509@topoi.pooq.com> On Wed, Feb 03, 2010 at 10:10:58PM +0100, Chris wrote: > On Wed, 3 Feb 2010 11:51:32 +0000 > Jay K wrote: > > There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, > wxWindows, etc... wxWindows is more than a UI toolkit; it's a complete environment for writing cross-platform C (or is it C++) programs -- right down to specifying how you have to write your main program. I think Modula 3 already provides a main program on Windows, right? -- hendrik From jay.krell at cornell.edu Wed Feb 3 23:09:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 22:09:45 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203215156.GA20509@topoi.pooq.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com>, , <20100203171429.533b2e69.Highjinks@gmx.com>, <20100203215156.GA20509@topoi.pooq.com> Message-ID: I think that is a lesser concern. I think a larger issue is what the binding should look like and if it can be generated. And if we import the library into our tree (probably not). And then how we configure, like, is the thing on the system. Do we generate the headers in the build? Maybe. That is good in that they match and don't go stale. Bad in that it hurts cross builds. Possibly generate, checkin, and then regenerate if possible and compare to what is checked in. (But now I've digressed to lesser concerns as well. The important part is figuring out what the binding should look like and how to generate it. Less important how often to regenerate it.) Of course Modula-3 provides main. Likely wxWindows doesn't absolutely require special main. Likely any binding can just have you add some function call from your Modula-3 main. Absolute terrible worst case if you can teach the Modula-3 compiler to not provide main. In fact that's not a bad idea for other reasons -- for better interop with existing code. Basically we should have a flag to RTLinker__InitRuntime that specifies if it returns or runs Main__M3(1) or however that works. Or an alternate RTLinker__InitRuntimeEx. wxWindows is C++. There are Python bindings. These libraries often provide cross-platform threading/synchronization, I/O, etc. And sometimes IDEs, right. There are many such efforts. Any binding effort imho could limit itself to just the gui parts. The other parts ok, but I'm suspicious that Modula-3's container/string/i/o/threading libraries aren't so bad/ugly, whereas its GUI library at least looks awful and Olaf says the Win32 port is incomplete, so more work merited there it seems vs. other library parts. - Jay ---------------------------------------- > Date: Wed, 3 Feb 2010 16:51:56 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > On Wed, Feb 03, 2010 at 10:10:58PM +0100, Chris wrote: >> On Wed, 3 Feb 2010 11:51:32 +0000 >> Jay K wrote: >> >> There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, >> wxWindows, etc... > > wxWindows is more than a UI toolkit; it's a complete environment for > writing cross-platform C (or is it C++) programs -- right down to > specifying how you have to write your main program. > > I think Modula 3 already provides a main program on Windows, right? > > -- hendrik From jay.krell at cornell.edu Fri Feb 5 13:21:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Feb 2010 12:21:10 +0000 Subject: [M3devel] NT386 int64/longint Message-ID: nevermind, it's looking much better now. A few more days though. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: NT386 int64/longint Date: Wed, 3 Feb 2010 20:49:30 +0000 I've actually been able to compile a fair amount of code now, and at a very cursory glance, it looks reasonably correct. e.g. all of m3core -- including the long/word stuff and Convert.m3. This is using an approach where I "split" operands and then loop over the parts. Variables become two variables. Registers become two registers. Immediates become two immediates. However I seem unable to get the bookkeeping within the backend correct. I had to remove various asserts. Not great. In some places I believe more asserts are clearly correct, but yet they fail when I put them in. Some of the asserts are suspicous to me and further investigation makes me suspicious of some of the existing code in m3back. But I'm not very confident here. I'd have to demonstrate incorrect codegen before making changes. For example the first releaseall in call_indirect seems wrong. It seems like releaseall should only be called when the virtual stack must be empty. But it always has depth at least one there. The second one seems correct. I think it is also overkill in that it need only release volatile registers. I'm also not sure if the virtual stack should really even be empty there. Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2). Perhaps there are assumptions regarding how the front end works. For example I have various add/mult/div making function calls and that seems to be unexpected. I'm also not sure why in_proc_call is limited to two. And, why that is enforced with an assert instead of a subrange. Perhaps I can model int64/longint mostly as a struct. I'll look into that. Or maybe I can somewhat "start over" with the current approach. What is already commited is very safe and conservative and a useful step, depending on what the end result is. One of the problems with the current approach is that if we zero extend a 32bit cardinal, we waste a register for the upper half zero. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 6 13:29:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Feb 2010 12:29:39 +0000 Subject: [M3devel] front end function about a "virtual stack" Message-ID: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 6 19:07:23 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 6 Feb 2010 13:07:23 -0500 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: References: Message-ID: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: > Tony, can you confirm something? > It's hard to explain. > > > The NT36 backend of course maintains > a bunch of information as to which registers are in use. > > > For example, at the start of the function, it > marks all registers as not in use. > (It always preserves all volatile registers I believe. > Obviously it could do better. It should only > mark non-volatile registers as in use, see > which registers it uses in the function, and > then only preserve/restore the nonvolatile ones > that it uses.) > > > As well when it generates a function call it > marks them as all not in use too. > But in that case, it checks itself. > Again, it is a bit dumb -- nonvolatile registers > would be ok to still be in use. > > > Now, all is ok. > But then, I've introduced function calls where > they weren't before -- multiply, divide, mod etc. > > > Upon generating the call to mod (for example), > I get an assertion failure, because registers > are still in use. In this case it is a nonvolatile > register, but I think that's largely luck. > > > In particular I think the location that > will be stored to after the mod is in a register. > That is reasonable. > You know..as a compiler, given: > *(a + b) = f(); > > > you might generate code to evaluate a + b first, > put it in a (non volatile) register, then call f(), > or you might call f() first. > > > A simpler approach is to call all the functions first, > so you have more easy use of registers. > > > But then imagine > *(a + b) = (c % d); > > > is there a function call in there or not? > It depends. > > > So then my question is, like, when does the > frontend assume a "stack based code generator"'s > stack can/should/will be empty? > Does it endeavor to make it so? > > > That is, is it very reasonable to for the NT386 > backend to assume its stack is empty when > it calls a function, because the front end > colludes to make it so, but then > the front end doesn't do similar for things > like multiply/divide? > > > I can deal with this pretty easily either way. > Around function calls I introduce that weren't > previously there I can save whatever volatile > registers are in use. > > > But I'd like to understand. > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 07:49:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 06:49:11 +0000 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> References: , <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> Message-ID: > But, there have always been calls for mod/div Not on NT386. - Jay Subject: Re: front end function about a "virtual stack" From: hosking at cs.purdue.edu Date: Sat, 6 Feb 2010 13:07:23 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 08:02:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 07:02:24 +0000 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> References: , <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> Message-ID: I think I have this aspect dealt with now. Convert.m3: -----LINE 129 ----- load tv.25[_nDigits] 0 Int.32 Int.32 check_range 0 n:8,x:0,0,0,0,0,0,0,0 64 n:4,x:40,0,0,0,0,0,0,0 2 00000435: 8B5DFC MOV EBX tv.25[_nDigits] 00000438: 83FB40 CMP EBX $64 0000043B: 7600 JBE rel8 L.68 0000043D: B822100000 MOV EAX $4130 00000442: E800000000 CALL L.0 loophole Int.32 Int.32 load_address tv.31[_result] 0 00000447: 8D75AE LEA ESI tv.31[_result] swap Int.32 Addr index_address Int.32 1 0000044A: 03F3 ADD ESI EBX ** result location in ESI * load tv.35[_base] 0 Word.8 Int.32 loophole Int.32 Int.64 0000044C: 33D2 XOR EDX EDX 0000044E: 8A5514 MOV EDX tv.35[_base]:Word.8 00000451: 33FF XOR EDI EDI load tv.34[_value] 0 Int.64 Int.64 swap Int.64 Int.64 mod Int.64 X P call_64 m3_mod64 2 import_procedure m3_mod64 2 Int.64 "__stdcall" p.31[m3_mod64] declare_param * 8 8 Word.64 0 F F 100 tv.201[T$201] 8 declare_param * 8 8 Word.64 0 F F 100 tv.202[T$202] 16 start_call_direct p.31[_m3_mod64 at 16] 0 Int.64 load_stack_param Word.64 1 00000453: 8B4D0C MOV ECX tv.34[_value] 00000456: 8B4510 MOV EAX tv.34[_value]+4 00000459: 50 PUSH EAX 0000045A: 51 PUSH ECX load_stack_param Word.64 0 0000045B: 57 PUSH EDI 0000045C: 52 PUSH EDX declare_temp 4 4 Addr F tv.203[T$203] -92 0000045D: 8975A4 MOV tv.203[T$203] ESI ** ESI saved unnecessarily in temporary to satisfy us ** call_direct p.31[_m3_mod64 at 16] Int.64 00000460: FF1500000000 CALL p.31[_m3_mod64 at 16] loophole Int.64 Int.32 loophole Int.32 Int.32 load_address gv.2[_MM_Convert] 52 00000466: 8D3534000000 LEA ESI gv.2[_MM_Convert]+52 swap Int.32 Addr index_address Int.32 1 0000046C: 03F0 ADD ESI EAX load_indirect 0 Word.8 Int.32 0000046E: 33DB XOR EBX EBX 00000470: 8A5E00 MOV EBX ESI^[0:Word.8] store_indirect 0 Int.32 Word.8 00000473: 8B75A4 MOV ESI tv.203[T$203]:Addr ** ESI refetched from temporary ** free_temp tv.203[T$203] 00000476: 885E00 MOV ESI^[0:Word.8] EBX -----LINE 130 ----- Pretty wasteful. Instead it should just compute the destination when it does the store. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: front end function about a "virtual stack" Date: Sun, 7 Feb 2010 06:49:11 +0000 > But, there have always been calls for mod/div Not on NT386. - Jay Subject: Re: front end function about a "virtual stack" From: hosking at cs.purdue.edu Date: Sat, 6 Feb 2010 13:07:23 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:08:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:08:11 +0000 Subject: [M3devel] initializing LONGINT doesn't work Message-ID: Maybe not fully up to date, Linux/x86: jay at xlin2:~/t$ cat src/Main.m3 MODULE Main; VAR a := 1L; BEGIN END Main. jay at xlin2:~/t$ /cm3/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Main.m3 "../src/Main.m3", line 3: warning: not used (a) "../src/Main.m3", line 1: ** INTERNAL CG ERROR *** unable to stuff bit field val ue?? *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/misc/CG.m3", line 1013 *** Aborted jay at xlin2:~/t$ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:09:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Message-ID: Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:16:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: Message-ID: Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:39:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:39:25 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: , Message-ID: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 16:12:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 15:12:13 +0000 Subject: [M3devel] NT386 longint=64bits In-Reply-To: <20100207150232.B9F282474001@birch.elegosoft.com> References: <20100207150232.B9F282474001@birch.elegosoft.com> Message-ID: LONGINT on NT386 is now 64bits. It could use more testing. See m3-sys\m3tests\src\p2\p227. Add more there. Try it on NT386 and others. Disassemble the output (or use cm3 -debug and look at the *log (not *.log) files in the output directory, very useful). It doesn't run in the automated runs though, yet. There are two known problems: converting between INTEGER and LONGINT doesn't sign extend I'm not sure if LONGINT to INTEGER range checks either. In fact I didn't test any of the range checking, but it layers on top of simple compares. You cannot initialize a global LONGINT to other than 0; this bug is on all platforms. I'm hoping Tony fixes that. I think I need to make a change in m3back for this too though, to use the change I put in m3objfile (append vs. appendBytes). It'd be nifty if the front end could deal with the conversion. Generate the compares to 0, oring with FFFFFFFF00000... But I'll get to before too long either way. There are also obvious missing optimizations, some of which are easily fixed, some are not. In particular, some of the code is in the "wrong" place, such as to miss out on constant folding. Including division by constants. The fix is just to move the code later after constant cases are handled. I'll get to this stuff before too long. There are a few "support" functions. For example 64bit multiply calls out to a function. If you do a 64bit multiply in C, that calls a function too. We call the same function, where applicable. And m3core/src/Csupport/Common/hand.c has a few functions. I'm particularly nervous about extract/insert, but they seem to work. If you find a problem and really must go back to 32bit LONGINT, see the change below in Target.m3. Maybe make it a command line option. - Jay > Date: Sun, 7 Feb 2010 16:02:32 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/02/07 16:02:32 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > and bang: longint is now 64bits on NT386 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 7 19:55:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 13:55:13 -0500 Subject: [M3devel] atomic problem In-Reply-To: References: , Message-ID: <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: > ok, better now, but: > > == package /home/jay/dev2/cm3/m3-sys/m3staloneback == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - > DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in LINUXLIBC6 --- > ignoring ../src/m3overrides > new source -> compiling Main.m3 > -> linking m3back > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_xor_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:16:45 +0000 > Subject: Re: [M3devel] atomic problem > > Probably an out of date m3cg. > I'll see. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:09:57 +0000 > Subject: [M3devel] atomic problem > > Could be I'm out of date or building in the wrong order. > I'll maybe dig into it. > Linux/x86: > > new source -> compiling AtomicWideChar.m3 > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW > ideChar__Load': > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler > error: in expand_expr_real_1, at expr.c:7290 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc > new source -> compiling hand.c > new source -> compiling dtoa.c > new source -> compiling libgcc.c > new source -> compiling RTIOc.c > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 20:08:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 19:08:27 +0000 Subject: [M3devel] atomic problem In-Reply-To: <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> References: , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> Message-ID: It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. We can probably adjust m3cc/m3makefile. The platforms.quake file won't do, since native builds don't use it. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 13:55:13 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 7 20:32:44 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 14:32:44 -0500 Subject: [M3devel] atomic problem In-Reply-To: References: , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> Message-ID: I think -march=native works too assuming you are on a modern x86. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 14:08, Jay K wrote: > It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. > Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. > We can probably adjust m3cc/m3makefile. > The platforms.quake file won't do, since native builds don't use it. > > - Jay > > From: hosking at cs.purdue.edu > Date: Sun, 7 Feb 2010 13:55:13 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] atomic problem > > -march=i686 > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 7 Feb 2010, at 08:39, Jay K wrote: > > ok, better now, but: > > == package /home/jay/dev2/cm3/m3-sys/m3staloneback == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - > DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in LINUXLIBC6 --- > ignoring ../src/m3overrides > new source -> compiling Main.m3 > -> linking m3back > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_xor_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:16:45 +0000 > Subject: Re: [M3devel] atomic problem > > Probably an out of date m3cg. > I'll see. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:09:57 +0000 > Subject: [M3devel] atomic problem > > Could be I'm out of date or building in the wrong order. > I'll maybe dig into it. > Linux/x86: > > new source -> compiling AtomicWideChar.m3 > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW > ideChar__Load': > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler > error: in expand_expr_real_1, at expr.c:7290 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc > new source -> compiling hand.c > new source -> compiling dtoa.c > new source -> compiling libgcc.c > new source -> compiling RTIOc.c > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 00:51:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 23:51:11 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: , , , , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu>, , Message-ID: I don't like such "non-determinism". Granted, it isn't really non-deterministic. I want to know which other machines things will run on, not just have them run on the machine on which they are built. Building things yourself is nice, but not doing it is also nice too. And not doing it on every machine even if you do build it yourself is nice. Which "reminds", or rather "convinces" me..we should just never do native builds in m3cc and m3gdb. We should pass imho what we believe to be the platform, but with carefully chosing which processor. Gotta test like every platform though. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 14:32:44 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem I think -march=native works too assuming you are on a modern x86. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 14:08, Jay K wrote: It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. We can probably adjust m3cc/m3makefile. The platforms.quake file won't do, since native builds don't use it. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 13:55:13 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 00:59:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 23:59:11 +0000 Subject: [M3devel] 386?486?586?686?etc.? Message-ID: Any opinions/counter-opinions on which processors we should support? Presumably it doesn't vary per platform. Like, it wouldn't be Linux/586 and FreeBSD/486 or such. Unless maybe there is clear data about what the kernels support? The atomic stuff is pushing things to i586. I believe before 486 and possibly 386 worked. 686 is probably reasonable. I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. We might even drop "x87" support and use SSE/SSE2/SSE3? (Trolling for work in m3back? :) ) Or make it a different set of platforms? I686_LINUX? I686SSE2_LINUX? etc.? But I don't like such combinatorial work -- supporting more combinations. Maybe, uh, drop all existing 32bit platforms and go with I686_*?? "Darwin" can pretty much imply modern processors. Assuming Apple hardware...granted, I had Darwin/x86 on non-Apple hardware. None of this makes a huge difference. I mean, in that, there's almost no changes that follow from these decisions. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 8 01:11:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 19:11:02 -0500 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: <29775A29-715B-4BD9-8DDA-EBA6235AB931@cs.purdue.edu> We probably should provide pthread-mutex-based atomics for targets that don't support the intrinsic atomics. Initially, I suggest we simply provide stubs that fail for the gcc-intrinsic functions. Thoughts? I doubt there are any older-than-Pentium processors that we need to worry about. On 7 Feb 2010, at 18:59, Jay K wrote: > Any opinions/counter-opinions on which processors we should support? > Presumably it doesn't vary per platform. > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > Unless maybe there is clear data about what the kernels support? > > > The atomic stuff is pushing things to i586. > I believe before 486 and possibly 386 worked. > 686 is probably reasonable. > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. > > > We might even drop "x87" support and use SSE/SSE2/SSE3? > (Trolling for work in m3back? :) ) > Or make it a different set of platforms? > I686_LINUX? > I686SSE2_LINUX? > etc.? > > > But I don't like such combinatorial work -- supporting more combinations. > Maybe, uh, drop all existing 32bit platforms and go with I686_*?? > > > "Darwin" can pretty much imply modern processors. > Assuming Apple hardware...granted, I had Darwin/x86 on non-Apple hardware. > > None of this makes a huge difference. > I mean, in that, there's almost no changes that follow from these decisions. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Feb 8 04:58:48 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 7 Feb 2010 22:58:48 -0500 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: <20100208035847.GB13743@topoi.pooq.com> On Sun, Feb 07, 2010 at 11:59:11PM +0000, Jay K wrote: > > Any opinions/counter-opinions on which processors we should support? > > Presumably it doesn't vary per platform. > > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > > Unless maybe there is clear data about what the kernels support? > > > > > > The atomic stuff is pushing things to i586. > I believe before 486 and possibly 386 worked. > > 686 is probably reasonable. > > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. I'm still running an old 100 MHz Pentium and using it on a daily basis. Debian has dropped support for the 386 with, as far as I know, no complaints. -- hendrik. From jay.krell at cornell.edu Mon Feb 8 15:03:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Feb 2010 14:03:30 +0000 Subject: [M3devel] hand.c to Modula-3? Message-ID: Just a note that hand.c could be mostly/easily be written in Modula-3 instead of C. The main problem is the names. Might be a fun little project for someone. We should also change the gcc backend to use memcmp instead of set_ne/set_eq. Or even the frontend. (There might be an extra efficiency to be had in that a) we don't need -1/0/+1, just a boolean b) we know it is a whole number of ulongs). Probably set_ne/set_eq are rare though. m3back compares to an empty set often, but it is small and the front end implements small sets as a single integer. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 16:22:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Feb 2010 15:22:21 +0000 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: <20100208035847.GB13743@topoi.pooq.com> References: , <20100208035847.GB13743@topoi.pooq.com> Message-ID: Wow. What for? And with Modula-3? What OS? I think Pentium will be ok. I think ultimately, if people really need, we should have separate targets. As I've been saying, like: I386_FREEBSD_USERTHREADS, I586_FREEBSD, etc. Esp. to enable easier "release engineering", such as when we do more cross builds, adding new targets will be cheaper. But we'd want some sort of system where if nobody downloads and installs and minimally tests a release, it is in some low grade classification. Certain ones we'd test automatically, like whatever we have available in Hudson. -Jay > Date: Sun, 7 Feb 2010 22:58:48 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 386?486?586?686?etc.? > > On Sun, Feb 07, 2010 at 11:59:11PM +0000, Jay K wrote: > > > > Any opinions/counter-opinions on which processors we should support? > > > > Presumably it doesn't vary per platform. > > > > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > > > > Unless maybe there is clear data about what the kernels support? > > > > The atomic stuff is pushing things to i586. > > I believe before 486 and possibly 386 worked. > > > > 686 is probably reasonable. > > > > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. > > I'm still running an old 100 MHz Pentium and using it on a daily basis. > > Debian has dropped support for the 386 with, as far as I know, no > complaints. > > -- hendrik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Feb 10 21:15:18 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 10 Feb 2010 21:15:18 +0100 (CET) Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: On Sun, 7 Feb 2010, Jay K wrote: > We might even drop "x87" support and use SSE/SSE2/SSE3? > ?(Trolling for work in m3back? :) ) > ?Or make it a different set of platforms? > ?? I686_LINUX? > ?? I686SSE2_LINUX? > ?? etc.? The SSE's do not support transcendental functions. But they are nice for basic floating point arithmetic, if you rely on the low precision of the IEEE formats. I assume that this is the reason, why LLVM uses SSE instead of FPU instructions where possible. From jay.krell at cornell.edu Thu Feb 11 09:53:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 08:53:08 +0000 Subject: [M3devel] optimizing for size or speed? Message-ID: There are all kinds of equivalent code sequences. For the maintainer of m3back to chose among. Given for example: int F(int a) { return a << 2; } Visual C++ optimizing for size uses: shl eax, 2 ; 3 bytes optimizing for speed gives: add eax, eax ; 2 bytes add eax, eax ; 2 bytes given a << 3, the choices are, obviously: shl eax, 3 ; 3 bytes or add eax, eax add eax, eax add eax, eax 6 bytes, double the size thoughts? I think go for size over speed. Smaller files, less I/O, both in the build and less code to pagein at runtime. At some point higher instruction counts saturate the ability of the processors to "run ahead"? However it might be nice to give the user a choice? But then you invite increased testing cost. Though maybe not too prohibitive. (for shift by one, size/speed both give add eax, eax; I'll do that) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 11 13:03:09 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 11 Feb 2010 07:03:09 -0500 Subject: [M3devel] optimizing for size or speed? In-Reply-To: References: Message-ID: <20100211120309.GB27402@topoi.pooq.com> On Thu, Feb 11, 2010 at 08:53:08AM +0000, Jay K wrote: > > There are all kinds of equivalent code sequences. > For the maintainer of m3back to chose among. In case of doubt, go for size; size all by itself costs time in cache misses, paging, etc. Besides, it's possible to measure space. -- hendrik From jay.krell at cornell.edu Thu Feb 11 13:05:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:05:53 +0000 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) Message-ID: TInt/TWord proposal TInt needs to be a "complete" replacement for INTEGER and LONGINT. Plus overflow checking. Not just for the frontend, but also m3back. TWord needs to be a "complete" replacement for Word and Long. Therefore not likely any overflow checking. But in reality you might need all four: signed with silent overflow signed with nonsilent overflow unsigned with silent overflow unsigned with nonsilent overflow You can provide silent overflow by computing the result and leaving it to the caller to ignore the BOOLEAN or not. However in practise I don't think I needed silent overflow at all. The only places I allow it, I think really I'm confusing TInt with TWord, because TWord doesn't provide the right interface. Settle on bits or bytes for sizes. Enshrine it mostly in the public interface. It maybe already is, granted. But more so -- external users can construct the things. Operations with mixed sizes shall not be allowed. <=== ***** Just as INTEGER, LONGINT, Word, Long don't allow. There would be some conversion functions, granted. SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. Constants Zero, One, MOne, etc. shall probably be replaced with an array of 8 each, or maybe just 1, 2, 4, 8 -- the number of bytes in the size. "M" for "minus" is the wrong term. It should N or Neg or Negative. Something like: TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) TYPE ByteCount = [1..8]; (* wasteful, darn *) CONST Invalid = Target.Int{-1,IntBytes{0,..}}; CONST ZeroBytes = IntBytes{0,..}; CONST OneBytes = IntBytes{1,0,..}; CONST NegativeOneBytes = IntBytes{16_FF,..}; CONST ThirtyTwoBytes = IntBytes{32,0,..}; etc. CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, Invalid, Target.Int{8,ZeroBytes}}; CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, Invalid, Target.Int{8,OneBytes}}; etc. TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] MAYBE as a possible simplification to the user: Introduce InternalTInt which is today's TInt and then: TInt implies Target.Integer.bytes TWord implies Target.Integer.bytes new TLongint implies Target.Longint.bytes new TLong implies Target.Longint.bytes I really thing the short name "Long" is bad. There is no indication of unsignedness in it. It should be ULong or UnsignedLong or LongWord. "Word" is to INTEGER as what is to LONGINT? I don't think Long is the answer. I'll start another thread on this. m3back maintains a stack of mixed types, but I think it works out ok. All that being said, I think what is there works and isn't terrible and we don't need to solve lots of problems here. I do think the variable sizing is a bit of a problem though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:09:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:09:13 +0000 Subject: [M3devel] "Word" is to INTEGER as what is to LONGINT? Message-ID: "Word" is to INTEGER as what is to LONGINT? I don't think Long is a good answer. It is the current answer. "Word" and "INTEGER" are not "related". "Related" might be "UnsignedInteger" or "Integer" or "IntegerOps" or "SilentOverflowInteger" I'm not proposing changing the name "Word". But whatever is the LONGINT replacement...maybe "LongWord" or "UnsignedLong"? I don't think "Long" is the correct answer. Or does "word" not imply "unsigned" or "silent overflow", merely "integer sized"? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:11:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:11:14 +0000 Subject: [M3devel] atomics questions Message-ID: What if some atomic operations aren't available? If none are available, then they can all fallback to one giant lock. But what if some are and some aren't? A lock per type? That fails with like union { short s[2]; int i; } u; and platform has atomic int but not atomic short. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:15:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:15:03 +0000 Subject: [M3devel] use of date and bc in m3tests Message-ID: Anyone: C:\dev2\cm3.2\m3-sys\m3tests\src\m3makefile Please try to remove the uses of date and bc. Thanks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:34:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:34:53 +0000 Subject: [M3devel] replacing hand.c with Modula-3? Message-ID: I see no great reason for hand.c to be in C. It should be easy to rewrite in Modula-3, using the Word interface. The only question really is, what to call things? M3_BUILTIN__set_union, etc.? I think I see M3_BUILTIN somewhere. RTHooks__set_union, etc.? SomethingElse__set_union? SomethingElse__somethingElse while we're at it? M3Set__Union M3Set__Singleton -- probably not even worth being a function M3Set__Intersect etc.? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:41:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:41:12 +0000 Subject: [M3devel] optimizing for size or speed? In-Reply-To: <20100211120309.GB27402@topoi.pooq.com> References: , <20100211120309.GB27402@topoi.pooq.com> Message-ID: cache -- good point I had forgotten, thanks. Still: use the divide instruction, which is smallest, or multiply by reciprocal (which is generally a multiply and a shift) (Given a 32x32=>64 multiply operation. x86 doesn't even have 32x32=>32, only 32x32=>64, I believe.) Any 32bit division by a constant can be optimized this way and every C compiler knows it. multiply by a constant using multiply instruction, or decompose into some adds? The AMD64 optimization guide suggests speed optimizations where they give a sequence for multiplication for every constant up to 32, some are just to use mul. But many are one or two other instructions. Multiply by 5 is: lea eax,[eax+eax*4] Multiply by 10 is: lea eax,[eax+eax*4] add eax,eax The AMD64 manual even advises to inline 64bit shifts by a non-constant. But I can't get Visual C++ to do that. It always calls a function. - Jay > Date: Thu, 11 Feb 2010 07:03:09 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] optimizing for size or speed? > > On Thu, Feb 11, 2010 at 08:53:08AM +0000, Jay K wrote: > > > > There are all kinds of equivalent code sequences. > > For the maintainer of m3back to chose among. > > In case of doubt, go for size; size all by itself costs time in cache > misses, paging, etc. > > Besides, it's possible to measure space. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 14:23:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 13:23:45 +0000 Subject: [M3devel] assertion failure in atomics Message-ID: Tony if you don't have enough to do already: VAR <*NOWARN*>a := 1; <*NOWARN*>b := 2; <*NOWARN*>c := 3; <*NOWARN*>d := 4; <*NOWARN*>A := 5L; <*NOWARN*>B := 6L; <*NOWARN*>C := 7L; <*NOWARN*>D := 8L; bool:BOOLEAN; PROCEDURE Test_AtomicInteger_CompareSwap() = BEGIN bool := AtomicInteger.CompareSwap(a, b, c); END Test_AtomicInteger_CompareSwap; C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 --- building in NT386 --- new source -> compiling Main.m3 "..\Main.m3", line 83: incompatible types (var) *** *** runtime error: *** An array subscript was out of range. *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", line 19 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil tinAtomic\CompareSwap.mg 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 ......... ......... ... more frames ... 1) The test is in error, wrong type on one of the params. 2) This could be specific to using m3back. 3) I'll poke around more. 4) Too bad we don't get line numbers in the stacks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 16:00:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 15:00:39 +0000 Subject: [M3devel] assertion failure in atomics In-Reply-To: References: Message-ID: Type-incorrect code seems to tend to assert. But type-correct code gets through the frontend ok. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 11 Feb 2010 13:23:45 +0000 Subject: [M3devel] assertion failure in atomics Tony if you don't have enough to do already: VAR <*NOWARN*>a := 1; <*NOWARN*>b := 2; <*NOWARN*>c := 3; <*NOWARN*>d := 4; <*NOWARN*>A := 5L; <*NOWARN*>B := 6L; <*NOWARN*>C := 7L; <*NOWARN*>D := 8L; bool:BOOLEAN; PROCEDURE Test_AtomicInteger_CompareSwap() = BEGIN bool := AtomicInteger.CompareSwap(a, b, c); END Test_AtomicInteger_CompareSwap; C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 --- building in NT386 --- new source -> compiling Main.m3 "..\Main.m3", line 83: incompatible types (var) *** *** runtime error: *** An array subscript was out of range. *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", line 19 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil tinAtomic\CompareSwap.mg 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 ......... ......... ... more frames ... 1) The test is in error, wrong type on one of the params. 2) This could be specific to using m3back. 3) I'll poke around more. 4) Too bad we don't get line numbers in the stacks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 11 16:35:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 11 Feb 2010 16:35:43 +0100 Subject: [M3devel] use of date and bc in m3tests In-Reply-To: References: Message-ID: <20100211163543.l5ohnxt6qswcgc84@mail.elegosoft.com> Quoting Jay K : > Anyone: > > C:\dev2\cm3.2\m3-sys\m3tests\src\m3makefile > > Please try to remove the uses of date and bc. > > Thanks. I happend to see this some minutes ago (lots of other unread M3 mails in my box I'm afraid). AFAIK date and bc are only used in the quake code to time the tests. There are several things that can be done: 1. They can be used conditionally, depending on the existence of date and bc on the test system. That should be possible in quake. Of course test time reporting will then not work if they are missing. 2. Somebody can write simple M3 or C programs that will be used instead. Should not be too difficult, but somewhat redundant. 3. Ideally, quake itself should be able to time the execution of procedures and to do simple arithmetic. That would be the best solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Feb 11 17:53:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:53:24 -0500 Subject: [M3devel] atomics questions In-Reply-To: References: Message-ID: <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> On 11 Feb 2010, at 07:11, Jay K wrote: > What if some atomic operations aren't available? > > > If none are available, then they can all fallback to one giant lock. > Correct. > > But what if some are and some aren't? > A lock per type? Yes. Definitely. No unions in M3. > > That fails with like > union { > short s[2]; > int i; > } u; > > > and platform has atomic int but not atomic short. We do have atomic WIDECHARl > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 11 17:52:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:52:12 -0500 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) In-Reply-To: References: Message-ID: Steady on. I have it fixed. CHeckin coming. No need for more. On 11 Feb 2010, at 07:05, Jay K wrote: > TInt/TWord proposal > > > TInt needs to be a "complete" replacement for INTEGER and LONGINT. > Plus overflow checking. > Not just for the frontend, but also m3back. > > > TWord needs to be a "complete" replacement for Word and Long. > Therefore not likely any overflow checking. > > > But in reality you might need all four: > signed with silent overflow > signed with nonsilent overflow > unsigned with silent overflow > unsigned with nonsilent overflow > > > You can provide silent overflow by computing the result > and leaving it to the caller to ignore the BOOLEAN or not. > > > However in practise I don't think I needed silent overflow at all. > The only places I allow it, I think really I'm confusing TInt with TWord, > because TWord doesn't provide the right interface. > > > Settle on bits or bytes for sizes. > Enshrine it mostly in the public interface. > It maybe already is, granted. > But more so -- external users can construct the things. > > > Operations with mixed sizes shall not be allowed. <=== ***** > Just as INTEGER, LONGINT, Word, Long don't allow. > > > There would be some conversion functions, granted. > SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. > > > Constants Zero, One, MOne, etc. shall probably be > replaced with an array of 8 each, or maybe just > 1, 2, 4, 8 -- the number of bytes in the size. > > > "M" for "minus" is the wrong term. > It should N or Neg or Negative. > > > Something like: > TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) > TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) > TYPE ByteCount = [1..8]; (* wasteful, darn *) > > CONST Invalid = Target.Int{-1,IntBytes{0,..}}; > > CONST ZeroBytes = IntBytes{0,..}; > CONST OneBytes = IntBytes{1,0,..}; > CONST NegativeOneBytes = IntBytes{16_FF,..}; > CONST ThirtyTwoBytes = IntBytes{32,0,..}; > etc. > > CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, > Invalid, Target.Int{8,ZeroBytes}}; > > CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, > Invalid, Target.Int{8,OneBytes}}; > etc. > > > TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] > > > MAYBE as a possible simplification to the user: > > Introduce InternalTInt which is today's TInt and then: > TInt implies Target.Integer.bytes > TWord implies Target.Integer.bytes > new TLongint implies Target.Longint.bytes > new TLong implies Target.Longint.bytes > > > I really thing the short name "Long" is bad. > There is no indication of unsignedness in it. > It should be ULong or UnsignedLong or LongWord. > > > "Word" is to INTEGER as what is to LONGINT? > I don't think Long is the answer. > I'll start another thread on this. > > > m3back maintains a stack of mixed types, but I think it works out ok. > > > All that being said, I think what is there works and isn't terrible > and we don't need to solve lots of problems here. > > > I do think the variable sizing is a bit of a problem though. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 11 17:54:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:54:59 -0500 Subject: [M3devel] assertion failure in atomics In-Reply-To: References: Message-ID: I figured we'd shake some of these problems out fairly soon. I need to get the TInt/TWord stuff checked in before I move on this. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Feb 2010, at 08:23, Jay K wrote: > Tony if you don't have enough to do already: > > VAR > <*NOWARN*>a := 1; > <*NOWARN*>b := 2; > <*NOWARN*>c := 3; > <*NOWARN*>d := 4; > <*NOWARN*>A := 5L; > <*NOWARN*>B := 6L; > <*NOWARN*>C := 7L; > <*NOWARN*>D := 8L; > bool:BOOLEAN; > > PROCEDURE Test_AtomicInteger_CompareSwap() = > BEGIN > bool := AtomicInteger.CompareSwap(a, b, c); > END Test_AtomicInteger_CompareSwap; > > > C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 > --- building in NT386 --- > new source -> compiling Main.m3 > "..\Main.m3", line 83: incompatible types (var) > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", > line 19 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil > tinAtomic\CompareSwap.mg > 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 > 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 > 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 > 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 > 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 > 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 > 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 > 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 > 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 > ......... ......... ... more frames ... > > > 1) The test is in error, wrong type on one of the params. > 2) This could be specific to using m3back. > 3) I'll poke around more. > 4) Too bad we don't get line numbers in the stacks. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 23:46:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 22:46:51 +0000 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) In-Reply-To: References: , Message-ID: To be clear, I'm not working on this, was just thinking about it. - Jay Subject: Re: [M3devel] TInt/TWord proposal (at least what I was thinking..) From: hosking at cs.purdue.edu Date: Thu, 11 Feb 2010 11:52:12 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Steady on. I have it fixed. CHeckin coming. No need for more. On 11 Feb 2010, at 07:05, Jay K wrote: TInt/TWord proposal TInt needs to be a "complete" replacement for INTEGER and LONGINT. Plus overflow checking. Not just for the frontend, but also m3back. TWord needs to be a "complete" replacement for Word and Long. Therefore not likely any overflow checking. But in reality you might need all four: signed with silent overflow signed with nonsilent overflow unsigned with silent overflow unsigned with nonsilent overflow You can provide silent overflow by computing the result and leaving it to the caller to ignore the BOOLEAN or not. However in practise I don't think I needed silent overflow at all. The only places I allow it, I think really I'm confusing TInt with TWord, because TWord doesn't provide the right interface. Settle on bits or bytes for sizes. Enshrine it mostly in the public interface. It maybe already is, granted. But more so -- external users can construct the things. Operations with mixed sizes shall not be allowed. <=== ***** Just as INTEGER, LONGINT, Word, Long don't allow. There would be some conversion functions, granted. SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. Constants Zero, One, MOne, etc. shall probably be replaced with an array of 8 each, or maybe just 1, 2, 4, 8 -- the number of bytes in the size. "M" for "minus" is the wrong term. It should N or Neg or Negative. Something like: TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) TYPE ByteCount = [1..8]; (* wasteful, darn *) CONST Invalid = Target.Int{-1,IntBytes{0,..}}; CONST ZeroBytes = IntBytes{0,..}; CONST OneBytes = IntBytes{1,0,..}; CONST NegativeOneBytes = IntBytes{16_FF,..}; CONST ThirtyTwoBytes = IntBytes{32,0,..}; etc. CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, Invalid, Target.Int{8,ZeroBytes}}; CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, Invalid, Target.Int{8,OneBytes}}; etc. TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] MAYBE as a possible simplification to the user: Introduce InternalTInt which is today's TInt and then: TInt implies Target.Integer.bytes TWord implies Target.Integer.bytes new TLongint implies Target.Longint.bytes new TLong implies Target.Longint.bytes I really thing the short name "Long" is bad. There is no indication of unsignedness in it. It should be ULong or UnsignedLong or LongWord. "Word" is to INTEGER as what is to LONGINT? I don't think Long is the answer. I'll start another thread on this. m3back maintains a stack of mixed types, but I think it works out ok. All that being said, I think what is there works and isn't terrible and we don't need to solve lots of problems here. I do think the variable sizing is a bit of a problem though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 09:45:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 08:45:17 +0000 Subject: [M3devel] atomics questions In-Reply-To: <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> References: , <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> Message-ID: loophole allows for union, right? I know there is widechar, point was, if some hypothetical platform without atomic widechar. - Jay From: hosking at cs.purdue.edu Date: Thu, 11 Feb 2010 11:53:24 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomics questions On 11 Feb 2010, at 07:11, Jay K wrote: What if some atomic operations aren't available? If none are available, then they can all fallback to one giant lock. Correct. But what if some are and some aren't? A lock per type? Yes. Definitely. No unions in M3. That fails with like union { short s[2]; int i; } u; and platform has atomic int but not atomic short. We do have atomic WIDECHARl - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 10:17:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 09:17:14 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Message-ID: Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 10:57:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 09:57:08 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: Message-ID: Hm. I think there's a bigger problem here. I think, not sure, but i think compare_exhcange needs to take a "Var", not an address on the stack. See how it is storing the address to the stack and comparing that. Wrong. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 12 Feb 2010 09:17:14 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 15:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 14:20:39 +0000 Subject: [M3devel] m3back atomic current summary Message-ID: "m3back atomics summary" After a while of looking at this, I conclude that the atomics interface has a bunch of functionality that doesn't map all that well to what x86 provides, and vice versa. In particular x86 allows lock mem or reg lock mem xor reg lock mem and reg lock not mem lock neg mem and several others but the requirement of the atomic interface to return the new value makes these not line up. The new value doesn't come back in a register and rereading memory will not be atomic. Now I see why the C compiler's _InterlockedOr and such use _InterlockedCompareExchange in a small loop. Any xchg with a memory operand on x86 is always atomic. fetch_and_op for add/sub can probably be more efficient using xadd. You get back the old value but you can do the add a second time. I understand the point isn't necessarily to expose whatever x86 can do, but also to provide an interface that can be reasonably implemented across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). It's possible the front end (or backend) should notice if the return value is ignored, such as by preceding it with EVAL, and then those can be implemented more efficiently. The NT386 backend does not have the level of sophistication required to do that. I'm torn on even providing this stuff. It's all very tricky to use. However any "systems" language should probobably provide for a portable efficient lock package, that others can then easily use. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 15:26:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 14:26:25 +0000 Subject: [M3devel] m3back atomic current summary In-Reply-To: References: Message-ID: aha, Visual C++ does do this optimization: void __fastcall xInterlockedOr(long* a, long b) { _InterlockedOr(a, b); } long __fastcall yInterlockedOr(long* a, long b) { return _InterlockedOr(a, b); } void __fastcall xInterlockedXor(long* a, long b) { _InterlockedXor(a, b); } long __fastcall yInterlockedXor(long* a, long b) { return _InterlockedXor(a, b); } yelds: ; 1 : void __fastcall xInterlockedOr(long* a, long b) { _InterlockedOr(a, b); } 00000 f0 09 11 lock or DWORD PTR [ecx], edx 00003 c3 ret 0 ; 2 : long __fastcall yInterlockedOr(long* a, long b) { return _InterlockedOr(a, b); } 00010 56 push esi 00011 8b 01 mov eax, DWORD PTR [ecx] $LN3@: 00013 8b f0 mov esi, eax 00015 0b f2 or esi, edx 00017 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 0001b 75 f6 jne SHORT $LN3@ 0001d 5e pop esi 0001e c3 ret 0 ; 3 : void __fastcall xInterlockedXor(long* a, long b) { _InterlockedXor(a, b); } 00020 f0 31 11 lock xor DWORD PTR [ecx], edx ; 4 : long __fastcall yInterlockedXor(long* a, long b) { return _InterlockedXor(a, b); } 00030 56 push esi 00031 8b 01 mov eax, DWORD PTR [ecx] $LN3@: 00033 8b f0 mov esi, eax 00035 33 f2 xor esi, edx 00037 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 0003b 75 f6 jne SHORT $LN3@ 0003d 5e pop esi 0003e c3 ret 0 cool. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Date: Fri, 12 Feb 2010 14:20:39 +0000 Subject: [M3devel] m3back atomic current summary "m3back atomics summary" After a while of looking at this, I conclude that the atomics interface has a bunch of functionality that doesn't map all that well to what x86 provides, and vice versa. In particular x86 allows lock mem or reg lock mem xor reg lock mem and reg lock not mem lock neg mem and several others but the requirement of the atomic interface to return the new value makes these not line up. The new value doesn't come back in a register and rereading memory will not be atomic. Now I see why the C compiler's _InterlockedOr and such use _InterlockedCompareExchange in a small loop. Any xchg with a memory operand on x86 is always atomic. fetch_and_op for add/sub can probably be more efficient using xadd. You get back the old value but you can do the add a second time. I understand the point isn't necessarily to expose whatever x86 can do, but also to provide an interface that can be reasonably implemented across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). It's possible the front end (or backend) should notice if the return value is ignored, such as by preceding it with EVAL, and then those can be implemented more efficiently. The NT386 backend does not have the level of sophistication required to do that. I'm torn on even providing this stuff. It's all very tricky to use. However any "systems" language should probobably provide for a portable efficient lock package, that others can then easily use. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 15:49:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 09:49:14 -0500 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: Message-ID: <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. The C source: int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) { return AO_compare_and_swap_full(addr, *old, new); } generates: .globl _Atomic__CompareSwap_ordered _Atomic__CompareSwap_ordered: LFB526: pushq %rbp LCFI42: movq %rsp, %rbp LCFI43: movq (%rsi), %rax lock; cmpxchgq %rdx, (%rdi); setz %al movsbl %al,%eax leave ret LFE526: .align 4,0x90 On 12 Feb 2010, at 04:17, Jay K wrote: > Tony, currently I have atomic.compare_and_exchange generating e.g.: > > > load_address gv.2[_MM_Main] 56 > 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 > load_address gv.2[_MM_Main] 152 > 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 > load gv.2[_MM_Main] 156 Int.32 Int.32 > compare_exchange Int.32 Int.32 Int.32 > 0000019A: 8BC7 MOV EAX EDI > 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 > declare_temp 4 4 Addr F tv.35[T$35] -4 > 000001A2: 8975FC MOV tv.35[T$35] ESI > 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX > > > This might not be correct, but it is close. > > > Now, the thing is, the eax register is special to lock cmpxchg. > It always holds the comparison value. > > The point is, if cg.compare_exchange took its parameters as > parameters instead of on the stack, it could chose the > right register right away, instead of as above where it > choses the wrong one and then must mov it. > > Easy to change it like that? > > > I realize this is an m3back deficiency. > It does the register allocation too early. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 15:42:04 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 09:42:04 -0500 Subject: [M3devel] atomics questions In-Reply-To: References: , <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> Message-ID: No, the values must have the same BITSIZE or you get an error. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Feb 2010, at 03:45, Jay K wrote: > loophole allows for union, right? > I know there is widechar, point was, if some hypothetical platform without atomic widechar. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 11 Feb 2010 11:53:24 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] atomics questions > > On 11 Feb 2010, at 07:11, Jay K wrote: > > What if some atomic operations aren't available? > > > If none are available, then they can all fallback to one giant lock. > > > Correct. > > > But what if some are and some aren't? > > > > A lock per type? > > Yes. Definitely. No unions in M3. > > > That fails with like > union { > short s[2]; > int i; > } u; > > > and platform has atomic int but not atomic short. > > We do have atomic WIDECHARl > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 16:16:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 10:16:50 -0500 Subject: [M3devel] m3back atomic current summary In-Reply-To: References: Message-ID: <69C6DDBB-3300-4B60-9FDC-E06BAF0A955E@cs.purdue.edu> Jay, I don't understand your issues here. On 12 Feb 2010, at 09:20, Jay K wrote: > "m3back atomics summary" > > After a while of looking at this, I conclude > that the atomics interface has a bunch > of functionality that doesn't map all that > well to what x86 provides, and vice versa. > > > In particular x86 allows > lock mem or reg > lock mem xor reg > lock mem and reg > lock not mem > lock neg mem > and several others > > > but the requirement of the atomic interface > to return the new value makes these not line up. Which new value? There is no *requirement* that CompareSwap return the actual value in the register: The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: > The new value doesn't come back in a register > and rereading memory will not be atomic. Again, I don't understand this. > Now I see why the C compiler's _InterlockedOr and such > use _InterlockedCompareExchange in a small loop. > > > Any xchg with a memory operand on x86 is always atomic. > > > fetch_and_op for add/sub can probably be more efficient using xadd. > You get back the old value but you can do the add a second time. > > > I understand the point isn't necessarily to expose whatever x86 can do, > but also to provide an interface that can be reasonably implemented > across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). > > > It's possible the front end (or backend) should notice if the return value > is ignored, such as by preceding it with EVAL, and then those can be > implemented more efficiently. > The NT386 backend does not have the level of sophistication required to do that. > > > I'm torn on even providing this stuff. > It's all very tricky to use. > However any "systems" language should probobably > provide for a portable efficient lock package, that > others can then easily use. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 18:42:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 17:42:05 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> References: , <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Message-ID: It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack. We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be. We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register. Again, if m3back were multi pass or somehow smarter, it'd be moot. I'll be looking into make it one or both of these maybe sometime soon. - Jay From: hosking at cs.purdue.edu Date: Fri, 12 Feb 2010 09:49:14 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. The C source: int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) { return AO_compare_and_swap_full(addr, *old, new); } generates: .globl _Atomic__CompareSwap_ordered _Atomic__CompareSwap_ordered: LFB526: pushq %rbp LCFI42: movq %rsp, %rbp LCFI43: movq (%rsi), %rax lock; cmpxchgq %rdx, (%rdi); setz %al movsbl %al,%eax leave ret LFE526: .align 4,0x90 On 12 Feb 2010, at 04:17, Jay K wrote: Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 19:35:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 13:35:27 -0500 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: , <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Message-ID: Let's be explicit here. You want compare_exchange to take an explicit Var? For which argument? The memory location being manipulated or the expected value? compare_exchange (t: MType; u: ZType; r: IType; success, failure: MemoryOrder); (* tmp := Mem[s2.A].t; IF (tmp = Mem[s1.A].t) THEN Mem [s2.A].t := s0.u; s2.r := 1; pop(2); ELSE Mem [s1.A].t := tmp; s2.r := 0; pop(2); END; This is permitted to fail spuriously, leaving Mem [s1.A] unchanged. *) So, you want s1 to be a Var or s2? On 12 Feb 2010, at 12:42, Jay K wrote: > It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack. > We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be. > We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register. > > Again, if m3back were multi pass or somehow smarter, it'd be moot. > I'll be looking into make it one or both of these maybe sometime soon. > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 12 Feb 2010 09:49:14 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? > > Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. > > The C source: > > int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) > { return AO_compare_and_swap_full(addr, *old, new); } > > generates: > > .globl _Atomic__CompareSwap_ordered > _Atomic__CompareSwap_ordered: > LFB526: > pushq %rbp > LCFI42: > movq %rsp, %rbp > LCFI43: > movq (%rsi), %rax > lock; cmpxchgq %rdx, (%rdi); setz %al > movsbl %al,%eax > leave > ret > LFE526: > .align 4,0x90 > > > > On 12 Feb 2010, at 04:17, Jay K wrote: > > Tony, currently I have atomic.compare_and_exchange generating e.g.: > > > load_address gv.2[_MM_Main] 56 > 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 > load_address gv.2[_MM_Main] 152 > 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 > load gv.2[_MM_Main] 156 Int.32 Int.32 > compare_exchange Int.32 Int.32 Int.32 > 0000019A: 8BC7 MOV EAX EDI > 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 > declare_temp 4 4 Addr F tv.35[T$35] -4 > 000001A2: 8975FC MOV tv.35[T$35] ESI > 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX > > > This might not be correct, but it is close. > > > Now, the thing is, the eax register is special to lock cmpxchg. > It always holds the comparison value. > > The point is, if cg.compare_exchange took its parameters as > parameters instead of on the stack, it could chose the > right register right away, instead of as above where it > choses the wrong one and then must mov it. > > Easy to change it like that? > > > I realize this is an m3back deficiency. > It does the register allocation too early. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 13 16:25:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 13 Feb 2010 16:25:26 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed Message-ID: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. But I don't seem to be able to upgrade to the current head of the release branch even with the upgrade script: http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console What do I miss? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Feb 14 13:55:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Feb 2010 12:55:42 +0000 Subject: [M3devel] m3back/longint/atomics Message-ID: As far as I know/can remember, longint and atomics should all work now on NT386. Atomics only currently for 32bit types. There are still a few small inefficiencies to maybe deal with. I'll add 64bit shortly and maybe 8 and 16. We should probably add *a lot* more test coverage in p226 and p227. e.g. longint multiply/add/sub/divide, not just insert/extract like I did a bunch of. Still to fix the Win32 m3core/libm3 to not always truncate file sizes. Still maybe to do something about rd/wr...? Still to wonder about NT386/longint support in the release branch? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 15 09:29:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Feb 2010 08:29:07 +0000 Subject: [M3devel] int64 division? Message-ID: Tony, there's something wrong with 64bit division. This program fails on LINUXLIBC6. I fixed it for NT386 (wrong parameter order) but the two are wildly divergent. MODULE Main; PROCEDURE NotConstL(a: LONGINT): LONGINT = BEGIN RETURN a; END NotConstL; BEGIN <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *> <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *> END Main. (gdb) x/200i Main_M3 0x804b03e : push %ebp 0x804b03f : mov %esp,%ebp 0x804b041 : push %ebx 0x804b042 : sub $0x14,%esp 0x804b045 : call 0x804b04a 0x804b04a : pop %ebx 0x804b04b : add $0x3a50a,%ebx 0x804b051 : mov 0x8(%ebp),%eax 0x804b054 : xor $0x1,%eax 0x804b057 : test %al,%al 0x804b059 : jne 0x804b100 0x804b05f : sub $0x8,%esp 0x804b062 : push $0x0 0x804b064 : push $0x1 0x804b066 : call 0x804b024 0x804b06b : add $0x10,%esp 0x804b06e : mov %eax,0xfffffff0(%ebp) 0x804b071 : mov %edx,0xfffffff4(%ebp) 0x804b074 : mov 0xfffffff0(%ebp),%eax 0x804b077 : mov 0xfffffff4(%ebp),%edx 0x804b07a : push $0x80000000 0x804b07f : push $0x0 0x804b081 : push %edx 0x804b082 : push %eax 0x804b0d0 : push %edx 0x804b0d1 : push %eax 0x804b0d2 : call 0x804bbd4 0x804b0d7 : add $0x10,%esp Right here this can't be correct. 64bit results are returned in the edx:eax pair, edx is high, eax low. (32bit results are turned in just eax.) It looks like m3_divL returned the correct value but whatever is happening here is trashing the results. 0x804b0da : mov %eax,%edx 0x804b0dc : sar $0x1f,%edx 0x804b0df : mov %edx,%ecx 0x804b0e1 : xor $0x7fffffff,%ecx 0x804b0e7 : xor $0xffffffff,%eax 0x804b0ea : or %ecx,%eax 0x804b0ec : test %eax,%eax 0x804b0ee : je 0x804b100 0x804b0f0 : sub $0xc,%esp 0x804b0f3 : push $0x140 0x804b0f8 : call 0x804b10b <_m3_fault> 0x804b0fd : add $0x10,%esp 0x804b100 : mov 0xfffffc74(%ebx),%eax 0x804b106 : mov 0xfffffffc(%ebp),%ebx 0x804b109 : leave 0x804b10a : ret 0x804b10b <_m3_fault>: push %ebp 0x804b10c <_m3_fault+1>: mov %esp,%ebp 0x804b10e <_m3_fault+3>: push %ebx I'll dig a bit more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 15 09:39:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Feb 2010 08:39:07 +0000 Subject: [M3devel] int64 division? In-Reply-To: References: Message-ID: Should be ok now. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Mon, 15 Feb 2010 08:29:07 +0000 Subject: [M3devel] int64 division? Tony, there's something wrong with 64bit division. This program fails on LINUXLIBC6. I fixed it for NT386 (wrong parameter order) but the two are wildly divergent. MODULE Main; PROCEDURE NotConstL(a: LONGINT): LONGINT = BEGIN RETURN a; END NotConstL; BEGIN <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *> <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *> END Main. (gdb) x/200i Main_M3 0x804b03e : push %ebp 0x804b03f : mov %esp,%ebp 0x804b041 : push %ebx 0x804b042 : sub $0x14,%esp 0x804b045 : call 0x804b04a 0x804b04a : pop %ebx 0x804b04b : add $0x3a50a,%ebx 0x804b051 : mov 0x8(%ebp),%eax 0x804b054 : xor $0x1,%eax 0x804b057 : test %al,%al 0x804b059 : jne 0x804b100 0x804b05f : sub $0x8,%esp 0x804b062 : push $0x0 0x804b064 : push $0x1 0x804b066 : call 0x804b024 0x804b06b : add $0x10,%esp 0x804b06e : mov %eax,0xfffffff0(%ebp) 0x804b071 : mov %edx,0xfffffff4(%ebp) 0x804b074 : mov 0xfffffff0(%ebp),%eax 0x804b077 : mov 0xfffffff4(%ebp),%edx 0x804b07a : push $0x80000000 0x804b07f : push $0x0 0x804b081 : push %edx 0x804b082 : push %eax 0x804b0d0 : push %edx 0x804b0d1 : push %eax 0x804b0d2 : call 0x804bbd4 0x804b0d7 : add $0x10,%esp Right here this can't be correct. 64bit results are returned in the edx:eax pair, edx is high, eax low. (32bit results are turned in just eax.) It looks like m3_divL returned the correct value but whatever is happening here is trashing the results. 0x804b0da : mov %eax,%edx 0x804b0dc : sar $0x1f,%edx 0x804b0df : mov %edx,%ecx 0x804b0e1 : xor $0x7fffffff,%ecx 0x804b0e7 : xor $0xffffffff,%eax 0x804b0ea : or %ecx,%eax 0x804b0ec : test %eax,%eax 0x804b0ee : je 0x804b100 0x804b0f0 : sub $0xc,%esp 0x804b0f3 : push $0x140 0x804b0f8 : call 0x804b10b <_m3_fault> 0x804b0fd : add $0x10,%esp 0x804b100 : mov 0xfffffc74(%ebx),%eax 0x804b106 : mov 0xfffffffc(%ebp),%ebx 0x804b109 : leave 0x804b10a : ret 0x804b10b <_m3_fault>: push %ebp 0x804b10c <_m3_fault+1>: mov %esp,%ebp 0x804b10e <_m3_fault+3>: push %ebx I'll dig a bit more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 16 15:18:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 15:18:12 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> Message-ID: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Quoting Olaf Wagner : > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > But I don't seem to be able to upgrade to the current head of the > release branch even with the upgrade script: > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > What do I miss? FYI The update to the current release branch tip of 5.8 requires an RC4 build as an intermediate step. It is not possible to update directly from older versions. This has been confirmed on FreeBSD4 and PPC_LINUX. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 16 15:37:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 15:37:26 +0100 Subject: [M3devel] release engineering: RC5 Message-ID: <20100216153726.168giuvpusskw444@mail.elegosoft.com> It took me some time to get the regression testing via Hudson up-to-date again, but it should be OK now. Can we rollout RC5 (which will hopefully become the final release) now? Is anybody still working on changes/fixes for the release? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 16 16:12:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 16:12:52 +0100 Subject: [M3devel] m3back/longint/atomics In-Reply-To: References: Message-ID: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Quoting Jay K : > > As far as I know/can remember, longint and atomics should all work > now on NT386. > > Atomics only currently for 32bit types. > There are still a few small inefficiencies to maybe deal with. > I'll add 64bit shortly and maybe 8 and 16. > > > We should probably add *a lot* more test coverage in p226 and p227. > > e.g. longint multiply/add/sub/divide, not just insert/extract like I > did a bunch of. Any volunteers to increase the test coverage? > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > > Still maybe to do something about rd/wr...? > > Still to wonder about NT386/longint support in the release branch? Should we / will you merge this stuff to the release branch? Or should we release without it? How local are the changes? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 17 02:46:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 01:46:49 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Message-ID: > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 02:44:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 01:44:00 +0000 Subject: [M3devel] m3back/longint/atomics In-Reply-To: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Message-ID: NT386/longint changes are almost entirely in the m3back package. There is also some small easy stuff in m3-libs/m3core/src/Csupport/common/hand.c. It'd be really great if anyone could test any of this and if anyone could review the diff between release and head. Not just me. The changes for longint are quite large, even if local. I can port them, in the case of m3back, just copy, and make sure the atomics stuff doesn't cause problems (it should be unused). There is also a small change in m3front so that longint can be initialized. That affects all platforms. And a small change in m3cc/parse.c for div/mod of longint on non-NT386. I have to test mod yet but my fix probably helps it. It'd be really great if anyone could do anything with this stuff. ie. for now in head, then could easily port to release. We can of course release either way, depending on how satisfied people are with 32bit longint on NT386. i.e. longint isn't useful portably, but it is useful on non-NT386 platforms. - Jay > Date: Tue, 16 Feb 2010 16:12:52 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back/longint/atomics > > Quoting Jay K : > > > > > As far as I know/can remember, longint and atomics should all work > > now on NT386. > > > > Atomics only currently for 32bit types. > > There are still a few small inefficiencies to maybe deal with. > > I'll add 64bit shortly and maybe 8 and 16. > > > > > > We should probably add *a lot* more test coverage in p226 and p227. > > > > e.g. longint multiply/add/sub/divide, not just insert/extract like I > > did a bunch of. > > Any volunteers to increase the test coverage? > > > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > > > > Still maybe to do something about rd/wr...? > > > > Still to wonder about NT386/longint support in the release branch? > > Should we / will you merge this stuff to the release branch? > Or should we release without it? How local are the changes? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 08:54:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Message-ID: I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 08:56:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 07:56:35 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, Message-ID: oops looks like I deleted my fixes. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 09:55:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 08:55:36 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, , , Message-ID: ok should be better now, I only tested LINUXLIBC6 5.4.0 to current. I can look at and fix more later. But this is "controversial" stuff and has to end somewhere. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:56:35 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed oops looks like I deleted my fixes. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 17 11:33:37 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 17 Feb 2010 11:33:37 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, , , Message-ID: <20100217113337.amzp2ojjusgw844k@mail.elegosoft.com> Quoting Jay K : > > ok should be better now, I only tested LINUXLIBC6 5.4.0 to current. > > I can look at and fix more later. > > But this is "controversial" stuff and has to end somewhere. Jay, no need to do more. I didn't mean that you should start fixing immediately; my mail was just to document the fact in the lists. Once 5.8 is out we can forget about older releases, too, I think. Olaf > > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 17 Feb 2010 07:56:35 +0000 > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > > > oops looks like I deleted my fixes. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 17 Feb 2010 07:54:04 +0000 > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > > > I can build current release from LINUXLIBC6 release 5.4.0 now. > Some of the fixes are applicable to PPC_LINUX. > I can test it against an older release. > > I could probably easily make it work back to older versions and more targets. > I had removed some of the workarounds, but they were fairly clean. > Stuff like not using -m32 on older cm3cg, etc. > > You cannot build current m3core/libm3 with old cm3 or old cm3cg. > I used "upgrade.py" which foists current config files on older > compiler, and, you know, doesn't build m3core/libm3 until after it > has a current compiler. > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] FreeBSD4 update on releng branch failed > Date: Wed, 17 Feb 2010 01:46:49 +0000 > > > > > It is not possible to update directly from older versions. > > Maybe nice to "fix". > I'll try to get to it. > > - Jay > > >> Date: Tue, 16 Feb 2010 15:18:12 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] FreeBSD4 update on releng branch failed >> >> Quoting Olaf Wagner : >> >> > Yesterday I've finally added a Hudson slave again for the >> FreeBSD4 platform. >> > But I don't seem to be able to upgrade to the current head of the >> > release branch even with the upgrade script: >> > >> > >> http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console >> > >> > What do I miss? >> >> FYI >> >> The update to the current release branch tip of 5.8 requires an RC4 >> build as an intermediate step. It is not possible to update directly from >> older versions. >> >> This has been confirmed on FreeBSD4 and PPC_LINUX. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 17 12:07:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 11:07:02 +0000 Subject: [M3devel] hand.c : m3_div Message-ID: Tony, presumably one of these will do: C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\tree.def /* Division for integer result that rounds the quotient toward zero. */ DEFTREECODE (TRUNC_DIV_EXPR, "trunc_div_expr", tcc_binary, 2) /* Division for integer result that rounds the quotient toward infinity. */ DEFTREECODE (CEIL_DIV_EXPR, "ceil_div_expr", tcc_binary, 2) /* Division for integer result that rounds toward minus infinity. */ DEFTREECODE (FLOOR_DIV_EXPR, "floor_div_expr", tcc_binary, 2) /* Division for integer result that rounds toward nearest integer. */ DEFTREECODE (ROUND_DIV_EXPR, "round_div_expr", tcc_binary, 2) /* Four kinds of remainder that go with the four kinds of division. */ DEFTREECODE (TRUNC_MOD_EXPR, "trunc_mod_expr", tcc_binary, 2) DEFTREECODE (CEIL_MOD_EXPR, "ceil_mod_expr", tcc_binary, 2) DEFTREECODE (FLOOR_MOD_EXPR, "floor_mod_expr", tcc_binary, 2) DEFTREECODE (ROUND_MOD_EXPR, "round_mod_expr", tcc_binary, 2) I can look into it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 17 15:52:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 17 Feb 2010 09:52:17 -0500 Subject: [M3devel] hand.c : m3_div In-Reply-To: References: Message-ID: <5C81AD48-5F6F-4741-AD07-D7D26CD1DC7B@cs.purdue.edu> Yes, I've wondered that for some time, but never been certain what code they produce.... There's no way to generate the ones we would want from C. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 17 Feb 2010, at 06:07, Jay K wrote: > Tony, presumably one of these will do: > > > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\tree.def > > /* Division for integer result that rounds the quotient toward zero. */ > DEFTREECODE (TRUNC_DIV_EXPR, "trunc_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds the quotient toward infinity. */ > DEFTREECODE (CEIL_DIV_EXPR, "ceil_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds toward minus infinity. */ > DEFTREECODE (FLOOR_DIV_EXPR, "floor_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds toward nearest integer. */ > DEFTREECODE (ROUND_DIV_EXPR, "round_div_expr", tcc_binary, 2) > > /* Four kinds of remainder that go with the four kinds of division. */ > > DEFTREECODE (TRUNC_MOD_EXPR, "trunc_mod_expr", tcc_binary, 2) > DEFTREECODE (CEIL_MOD_EXPR, "ceil_mod_expr", tcc_binary, 2) > DEFTREECODE (FLOOR_MOD_EXPR, "floor_mod_expr", tcc_binary, 2) > DEFTREECODE (ROUND_MOD_EXPR, "round_mod_expr", tcc_binary, 2) > > > I can look into it. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 00:47:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 23:47:11 +0000 Subject: [M3devel] replacing hand.c with Modula-3? Message-ID: ? I have a little more reduction to do here (e.g. remove table or tables, at least the exported NT386-specific one; replace set_eq and ne with memcmp even for m3cg), but stuff will remain. It'd be nifty if Modula-3 functions/variables could be explicitly named for compat but I'll just go ahead and change the names and break compat. We break compat in other ways and it seems ok, unless people object (e.g. I removed m3_div because current backend doesn't generate calls to it, but it could/should be preserved for compat with older binaries). - Jay ________________________________ > From: jay > > > I see no great reason for hand.c to be in C. > > It should be easy to rewrite in Modula-3, using the Word interface. > > The only question really is, what to call things? > > M3_BUILTIN__set_union, etc.? > > I think I see M3_BUILTIN somewhere. > > RTHooks__set_union, etc.? > > SomethingElse__set_union? > > SomethingElse__somethingElse while we're at it? > > > > > M3Set__Union > > M3Set__Singleton -- probably not even worth being a function > > M3Set__Intersect > > etc.? > > > > > > - Jay > From hosking at cs.purdue.edu Thu Feb 18 03:03:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 17 Feb 2010 21:03:33 -0500 Subject: [M3devel] replacing hand.c with Modula-3? In-Reply-To: References: Message-ID: <15D830F3-ACF0-435D-B27B-BC42D2833621@cs.purdue.edu> Let's not get into the compatibility rathole. Better to stay clean w.r.to current builds. On 17 Feb 2010, at 18:47, Jay K wrote: > > ? > > > I have a little more reduction to do here (e.g. remove table or tables, at least the exported NT386-specific one; replace set_eq and ne with memcmp even for m3cg), but stuff will remain. > > > It'd be nifty if Modula-3 functions/variables could be explicitly named for compat but I'll just go ahead and change the names and break compat. We break compat in other ways and it seems ok, unless people object (e.g. I removed m3_div because current backend doesn't generate calls to it, but it could/should be preserved for compat with older binaries). > > > > - Jay > > ________________________________ >> From: jay >> >> >> I see no great reason for hand.c to be in C. >> >> It should be easy to rewrite in Modula-3, using the Word interface. >> >> The only question really is, what to call things? >> >> M3_BUILTIN__set_union, etc.? >> >> I think I see M3_BUILTIN somewhere. >> >> RTHooks__set_union, etc.? >> >> SomethingElse__set_union? >> >> SomethingElse__somethingElse while we're at it? >> >> >> >> >> M3Set__Union >> >> M3Set__Singleton -- probably not even worth being a function >> >> M3Set__Intersect >> >> etc.? >> >> >> >> >> >> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 18 11:45:58 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 11:45:58 +0100 Subject: [M3devel] Auto-discard notification In-Reply-To: References: Message-ID: <20100218114558.rn033djp4wgs0wsg@mail.elegosoft.com> You need to subscribe to the list to be able to post to it. However, I can quickly answer some of your questions: o You need to use the script upgrade.sh or upgrade.py to perform a full core system upgrade from source. This bootstraps the compiler and runtime libraries using an existing compiler and installs everything it has built. "install-cm3-compiler.sh upgrade" will just install a compiler from your workspace. o Failures in the packages odbc, postgres95, and db are most likely due to missing libraries on your system. Just install the needed third party packages for this software with the appropriate tools for your system (e.g. pkg_add, apt-get, ...) and adapt the library paths in the cm3 config files if they still aren't found. Have a look at /usr/local/cm3/bin/cm3.cfg and its includes. o If the packages are missing, that should not be a problem, too, as long as you don't need their functionality. Hope this helps, Olaf Quoting m3devel-bounces at elegosoft.com: > The attached message has been automatically discarded. My CM3 build was getting pretty old, so I decided to re-install from scratch, and came across a number of problems whose solution wasn't obvious. Could someone please confirm that I got the answers right? (This was on a current x86 Linux box.) I installed from the cm3-bin-core tarfile, which gave me a basic m3 compiler and linker. I then tried installing from the cm3-src-all tarfile, with the command: install-cm3-compiler.sh upgrade since I wanted to force a compiler upgrade for various reasons. Should I have used do-cm3-core.sh buildship as well? Could I have used do-cm3-core.sh instead, if I didn't want to rebuild the compiler? I then tried: do-cm3-std.sh buildship which failed on the packages odbc, postgres95, and db (smalldb built correctly). This is where I ran into real problems, since I couldn't find any documentation on the packages to be built, or a way of restarting a failed build. I finally decided that pkginfo.txt was the one, and edited it. Re-running do-cm3-std then got me a working system. Was this the right approach, and does the pkginfo.txt format allow for commenting out lines (I just deleted the successful packages), and if so what is the comment symbol (; ? # ?). Is there an easier way to restart a failed build? Is any of this documented anywhere? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 18 12:26:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 11:26:19 +0000 Subject: [M3devel] other users of TInt Message-ID: I'll get to this soon... == package C:\dev2\cm3.2\m3-sys\m3tools == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling M3Lexer.i3 new source -> compiling M3Lexer.m3 "..\src\M3Lexer.m3", line 123: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 123: incompatible types (i) "..\src\M3Lexer.m3", line 126: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 126: incompatible types (i) "..\src\M3Lexer.m3", line 130: too many actual parameters: TWord.New "..\src\M3Lexer.m3", line 130: incompatible types (i) 6 errors encountered new source -> compiling M3AST.i3 new source -> compiling M3AST.m3 new source -> compiling M3Parse.m3 new source -> compiling M3Scope.i3 new source -> compiling M3Scope.m3 new source -> compiling M3Type.i3 new source -> compiling M3Type.m3 "..\src\M3Type.m3", line 48: unknown qualification '.' (x) "..\src\M3Type.m3", line 48: not enough values specified "..\src\M3Type.m3", line 251: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 251: incompatible types (i) "..\src\M3Type.m3", line 292: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 292: incompatible types (i) 6 errors encountered new source -> compiling M3Const.i3 new source -> compiling M3Builtin.i3 new source -> compiling M3ArrVal.i3 new source -> compiling M3RecVal.i3 new source -> compiling M3SetVal.i3 new source -> compiling M3Const.m3 "..\src\M3Const.m3", line 865: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 865: incompatible types (i) "..\src\M3Const.m3", line 1164: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1164: incompatible types (i) "..\src\M3Const.m3", line 1174: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1174: incompatible types (i) 6 errors encountered new source -> compiling M3SetVal.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 18 12:57:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 12:57:34 +0100 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Message-ID: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> If I understand Jay correctly, it wouldn't be too difficult to bring the m3ack LONGINT changes for Windows into the release branch, but more testing would be needed. Randy, you're the only one I remember offhand who actively uses M3 on Windows except for Jay. Could you have a closer look at it? (Changes are only on the trunk right now.) Or is anybody else here lurking and eager to do some Windows-based tests? If nobody volunteers, I'm afraid we will have to release without 64bit LONGINT on Windows. Olaf Quoting Jay K : > NT386/longint changes are almost entirely in the m3back package. > > There is also some small easy stuff in > m3-libs/m3core/src/Csupport/common/hand.c. > > It'd be really great if anyone could test any of this and if > anyone could review the diff between release and head. > > Not just me. > > The changes for longint are quite large, even if local. > > I can port them, in the case of m3back, just copy, and make sure > the atomics stuff doesn't cause problems (it should be unused). > > There is also a small change in m3front so that longint can be initialized. > That affects all platforms. > > And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > I have to test mod yet but my fix probably helps it. > > It'd be really great if anyone could do anything with this stuff. > ie. for now in head, then could easily port to release. > > We can of course release either way, depending on how satisfied people > are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > is useful on non-NT386 platforms. > > - Jay > >> Date: Tue, 16 Feb 2010 16:12:52 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3back/longint/atomics >> >> Quoting Jay K : >> >> > >> > As far as I know/can remember, longint and atomics should all work >> > now on NT386. >> > >> > Atomics only currently for 32bit types. >> > There are still a few small inefficiencies to maybe deal with. >> > I'll add 64bit shortly and maybe 8 and 16. >> > >> > >> > We should probably add *a lot* more test coverage in p226 and p227. >> > >> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >> > did a bunch of. >> >> Any volunteers to increase the test coverage? >> >> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >> > >> > Still maybe to do something about rd/wr...? >> > >> > Still to wonder about NT386/longint support in the release branch? >> >> Should we / will you merge this stuff to the release branch? >> Or should we release without it? How local are the changes? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Feb 18 12:51:17 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 18 Feb 2010 06:51:17 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> Message-ID: <20100218115116.GA2336@topoi.pooq.com> On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. I'm somewhat interested in getting my programs working on Windows, but I haven't yet installed *anything* on the pristine XP on my netbook. I'm hesitant about connecting it to the net; the only antivirus I have is refraining from using Windows, and it works fairly well(!). As far as I know, I have no way of reinstalling Windows if my Windows is damaged. I/m mostly interested in getting my software into a state where Windows nonprogrammers can use it; I use Linux myself. What would I need to do (from scratch; I'm not a Windows user; I just happened not to delete Windows when I installed Linux)? The machine is A 32-bit intel, and so it just might not be relevant to testing 64-bit LONGINT. -- hendrik From jay.krell at cornell.edu Thu Feb 18 15:11:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:11:33 +0000 Subject: [M3devel] other users of TInt In-Reply-To: References: Message-ID: Sorry, it looks like I was out of sync. Still something wierd to track down.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 18 Feb 2010 11:26:19 +0000 Subject: [M3devel] other users of TInt I'll get to this soon... == package C:\dev2\cm3.2\m3-sys\m3tools == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling M3Lexer.i3 new source -> compiling M3Lexer.m3 "..\src\M3Lexer.m3", line 123: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 123: incompatible types (i) "..\src\M3Lexer.m3", line 126: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 126: incompatible types (i) "..\src\M3Lexer.m3", line 130: too many actual parameters: TWord.New "..\src\M3Lexer.m3", line 130: incompatible types (i) 6 errors encountered new source -> compiling M3AST.i3 new source -> compiling M3AST.m3 new source -> compiling M3Parse.m3 new source -> compiling M3Scope.i3 new source -> compiling M3Scope.m3 new source -> compiling M3Type.i3 new source -> compiling M3Type.m3 "..\src\M3Type.m3", line 48: unknown qualification '.' (x) "..\src\M3Type.m3", line 48: not enough values specified "..\src\M3Type.m3", line 251: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 251: incompatible types (i) "..\src\M3Type.m3", line 292: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 292: incompatible types (i) 6 errors encountered new source -> compiling M3Const.i3 new source -> compiling M3Builtin.i3 new source -> compiling M3ArrVal.i3 new source -> compiling M3RecVal.i3 new source -> compiling M3SetVal.i3 new source -> compiling M3Const.m3 "..\src\M3Const.m3", line 865: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 865: incompatible types (i) "..\src\M3Const.m3", line 1164: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1164: incompatible types (i) "..\src\M3Const.m3", line 1174: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1174: incompatible types (i) 6 errors encountered new source -> compiling M3SetVal.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 15:14:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:14:01 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218115116.GA2336@topoi.pooq.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com>, , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <20100218115116.GA2336@topoi.pooq.com> Message-ID: Henrik, if you won't install anything, then you can't test anything. Modula-3 is not going to break your XP install. Nor is Visual C++. > machine is A 32-bit intel, and so it just might not be relevant to > testing 64-bit LONGINT. False! LONGINT is 64bits on all platforms. We have no 64bit Windows target currently. - Jay > Date: Thu, 18 Feb 2010 06:51:17 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > > If I understand Jay correctly, it wouldn't be too difficult to bring > > the m3ack LONGINT changes for Windows into the release branch, but > > more testing would be needed. > > > > Randy, you're the only one I remember offhand who actively uses M3 > > on Windows except for Jay. Could you have a closer look at it? > > (Changes are only on the trunk right now.) > > > > Or is anybody else here lurking and eager to do some Windows-based tests? > > > > If nobody volunteers, I'm afraid we will have to release without 64bit > > LONGINT on Windows. > > I'm somewhat interested in getting my programs working on Windows, but I > haven't yet installed *anything* on the pristine XP on my netbook. I'm > hesitant about connecting it to the net; the only antivirus I have is > refraining from using Windows, and it works fairly well(!). As far as I > know, I have no way of reinstalling Windows if my Windows is damaged. > > I/m mostly interested in getting my software into a state where Windows > nonprogrammers can use it; I use Linux myself. > > What would I need to do (from scratch; I'm not a Windows user; I just > happened not to delete Windows when I installed Linux)? The > machine is A 32-bit intel, and so it just might not be relevant to > testing 64-bit LONGINT. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 15:21:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:21:37 +0000 Subject: [M3devel] other users of TInt In-Reply-To: References: , Message-ID: > Still something wierd to track down.. typo in test case, oops -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Feb 18 15:26:43 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 18 Feb 2010 09:26:43 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> Message-ID: <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> I can certainly run some tests on Windows. I don't have any code that uses longint, so either someone needs to identify which existing programs I can build and run to do the tests, OR I suppose I can write something if you can give me an idea of how extensive the tests you want. I've been trying to keep my system updated to the latest sources on the main trunk, but I've been swamped lately and I'm afraid I'm a few weeks stale right now. I'll remedy that shortly. Regards, Randy ________________________________ From: Olaf Wagner [wagner at elegosoft.com] Sent: Thursday, February 18, 2010 6:57 AM To: Jay K Cc: m3devel Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics If I understand Jay correctly, it wouldn't be too difficult to bring the m3ack LONGINT changes for Windows into the release branch, but more testing would be needed. Randy, you're the only one I remember offhand who actively uses M3 on Windows except for Jay. Could you have a closer look at it? (Changes are only on the trunk right now.) Or is anybody else here lurking and eager to do some Windows-based tests? If nobody volunteers, I'm afraid we will have to release without 64bit LONGINT on Windows. Olaf Quoting Jay K : > NT386/longint changes are almost entirely in the m3back package. > > There is also some small easy stuff in > m3-libs/m3core/src/Csupport/common/hand.c. > > It'd be really great if anyone could test any of this and if > anyone could review the diff between release and head. > > Not just me. > > The changes for longint are quite large, even if local. > > I can port them, in the case of m3back, just copy, and make sure > the atomics stuff doesn't cause problems (it should be unused). > > There is also a small change in m3front so that longint can be initialized. > That affects all platforms. > > And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > I have to test mod yet but my fix probably helps it. > > It'd be really great if anyone could do anything with this stuff. > ie. for now in head, then could easily port to release. > > We can of course release either way, depending on how satisfied people > are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > is useful on non-NT386 platforms. > > - Jay > >> Date: Tue, 16 Feb 2010 16:12:52 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3back/longint/atomics >> >> Quoting Jay K : >> >> > >> > As far as I know/can remember, longint and atomics should all work >> > now on NT386. >> > >> > Atomics only currently for 32bit types. >> > There are still a few small inefficiencies to maybe deal with. >> > I'll add 64bit shortly and maybe 8 and 16. >> > >> > >> > We should probably add *a lot* more test coverage in p226 and p227. >> > >> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >> > did a bunch of. >> >> Any volunteers to increase the test coverage? >> >> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >> > >> > Still maybe to do something about rd/wr...? >> > >> > Still to wonder about NT386/longint support in the release branch? >> >> Should we / will you merge this stuff to the release branch? >> Or should we release without it? How local are the changes? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Feb 18 15:40:05 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 18 Feb 2010 09:40:05 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218115116.GA2336@topoi.pooq.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <20100218115116.GA2336@topoi.pooq.com> Message-ID: <357B777B-B964-418C-98A8-83AF9F6DB54F@mimectl> Hendrik: You can get a FREE antivirus for Windows from several sources. Microsoft has one, but I use AVG. Here is a link to the AVG download: http://download.cnet.com/AVG-Anti-Virus-Free-Edition/3000-2239_4-10320142.html?part=dl-10044820&subj=dl&tag=button&cdlPid=11014801 I don't think installing CM3 will "damage" your system. You will need some sort of C compiler/linker though because there is some C code that gets compiled and cm3 doesn't come with its own linker. I use the FREE Microsoft Visual Studio C++ 2008 Express Edition. Here is a link to the download: http://www.microsoft.com/express/downloads/#2008-Visual-CPP I have some scripts in cm3/scripts/dev/windows that may be useful to you on Windows. If you just want to get a working cm3 on your windows system, I could build you a minimal (or a full) distribution and ZIP it up and send to you. Then you would just unzip to a folder, say C:\cm3. There is nothing to "install" here that can mess up your registry. You will still need the Visual C++ Express to get the Microsoft Linker if you want to build any new programs. Regards, Randy ________________________________ From: hendrik at topoi.pooq.com [hendrik at topoi.pooq.com] Sent: Thursday, February 18, 2010 6:51 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. I'm somewhat interested in getting my programs working on Windows, but I haven't yet installed *anything* on the pristine XP on my netbook. I'm hesitant about connecting it to the net; the only antivirus I have is refraining from using Windows, and it works fairly well(!). As far as I know, I have no way of reinstalling Windows if my Windows is damaged. I/m mostly interested in getting my software into a state where Windows nonprogrammers can use it; I use Linux myself. What would I need to do (from scratch; I'm not a Windows user; I just happened not to delete Windows when I installed Linux)? The machine is A 32-bit intel, and so it just might not be relevant to testing 64-bit LONGINT. -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 18 15:34:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 18 Feb 2010 09:34:02 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: References: <20100218115116.GA2336@topoi.pooq.com> Message-ID: <20100218143402.GA12076@topoi.pooq.com> On Thu, Feb 18, 2010 at 02:14:01PM +0000, Jay K wrote: > > Henrik, if you won't install anything, then you can't test anything. > > Modula-3 is not going to break your XP install. > > Nor is Visual C++. I'm not afraid of Modula 3 or Visual C++. I'm worried about the stuff I might encounter while wanfering the net wondering what it is I have to do. Randy's reply will probably get me started. > > > > > machine is A 32-bit intel, and so it just might not be relevant to > > testing 64-bit LONGINT. > > > False! > > LONGINT is 64bits on all platforms. > > We have no 64bit Windows target currently. Ah. I've heard of a 64-bit Windows. Evidently not relevant to us now. -- hendrik From wagner at elegosoft.com Thu Feb 18 17:20:56 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 17:20:56 +0100 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> Message-ID: <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> Quoting "Coleburn, Randy" : > I can certainly run some tests on Windows. > > I don't have any code that uses longint, so either someone needs to > identify which existing programs I can build and run to do the > tests, OR I suppose I can write something if you can give me an idea > of how extensive the tests you want. This sounds good! Some things that come to mind for LONGINT immeditately: o standard integer arithmetic (+, -, *, DIV, MOD) at runtime, with and without overflows etc. o constant declarations o constant expressions o assignability (should be rather strict; I'd have to check the mail archive for the details) o pickles It would be great if you could add some tests to m3tests that are valid on all platforms. I expect that some should already be in place, but haven't checked yet... Hm, a quick search for longint in http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ for example doesn't find anything. Has nobody added any LONGINT test yet? Probably I'm looking for the wrong string... A complete regression with cm3 and other programs you may have available would be great, too, just to make sure that the backend changes don't break any old functionality. Olaf > > I've been trying to keep my system updated to the latest sources on > the main trunk, but I've been swamped lately and I'm afraid I'm a > few weeks stale right now. I'll remedy that shortly. > > Regards, > Randy > > ________________________________ > From: Olaf Wagner [wagner at elegosoft.com] > Sent: Thursday, February 18, 2010 6:57 AM > To: Jay K > Cc: m3devel > Subject: [M3devel] More testing needed for m3back, was: RE: > m3back/longint/atomics > > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. > > Olaf > > Quoting Jay K : > >> NT386/longint changes are almost entirely in the m3back package. >> >> There is also some small easy stuff in >> m3-libs/m3core/src/Csupport/common/hand.c. >> >> It'd be really great if anyone could test any of this and if >> anyone could review the diff between release and head. >> >> Not just me. >> >> The changes for longint are quite large, even if local. >> >> I can port them, in the case of m3back, just copy, and make sure >> the atomics stuff doesn't cause problems (it should be unused). >> >> There is also a small change in m3front so that longint can be initialized. >> That affects all platforms. >> >> And a small change in m3cc/parse.c for div/mod of longint on non-NT386. >> I have to test mod yet but my fix probably helps it. >> >> It'd be really great if anyone could do anything with this stuff. >> ie. for now in head, then could easily port to release. >> >> We can of course release either way, depending on how satisfied people >> are with 32bit longint on NT386. i.e. longint isn't useful portably, but it >> is useful on non-NT386 platforms. >> >> - Jay >> >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3back/longint/atomics >>> >>> Quoting Jay K : >>> >>> > >>> > As far as I know/can remember, longint and atomics should all work >>> > now on NT386. >>> > >>> > Atomics only currently for 32bit types. >>> > There are still a few small inefficiencies to maybe deal with. >>> > I'll add 64bit shortly and maybe 8 and 16. >>> > >>> > >>> > We should probably add *a lot* more test coverage in p226 and p227. >>> > >>> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >>> > did a bunch of. >>> >>> Any volunteers to increase the test coverage? >>> >>> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >>> > >>> > Still maybe to do something about rd/wr...? >>> > >>> > Still to wonder about NT386/longint support in the release branch? >>> >>> Should we / will you merge this stuff to the release branch? >>> Or should we release without it? How local are the changes? >>> >>> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 18 22:26:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 21:26:19 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> References: , , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com>, , , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl>, <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> Message-ID: I added some testing, found/fixed bugs in the gcc backend (initializing constants, division). They should be in the automated tests already. However don't let this stop you from doing everything/anything you can think of. I didn't do all that much and you can save time and get more done by not worrying about the duplication. Pickles I didn't do anything with at all, so if you really want to avoid/delay duplication, start with them. - Jay > Date: Thu, 18 Feb 2010 17:20:56 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Quoting "Coleburn, Randy" : > > > I can certainly run some tests on Windows. > > > > I don't have any code that uses longint, so either someone needs to > > identify which existing programs I can build and run to do the > > tests, OR I suppose I can write something if you can give me an idea > > of how extensive the tests you want. > > This sounds good! > > Some things that come to mind for LONGINT immeditately: > > o standard integer arithmetic (+, -, *, DIV, MOD) at runtime, > with and without overflows etc. > o constant declarations > o constant expressions > o assignability (should be rather strict; I'd have to check the mail > archive for the details) > o pickles > > It would be great if you could add some tests to m3tests that are > valid on all platforms. I expect that some should already be in place, > but haven't checked yet... > > Hm, a quick search for longint in > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > for example doesn't find anything. Has nobody added any LONGINT > test yet? Probably I'm looking for the wrong string... > > A complete regression with cm3 and other programs you may have available > would be great, too, just to make sure that the backend changes > don't break any old functionality. > > Olaf > > > > > I've been trying to keep my system updated to the latest sources on > > the main trunk, but I've been swamped lately and I'm afraid I'm a > > few weeks stale right now. I'll remedy that shortly. > > > > Regards, > > Randy > > > > ________________________________ > > From: Olaf Wagner [wagner at elegosoft.com] > > Sent: Thursday, February 18, 2010 6:57 AM > > To: Jay K > > Cc: m3devel > > Subject: [M3devel] More testing needed for m3back, was: RE: > > m3back/longint/atomics > > > > If I understand Jay correctly, it wouldn't be too difficult to bring > > the m3ack LONGINT changes for Windows into the release branch, but > > more testing would be needed. > > > > Randy, you're the only one I remember offhand who actively uses M3 > > on Windows except for Jay. Could you have a closer look at it? > > (Changes are only on the trunk right now.) > > > > Or is anybody else here lurking and eager to do some Windows-based tests? > > > > If nobody volunteers, I'm afraid we will have to release without 64bit > > LONGINT on Windows. > > > > Olaf > > > > Quoting Jay K : > > > >> NT386/longint changes are almost entirely in the m3back package. > >> > >> There is also some small easy stuff in > >> m3-libs/m3core/src/Csupport/common/hand.c. > >> > >> It'd be really great if anyone could test any of this and if > >> anyone could review the diff between release and head. > >> > >> Not just me. > >> > >> The changes for longint are quite large, even if local. > >> > >> I can port them, in the case of m3back, just copy, and make sure > >> the atomics stuff doesn't cause problems (it should be unused). > >> > >> There is also a small change in m3front so that longint can be initialized. > >> That affects all platforms. > >> > >> And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > >> I have to test mod yet but my fix probably helps it. > >> > >> It'd be really great if anyone could do anything with this stuff. > >> ie. for now in head, then could easily port to release. > >> > >> We can of course release either way, depending on how satisfied people > >> are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > >> is useful on non-NT386 platforms. > >> > >> - Jay > >> > >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] m3back/longint/atomics > >>> > >>> Quoting Jay K : > >>> > >>> > > >>> > As far as I know/can remember, longint and atomics should all work > >>> > now on NT386. > >>> > > >>> > Atomics only currently for 32bit types. > >>> > There are still a few small inefficiencies to maybe deal with. > >>> > I'll add 64bit shortly and maybe 8 and 16. > >>> > > >>> > > >>> > We should probably add *a lot* more test coverage in p226 and p227. > >>> > > >>> > e.g. longint multiply/add/sub/divide, not just insert/extract like I > >>> > did a bunch of. > >>> > >>> Any volunteers to increase the test coverage? > >>> > >>> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > >>> > > >>> > Still maybe to do something about rd/wr...? > >>> > > >>> > Still to wonder about NT386/longint support in the release branch? > >>> > >>> Should we / will you merge this stuff to the release branch? > >>> Or should we release without it? How local are the changes? > >>> > >>> Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 19 04:07:36 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 03:07:36 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <683477.25152.qm@web23602.mail.ird.yahoo.com> Hi all: great news to hear about a release coming soon, but how about testing NT386GNU or derivatives of it, would be hard to set up (I might try a friend's machine). As I understood that was a great port to new Modula-3 programmers coming into the M3 world from win world. This doesn't have the all packages but is this a must to give have a check to release this port? Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 ? Is there any chance to bring those platforms in final release? Any difficulties to start trying that? Thanks in advance --- El jue, 18/2/10, Jay K escribi?: > De: Jay K > Asunto: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Olaf" , "m3devel" > Fecha: jueves, 18 de febrero, 2010 16:26 > > > > > > I added some testing, found/fixed bugs in the gcc > backend (initializing constants, division). > > They should be in the automated tests already. > > However don't let this stop you from doing > everything/anything you can think of. > > I didn't do all that much and you can save time and get > more done by not worrying > > about the duplication. > > Pickles I didn't do anything with at all, so if you > really want to avoid/delay duplication, > > start with them. > > > > - Jay > > > > Date: Thu, 18 Feb 2010 17:20:56 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > > > Quoting "Coleburn, Randy" > : > > > > > I can certainly run some tests on Windows. > > > > > > I don't have any code that uses longint, so > either someone needs to > > > identify which existing programs I can build and > run to do the > > > tests, OR I suppose I can write something if you > can give me an idea > > > of how extensive the tests you want. > > > > This sounds good! > > > > Some things that come to mind for LONGINT > immeditately: > > > > o standard integer arithmetic (+, -, *, DIV, MOD) at > runtime, > > with and without overflows etc. > > o constant declarations > > o constant expressions > > o assignability (should be rather strict; I'd have > to check the mail > > archive for the details) > > o pickles > > > > It would be great if you could add some tests to > m3tests that are > > valid on all platforms. I expect that some should > already be in place, > > but haven't checked yet... > > > > Hm, a quick search for longint in > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > > for example doesn't find anything. Has nobody > added any LONGINT > > test yet? Probably I'm looking for the wrong > string... > > > > A complete regression with cm3 and other programs you > may have available > > would be great, too, just to make sure that the > backend changes > > don't break any old functionality. > > > > Olaf > > > > > > > > I've been trying to keep my system updated to > the latest sources on > > > the main trunk, but I've been swamped lately > and I'm afraid I'm a > > > few weeks stale right now. I'll remedy that > shortly. > > > > > > Regards, > > > Randy > > > > > > ________________________________ > > > From: Olaf Wagner [wagner at elegosoft.com] > > > Sent: Thursday, February 18, 2010 6:57 AM > > > To: Jay K > > > Cc: m3devel > > > Subject: [M3devel] More testing needed for > m3back, was: RE: > > > m3back/longint/atomics > > > > > > If I understand Jay correctly, it wouldn't be > too difficult to bring > > > the m3ack LONGINT changes for Windows into the > release branch, but > > > more testing would be needed. > > > > > > Randy, you're the only one I remember offhand > who actively uses M3 > > > on Windows except for Jay. Could you have a > closer look at it? > > > (Changes are only on the trunk right now.) > > > > > > Or is anybody else here lurking and eager to do > some Windows-based tests? > > > > > > If nobody volunteers, I'm afraid we will have > to release without 64bit > > > LONGINT on Windows. > > > > > > Olaf > > > > > > Quoting Jay K : > > > > > >> NT386/longint changes are almost entirely in > the m3back package. > > >> > > >> There is also some small easy stuff in > > >> m3-libs/m3core/src/Csupport/common/hand.c. > > >> > > >> It'd be really great if anyone could test > any of this and if > > >> anyone could review the diff between release > and head. > > >> > > >> Not just me. > > >> > > >> The changes for longint are quite large, even > if local. > > >> > > >> I can port them, in the case of m3back, just > copy, and make sure > > >> the atomics stuff doesn't cause problems > (it should be unused). > > >> > > >> There is also a small change in m3front so > that longint can be initialized. > > >> That affects all platforms. > > >> > > >> And a small change in m3cc/parse.c for > div/mod of longint on non-NT386. > > >> I have to test mod yet but my fix probably > helps it. > > >> > > >> It'd be really great if anyone could do > anything with this stuff. > > >> ie. for now in head, then could easily port > to release. > > >> > > >> We can of course release either way, > depending on how satisfied people > > >> are with 32bit longint on NT386. i.e. longint > isn't useful portably, but it > > >> is useful on non-NT386 platforms. > > >> > > >> - Jay > > >> > > >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 > > >>> From: wagner at elegosoft.com > > >>> To: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] > m3back/longint/atomics > > >>> > > >>> Quoting Jay K > : > > >>> > > >>> > > > >>> > As far as I know/can remember, > longint and atomics should all work > > >>> > now on NT386. > > >>> > > > >>> > Atomics only currently for 32bit > types. > > >>> > There are still a few small > inefficiencies to maybe deal with. > > >>> > I'll add 64bit shortly and maybe > 8 and 16. > > >>> > > > >>> > > > >>> > We should probably add *a lot* more > test coverage in p226 and p227. > > >>> > > > >>> > e.g. longint > multiply/add/sub/divide, not just insert/extract like I > > >>> > did a bunch of. > > >>> > > >>> Any volunteers to increase the test > coverage? > > >>> > > >>> > Still to fix the Win32 m3core/libm3 > to not always truncate file sizes. > > >>> > > > >>> > Still maybe to do something about > rd/wr...? > > >>> > > > >>> > Still to wonder about NT386/longint > support in the release branch? > > >>> > > >>> Should we / will you merge this stuff to > the release branch? > > >>> Or should we release without it? How > local are the changes? > > >>> > > >>> Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 fax: +49 30 23 45 86 95 > > > > http://www.elegosoft.com | > > > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB > 77719 | USt-IdNr: DE163214194 > > > > > > > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > From jay.krell at cornell.edu Fri Feb 19 05:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 04:54:03 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <683477.25152.qm@web23602.mail.ird.yahoo.com> References: , <683477.25152.qm@web23602.mail.ird.yahoo.com> Message-ID: https://projects.elego.de/cm3/ticket/1080 can you provide the cvsup configuration file? Thanks. Can you try building with user threads and see if it occurs? Or on another platform? This is definitely something we want to look into. NT386GNU is there and worked for me, but it is slow. It had 64bit longint way ahead of NT386, but NT386 is there now. There is also NT386MINGNU. More testing definitely appreciated. Thanks, - Jay ---------------------------------------- > Date: Fri, 19 Feb 2010 03:07:36 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi all: > great news to hear about a release coming soon, but how about testing NT386GNU or derivatives of it, would be hard to set up (I might try a friend's machine). > As I understood that was a great port to new Modula-3 programmers coming into the M3 world from win world. This doesn't have the all packages but is this a must to give have a check to release this port? > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 ? > Is there any chance to bring those platforms in final release? > Any difficulties to start trying that? > Thanks in advance > > --- El jue, 18/2/10, Jay K escribi?: > >> De: Jay K >> Asunto: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics >> Para: "Olaf" , "m3devel" >> Fecha: jueves, 18 de febrero, 2010 16:26 >> >> >> >> >> >> I added some testing, found/fixed bugs in the gcc >> backend (initializing constants, division). >> >> They should be in the automated tests already. >> >> However don't let this stop you from doing >> everything/anything you can think of. >> >> I didn't do all that much and you can save time and get >> more done by not worrying >> >> about the duplication. >> >> Pickles I didn't do anything with at all, so if you >> really want to avoid/delay duplication, >> >> start with them. >> >> >> >> - Jay >> >> >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] More testing needed for m3back, >> was: RE: m3back/longint/atomics >>> >>> Quoting "Coleburn, Randy" >> : >>> >>>> I can certainly run some tests on Windows. >>>> >>>> I don't have any code that uses longint, so >> either someone needs to >>>> identify which existing programs I can build and >> run to do the >>>> tests, OR I suppose I can write something if you >> can give me an idea >>>> of how extensive the tests you want. >>> >>> This sounds good! >>> >>> Some things that come to mind for LONGINT >> immeditately: >>> >>> o standard integer arithmetic (+, -, *, DIV, MOD) at >> runtime, >>> with and without overflows etc. >>> o constant declarations >>> o constant expressions >>> o assignability (should be rather strict; I'd have >> to check the mail >>> archive for the details) >>> o pickles >>> >>> It would be great if you could add some tests to >> m3tests that are >>> valid on all platforms. I expect that some should >> already be in place, >>> but haven't checked yet... >>> >>> Hm, a quick search for longint in >>> >>> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ >>> >>> for example doesn't find anything. Has nobody >> added any LONGINT >>> test yet? Probably I'm looking for the wrong >> string... >>> >>> A complete regression with cm3 and other programs you >> may have available >>> would be great, too, just to make sure that the >> backend changes >>> don't break any old functionality. >>> >>> Olaf >>> >>>> >>>> I've been trying to keep my system updated to >> the latest sources on >>>> the main trunk, but I've been swamped lately >> and I'm afraid I'm a >>>> few weeks stale right now. I'll remedy that >> shortly. >>>> >>>> Regards, >>>> Randy >>>> >>>> ________________________________ >>>> From: Olaf Wagner [wagner at elegosoft.com] >>>> Sent: Thursday, February 18, 2010 6:57 AM >>>> To: Jay K >>>> Cc: m3devel >>>> Subject: [M3devel] More testing needed for >> m3back, was: RE: >>>> m3back/longint/atomics >>>> >>>> If I understand Jay correctly, it wouldn't be >> too difficult to bring >>>> the m3ack LONGINT changes for Windows into the >> release branch, but >>>> more testing would be needed. >>>> >>>> Randy, you're the only one I remember offhand >> who actively uses M3 >>>> on Windows except for Jay. Could you have a >> closer look at it? >>>> (Changes are only on the trunk right now.) >>>> >>>> Or is anybody else here lurking and eager to do >> some Windows-based tests? >>>> >>>> If nobody volunteers, I'm afraid we will have >> to release without 64bit >>>> LONGINT on Windows. >>>> >>>> Olaf >>>> >>>> Quoting Jay K : >>>> >>>>> NT386/longint changes are almost entirely in >> the m3back package. >>>>> >>>>> There is also some small easy stuff in >>>>> m3-libs/m3core/src/Csupport/common/hand.c. >>>>> >>>>> It'd be really great if anyone could test >> any of this and if >>>>> anyone could review the diff between release >> and head. >>>>> >>>>> Not just me. >>>>> >>>>> The changes for longint are quite large, even >> if local. >>>>> >>>>> I can port them, in the case of m3back, just >> copy, and make sure >>>>> the atomics stuff doesn't cause problems >> (it should be unused). >>>>> >>>>> There is also a small change in m3front so >> that longint can be initialized. >>>>> That affects all platforms. >>>>> >>>>> And a small change in m3cc/parse.c for >> div/mod of longint on non-NT386. >>>>> I have to test mod yet but my fix probably >> helps it. >>>>> >>>>> It'd be really great if anyone could do >> anything with this stuff. >>>>> ie. for now in head, then could easily port >> to release. >>>>> >>>>> We can of course release either way, >> depending on how satisfied people >>>>> are with 32bit longint on NT386. i.e. longint >> isn't useful portably, but it >>>>> is useful on non-NT386 platforms. >>>>> >>>>> - Jay >>>>> >>>>>> Date: Tue, 16 Feb 2010 16:12:52 +0100 >>>>>> From: wagner at elegosoft.com >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] >> m3back/longint/atomics >>>>>> >>>>>> Quoting Jay K >> : >>>>>> >>>>>>> >>>>>>> As far as I know/can remember, >> longint and atomics should all work >>>>>>> now on NT386. >>>>>>> >>>>>>> Atomics only currently for 32bit >> types. >>>>>>> There are still a few small >> inefficiencies to maybe deal with. >>>>>>> I'll add 64bit shortly and maybe >> 8 and 16. >>>>>>> >>>>>>> >>>>>>> We should probably add *a lot* more >> test coverage in p226 and p227. >>>>>>> >>>>>>> e.g. longint >> multiply/add/sub/divide, not just insert/extract like I >>>>>>> did a bunch of. >>>>>> >>>>>> Any volunteers to increase the test >> coverage? >>>>>> >>>>>>> Still to fix the Win32 m3core/libm3 >> to not always truncate file sizes. >>>>>>> >>>>>>> Still maybe to do something about >> rd/wr...? >>>>>>> >>>>>>> Still to wonder about NT386/longint >> support in the release branch? >>>>>> >>>>>> Should we / will you merge this stuff to >> the release branch? >>>>>> Or should we release without it? How >> local are the changes? >>>>>> >>>>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >> 869 fax: +49 30 23 45 86 95 >>>> >> http://www.elegosoft.com | >> >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | USt-IdNr: DE163214194 >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 >> fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf >> Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >>> >> >> > > > From dabenavidesd at yahoo.es Fri Feb 19 07:20:10 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 06:20:10 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <621322.72118.qm@web23603.mail.ird.yahoo.com> HI: thanks for answering so fast! Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup more or less it makes you to do cvsupd -b /diska/cvsup/base/ which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: (First command and executing after it the client with .sup file given there in the web page) % telnet 192.168.0.3 5999 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. OK 17 0 2009-07-20 14:06:34 CVSup server ready Connection closed by foreign host. (After, second command it doesn't wait anything or if some client request, it just finish like this) % telnet 192.168.0.3 5999 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. Connection closed by foreign host. % pwd seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. (m3gdb) file LINUXLIBC6/cvsupd Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (m3gdb) break src/Main.m3:BecomeDaemon No source file named src/Main.m3. Make breakpoint pending on future shared library load? (y or [n]) y Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log (m3gdb) set follow-fork-mode child (m3gdb) run Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log Signal Stop Print Pass to program Description SIG64 No No Yes Real-time event 64 [Thread debugging using libthread_db enabled] [Nuevo LWP 5074] [Nuevo Thread -1221278032 (LWP 5074)] In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. Thanks in advance, --- El jue, 18/2/10, Jay K escribi?: > De: Jay K > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Daniel (M3)" , "Olaf" , "m3devel" > Fecha: jueves, 18 de febrero, 2010 23:54 > > https://projects.elego.de/cm3/ticket/1080 > can you provide the cvsup configuration file? Thanks. > Can you try building with user threads and see if it > occurs? > Or on another platform? > > > This is definitely something we want to look into. > > > NT386GNU is there and worked for me, but it is slow. > It had 64bit longint way ahead of NT386, but NT386 is there > now. > There is also NT386MINGNU. > > > More testing definitely appreciated. > > > Thanks, > - Jay > > > ---------------------------------------- > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > From: dabenavidesd at yahoo.es > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > To: wagner at elegosoft.com; > m3devel at elegosoft.com; > jay.krell at cornell.edu > > > > Hi all: > > great news to hear about a release coming soon, but > how about testing NT386GNU or derivatives of it, would be > hard to set up (I might try a friend's machine). > > As I understood that was a great port to new Modula-3 > programmers coming into the M3 world from win world. This > doesn't have the all packages but is this a must to give > have a check to release this port? > > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 > ? > > Is there any chance to bring those platforms in final > release? > > Any difficulties to start trying that? > > Thanks in advance > > > > --- El jue, 18/2/10, Jay K escribi?: > > > >> De: Jay K > >> Asunto: Re: [M3devel] More testing needed for > m3back, was: RE: m3back/longint/atomics > >> Para: "Olaf" , "m3devel" > >> Fecha: jueves, 18 de febrero, 2010 16:26 > >> > >> > >> > >> > >> > >> I added some testing, found/fixed bugs in the gcc > >> backend (initializing constants, division). > >> > >> They should be in the automated tests already. > >> > >> However don't let this stop you from doing > >> everything/anything you can think of. > >> > >> I didn't do all that much and you can save time > and get > >> more done by not worrying > >> > >> about the duplication. > >> > >> Pickles I didn't do anything with at all, so if > you > >> really want to avoid/delay duplication, > >> > >> start with them. > >> > >> > >> > >> - Jay > >> > >> > >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] More testing needed for > m3back, > >> was: RE: m3back/longint/atomics > >>> > >>> Quoting "Coleburn, Randy" > >> : > >>> > >>>> I can certainly run some tests on > Windows. > >>>> > >>>> I don't have any code that uses longint, > so > >> either someone needs to > >>>> identify which existing programs I can > build and > >> run to do the > >>>> tests, OR I suppose I can write something > if you > >> can give me an idea > >>>> of how extensive the tests you want. > >>> > >>> This sounds good! > >>> > >>> Some things that come to mind for LONGINT > >> immeditately: > >>> > >>> o standard integer arithmetic (+, -, *, DIV, > MOD) at > >> runtime, > >>> with and without overflows etc. > >>> o constant declarations > >>> o constant expressions > >>> o assignability (should be rather strict; I'd > have > >> to check the mail > >>> archive for the details) > >>> o pickles > >>> > >>> It would be great if you could add some tests > to > >> m3tests that are > >>> valid on all platforms. I expect that some > should > >> already be in place, > >>> but haven't checked yet... > >>> > >>> Hm, a quick search for longint in > >>> > >>> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > >>> > >>> for example doesn't find anything. Has nobody > >> added any LONGINT > >>> test yet? Probably I'm looking for the wrong > >> string... > >>> > >>> A complete regression with cm3 and other > programs you > >> may have available > >>> would be great, too, just to make sure that > the > >> backend changes > >>> don't break any old functionality. > >>> > >>> Olaf > >>> > >>>> > >>>> I've been trying to keep my system updated > to > >> the latest sources on > >>>> the main trunk, but I've been swamped > lately > >> and I'm afraid I'm a > >>>> few weeks stale right now. I'll remedy > that > >> shortly. > >>>> > >>>> Regards, > >>>> Randy > >>>> > >>>> ________________________________ > >>>> From: Olaf Wagner [wagner at elegosoft.com] > >>>> Sent: Thursday, February 18, 2010 6:57 AM > >>>> To: Jay K > >>>> Cc: m3devel > >>>> Subject: [M3devel] More testing needed > for > >> m3back, was: RE: > >>>> m3back/longint/atomics > >>>> > >>>> If I understand Jay correctly, it wouldn't > be > >> too difficult to bring > >>>> the m3ack LONGINT changes for Windows into > the > >> release branch, but > >>>> more testing would be needed. > >>>> > >>>> Randy, you're the only one I remember > offhand > >> who actively uses M3 > >>>> on Windows except for Jay. Could you have > a > >> closer look at it? > >>>> (Changes are only on the trunk right > now.) > >>>> > >>>> Or is anybody else here lurking and eager > to do > >> some Windows-based tests? > >>>> > >>>> If nobody volunteers, I'm afraid we will > have > >> to release without 64bit > >>>> LONGINT on Windows. > >>>> > >>>> Olaf > >>>> > >>>> Quoting Jay K : > >>>> > >>>>> NT386/longint changes are almost > entirely in > >> the m3back package. > >>>>> > >>>>> There is also some small easy stuff > in > >>>>> > m3-libs/m3core/src/Csupport/common/hand.c. > >>>>> > >>>>> It'd be really great if anyone could > test > >> any of this and if > >>>>> anyone could review the diff between > release > >> and head. > >>>>> > >>>>> Not just me. > >>>>> > >>>>> The changes for longint are quite > large, even > >> if local. > >>>>> > >>>>> I can port them, in the case of > m3back, just > >> copy, and make sure > >>>>> the atomics stuff doesn't cause > problems > >> (it should be unused). > >>>>> > >>>>> There is also a small change in > m3front so > >> that longint can be initialized. > >>>>> That affects all platforms. > >>>>> > >>>>> And a small change in m3cc/parse.c > for > >> div/mod of longint on non-NT386. > >>>>> I have to test mod yet but my fix > probably > >> helps it. > >>>>> > >>>>> It'd be really great if anyone could > do > >> anything with this stuff. > >>>>> ie. for now in head, then could easily > port > >> to release. > >>>>> > >>>>> We can of course release either way, > >> depending on how satisfied people > >>>>> are with 32bit longint on NT386. i.e. > longint > >> isn't useful portably, but it > >>>>> is useful on non-NT386 platforms. > >>>>> > >>>>> - Jay > >>>>> > >>>>>> Date: Tue, 16 Feb 2010 16:12:52 > +0100 > >>>>>> From: wagner at elegosoft.com > >>>>>> To: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] > >> m3back/longint/atomics > >>>>>> > >>>>>> Quoting Jay K > >> : > >>>>>> > >>>>>>> > >>>>>>> As far as I know/can > remember, > >> longint and atomics should all work > >>>>>>> now on NT386. > >>>>>>> > >>>>>>> Atomics only currently for > 32bit > >> types. > >>>>>>> There are still a few small > >> inefficiencies to maybe deal with. > >>>>>>> I'll add 64bit shortly and > maybe > >> 8 and 16. > >>>>>>> > >>>>>>> > >>>>>>> We should probably add *a lot* > more > >> test coverage in p226 and p227. > >>>>>>> > >>>>>>> e.g. longint > >> multiply/add/sub/divide, not just insert/extract > like I > >>>>>>> did a bunch of. > >>>>>> > >>>>>> Any volunteers to increase the > test > >> coverage? > >>>>>> > >>>>>>> Still to fix the Win32 > m3core/libm3 > >> to not always truncate file sizes. > >>>>>>> > >>>>>>> Still maybe to do something > about > >> rd/wr...? > >>>>>>> > >>>>>>> Still to wonder about > NT386/longint > >> support in the release branch? > >>>>>> > >>>>>> Should we / will you merge this > stuff to > >> the release branch? > >>>>>> Or should we release without it? > How > >> local are the changes? > >>>>>> > >>>>>> Olaf > >>>> -- > >>>> Olaf Wagner -- elego Software Solutions > GmbH > >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 > >> Berlin, Germany > >>>> phone: +49 30 23 45 86 96 mobile: +49 177 > 2345 > >> 869 fax: +49 30 23 45 86 95 > >>>> > >> http://www.elegosoft.com | > >> > >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > >>>> Handelregister: Amtsgericht Charlottenburg > HRB > >> 77719 | USt-IdNr: DE163214194 > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > Berlin, > >> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 > >> fax: +49 30 23 45 86 95 > >>> http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf > >> Wagner | Sitz: Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > >> USt-IdNr: DE163214194 > >>> > >> > >> > > > > > > > > > From jay.krell at cornell.edu Fri Feb 19 09:50:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 08:50:36 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <621322.72118.qm@web23603.mail.ird.yahoo.com> References: , <621322.72118.qm@web23603.mail.ird.yahoo.com> Message-ID: - Our system isn't multithreaded enough to benefit from multicore. There are too many globals. Modula-3 allows for and takes advantage of programmers writing "separate headers" in the fashion that all C/C++ programmers do anyway (but which the C/C++ compiler can't take advantage of, but instead parses over and over and over) but it doesn't discourage you to have interfaces that merely manage globals. We might be able to win with a coarse grained parallelism: multiple processes instead of threads - Cygwin is so slow, and has been for so long, I have no hope for it getting much better. Maybe the gcc Makefiles won't create so many processes at some point. It does work to an impressive degree, but is also very slow. NT386 has always been very fast. The other Posix systems are getting better, my newer Intel Mac is closer in speed to NT386 than older PPC Mac. But NT386 is still much faster (on old machine). - to build with user threads, you have tweak m3-libs/m3core/src/threads.quake and build the whole system -- BUT you don't need a new compiler Just: edit that file cd $CVSROOT/scripts/python ./do-cm3-std.py realclean ./do-cm3-std.py buildship I again really strongly suggest we should either: - have multiple platforms, so there are regular builds, people can just install I386_LINUX_USERTHREADS, I386_FREEBSD_USERTHREADS, etc. - make it an @M3 option You cannot just drop in a replacement m3core.so. The types aren't sufficiently the same. - Jay ---------------------------------------- > Date: Fri, 19 Feb 2010 06:20:10 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > HI: > thanks for answering so fast! > Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. > First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup > > more or less it makes you to do > cvsupd -b /diska/cvsup/base/ > which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) > Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: > > (First command and executing after it the client with .sup file given there in the web page) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > OK 17 0 2009-07-20 14:06:34 CVSup server ready > Connection closed by foreign host. > > (After, second command it doesn't wait anything or if some client request, it just finish like this) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > > > Connection closed by foreign host. > % pwd > > > seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. > (m3gdb) file LINUXLIBC6/cvsupd > Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) break src/Main.m3:BecomeDaemon > No source file named src/Main.m3. > Make breakpoint pending on future shared library load? (y or [n]) y > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > (m3gdb) set follow-fork-mode child > (m3gdb) run > Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > Signal Stop Print Pass to program Description > SIG64 No No Yes Real-time event 64 > [Thread debugging using libthread_db enabled] > [Nuevo LWP 5074] > [Nuevo Thread -1221278032 (LWP 5074)] > > > In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. > I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. > > About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. > > Thanks in advance, > > --- El jue, 18/2/10, Jay K escribi?: > >> De: Jay K >> Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics >> Para: "Daniel (M3)" , "Olaf" , "m3devel" >> Fecha: jueves, 18 de febrero, 2010 23:54 >> >> https://projects.elego.de/cm3/ticket/1080 >> can you provide the cvsup configuration file? Thanks. >> Can you try building with user threads and see if it >> occurs? >> Or on another platform? >> >> >> This is definitely something we want to look into. >> >> >> NT386GNU is there and worked for me, but it is slow. >> It had 64bit longint way ahead of NT386, but NT386 is there >> now. >> There is also NT386MINGNU. >> >> >> More testing definitely appreciated. >> >> >> Thanks, >> - Jay >> >> >> ---------------------------------------- >>> Date: Fri, 19 Feb 2010 03:07:36 +0000 >>> From: dabenavidesd at yahoo.es >>> Subject: Re: [M3devel] More testing needed for m3back, >> was: RE: m3back/longint/atomics >>> To: wagner at elegosoft.com; >> m3devel at elegosoft.com; >> jay.krell at cornell.edu >>> >>> Hi all: >>> great news to hear about a release coming soon, but >> how about testing NT386GNU or derivatives of it, would be >> hard to set up (I might try a friend's machine). >>> As I understood that was a great port to new Modula-3 >> programmers coming into the M3 world from win world. This >> doesn't have the all packages but is this a must to give >> have a check to release this port? >>> Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 >> ? >>> Is there any chance to bring those platforms in final >> release? >>> Any difficulties to start trying that? >>> Thanks in advance >>> >>> --- El jue, 18/2/10, Jay K escribi?: >>> >>>> De: Jay K >>>> Asunto: Re: [M3devel] More testing needed for >> m3back, was: RE: m3back/longint/atomics >>>> Para: "Olaf" , "m3devel" >>>> Fecha: jueves, 18 de febrero, 2010 16:26 >>>> >>>> >>>> >>>> >>>> >>>> I added some testing, found/fixed bugs in the gcc >>>> backend (initializing constants, division). >>>> >>>> They should be in the automated tests already. >>>> >>>> However don't let this stop you from doing >>>> everything/anything you can think of. >>>> >>>> I didn't do all that much and you can save time >> and get >>>> more done by not worrying >>>> >>>> about the duplication. >>>> >>>> Pickles I didn't do anything with at all, so if >> you >>>> really want to avoid/delay duplication, >>>> >>>> start with them. >>>> >>>> >>>> >>>> - Jay >>>> >>>> >>>>> Date: Thu, 18 Feb 2010 17:20:56 +0100 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] More testing needed for >> m3back, >>>> was: RE: m3back/longint/atomics >>>>> >>>>> Quoting "Coleburn, Randy" >>>> : >>>>> >>>>>> I can certainly run some tests on >> Windows. >>>>>> >>>>>> I don't have any code that uses longint, >> so >>>> either someone needs to >>>>>> identify which existing programs I can >> build and >>>> run to do the >>>>>> tests, OR I suppose I can write something >> if you >>>> can give me an idea >>>>>> of how extensive the tests you want. >>>>> >>>>> This sounds good! >>>>> >>>>> Some things that come to mind for LONGINT >>>> immeditately: >>>>> >>>>> o standard integer arithmetic (+, -, *, DIV, >> MOD) at >>>> runtime, >>>>> with and without overflows etc. >>>>> o constant declarations >>>>> o constant expressions >>>>> o assignability (should be rather strict; I'd >> have >>>> to check the mail >>>>> archive for the details) >>>>> o pickles >>>>> >>>>> It would be great if you could add some tests >> to >>>> m3tests that are >>>>> valid on all platforms. I expect that some >> should >>>> already be in place, >>>>> but haven't checked yet... >>>>> >>>>> Hm, a quick search for longint in >>>>> >>>>> >>>> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ >>>>> >>>>> for example doesn't find anything. Has nobody >>>> added any LONGINT >>>>> test yet? Probably I'm looking for the wrong >>>> string... >>>>> >>>>> A complete regression with cm3 and other >> programs you >>>> may have available >>>>> would be great, too, just to make sure that >> the >>>> backend changes >>>>> don't break any old functionality. >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> I've been trying to keep my system updated >> to >>>> the latest sources on >>>>>> the main trunk, but I've been swamped >> lately >>>> and I'm afraid I'm a >>>>>> few weeks stale right now. I'll remedy >> that >>>> shortly. >>>>>> >>>>>> Regards, >>>>>> Randy >>>>>> >>>>>> ________________________________ >>>>>> From: Olaf Wagner [wagner at elegosoft.com] >>>>>> Sent: Thursday, February 18, 2010 6:57 AM >>>>>> To: Jay K >>>>>> Cc: m3devel >>>>>> Subject: [M3devel] More testing needed >> for >>>> m3back, was: RE: >>>>>> m3back/longint/atomics >>>>>> >>>>>> If I understand Jay correctly, it wouldn't >> be >>>> too difficult to bring >>>>>> the m3ack LONGINT changes for Windows into >> the >>>> release branch, but >>>>>> more testing would be needed. >>>>>> >>>>>> Randy, you're the only one I remember >> offhand >>>> who actively uses M3 >>>>>> on Windows except for Jay. Could you have >> a >>>> closer look at it? >>>>>> (Changes are only on the trunk right >> now.) >>>>>> >>>>>> Or is anybody else here lurking and eager >> to do >>>> some Windows-based tests? >>>>>> >>>>>> If nobody volunteers, I'm afraid we will >> have >>>> to release without 64bit >>>>>> LONGINT on Windows. >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting Jay K : >>>>>> >>>>>>> NT386/longint changes are almost >> entirely in >>>> the m3back package. >>>>>>> >>>>>>> There is also some small easy stuff >> in >>>>>>> >> m3-libs/m3core/src/Csupport/common/hand.c. >>>>>>> >>>>>>> It'd be really great if anyone could >> test >>>> any of this and if >>>>>>> anyone could review the diff between >> release >>>> and head. >>>>>>> >>>>>>> Not just me. >>>>>>> >>>>>>> The changes for longint are quite >> large, even >>>> if local. >>>>>>> >>>>>>> I can port them, in the case of >> m3back, just >>>> copy, and make sure >>>>>>> the atomics stuff doesn't cause >> problems >>>> (it should be unused). >>>>>>> >>>>>>> There is also a small change in >> m3front so >>>> that longint can be initialized. >>>>>>> That affects all platforms. >>>>>>> >>>>>>> And a small change in m3cc/parse.c >> for >>>> div/mod of longint on non-NT386. >>>>>>> I have to test mod yet but my fix >> probably >>>> helps it. >>>>>>> >>>>>>> It'd be really great if anyone could >> do >>>> anything with this stuff. >>>>>>> ie. for now in head, then could easily >> port >>>> to release. >>>>>>> >>>>>>> We can of course release either way, >>>> depending on how satisfied people >>>>>>> are with 32bit longint on NT386. i.e. >> longint >>>> isn't useful portably, but it >>>>>>> is useful on non-NT386 platforms. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>>> Date: Tue, 16 Feb 2010 16:12:52 >> +0100 >>>>>>>> From: wagner at elegosoft.com >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] >>>> m3back/longint/atomics >>>>>>>> >>>>>>>> Quoting Jay K >>>> : >>>>>>>> >>>>>>>>> >>>>>>>>> As far as I know/can >> remember, >>>> longint and atomics should all work >>>>>>>>> now on NT386. >>>>>>>>> >>>>>>>>> Atomics only currently for >> 32bit >>>> types. >>>>>>>>> There are still a few small >>>> inefficiencies to maybe deal with. >>>>>>>>> I'll add 64bit shortly and >> maybe >>>> 8 and 16. >>>>>>>>> >>>>>>>>> >>>>>>>>> We should probably add *a lot* >> more >>>> test coverage in p226 and p227. >>>>>>>>> >>>>>>>>> e.g. longint >>>> multiply/add/sub/divide, not just insert/extract >> like I >>>>>>>>> did a bunch of. >>>>>>>> >>>>>>>> Any volunteers to increase the >> test >>>> coverage? >>>>>>>> >>>>>>>>> Still to fix the Win32 >> m3core/libm3 >>>> to not always truncate file sizes. >>>>>>>>> >>>>>>>>> Still maybe to do something >> about >>>> rd/wr...? >>>>>>>>> >>>>>>>>> Still to wonder about >> NT386/longint >>>> support in the release branch? >>>>>>>> >>>>>>>> Should we / will you merge this >> stuff to >>>> the release branch? >>>>>>>> Or should we release without it? >> How >>>> local are the changes? >>>>>>>> >>>>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions >> GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, >> 13355 >>>> Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 >>>> 869 fax: +49 30 23 45 86 95 >>>>>> >>>> http://www.elegosoft.com | >>>> >>>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg >> HRB >>>> 77719 | USt-IdNr: DE163214194 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, >>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >> 869 >>>> fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf >>>> Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | >>>> USt-IdNr: DE163214194 >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From jay.krell at cornell.edu Fri Feb 19 11:43:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 10:43:02 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <621322.72118.qm@web23603.mail.ird.yahoo.com> References: , <621322.72118.qm@web23603.mail.ird.yahoo.com> Message-ID: Daniel, if you really last tried this in 2008, please try again. I'm not sure we had cvsup in our tree in 2008 though. Even if you tried it in 2009, try again? http://aivwiki.alma.cl/index.php/Installing_CVSup points to a particular non-current Modula-3 and a particular cvsup. We have cvsup in our tree now. Which did you use? Please try ours. -Jay > Date: Fri, 19 Feb 2010 06:20:10 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > HI: > thanks for answering so fast! > Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. > First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup > > more or less it makes you to do > cvsupd -b /diska/cvsup/base/ > which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) > Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: > > (First command and executing after it the client with .sup file given there in the web page) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > OK 17 0 2009-07-20 14:06:34 CVSup server ready > Connection closed by foreign host. > > (After, second command it doesn't wait anything or if some client request, it just finish like this) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > > > Connection closed by foreign host. > % pwd > > > seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. > (m3gdb) file LINUXLIBC6/cvsupd > Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) break src/Main.m3:BecomeDaemon > No source file named src/Main.m3. > Make breakpoint pending on future shared library load? (y or [n]) y > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > (m3gdb) set follow-fork-mode child > (m3gdb) run > Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > Signal Stop Print Pass to program Description > SIG64 No No Yes Real-time event 64 > [Thread debugging using libthread_db enabled] > [Nuevo LWP 5074] > [Nuevo Thread -1221278032 (LWP 5074)] > > > In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. > I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. > > About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. > > Thanks in advance, > > --- El jue, 18/2/10, Jay K escribi?: > > > De: Jay K > > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Para: "Daniel (M3)" , "Olaf" , "m3devel" > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > https://projects.elego.de/cm3/ticket/1080 > > can you provide the cvsup configuration file? Thanks. > > Can you try building with user threads and see if it > > occurs? > > Or on another platform? > > > > > > This is definitely something we want to look into. > > > > > > NT386GNU is there and worked for me, but it is slow. > > It had 64bit longint way ahead of NT386, but NT386 is there > > now. > > There is also NT386MINGNU. > > > > > > More testing definitely appreciated. > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > From: dabenavidesd at yahoo.es > > > Subject: Re: [M3devel] More testing needed for m3back, > > was: RE: m3back/longint/atomics > > > To: wagner at elegosoft.com; > > m3devel at elegosoft.com; > > jay.krell at cornell.edu > > > > > > Hi all: > > > great news to hear about a release coming soon, but > > how about testing NT386GNU or derivatives of it, would be > > hard to set up (I might try a friend's machine). > > > As I understood that was a great port to new Modula-3 > > programmers coming into the M3 world from win world. This > > doesn't have the all packages but is this a must to give > > have a check to release this port? > > > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 > > ? > > > Is there any chance to bring those platforms in final > > release? > > > Any difficulties to start trying that? > > > Thanks in advance > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > >> De: Jay K > > >> Asunto: Re: [M3devel] More testing needed for > > m3back, was: RE: m3back/longint/atomics > > >> Para: "Olaf" , "m3devel" > > >> Fecha: jueves, 18 de febrero, 2010 16:26 > > >> > > >> > > >> > > >> > > >> > > >> I added some testing, found/fixed bugs in the gcc > > >> backend (initializing constants, division). > > >> > > >> They should be in the automated tests already. > > >> > > >> However don't let this stop you from doing > > >> everything/anything you can think of. > > >> > > >> I didn't do all that much and you can save time > > and get > > >> more done by not worrying > > >> > > >> about the duplication. > > >> > > >> Pickles I didn't do anything with at all, so if > > you > > >> really want to avoid/delay duplication, > > >> > > >> start with them. > > >> > > >> > > >> > > >> - Jay > > >> > > >> > > >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 > > >>> From: wagner at elegosoft.com > > >>> To: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] More testing needed for > > m3back, > > >> was: RE: m3back/longint/atomics > > >>> > > >>> Quoting "Coleburn, Randy" > > >> : > > >>> > > >>>> I can certainly run some tests on > > Windows. > > >>>> > > >>>> I don't have any code that uses longint, > > so > > >> either someone needs to > > >>>> identify which existing programs I can > > build and > > >> run to do the > > >>>> tests, OR I suppose I can write something > > if you > > >> can give me an idea > > >>>> of how extensive the tests you want. > > >>> > > >>> This sounds good! > > >>> > > >>> Some things that come to mind for LONGINT > > >> immeditately: > > >>> > > >>> o standard integer arithmetic (+, -, *, DIV, > > MOD) at > > >> runtime, > > >>> with and without overflows etc. > > >>> o constant declarations > > >>> o constant expressions > > >>> o assignability (should be rather strict; I'd > > have > > >> to check the mail > > >>> archive for the details) > > >>> o pickles > > >>> > > >>> It would be great if you could add some tests > > to > > >> m3tests that are > > >>> valid on all platforms. I expect that some > > should > > >> already be in place, > > >>> but haven't checked yet... > > >>> > > >>> Hm, a quick search for longint in > > >>> > > >>> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > >>> > > >>> for example doesn't find anything. Has nobody > > >> added any LONGINT > > >>> test yet? Probably I'm looking for the wrong > > >> string... > > >>> > > >>> A complete regression with cm3 and other > > programs you > > >> may have available > > >>> would be great, too, just to make sure that > > the > > >> backend changes > > >>> don't break any old functionality. > > >>> > > >>> Olaf > > >>> > > >>>> > > >>>> I've been trying to keep my system updated > > to > > >> the latest sources on > > >>>> the main trunk, but I've been swamped > > lately > > >> and I'm afraid I'm a > > >>>> few weeks stale right now. I'll remedy > > that > > >> shortly. > > >>>> > > >>>> Regards, > > >>>> Randy > > >>>> > > >>>> ________________________________ > > >>>> From: Olaf Wagner [wagner at elegosoft.com] > > >>>> Sent: Thursday, February 18, 2010 6:57 AM > > >>>> To: Jay K > > >>>> Cc: m3devel > > >>>> Subject: [M3devel] More testing needed > > for > > >> m3back, was: RE: > > >>>> m3back/longint/atomics > > >>>> > > >>>> If I understand Jay correctly, it wouldn't > > be > > >> too difficult to bring > > >>>> the m3ack LONGINT changes for Windows into > > the > > >> release branch, but > > >>>> more testing would be needed. > > >>>> > > >>>> Randy, you're the only one I remember > > offhand > > >> who actively uses M3 > > >>>> on Windows except for Jay. Could you have > > a > > >> closer look at it? > > >>>> (Changes are only on the trunk right > > now.) > > >>>> > > >>>> Or is anybody else here lurking and eager > > to do > > >> some Windows-based tests? > > >>>> > > >>>> If nobody volunteers, I'm afraid we will > > have > > >> to release without 64bit > > >>>> LONGINT on Windows. > > >>>> > > >>>> Olaf > > >>>> > > >>>> Quoting Jay K : > > >>>> > > >>>>> NT386/longint changes are almost > > entirely in > > >> the m3back package. > > >>>>> > > >>>>> There is also some small easy stuff > > in > > >>>>> > > m3-libs/m3core/src/Csupport/common/hand.c. > > >>>>> > > >>>>> It'd be really great if anyone could > > test > > >> any of this and if > > >>>>> anyone could review the diff between > > release > > >> and head. > > >>>>> > > >>>>> Not just me. > > >>>>> > > >>>>> The changes for longint are quite > > large, even > > >> if local. > > >>>>> > > >>>>> I can port them, in the case of > > m3back, just > > >> copy, and make sure > > >>>>> the atomics stuff doesn't cause > > problems > > >> (it should be unused). > > >>>>> > > >>>>> There is also a small change in > > m3front so > > >> that longint can be initialized. > > >>>>> That affects all platforms. > > >>>>> > > >>>>> And a small change in m3cc/parse.c > > for > > >> div/mod of longint on non-NT386. > > >>>>> I have to test mod yet but my fix > > probably > > >> helps it. > > >>>>> > > >>>>> It'd be really great if anyone could > > do > > >> anything with this stuff. > > >>>>> ie. for now in head, then could easily > > port > > >> to release. > > >>>>> > > >>>>> We can of course release either way, > > >> depending on how satisfied people > > >>>>> are with 32bit longint on NT386. i.e. > > longint > > >> isn't useful portably, but it > > >>>>> is useful on non-NT386 platforms. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>>>> Date: Tue, 16 Feb 2010 16:12:52 > > +0100 > > >>>>>> From: wagner at elegosoft.com > > >>>>>> To: m3devel at elegosoft.com > > >>>>>> Subject: Re: [M3devel] > > >> m3back/longint/atomics > > >>>>>> > > >>>>>> Quoting Jay K > > >> : > > >>>>>> > > >>>>>>> > > >>>>>>> As far as I know/can > > remember, > > >> longint and atomics should all work > > >>>>>>> now on NT386. > > >>>>>>> > > >>>>>>> Atomics only currently for > > 32bit > > >> types. > > >>>>>>> There are still a few small > > >> inefficiencies to maybe deal with. > > >>>>>>> I'll add 64bit shortly and > > maybe > > >> 8 and 16. > > >>>>>>> > > >>>>>>> > > >>>>>>> We should probably add *a lot* > > more > > >> test coverage in p226 and p227. > > >>>>>>> > > >>>>>>> e.g. longint > > >> multiply/add/sub/divide, not just insert/extract > > like I > > >>>>>>> did a bunch of. > > >>>>>> > > >>>>>> Any volunteers to increase the > > test > > >> coverage? > > >>>>>> > > >>>>>>> Still to fix the Win32 > > m3core/libm3 > > >> to not always truncate file sizes. > > >>>>>>> > > >>>>>>> Still maybe to do something > > about > > >> rd/wr...? > > >>>>>>> > > >>>>>>> Still to wonder about > > NT386/longint > > >> support in the release branch? > > >>>>>> > > >>>>>> Should we / will you merge this > > stuff to > > >> the release branch? > > >>>>>> Or should we release without it? > > How > > >> local are the changes? > > >>>>>> > > >>>>>> Olaf > > >>>> -- > > >>>> Olaf Wagner -- elego Software Solutions > > GmbH > > >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, > > 13355 > > >> Berlin, Germany > > >>>> phone: +49 30 23 45 86 96 mobile: +49 177 > > 2345 > > >> 869 fax: +49 30 23 45 86 95 > > >>>> > > >> http://www.elegosoft.com | > > >> > > >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > >>>> Handelregister: Amtsgericht Charlottenburg > > HRB > > >> 77719 | USt-IdNr: DE163214194 > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Olaf Wagner -- elego Software Solutions GmbH > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > > Berlin, > > >> Germany > > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 > > 869 > > >> fax: +49 30 23 45 86 95 > > >>> http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf > > >> Wagner | Sitz: Berlin > > >>> Handelregister: Amtsgericht Charlottenburg HRB > > 77719 | > > >> USt-IdNr: DE163214194 > > >>> > > >> > > >> > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 19 15:04:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 19 Feb 2010 15:04:50 +0100 Subject: [M3devel] Reliable CM3 builds, was: Re: Auto-discard notification / CM3 build In-Reply-To: <20100219135528.2061552yxuem8800@webmail.netcom.co.uk> References: <20100218114558.rn033djp4wgs0wsg@mail.elegosoft.com> <20100219135528.2061552yxuem8800@webmail.netcom.co.uk> Message-ID: <20100219150450.jh85hsh5skkc04ko@mail.elegosoft.com> Quoting cwr at netcom.co.uk: > Quoting Olaf Wagner : > >> You need to subscribe to the list to be able to post to it. > > Oh well, I was hoping to set up a reliable automatic build process > for CM2, but it looks as if that's not possible. Thanks anyway. I don't really follow you here. If you're talking about CM3, the Hudson continuous integration of the current release branch has been working well for several months now: http://hudson.modula3.com:8080/ I'd call that automatic reliable build process :-) Of course there are problems now and then, but they usually are fixed quickly. The Hudson resources will be retargeted at the main line trunk as soon as the release is finally complete. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Fri Feb 19 16:08:04 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 15:08:04 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <168033.59265.qm@web23601.mail.ird.yahoo.com> Hi: Thanks for your answer. Yes, I tried it in late 2008 as in the web page resulted. Then on mid 2009 with cm3's tree cvsup. I was thinking in a command line switch like to cm3 -DNO_PTHREADS (or cm3 -DUSER_THREADS). Does something like that exist? Yes, I will try it building again to see where it gets with current (cvs release ranch). Do you know which branch I should use cvs like cvs tag release_branch_cm3_5_8 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 ? Thanks in advance, --- El vie, 19/2/10, Jay K escribi?: > De: Jay K > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Daniel (M3)" , "Olaf" , "m3devel" > Fecha: viernes, 19 de febrero, 2010 05:43 > > > > > > Daniel, if you really last tried this in 2008, please > try again. > > I'm not sure we had cvsup in our tree in 2008 though. > > Even if you tried it in 2009, try again? > > http://aivwiki.alma.cl/index.php/Installing_CVSup > points to a particular non-current Modula-3 and a particular > cvsup. > > We have cvsup in our tree now. Which did you use? Please > try ours. > > > > -Jay > > > > Date: Fri, 19 Feb 2010 06:20:10 +0000 > > From: dabenavidesd at yahoo.es > > To: wagner at elegosoft.com; m3devel at elegosoft.com; > jay.krell at cornell.edu > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > > > HI: > > thanks for answering so fast! > > Well, more or less I tried to understand what was > happening on cvsup LINUXLIBC6 on late 2008 quickly and half > a year ago more carefully. > > First I tried with system level threads and the first > connection worked to retrieve files as I remember in this > example case: > http://aivwiki.alma.cl/index.php/Installing_CVSup > > > > more or less it makes you to do > > cvsupd -b /diska/cvsup/base/ > > which works for first client login as is written in > the web page (that happened in my late 2008 try seeing the > above url case as pointed by the person who tried and > reported this at that time) > > Then you had to use background command to cvsupd > (where I think the problem appears but not in the first > process, but in the forked, if forked or in both) > copying/pasting the two commands from the url of case above > mentioned > > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > > This doesn't work (for me in both tries) and the > reason is the problem is when the process forks so there > might somehow a "small" error because process > forked won't work as expectedly (I don't even if it > dies on system) or if and runtime error is given. I just > grabbed this output from terminal: > > > > (First command and executing after it the client with > .sup file given there in the web page) > > % telnet 192.168.0.3 5999 > > Trying 192.168.0.3... > > Connected to 192.168.0.3. > > Escape character is '^]'. > > OK 17 0 2009-07-20 14:06:34 CVSup server ready > > Connection closed by foreign host. > > > > (After, second command it doesn't wait anything or > if some client request, it just finish like this) > > % telnet 192.168.0.3 5999 > > Trying 192.168.0.3... > > Connected to 192.168.0.3. > > Escape character is '^]'. > > > > > > Connection closed by foreign host. > > % pwd > > > > > > seeing docs from and now not found > http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > > Directorio de trabajo > /home/test/code/cm3-cvs/m3-tools/cvsup/server. > > (m3gdb) file LINUXLIBC6/cvsupd > > Reading symbols from > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > > Using host libthread_db library > "/lib/tls/i686/cmov/libthread_db.so.1". > > > > (m3gdb) break src/Main.m3:BecomeDaemon > > No source file named src/Main.m3. > > Make breakpoint pending on future shared library load? > (y or [n]) y > > > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) > pendiente. > > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 > -l /home/test/code/cvsup/log > > (m3gdb) set follow-fork-mode child > > (m3gdb) run > > Starting program: > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd > -b /home/test/code/cvsup/base/ -C 5 -l > /home/test/code/cvsup/log > > Signal Stop Print Pass to program Description > > SIG64 No No Yes Real-time event 64 > > [Thread debugging using libthread_db enabled] > > [Nuevo LWP 5074] > > [Nuevo Thread -1221278032 (LWP 5074)] > > > > > > In the above m3gdb session I did last year a session > on it; I didn't find quite easy to follow track of > forked process to see the stacks of the forked process, I > didn't tried too hard. But I know gdb has a feature to > allow you doing that, but I merely looked into gdb docs > quickly, and thinking it now I should retry to see if m3gdb > could get these days into that. Hints here or some advise > would be appreciated, perhaps Rodney has a better idea of > status of this feature on current m3gdb. > > I don't know how to build with user-level threads, > first I think I must recompile from bootstrap switched to > user-level threads, right? I would appreciate any help on > how to do that. > > > > About the case of NT386GNU and alternatives, I expect > this tools gets optimized over the time more and more, which > is the case for other platforms systems, current multi-core > machines shows the speed up as you might have compared in > over all compile time with older systems (wouldn't be a > bad idea to grab those statistics from m3quake) to compare > results in M3 terms and probably in over-all process if > possible. There could be a similar performance or at least a > constant reduction in number of seconds each time it gets a > better platform. > > > > Thanks in advance, > > > > --- El jue, 18/2/10, Jay K > escribi?: > > > > > De: Jay K > > > Asunto: RE: [M3devel] More testing needed for > m3back, was: RE: m3back/longint/atomics > > > Para: "Daniel (M3)" > , "Olaf" > , "m3devel" > > > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > > > https://projects.elego.de/cm3/ticket/1080 > > > can you provide the cvsup configuration file? > Thanks. > > > Can you try building with user threads and see if > it > > > occurs? > > > Or on another platform? > > > > > > > > > This is definitely something we want to look > into. > > > > > > > > > NT386GNU is there and worked for me, but it is > slow. > > > It had 64bit longint way ahead of NT386, but > NT386 is there > > > now. > > > There is also NT386MINGNU. > > > > > > > > > More testing definitely appreciated. > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > > From: dabenavidesd at yahoo.es > > > > Subject: Re: [M3devel] More testing needed > for m3back, > > > was: RE: m3back/longint/atomics > > > > To: wagner at elegosoft.com; > > > m3devel at elegosoft.com; > > > jay.krell at cornell.edu > > > > > > > > Hi all: > > > > great news to hear about a release coming > soon, but > > > how about testing NT386GNU or derivatives of it, > would be > > > hard to set up (I might try a friend's > machine). > > > > As I understood that was a great port to new > Modula-3 > > > programmers coming into the M3 world from win > world. This > > > doesn't have the all packages but is this a > must to give > > > have a check to release this port? > > > > Any news from cvsup ticket #1080 > https://projects.elego.de/cm3/ticket/1080 > > > ? > > > > Is there any chance to bring those platforms > in final > > > release? > > > > Any difficulties to start trying that? > > > > Thanks in advance > > > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > > > >> De: Jay K > > > >> Asunto: Re: [M3devel] More testing > needed for > > > m3back, was: RE: m3back/longint/atomics > > > >> Para: "Olaf" , > "m3devel" > > > >> Fecha: jueves, 18 de febrero, 2010 > 16:26 > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> I added some testing, found/fixed bugs > in the gcc > > > >> backend (initializing constants, > division). > > > >> > > > >> They should be in the automated tests > already. > > > >> > > > >> However don't let this stop you from > doing > > > >> everything/anything you can think of. > > > >> > > > >> I didn't do all that much and you > can save time > > > and get > > > >> more done by not worrying > > > >> > > > >> about the duplication. > > > >> > > > >> Pickles I didn't do anything with at > all, so if > > > you > > > >> really want to avoid/delay duplication, > > > >> > > > >> start with them. > > > >> > > > >> > > > >> > > > >> - Jay > > > >> > > > >> > > > >>> Date: Thu, 18 Feb 2010 17:20:56 > +0100 > > > >>> From: wagner at elegosoft.com > > > >>> To: m3devel at elegosoft.com > > > >>> Subject: Re: [M3devel] More testing > needed for > > > m3back, > > > >> was: RE: m3back/longint/atomics > > > >>> > > > >>> Quoting "Coleburn, Randy" > > > >> : > > > >>> > > > >>>> I can certainly run some tests > on > > > Windows. > > > >>>> > > > >>>> I don't have any code that > uses longint, > > > so > > > >> either someone needs to > > > >>>> identify which existing programs > I can > > > build and > > > >> run to do the > > > >>>> tests, OR I suppose I can write > something > > > if you > > > >> can give me an idea > > > >>>> of how extensive the tests you > want. > > > >>> > > > >>> This sounds good! > > > >>> > > > >>> Some things that come to mind for > LONGINT > > > >> immeditately: > > > >>> > > > >>> o standard integer arithmetic (+, -, > *, DIV, > > > MOD) at > > > >> runtime, > > > >>> with and without overflows etc. > > > >>> o constant declarations > > > >>> o constant expressions > > > >>> o assignability (should be rather > strict; I'd > > > have > > > >> to check the mail > > > >>> archive for the details) > > > >>> o pickles > > > >>> > > > >>> It would be great if you could add > some tests > > > to > > > >> m3tests that are > > > >>> valid on all platforms. I expect > that some > > > should > > > >> already be in place, > > > >>> but haven't checked yet... > > > >>> > > > >>> Hm, a quick search for longint in > > > >>> > > > >>> > > > >> > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > >>> > > > >>> for example doesn't find > anything. Has nobody > > > >> added any LONGINT > > > >>> test yet? Probably I'm looking > for the wrong > > > >> string... > > > >>> > > > >>> A complete regression with cm3 and > other > > > programs you > > > >> may have available > > > >>> would be great, too, just to make > sure that > > > the > > > >> backend changes > > > >>> don't break any old > functionality. > > > >>> > > > >>> Olaf > > > >>> > > > >>>> > > > >>>> I've been trying to keep my > system updated > > > to > > > >> the latest sources on > > > >>>> the main trunk, but I've > been swamped > > > lately > > > >> and I'm afraid I'm a > > > >>>> few weeks stale right now. > I'll remedy > > > that > > > >> shortly. > > > >>>> > > > >>>> Regards, > > > >>>> Randy > > > >>>> > > > >>>> > ________________________________ > > > >>>> From: Olaf Wagner > [wagner at elegosoft.com] > > > >>>> Sent: Thursday, February 18, > 2010 6:57 AM > > > >>>> To: Jay K > > > >>>> Cc: m3devel > > > >>>> Subject: [M3devel] More testing > needed > > > for > > > >> m3back, was: RE: > > > >>>> m3back/longint/atomics > > > >>>> > > > >>>> If I understand Jay correctly, > it wouldn't > > > be > > > >> too difficult to bring > > > >>>> the m3ack LONGINT changes for > Windows into > > > the > > > >> release branch, but > > > >>>> more testing would be needed. > > > >>>> > > > >>>> Randy, you're the only one I > remember > > > offhand > > > >> who actively uses M3 > > > >>>> on Windows except for Jay. Could > you have > > > a > > > >> closer look at it? > > > >>>> (Changes are only on the trunk > right > > > now.) > > > >>>> > > > >>>> Or is anybody else here lurking > and eager > > > to do > > > >> some Windows-based tests? > > > >>>> > > > >>>> If nobody volunteers, I'm > afraid we will > > > have > > > >> to release without 64bit > > > >>>> LONGINT on Windows. > > > >>>> > > > >>>> Olaf > > > >>>> > > > >>>> Quoting Jay K : > > > >>>> > > > >>>>> NT386/longint changes are > almost > > > entirely in > > > >> the m3back package. > > > >>>>> > > > >>>>> There is also some small > easy stuff > > > in > > > >>>>> > > > m3-libs/m3core/src/Csupport/common/hand.c. > > > >>>>> > > > >>>>> It'd be really great if > anyone could > > > test > > > >> any of this and if > > > >>>>> anyone could review the diff > between > > > release > > > >> and head. > > > >>>>> > > > >>>>> Not just me. > > > >>>>> > > > >>>>> The changes for longint are > quite > > > large, even > > > >> if local. > > > >>>>> > > > >>>>> I can port them, in the case > of > > > m3back, just > > > >> copy, and make sure > > > >>>>> the atomics stuff > doesn't cause > > > problems > > > >> (it should be unused). > > > >>>>> > > > >>>>> There is also a small change > in > > > m3front so > > > >> that longint can be initialized. > > > >>>>> That affects all platforms. > > > >>>>> > > > >>>>> And a small change in > m3cc/parse.c > > > for > > > >> div/mod of longint on non-NT386. > > > >>>>> I have to test mod yet but > my fix > > > probably > > > >> helps it. > > > >>>>> > > > >>>>> It'd be really great if > anyone could > > > do > > > >> anything with this stuff. > > > >>>>> ie. for now in head, then > could easily > > > port > > > >> to release. > > > >>>>> > > > >>>>> We can of course release > either way, > > > >> depending on how satisfied people > > > >>>>> are with 32bit longint on > NT386. i.e. > > > longint > > > >> isn't useful portably, but it > > > >>>>> is useful on non-NT386 > platforms. > > > >>>>> > > > >>>>> - Jay > > > >>>>> > > > >>>>>> Date: Tue, 16 Feb 2010 > 16:12:52 > > > +0100 > > > >>>>>> From: > wagner at elegosoft.com > > > >>>>>> To: > m3devel at elegosoft.com > > > >>>>>> Subject: Re: [M3devel] > > > >> m3back/longint/atomics > > > >>>>>> > > > >>>>>> Quoting Jay K > > > >> : > > > >>>>>> > > > >>>>>>> > > > >>>>>>> As far as I > know/can > > > remember, > > > >> longint and atomics should all work > > > >>>>>>> now on NT386. > > > >>>>>>> > > > >>>>>>> Atomics only > currently for > > > 32bit > > > >> types. > > > >>>>>>> There are still a > few small > > > >> inefficiencies to maybe deal with. > > > >>>>>>> I'll add 64bit > shortly and > > > maybe > > > >> 8 and 16. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> We should probably > add *a lot* > > > more > > > >> test coverage in p226 and p227. > > > >>>>>>> > > > >>>>>>> e.g. longint > > > >> multiply/add/sub/divide, not just > insert/extract > > > like I > > > >>>>>>> did a bunch of. > > > >>>>>> > > > >>>>>> Any volunteers to > increase the > > > test > > > >> coverage? > > > >>>>>> > > > >>>>>>> Still to fix the > Win32 > > > m3core/libm3 > > > >> to not always truncate file sizes. > > > >>>>>>> > > > >>>>>>> Still maybe to do > something > > > about > > > >> rd/wr...? > > > >>>>>>> > > > >>>>>>> Still to wonder > about > > > NT386/longint > > > >> support in the release branch? > > > >>>>>> > > > >>>>>> Should we / will you > merge this > > > stuff to > > > >> the release branch? > > > >>>>>> Or should we release > without it? > > > How > > > >> local are the changes? > > > >>>>>> > > > >>>>>> Olaf > > > >>>> -- > > > >>>> Olaf Wagner -- elego Software > Solutions > > > GmbH > > > >>>> Gustav-Meyer-Allee 25 / Geb?ude > 12, > > > 13355 > > > >> Berlin, Germany > > > >>>> phone: +49 30 23 45 86 96 > mobile: +49 177 > > > 2345 > > > >> 869 fax: +49 30 23 45 86 95 > > > >>>> > > > >> http://www.elegosoft.com | > > > >> > > > >>>> Gesch?ftsf?hrer: Olaf Wagner | > Sitz: > > > Berlin > > > >>>> Handelregister: Amtsgericht > Charlottenburg > > > HRB > > > >> 77719 | USt-IdNr: DE163214194 > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> Olaf Wagner -- elego Software > Solutions GmbH > > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 > > > Berlin, > > > >> Germany > > > >>> phone: +49 30 23 45 86 96 mobile: > +49 177 2345 > > > 869 > > > >> fax: +49 30 23 45 86 95 > > > >>> http://www.elegosoft.com | > > > Gesch?ftsf?hrer: Olaf > > > >> Wagner | Sitz: Berlin > > > >>> Handelregister: Amtsgericht > Charlottenburg HRB > > > 77719 | > > > >> USt-IdNr: DE163214194 > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jay.krell at cornell.edu Fri Feb 19 22:08:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 21:08:47 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <168033.59265.qm@web23601.mail.ird.yahoo.com> References: , <168033.59265.qm@web23601.mail.ird.yahoo.com> Message-ID: Either head or release_branch_cm3_5_8. Something like cm3 -DNO-PTHREADS should work, yes. My scripts/python doesn't accept extra switches though. You could edit that into them, or use the *.sh files. Or edit m3-libs\m3core\src\thread.quake as I said. Thanks, - Jay > Date: Fri, 19 Feb 2010 15:08:04 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Hi: > Thanks for your answer. Yes, I tried it in late 2008 as in the web page resulted. Then on mid 2009 with cm3's tree cvsup. > I was thinking in a command line switch like to cm3 -DNO_PTHREADS (or cm3 -DUSER_THREADS). Does something like that exist? > Yes, I will try it building again to see where it gets with current (cvs release ranch). Do you know which branch I should use cvs like > cvs tag release_branch_cm3_5_8 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 ? > > > Thanks in advance, > > --- El vie, 19/2/10, Jay K escribi?: > > > De: Jay K > > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Para: "Daniel (M3)" , "Olaf" , "m3devel" > > Fecha: viernes, 19 de febrero, 2010 05:43 > > > > > > > > > > > > Daniel, if you really last tried this in 2008, please > > try again. > > > > I'm not sure we had cvsup in our tree in 2008 though. > > > > Even if you tried it in 2009, try again? > > > > http://aivwiki.alma.cl/index.php/Installing_CVSup > > points to a particular non-current Modula-3 and a particular > > cvsup. > > > > We have cvsup in our tree now. Which did you use? Please > > try ours. > > > > > > > > -Jay > > > > > > > Date: Fri, 19 Feb 2010 06:20:10 +0000 > > > From: dabenavidesd at yahoo.es > > > To: wagner at elegosoft.com; m3devel at elegosoft.com; > > jay.krell at cornell.edu > > > Subject: Re: [M3devel] More testing needed for m3back, > > was: RE: m3back/longint/atomics > > > > > > HI: > > > thanks for answering so fast! > > > Well, more or less I tried to understand what was > > happening on cvsup LINUXLIBC6 on late 2008 quickly and half > > a year ago more carefully. > > > First I tried with system level threads and the first > > connection worked to retrieve files as I remember in this > > example case: > > http://aivwiki.alma.cl/index.php/Installing_CVSup > > > > > > more or less it makes you to do > > > cvsupd -b /diska/cvsup/base/ > > > which works for first client login as is written in > > the web page (that happened in my late 2008 try seeing the > > above url case as pointed by the person who tried and > > reported this at that time) > > > Then you had to use background command to cvsupd > > (where I think the problem appears but not in the first > > process, but in the forked, if forked or in both) > > copying/pasting the two commands from the url of case above > > mentioned > > > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > > > This doesn't work (for me in both tries) and the > > reason is the problem is when the process forks so there > > might somehow a "small" error because process > > forked won't work as expectedly (I don't even if it > > dies on system) or if and runtime error is given. I just > > grabbed this output from terminal: > > > > > > (First command and executing after it the client with > > .sup file given there in the web page) > > > % telnet 192.168.0.3 5999 > > > Trying 192.168.0.3... > > > Connected to 192.168.0.3. > > > Escape character is '^]'. > > > OK 17 0 2009-07-20 14:06:34 CVSup server ready > > > Connection closed by foreign host. > > > > > > (After, second command it doesn't wait anything or > > if some client request, it just finish like this) > > > % telnet 192.168.0.3 5999 > > > Trying 192.168.0.3... > > > Connected to 192.168.0.3. > > > Escape character is '^]'. > > > > > > > > > Connection closed by foreign host. > > > % pwd > > > > > > > > > seeing docs from and now not found > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > > > > > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > > > Directorio de trabajo > > /home/test/code/cm3-cvs/m3-tools/cvsup/server. > > > (m3gdb) file LINUXLIBC6/cvsupd > > > Reading symbols from > > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > > > Using host libthread_db library > > "/lib/tls/i686/cmov/libthread_db.so.1". > > > > > > (m3gdb) break src/Main.m3:BecomeDaemon > > > No source file named src/Main.m3. > > > Make breakpoint pending on future shared library load? > > (y or [n]) y > > > > > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) > > pendiente. > > > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 > > -l /home/test/code/cvsup/log > > > (m3gdb) set follow-fork-mode child > > > (m3gdb) run > > > Starting program: > > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd > > -b /home/test/code/cvsup/base/ -C 5 -l > > /home/test/code/cvsup/log > > > Signal Stop Print Pass to program Description > > > SIG64 No No Yes Real-time event 64 > > > [Thread debugging using libthread_db enabled] > > > [Nuevo LWP 5074] > > > [Nuevo Thread -1221278032 (LWP 5074)] > > > > > > > > > In the above m3gdb session I did last year a session > > on it; I didn't find quite easy to follow track of > > forked process to see the stacks of the forked process, I > > didn't tried too hard. But I know gdb has a feature to > > allow you doing that, but I merely looked into gdb docs > > quickly, and thinking it now I should retry to see if m3gdb > > could get these days into that. Hints here or some advise > > would be appreciated, perhaps Rodney has a better idea of > > status of this feature on current m3gdb. > > > I don't know how to build with user-level threads, > > first I think I must recompile from bootstrap switched to > > user-level threads, right? I would appreciate any help on > > how to do that. > > > > > > About the case of NT386GNU and alternatives, I expect > > this tools gets optimized over the time more and more, which > > is the case for other platforms systems, current multi-core > > machines shows the speed up as you might have compared in > > over all compile time with older systems (wouldn't be a > > bad idea to grab those statistics from m3quake) to compare > > results in M3 terms and probably in over-all process if > > possible. There could be a similar performance or at least a > > constant reduction in number of seconds each time it gets a > > better platform. > > > > > > Thanks in advance, > > > > > > --- El jue, 18/2/10, Jay K > > escribi?: > > > > > > > De: Jay K > > > > Asunto: RE: [M3devel] More testing needed for > > m3back, was: RE: m3back/longint/atomics > > > > Para: "Daniel (M3)" > > , "Olaf" > > , "m3devel" > > > > > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > > > > > https://projects.elego.de/cm3/ticket/1080 > > > > can you provide the cvsup configuration file? > > Thanks. > > > > Can you try building with user threads and see if > > it > > > > occurs? > > > > Or on another platform? > > > > > > > > > > > > This is definitely something we want to look > > into. > > > > > > > > > > > > NT386GNU is there and worked for me, but it is > > slow. > > > > It had 64bit longint way ahead of NT386, but > > NT386 is there > > > > now. > > > > There is also NT386MINGNU. > > > > > > > > > > > > More testing definitely appreciated. > > > > > > > > > > > > Thanks, > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > > > From: dabenavidesd at yahoo.es > > > > > Subject: Re: [M3devel] More testing needed > > for m3back, > > > > was: RE: m3back/longint/atomics > > > > > To: wagner at elegosoft.com; > > > > m3devel at elegosoft.com; > > > > jay.krell at cornell.edu > > > > > > > > > > Hi all: > > > > > great news to hear about a release coming > > soon, but > > > > how about testing NT386GNU or derivatives of it, > > would be > > > > hard to set up (I might try a friend's > > machine). > > > > > As I understood that was a great port to new > > Modula-3 > > > > programmers coming into the M3 world from win > > world. This > > > > doesn't have the all packages but is this a > > must to give > > > > have a check to release this port? > > > > > Any news from cvsup ticket #1080 > > https://projects.elego.de/cm3/ticket/1080 > > > > ? > > > > > Is there any chance to bring those platforms > > in final > > > > release? > > > > > Any difficulties to start trying that? > > > > > Thanks in advance > > > > > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > > > > > >> De: Jay K > > > > >> Asunto: Re: [M3devel] More testing > > needed for > > > > m3back, was: RE: m3back/longint/atomics > > > > >> Para: "Olaf" , > > "m3devel" > > > > >> Fecha: jueves, 18 de febrero, 2010 > > 16:26 > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> I added some testing, found/fixed bugs > > in the gcc > > > > >> backend (initializing constants, > > division). > > > > >> > > > > >> They should be in the automated tests > > already. > > > > >> > > > > >> However don't let this stop you from > > doing > > > > >> everything/anything you can think of. > > > > >> > > > > >> I didn't do all that much and you > > can save time > > > > and get > > > > >> more done by not worrying > > > > >> > > > > >> about the duplication. > > > > >> > > > > >> Pickles I didn't do anything with at > > all, so if > > > > you > > > > >> really want to avoid/delay duplication, > > > > >> > > > > >> start with them. > > > > >> > > > > >> > > > > >> > > > > >> - Jay > > > > >> > > > > >> > > > > >>> Date: Thu, 18 Feb 2010 17:20:56 > > +0100 > > > > >>> From: wagner at elegosoft.com > > > > >>> To: m3devel at elegosoft.com > > > > >>> Subject: Re: [M3devel] More testing > > needed for > > > > m3back, > > > > >> was: RE: m3back/longint/atomics > > > > >>> > > > > >>> Quoting "Coleburn, Randy" > > > > >> : > > > > >>> > > > > >>>> I can certainly run some tests > > on > > > > Windows. > > > > >>>> > > > > >>>> I don't have any code that > > uses longint, > > > > so > > > > >> either someone needs to > > > > >>>> identify which existing programs > > I can > > > > build and > > > > >> run to do the > > > > >>>> tests, OR I suppose I can write > > something > > > > if you > > > > >> can give me an idea > > > > >>>> of how extensive the tests you > > want. > > > > >>> > > > > >>> This sounds good! > > > > >>> > > > > >>> Some things that come to mind for > > LONGINT > > > > >> immeditately: > > > > >>> > > > > >>> o standard integer arithmetic (+, -, > > *, DIV, > > > > MOD) at > > > > >> runtime, > > > > >>> with and without overflows etc. > > > > >>> o constant declarations > > > > >>> o constant expressions > > > > >>> o assignability (should be rather > > strict; I'd > > > > have > > > > >> to check the mail > > > > >>> archive for the details) > > > > >>> o pickles > > > > >>> > > > > >>> It would be great if you could add > > some tests > > > > to > > > > >> m3tests that are > > > > >>> valid on all platforms. I expect > > that some > > > > should > > > > >> already be in place, > > > > >>> but haven't checked yet... > > > > >>> > > > > >>> Hm, a quick search for longint in > > > > >>> > > > > >>> > > > > >> > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > > >>> > > > > >>> for example doesn't find > > anything. Has nobody > > > > >> added any LONGINT > > > > >>> test yet? Probably I'm looking > > for the wrong > > > > >> string... > > > > >>> > > > > >>> A complete regression with cm3 and > > other > > > > programs you > > > > >> may have available > > > > >>> would be great, too, just to make > > sure that > > > > the > > > > >> backend changes > > > > >>> don't break any old > > functionality. > > > > >>> > > > > >>> Olaf > > > > >>> > > > > >>>> > > > > >>>> I've been trying to keep my > > system updated > > > > to > > > > >> the latest sources on > > > > >>>> the main trunk, but I've > > been swamped > > > > lately > > > > >> and I'm afraid I'm a > > > > >>>> few weeks stale right now. > > I'll remedy > > > > that > > > > >> shortly. > > > > >>>> > > > > >>>> Regards, > > > > >>>> Randy > > > > >>>> > > > > >>>> > > ________________________________ > > > > >>>> From: Olaf Wagner > > [wagner at elegosoft.com] > > > > >>>> Sent: Thursday, February 18, > > 2010 6:57 AM > > > > >>>> To: Jay K > > > > >>>> Cc: m3devel > > > > >>>> Subject: [M3devel] More testing > > needed > > > > for > > > > >> m3back, was: RE: > > > > >>>> m3back/longint/atomics > > > > >>>> > > > > >>>> If I understand Jay correctly, > > it wouldn't > > > > be > > > > >> too difficult to bring > > > > >>>> the m3ack LONGINT changes for > > Windows into > > > > the > > > > >> release branch, but > > > > >>>> more testing would be needed. > > > > >>>> > > > > >>>> Randy, you're the only one I > > remember > > > > offhand > > > > >> who actively uses M3 > > > > >>>> on Windows except for Jay. Could > > you have > > > > a > > > > >> closer look at it? > > > > >>>> (Changes are only on the trunk > > right > > > > now.) > > > > >>>> > > > > >>>> Or is anybody else here lurking > > and eager > > > > to do > > > > >> some Windows-based tests? > > > > >>>> > > > > >>>> If nobody volunteers, I'm > > afraid we will > > > > have > > > > >> to release without 64bit > > > > >>>> LONGINT on Windows. > > > > >>>> > > > > >>>> Olaf > > > > >>>> > > > > >>>> Quoting Jay K : > > > > >>>> > > > > >>>>> NT386/longint changes are > > almost > > > > entirely in > > > > >> the m3back package. > > > > >>>>> > > > > >>>>> There is also some small > > easy stuff > > > > in > > > > >>>>> > > > > m3-libs/m3core/src/Csupport/common/hand.c. > > > > >>>>> > > > > >>>>> It'd be really great if > > anyone could > > > > test > > > > >> any of this and if > > > > >>>>> anyone could review the diff > > between > > > > release > > > > >> and head. > > > > >>>>> > > > > >>>>> Not just me. > > > > >>>>> > > > > >>>>> The changes for longint are > > quite > > > > large, even > > > > >> if local. > > > > >>>>> > > > > >>>>> I can port them, in the case > > of > > > > m3back, just > > > > >> copy, and make sure > > > > >>>>> the atomics stuff > > doesn't cause > > > > problems > > > > >> (it should be unused). > > > > >>>>> > > > > >>>>> There is also a small change > > in > > > > m3front so > > > > >> that longint can be initialized. > > > > >>>>> That affects all platforms. > > > > >>>>> > > > > >>>>> And a small change in > > m3cc/parse.c > > > > for > > > > >> div/mod of longint on non-NT386. > > > > >>>>> I have to test mod yet but > > my fix > > > > probably > > > > >> helps it. > > > > >>>>> > > > > >>>>> It'd be really great if > > anyone could > > > > do > > > > >> anything with this stuff. > > > > >>>>> ie. for now in head, then > > could easily > > > > port > > > > >> to release. > > > > >>>>> > > > > >>>>> We can of course release > > either way, > > > > >> depending on how satisfied people > > > > >>>>> are with 32bit longint on > > NT386. i.e. > > > > longint > > > > >> isn't useful portably, but it > > > > >>>>> is useful on non-NT386 > > platforms. > > > > >>>>> > > > > >>>>> - Jay > > > > >>>>> > > > > >>>>>> Date: Tue, 16 Feb 2010 > > 16:12:52 > > > > +0100 > > > > >>>>>> From: > > wagner at elegosoft.com > > > > >>>>>> To: > > m3devel at elegosoft.com > > > > >>>>>> Subject: Re: [M3devel] > > > > >> m3back/longint/atomics > > > > >>>>>> > > > > >>>>>> Quoting Jay K > > > > >> : > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> As far as I > > know/can > > > > remember, > > > > >> longint and atomics should all work > > > > >>>>>>> now on NT386. > > > > >>>>>>> > > > > >>>>>>> Atomics only > > currently for > > > > 32bit > > > > >> types. > > > > >>>>>>> There are still a > > few small > > > > >> inefficiencies to maybe deal with. > > > > >>>>>>> I'll add 64bit > > shortly and > > > > maybe > > > > >> 8 and 16. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> We should probably > > add *a lot* > > > > more > > > > >> test coverage in p226 and p227. > > > > >>>>>>> > > > > >>>>>>> e.g. longint > > > > >> multiply/add/sub/divide, not just > > insert/extract > > > > like I > > > > >>>>>>> did a bunch of. > > > > >>>>>> > > > > >>>>>> Any volunteers to > > increase the > > > > test > > > > >> coverage? > > > > >>>>>> > > > > >>>>>>> Still to fix the > > Win32 > > > > m3core/libm3 > > > > >> to not always truncate file sizes. > > > > >>>>>>> > > > > >>>>>>> Still maybe to do > > something > > > > about > > > > >> rd/wr...? > > > > >>>>>>> > > > > >>>>>>> Still to wonder > > about > > > > NT386/longint > > > > >> support in the release branch? > > > > >>>>>> > > > > >>>>>> Should we / will you > > merge this > > > > stuff to > > > > >> the release branch? > > > > >>>>>> Or should we release > > without it? > > > > How > > > > >> local are the changes? > > > > >>>>>> > > > > >>>>>> Olaf > > > > >>>> -- > > > > >>>> Olaf Wagner -- elego Software > > Solutions > > > > GmbH > > > > >>>> Gustav-Meyer-Allee 25 / Geb?ude > > 12, > > > > 13355 > > > > >> Berlin, Germany > > > > >>>> phone: +49 30 23 45 86 96 > > mobile: +49 177 > > > > 2345 > > > > >> 869 fax: +49 30 23 45 86 95 > > > > >>>> > > > > >> http://www.elegosoft.com | > > > > >> > > > > >>>> Gesch?ftsf?hrer: Olaf Wagner | > > Sitz: > > > > Berlin > > > > >>>> Handelregister: Amtsgericht > > Charlottenburg > > > > HRB > > > > >> 77719 | USt-IdNr: DE163214194 > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> -- > > > > >>> Olaf Wagner -- elego Software > > Solutions GmbH > > > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, > > 13355 > > > > Berlin, > > > > >> Germany > > > > >>> phone: +49 30 23 45 86 96 mobile: > > +49 177 2345 > > > > 869 > > > > >> fax: +49 30 23 45 86 95 > > > > >>> http://www.elegosoft.com | > > > > Gesch?ftsf?hrer: Olaf > > > > >> Wagner | Sitz: Berlin > > > > >>> Handelregister: Amtsgericht > > Charlottenburg HRB > > > > 77719 | > > > > >> USt-IdNr: DE163214194 > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 11:31:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 10:31:06 +0000 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int Message-ID: 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. Or TInt/TWord/.i3/.m3, since they know deeply about it. Having m3back know about them seems a bit off. Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. This is a minor dilemna though. 2) Are you sure having a fixed precision of 8 bytes is correct here? More generally are you sure TInt has the right interface? How does one check for overflow within the precision one cares about? I think I know. I think Chop should return a boolean, as to if the value fits. For that matter, have SignedChop and UnsignedChop. Or TInt.Chop and TWord.Chop. TInt.Chop is already SignedChop. Do the math in 64bits, if that overflows, then overflow. And then truncate to whatever, and that can overflow too. This is related to "you all have convinced me that overflow isn't all that important really, but range checking is". So you in sense defer the overflow. You don't do the complete overflow check at Add or whatever, but then you do a range check converting to a small size. But hm. This will skip "intermediate overflow". Does that matter? 1 billion * 8 / 8 Should that overflow in 32bits? Well, easy enough, do the chop after each operation. I said "defer", but it is brief. 1B * 8 / 8 isn't written as 1* 8 / 8 convert to 32bits but rather 1B * 8 convert to 32bits => failure here / 8 convert to 32bits ? 3) Related to #2. Where should RightShift insert zeros? I guess you chop first, and then it works. Proposed something like: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = CONST extension = 0; VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; But I have to back to your version of m3back and try these out. Very speculative at the moment. Could also leave the data alone upon failure, trivially related to previous: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); BEGIN FOR i := n TO LAST(Int) DO IF r[i] # extension THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := extension; END; RETURN TRUE; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO IF r[i] # 0 THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := 0; END; return TRUE; END Chop; I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. I'd prefer TInt.UnsignedChop and TInt.SignedChop. Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 11:39:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 10:39:13 +0000 Subject: [M3devel] diff -c vs. diff -u Message-ID: For the record, I don't like diff -c. In particular the use of "!" to show a changed line, without showing what was there before. diff -u and plain diff seem better. (Sometimes plain diff is superior, like if there is an unordered list of things, context doesn't matter.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 12:28:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 11:28:18 +0000 Subject: [M3devel] diffs in checkin comments Message-ID: I know I started this, and I'm still undecided, but, right now, the diffs in comments makes it hard to scroll through history, too much distance between versions. e.g. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3 It would be super duper nice if the m3commit mail automatically included the (unified) diffs though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 12:52:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 11:52:21 +0000 Subject: [M3devel] calling conventions (small proposal) Message-ID: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 21 13:34:51 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Feb 2010 13:34:51 +0100 Subject: [M3devel] LONGCARD, release branch... Message-ID: <1266755691.5451.1.camel@faramir.m3w.org> I would like to build release branch from sources.... Where can I get cm3-bin-min which knows about LONGCARD? -- Dragi?a Duri? From jay.krell at cornell.edu Sun Feb 21 13:57:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 12:57:57 +0000 Subject: [M3devel] LONGCARD, release branch... In-Reply-To: <1266755691.5451.1.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> Message-ID: You shouldn't need it. Really. Again. do this: Get almost any old release. I recently used 5.4 on LINUXLIBC6. Maybe that was with head instead of release. cd scripts/python ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py buildship skipgcc - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 21 Feb 2010 13:34:51 +0100 > Subject: [M3devel] LONGCARD, release branch... > > I would like to build release branch from sources.... Where can I get > cm3-bin-min which knows about LONGCARD? > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 14:33:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 13:33:40 +0000 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int Message-ID: I *suspect* the "real" "big" problem is that left and right shift and "plain" shift should take a size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Subject: opacity of Target.Int, overflow of Target.Int Date: Sun, 21 Feb 2010 10:31:06 +0000 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. Or TInt/TWord/.i3/.m3, since they know deeply about it. Having m3back know about them seems a bit off. Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. This is a minor dilemna though. 2) Are you sure having a fixed precision of 8 bytes is correct here? More generally are you sure TInt has the right interface? How does one check for overflow within the precision one cares about? I think I know. I think Chop should return a boolean, as to if the value fits. For that matter, have SignedChop and UnsignedChop. Or TInt.Chop and TWord.Chop. TInt.Chop is already SignedChop. Do the math in 64bits, if that overflows, then overflow. And then truncate to whatever, and that can overflow too. This is related to "you all have convinced me that overflow isn't all that important really, but range checking is". So you in sense defer the overflow. You don't do the complete overflow check at Add or whatever, but then you do a range check converting to a small size. But hm. This will skip "intermediate overflow". Does that matter? 1 billion * 8 / 8 Should that overflow in 32bits? Well, easy enough, do the chop after each operation. I said "defer", but it is brief. 1B * 8 / 8 isn't written as 1* 8 / 8 convert to 32bits but rather 1B * 8 convert to 32bits => failure here / 8 convert to 32bits ? 3) Related to #2. Where should RightShift insert zeros? I guess you chop first, and then it works. Proposed something like: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = CONST extension = 0; VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; But I have to back to your version of m3back and try these out. Very speculative at the moment. Could also leave the data alone upon failure, trivially related to previous: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); BEGIN FOR i := n TO LAST(Int) DO IF r[i] # extension THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := extension; END; RETURN TRUE; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO IF r[i] # 0 THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := 0; END; return TRUE; END Chop; I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. I'd prefer TInt.UnsignedChop and TInt.SignedChop. Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 21 16:17:05 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Feb 2010 16:17:05 +0100 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: References: <1266755691.5451.1.camel@faramir.m3w.org> Message-ID: <1266765425.5451.9.camel@faramir.m3w.org> Can you PLEASE enable other people to use this system, TOO. As we once used it, before all this moving-target-****?????? PLEASE, I just need minimal compiler runtime so I can use STANDARD scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT and RECODE every single time you found it INTERESTING and FUNNY to CHANGE ALL OVER????!!! And I thought I am INSIDE of this development process. Do we really think other people will not be bored by our change-it-all-again-and-again games??? Do I have to spend some fixed weekly time on this list so I won't miss LATEST and GREATEST IDEAS and PRACTICES? Sorry for all this "screaming" but I am really dissapointed to see all this changed AGAIN! What do you people think potentital users of this systems are?? And what measure of torturing people are ready to endure along the way? On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: > ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py > buildship skipgcc -- Dragi?a Duri? From hosking at cs.purdue.edu Sun Feb 21 20:23:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:23:20 -0500 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int In-Reply-To: References: Message-ID: <5637ACC9-D874-48B4-8071-2B1D3375DE7C@cs.purdue.edu> On 21 Feb 2010, at 05:31, Jay K wrote: > 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. > Or TInt/TWord/.i3/.m3, since they know deeply about it. > Having m3back know about them seems a bit off. > Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. > This is a minor dilemna though. Yeah, but it doesn't need to be totally opaque does it? An array of sign-extended bytes in little-endian order seems pretty general. You don't even need to specify the length of the array. I actually contemplated having TInt take open arrays of arbitrary length, with the result array length indicating the precision desired, but didn't do that just to maintain a simple implementation. > 2) Are you sure having a fixed precision of 8 bytes is correct here? There is nothing to stop it having more precision. In fact, increasing the size shouldn't affect any client code (so long as it uses appropriate array constructors to fill the sign in to the end, and performs bounds-checking to results to the desired precision, as well as checking the return values for potential overflow in whatever precision is implemented by TInt). > More generally are you sure TInt has the right interface? > How does one check for overflow within the precision one cares about? Bounds check. > I think I know. > I think Chop should return a boolean, as to if the value fits. No, because you may choose to ignore the high bits yet still want to sign-extend from the precision desired. That is exactly what I do for word operations in the front-end. > For that matter, have SignedChop and UnsignedChop. You should not need these. > Or TInt.Chop and TWord.Chop. What do you need TWord.Chop for. For example, TWord.And(val, Target.Word.max) gives me just the bits I need for a Word.Size full value. Take a look at the (relatively small number of) changes I made to the front-end to do the appropriate checks and conversions. > TInt.Chop is already SignedChop. > > Do the math in 64bits, if that overflows, then overflow. > And then truncate to whatever, and that can overflow too. > This is related to "you all have convinced me that overflow isn't > all that important really, but range checking is". > So you in sense defer the overflow. You don't do the complete > overflow check at Add or whatever, but then you do a range > check converting to a small size. > > But hm. This will skip "intermediate overflow". Does that matter? > 1 billion * 8 / 8 > > > Should that overflow in 32bits? > > > Well, easy enough, do the chop after each operation. > I said "defer", but it is brief. > 1B * 8 / 8 > isn't written as > 1* 8 / 8 > convert to 32bits > > but rather > 1B * 8 > convert to 32bits > => failure here > / 8 > convert to 32bits > > ? > > > 3) Related to #2. > Where should RightShift insert zeros? > I guess you chop first, and then it works. > > > Proposed something like: > > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > CONST extension = 0; > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > > > But I have to back to your version of m3back and try these out. > Very speculative at the moment. > > Could also leave the data alone upon failure, trivially related to previous: > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # extension THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := extension; > END; > RETURN TRUE; > END Chop; > > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # 0 THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := 0; > END; > return TRUE; > END Chop; > > > I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. > I'd prefer TInt.UnsignedChop and TInt.SignedChop. > Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. > > > Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". > (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 20:24:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:24:12 -0500 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int In-Reply-To: References: Message-ID: <3F542805-0277-4334-BBD2-11D33231D22F@cs.purdue.edu> On 21 Feb 2010, at 08:33, Jay K wrote: > I *suspect* the "real" "big" problem is that left and right shift and "plain" shift should take a size. No! Simply mask the bits you want and perform the shift right, or shift left and mask the result. Easy! > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: opacity of Target.Int, overflow of Target.Int > Date: Sun, 21 Feb 2010 10:31:06 +0000 > > 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. > Or TInt/TWord/.i3/.m3, since they know deeply about it. > Having m3back know about them seems a bit off. > Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. > This is a minor dilemna though. > > > 2) Are you sure having a fixed precision of 8 bytes is correct here? > More generally are you sure TInt has the right interface? > How does one check for overflow within the precision one cares about? > I think I know. > I think Chop should return a boolean, as to if the value fits. > For that matter, have SignedChop and UnsignedChop. > Or TInt.Chop and TWord.Chop. > TInt.Chop is already SignedChop. > > Do the math in 64bits, if that overflows, then overflow. > And then truncate to whatever, and that can overflow too. > This is related to "you all have convinced me that overflow isn't > all that important really, but range checking is". > So you in sense defer the overflow. You don't do the complete > overflow check at Add or whatever, but then you do a range > check converting to a small size. > > But hm. This will skip "intermediate overflow". Does that matter? > 1 billion * 8 / 8 > > > Should that overflow in 32bits? > > > Well, easy enough, do the chop after each operation. > I said "defer", but it is brief. > 1B * 8 / 8 > isn't written as > 1* 8 / 8 > convert to 32bits > > but rather > 1B * 8 > convert to 32bits > => failure here > / 8 > convert to 32bits > > ? > > > 3) Related to #2. > Where should RightShift insert zeros? > I guess you chop first, and then it works. > > > Proposed something like: > > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > CONST extension = 0; > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > > > But I have to back to your version of m3back and try these out. > Very speculative at the moment. > > Could also leave the data alone upon failure, trivially related to previous: > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # extension THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := extension; > END; > RETURN TRUE; > END Chop; > > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # 0 THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := 0; > END; > return TRUE; > END Chop; > > > I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. > I'd prefer TInt.UnsignedChop and TInt.SignedChop. > Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. > > > Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". > (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 20:30:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:30:50 -0500 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <1266765425.5451.9.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> <1266765425.5451.9.camel@faramir.m3w.org> Message-ID: <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> Hi Dragisa, I too am a luddite and have never used any of Jay's scripts. I even still have essentially the same *old* monolithic config files on my system. Here is the general strategy. Take an old release. Compile and ship the following in order... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *old* libraries (m3core, libm3, sysutils). Now, compile and ship new libraries using the new compiler... m3core libm3 sysutils And build a new compiler against the new libraries... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *new* libraries. You should now be able to rebuild everything using the new compiler. Hope this helps! -- Tony (PS Let me know if you have any problems with this. I have a feeling there are some tweaks I have made to the m3makefiles to make this go through smoothly.) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 21 Feb 2010, at 10:17, Dragi?a Duri? wrote: > Can you PLEASE enable other people to use this system, TOO. As we once > used it, before all this moving-target-****?????? > > PLEASE, I just need minimal compiler runtime so I can use STANDARD > scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT > and RECODE every single time you found it INTERESTING and FUNNY to > CHANGE ALL OVER????!!! > > And I thought I am INSIDE of this development process. Do we really > think other people will not be bored by our > change-it-all-again-and-again games??? Do I have to spend some fixed > weekly time on this list so I won't miss LATEST and GREATEST IDEAS and > PRACTICES? > > Sorry for all this "screaming" but I am really dissapointed to see all > this changed AGAIN! What do you people think potentital users of this > systems are?? And what measure of torturing people are ready to endure > along the way? > > > On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: >> ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py >> buildship skipgcc > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 21 21:09:28 2010 From: darko at darko.org (Darko) Date: Mon, 22 Feb 2010 07:09:28 +1100 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:09:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:09:28 +0000 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> References: <1266755691.5451.1.camel@faramir.m3w.org>, , <1266765425.5451.9.camel@faramir.m3w.org>, <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> Message-ID: Dragisa, I didn't change or break anything here. You can use the older upgrade.sh, or you can do what Tony said. None of the options seem to be well known, neither mine nor the old ways. I find Tony's steps long and tedious, so much so that he made some mistakes below (sysutils isn't in old releases, so needs to be in the first pass (and the second pass), m3cc is needed at some point). Obviously others did too, as they where automated first in the *.sh files. Who can remember that order? I just made it all easier, automated, portable, maintainable. And I did it years ago. For some definition of easier/automated/portable/maintable. To me .sh is not maintainable, and .py is more portable -- I'd rather depend on Python than Cygwin. Writing .sh that works across Linux, *BSD, Solaris, seems to be quite a battle. I can't remember all the rules for "how to write portable .sh" (see the Autoconf documentation), and I witness Olaf struggle with that too, I can hardly grasp the .sh language in the first place, and I suspect it is "overly string based", in the genre of severely flawed languages like cmd and Tcl. (Look at what '{' and '}' mean in Tcl. They aren't lexically scoping, as they appear to be, they are actually a string escape mechanism.) However I still don't have OpenBSD/mips64 Python, and I use *.sh there (haven't been there in a while, small probably with libffi). The automated builds use mostly *.sh, though making the .msis and .debs use Python. Given a system - not written in C - with necessary circular dependencies - that doesn't use make/autoconf Not necessarily bad things any of them (circular dependencies are just unavoidable), it's never going to be among the easiest to build. Since I do occasionally go back to old releases, and find running cminstall annoying, I've made the current config files compatible with older releases. The .py scripts do upgrade them first. Where .sh probably doesn't. We do provide prebuilt binaries, just that I don't always know where to get them esp. up to date ones. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 14:30:50 -0500 To: dragisha at m3w.org CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] LONGCARD, release branch... A R G H Hi Dragisa, I too am a luddite and have never used any of Jay's scripts. I even still have essentially the same *old* monolithic config files on my system. Here is the general strategy. Take an old release. Compile and ship the following in order... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *old* libraries (m3core, libm3, sysutils). Now, compile and ship new libraries using the new compiler... m3core libm3 sysutils And build a new compiler against the new libraries... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *new* libraries. You should now be able to rebuild everything using the new compiler. Hope this helps! -- Tony (PS Let me know if you have any problems with this. I have a feeling there are some tweaks I have made to the m3makefiles to make this go through smoothly.) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 21 Feb 2010, at 10:17, Dragi?a Duri? wrote: Can you PLEASE enable other people to use this system, TOO. As we once used it, before all this moving-target-****?????? PLEASE, I just need minimal compiler runtime so I can use STANDARD scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT and RECODE every single time you found it INTERESTING and FUNNY to CHANGE ALL OVER????!!! And I thought I am INSIDE of this development process. Do we really think other people will not be bored by our change-it-all-again-and-again games??? Do I have to spend some fixed weekly time on this list so I won't miss LATEST and GREATEST IDEAS and PRACTICES? Sorry for all this "screaming" but I am really dissapointed to see all this changed AGAIN! What do you people think potentital users of this systems are?? And what measure of torturing people are ready to endure along the way? On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py buildship skipgcc -- Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:16:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:16:38 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Message-ID: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 21:54:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 15:54:13 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> Message-ID: <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 21 21:51:07 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 21 Feb 2010 15:51:07 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> Message-ID: <20100221205107.GD17113@topoi.pooq.com> On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the > NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl The first time I read this, I think I misunderstood. Presumably you don't mean that *all* platforms should ignore. You mean that NT386/I386_CYGWIN/etc. should still interpret them? -- hendrik From hosking at cs.purdue.edu Sun Feb 21 22:42:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 16:42:06 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Message-ID: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:47:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:47:31 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <20100221205107.GD17113@topoi.pooq.com> References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <20100221205107.GD17113@topoi.pooq.com> Message-ID: Right, of course. - Jay > Date: Sun, 21 Feb 2010 15:51:07 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] calling conventions (small proposal) > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > > > 1) All platforms should accept, but silently ignore, the > > NT386/I386_CYGWIN/etc. calling conventions: > > at least __stdcall, and __cdecl > > The first time I read this, I think I misunderstood. Presumably you > don't mean that *all* platforms should ignore. You mean that > NT386/I386_CYGWIN/etc. should still interpret them? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:48:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:48:31 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Message-ID: Its meaning varies per platform. On platforms it changes the calling convention. On other platforms it means do nothing. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:42:06 -0500 CC: darko at darko.org; m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 22:52:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 16:52:20 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> Message-ID: The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage some. >> >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. Besides, as long as no platform uses >> the same name to mean multiple things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 21 22:47:58 2010 From: darko at darko.org (Darko) Date: Mon, 22 Feb 2010 08:47:58 +1100 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Message-ID: <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 10:52:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 09:52:21 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 22 15:39:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Feb 2010 15:39:11 +0100 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <1266765425.5451.9.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> <1266765425.5451.9.camel@faramir.m3w.org> Message-ID: <20100222153911.chn7guy1w4gs00s0@mail.elegosoft.com> Quoting Dragi?a Duri? : > Can you PLEASE enable other people to use this system, TOO. As we once > used it, before all this moving-target-****?????? > > PLEASE, I just need minimal compiler runtime so I can use STANDARD > scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT > and RECODE every single time you found it INTERESTING and FUNNY to > CHANGE ALL OVER????!!! > > And I thought I am INSIDE of this development process. Do we really > think other people will not be bored by our > change-it-all-again-and-again games??? Do I have to spend some fixed > weekly time on this list so I won't miss LATEST and GREATEST IDEAS and > PRACTICES? > > Sorry for all this "screaming" but I am really dissapointed to see all > this changed AGAIN! What do you people think potentital users of this > systems are?? And what measure of torturing people are ready to endure > along the way? Hi Dragisha, I don't think that anything has changed or become broken recently regarding the cm3 build, too. If you want to avoid the tedious upgrade path, you can always find some recent executables in the Hudson jobs' workspaces. They only follow the release branch currently though. For example, look at http://hudson.modula3.com:8080/job/cm3-build-LINUXLIBC6/ws/cm3/m3-sys/cm3/LINUXLIBC6/ for the Linux 32 bit platform. If the build isn't in progress right when you look, you should find the last built cm3 there. Of course you can do that for other target platforms, too, as long as the servers are up. I haven't started building RC5 yet, as more testing is going on for the 64 bit LONGINT changes in the integrated Windows backend. So there is no `official' package giving you the latest state as you seem to require. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 22 15:43:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Feb 2010 15:43:50 +0100 Subject: [M3devel] diffs in checkin comments In-Reply-To: References: Message-ID: <20100222154350.npvj1ypb4kokcows@mail.elegosoft.com> Quoting Jay K : > I know I started this, and I'm still undecided, but, right now, the > diffs in comments makes it hard to scroll through history, too much > distance between versions. e.g. > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3 Well, yes, actually diffs are derivable information and shouldn't be stored in the change log. > It would be super duper nice if the m3commit mail automatically > included the (unified) diffs though. Jay, I haven't got the time, but we would need to adapt one of the Perl scripts in the CVSROOT of cm3 to do that. I don't know how difficult it would be (and won't try as I'm not really good in Perl and haven't got the time right now), but a decent Perl hacker should be able to do the job quickly ;-) Any volunteers? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 22 17:01:57 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 11:01:57 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 22:10:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 21:10:08 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Message-ID: >> But why would you have platform-dependent pragmas in code that is not platform-dependent? example of mostly portable + pragma: ? hand.c: ? #if !defined(_MSC_VER) && !defined(__stdcall) #define __stdcall /* nothing */ #endif ? void __stdcall set_singleton ANSI(( ulong a, ulong* s)) KR((a, s) ulong a; ulong* s;) { ulong a_word = a / SET_GRAIN; ulong a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } ? (gcc on Windows #defines __stdcall to __attribute__(something)) ? Not the best example -- this function doesn't seem well motivated. We probably need a CG.i3 function to do div and mod in one go, since the processors usually expose that. Though this case is with a constant power of two, so.. And m3front would be a little pressed to notice the opportunity? - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 11:01:57 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 22:31:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 21:31:04 +0000 Subject: [M3devel] "pragmas being ignorable" In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: > I thought that was the point of pragmas, that the compiler could freely ignore them and that they > did not involve the correctness of the program. This confuses me. I'm not sure I see the line between having important meaning and having ignorable meaning. Is it like, they affect only codegen and diagnostics but not front end type/semantic analysis? Like "inline" and "nowarn"? <* asserts *> definitely change the behavior of a program. But I guess "behavior" and "correctness" are different? A "correct" program will never fail an assert, therefore removing them from a "correct" program makes no difference? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 22 23:45:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 17:45:12 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Message-ID: This is C code... On 22 Feb 2010, at 16:10, Jay K wrote: > >> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a constant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different than "ign! ore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, ! as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 22 23:46:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 17:46:14 -0500 Subject: [M3devel] "pragmas being ignorable" In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: <69ACB693-C6BA-4165-B901-F82F3FCBAD4E@cs.purdue.edu> On 22 Feb 2010, at 16:31, Jay K wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they > > did not involve the correctness of the program. > > This confuses me. I'm not sure I see the line between having > important meaning and having ignorable meaning. > Is it like, they affect only codegen and diagnostics but not > front end type/semantic analysis? Like "inline" and "nowarn"? Yes. > <* asserts *> definitely change the behavior of a program. > But I guess "behavior" and "correctness" are different? Asserts are benign so long as the program never violates the assertion. > A "correct" program will never fail an assert, therefore > removing them from a "correct" program makes no difference? Correct! And there is a compiler flag that lets you compile with assertions turned off... > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 23:59:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 22:59:36 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , Message-ID: There is an analog to Modula-3. Setting the calling convention on platforms that have them. "Doing nothing" on others. - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 17:45:12 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) This is C code... On 22 Feb 2010, at 16:10, Jay K wrote: >> But why would you have platform-dependent pragmas in code that is not platform-dependent? example of mostly portable + pragma: ? hand.c: ? #if !defined(_MSC_VER) && !defined(__stdcall) #define __stdcall /* nothing */ #endif ? void __stdcall set_singleton ANSI(( ulong a, ulong* s)) KR((a, s) ulong a; ulong* s;) { ulong a_word = a / SET_GRAIN; ulong a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } ? (gcc on Windows #defines __stdcall to __attribute__(something)) ? Not the best example -- this function doesn't seem well motivated. We probably need a CG.i3 function to do div and mod in one go, since the processors usually expose that. Though this case is with a constant power of two, so.. And m3front would be a little pressed to notice the opportunity? - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 11:01:57 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ign! ore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gr! atuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. ! Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, ! as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 23 02:05:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 20:05:46 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , Message-ID: <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? Again, I am very wary of platform-dependent pragmas in supposedly portable code! Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 17:59, Jay K wrote: > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > > >> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Feb 23 02:20:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 01:20:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> References: , ,,<8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , ,,<79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, ,,, ,,<477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, ,,<6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , ,,, ,,, , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> Message-ID: Two parts (sort of). 1) We do have what you describe -- __stdcall C code that Modula-3 calls. And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. I hope to get rid of that duplication. Later rather than earlier. 2) I want to write Modula-3 code that is __stdcall. We already have this, in platform specific code, e.g. the parameter to CreateThread. However I want to write code that is "otherwise" portable. In particular the replacements for hand.c Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:05:46 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > > > So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? > Again, I am very wary of platform-dependent pragmas in supposedly portable code! > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 17:59, Jay K wrote: > > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > >>> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > > From hosking at cs.purdue.edu Tue Feb 23 03:11:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 21:11:27 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> Message-ID: Why would Modula-3 coded versions of hand.c need calling conventions? They are Modula-3 code which will use the standard Modula-3 calling convention to call from Modula-3! On 22 Feb 2010, at 20:20, Jay K wrote: > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> From jay.krell at cornell.edu Tue Feb 23 03:27:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 02:27:40 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , ,,<8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , ,,<79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, ,,, ,,<477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, ,,<6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , ,,, ,,, , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> , Message-ID: > the standard Modula-3 calling convention I'm not sure I'm happy with the standard Modula-3 calling convention. It isn't the smaller one. - Jay ---------------------------------------- > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 21:11:27 -0500 > CC: m3devel at elegosoft.com; darko at darko.org > To: jay.krell at cornell.edu > > Why would Modula-3 coded versions of hand.c need calling conventions? They are Modula-3 code which will use the standard Modula-3 calling convention to call from Modula-3! > > > On 22 Feb 2010, at 20:20, Jay K wrote: > >> >> Two parts (sort of). >> >> >> 1) >> We do have what you describe -- __stdcall C code that Modula-3 calls. >> And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. >> I hope to get rid of that duplication. Later rather than earlier. >> >> >> >> 2) >> I want to write Modula-3 code that is __stdcall. >> We already have this, in platform specific code, e.g. the parameter to CreateThread. >> However I want to write code that is "otherwise" portable. >> In particular the replacements for hand.c >> >> >> Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. >> >> >> >> 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). >> >> >> 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. >> >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 20:05:46 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> >>> >>> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >>> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 22 Feb 2010, at 17:59, Jay K wrote: >>> >>> There is an analog to Modula-3. >>> Setting the calling convention on platforms that have them. >>> "Doing nothing" on others. >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 17:45:12 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> This is C code... >>> >>> On 22 Feb 2010, at 16:10, Jay K wrote: >>> >>>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> >>> example of mostly portable + pragma: >>> >>> ? >>> hand.c: >>> ? >>> #if !defined(_MSC_VER) && !defined(__stdcall) >>> #define __stdcall /* nothing */ >>> #endif >>> ? >>> void __stdcall set_singleton >>> ANSI(( ulong a, ulong* s)) >>> KR((a, s) ulong a; ulong* s;) >>> { >>> ulong a_word = a / SET_GRAIN; >>> ulong a_bit = a % SET_GRAIN; >>> s[a_word] |= (1UL << a_bit); >>> } >>> ? >>> >>> (gcc on Windows #defines __stdcall to __attribute__(something)) >>> ? >>> >>> Not the best example -- this function doesn't seem well motivated. >>> We probably need a CG.i3 function to do div and mod in one go, since >>> the processors usually expose that. >>> Though this case is with a co! nstant power of two, so.. >>> And m3front would be a little pressed to notice the opportunity? >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 11:01:57 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> Pragmas should never give errors. >>> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 22 Feb 2010, at 04:52, Jay K wrote: >>> >>> I wouldn't mind >>> - an error >>> - or a way to mark a pragma as needing an error vs. being ok with a warning >>> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >>> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >>> the syntax is, but there is a legitimate need to note calling conventions, >>> a syntax is already in use. I'd rather not invent a new syntax. >>> >>> >>> The word "ignore" isn't relevant. >>> Sorry if I was confusing. >>> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >>> but that most platforms interpret them as doing nothing. >>> The pragmas already exist. >>> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 16:52:20 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> The compiler does continue to compile having warned that the pragma has no meaning. >>> >>> So, yes, they are ignored, but I want a warning. >>> >>> I even want a warning if I write <**>. >>> >>> >>> On 21 Feb 2010, at 16:47, Darko wrote: >>> >>> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >>> >>> >>> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >>> >>> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >>> >>> On 21 Feb 2010, at 16:16, Jay K wrote: >>> >>> To be clear, I don't propose ignoring all unrecognized pragmas. >>> Just calling conventions. >>> You could interpret it as: >>> The pragmas *are* recognized, on all targets, but they have no meaning on most. >>> The meaning is "do nothing". >>> >>> >>> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >>> with I386_NT source. And they all mean nothing. This lets people maintain >>> one portable code base, and they *don't* even need to do so much as: >>> #ifndef _X86_ >>> #define __stdcall /* nothing */ >>> #define __cdecl /* nothing */ >>> #define __fastcall /* nothing */ >>> #endif >>> >>> >>> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >>> The rest are a pointless proliferation of synonyms. >>> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >>> a few minutes, that's not the issue). >>> >>> >>> Separate file would work, but I'd really rather stuff be all together. >>> Once you separate things, one version goes stale. >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 15:54:13 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> Accepting and silently ignoring sounds very dangerous! >>> >>> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >>> >>> Silence is deadly! >>> >>> On 21 Feb 2010, at 15:09, Darko wrote: >>> >>> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >>> >>> >>> >>> On 21/02/2010, at 10:52 PM, Jay K wrote: >>> >>> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >>> at least __stdcall, and __cdecl >>> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >>> >>> This is a very small change. >>> >>> >>> This is will allow: >>> a) possibly merging the two nearly identical OpenGL.i3 files >>> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >>> I intend to that for hand.c's replacement, soon. >>> >>> >>> Maybe experiment as to the perf. >>> __stdcall is supposed to be faster, because the code is smaller. >>> But __cdecl might be able to compete by using stores to the stack instead of pushes? >>> I'd have to see how that compares in size, and it does increase stack usage som! e. >>> ! >>> >>> Probably not worth large scale experimenting/changing, but maybe nice to mark >>> new functions/interfaces as __stdcall (see next point). >>> >>> >>> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >>> what with all the C<=>Modula-3 transitions. And not worth it given other >>> more valuable work to do. >>> >>> >>> 2) The calling convention pragmas should be allowed on an interface, to set >>> the default for an interface. >>> >>> 2b) and I guess as well on a module, for unexported functions >>> >>> I assert that other than __stdcall and __cdecl on NT386, nothing else is >>> particularly interesting here. There is __fastcall, maybe interesting. >>> It has different meanings to different compilers. >>> I'd rather keep this all fairly constrained. >>> >>> No other platform has more than one calling convention, so this doesn't >>> have be to further generalized. B! esides, ! as long as no platform uses >>> the same name to mean multipl e things, ok. >>> Mac68K Classic? >>> Mac68K CFM? >>> Win16? >>> MS-DOS? >>> >>> >>> (I did recently acquire a working Mac68K, as well it is easily >>> run on a modern PPC Mac; far down the list, but...) >>> >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > From darko at darko.org Tue Feb 23 05:03:55 2010 From: darko at darko.org (Darko) Date: Tue, 23 Feb 2010 15:03:55 +1100 Subject: [M3devel] calling conventions (small proposal) Message-ID: Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? -original message- Subject: RE: [M3devel] calling conventions (small proposal) From: Jay K Date: 23/02/2010 12:20 pm Two parts (sort of). 1) We do have what you describe -- __stdcall C code that Modula-3 calls. And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. I hope to get rid of that duplication. Later rather than earlier. 2) I want to write Modula-3 code that is __stdcall. We already have this, in platform specific code, e.g. the parameter to CreateThread. However I want to write code that is "otherwise" portable. In particular the replacements for hand.c Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:05:46 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > > > So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? > Again, I am very wary of platform-dependent pragmas in supposedly portable code! > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 17:59, Jay K wrote: > > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > >>> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > > From jay.krell at cornell.edu Tue Feb 23 05:37:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 04:37:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: You mean like: module("foo") module_calling_convention("foo", "__stdcall") % default calling convention for module foo or calling_convention("foocall", "__stdcall") calling_convention("barcall", "__cdecl") foo.m3: <*foocall*> PROCEDURE Foo()... <*barcall*> PROCEDURE Bar()... Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. The integration of quake and Modula-3..like.. "confuses" me. That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. If I look for analogies however..in C and C++ you can do something like easily enough Makefile: !if WIN32 CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl !else CFLAGS=-DFOOCALL= -DBARCALL= !endif so maybe not a bad idea? To repeat myself, we already have the following valid working syntax, on NT386: foo.i3 <*__stdcall*> PROCEDURE Foo()... foo.m3 <*__stdcall*> PROCEDURE Foo()... They have to match I believe. Of course the procedure doesn't necessarily occur in the .i3 file. My proposal is two part. 1) Accept the existing syntax on all platforms. The interpretion is "do nothing" on most platforms. 2) Allow the existing pragmas on interface/module also: <*__stdcall*> INTERFACE Foo... <*__stdcall*> MODULE Foo... #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. #2 allows for less repetition. This will let me use the possibly more efficient non-default calling convention for hand.c replacement. And possibly avoid having two nearly identical OpenGL.i3 files. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 15:03:55 +1100 > > Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 12:20 pm > > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> > From darko at darko.org Tue Feb 23 07:44:01 2010 From: darko at darko.org (Darko) Date: Tue, 23 Feb 2010 17:44:01 +1100 Subject: [M3devel] calling conventions (small proposal) Message-ID: Calling convention is almost a linking issue it seems pretty good idea to move it to the makefile somehow since it reduces portability otherwise -original message- Subject: RE: [M3devel] calling conventions (small proposal) From: Jay K Date: 23/02/2010 3:37 pm You mean like: module("foo") module_calling_convention("foo", "__stdcall") % default calling convention for module foo or calling_convention("foocall", "__stdcall") calling_convention("barcall", "__cdecl") foo.m3: <*foocall*> PROCEDURE Foo()... <*barcall*> PROCEDURE Bar()... Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. The integration of quake and Modula-3..like.. "confuses" me. That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. If I look for analogies however..in C and C++ you can do something like easily enough Makefile: !if WIN32 CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl !else CFLAGS=-DFOOCALL= -DBARCALL= !endif so maybe not a bad idea? To repeat myself, we already have the following valid working syntax, on NT386: foo.i3 <*__stdcall*> PROCEDURE Foo()... foo.m3 <*__stdcall*> PROCEDURE Foo()... They have to match I believe. Of course the procedure doesn't necessarily occur in the .i3 file. My proposal is two part. 1) Accept the existing syntax on all platforms. The interpretion is "do nothing" on most platforms. 2) Allow the existing pragmas on interface/module also: <*__stdcall*> INTERFACE Foo... <*__stdcall*> MODULE Foo... #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. #2 allows for less repetition. This will let me use the possibly more efficient non-default calling convention for hand.c replacement. And possibly avoid having two nearly identical OpenGL.i3 files. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 15:03:55 +1100 > > Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 12:20 pm > > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> > From jay.krell at cornell.edu Tue Feb 23 08:33:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 07:33:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: I don't understand. Assuming there are precious few calling conventions in the world, beyond 1 per platform, it seems fine as I propose. Oh, I think I see what you mean though. If you imagine multiple platforms with multiple calling conventions, then you'd want to intercede one portable name that is then redefined on a per-platform basis? My proposal either assumes there is one (set of) platform with any calling conventions (the same ones) OR, at least, that the names don't overlap across platforms with different meaning. That is, NT386 has __stcall, __cdecl. I write: INTERFACE Foo; <*__stdcall*>PROCEDURE Bar(); then future platform WIERD comes along and it has a calling convention "wierdcall". In this unlikely hypothetical world, I'd propose you write: <*wierdcall*><*__stdcall*>PROCEDURE Bar(); All platforms would be taught to recognize the pragma wierdcall, and the interpretation would be to do nothing except for target WIERD. The problem becomes if target WIERD has conventions, say, wierdcall and __stdcall, and you want __stcall on NT386 but wierdcall on WIERD. Then the above is ambiguous. But you could repair the unlikely problem after the fact, by using longer/diferent names when clashes come along. We'd stomp on __stdcall today for NT386, because it has been around a long time and is likely to remain unique. If WIERD comes along later with __stdcall, ok, we'd just call it weird__stdcall, and you'd write: <*wierd__stdcall*><*__stdcall*>PROCEDURE Foo(); ? If you wrote <*wierdcall__stdcall*><*wierdcall*>PROCEDURE Foo(); that would be an error, at least when targeting target WIERD. Just as, today, I hope, <*__stdcall*><*__cdecl*>PROCEDURE Foo() is an error. This is *slightly* complicated -- the long term hypothetical proposal is that multiple calling convension pragmas be allowed, depending on what exactly they are. Again remember that it is highly unusual for any platform to have multiple calling conventions, so this "problem" is not likely to grow. Does ARM have serious issues here? I know they have all kinds of execution modes. But I think Debian, for example, has two ARM platforms, and one calling convention each. ? Again, minimal is 1) allow existing NT386 syntax on all targets 2) possibly allow existing NT386 procedure pragma on modules/interfaces Is your desire to annotate something with "FOOCALL" and then experiment in m3makefile with mapping FOOCALL to one convention or another? And it would be multiple files, so the terseness of an interface/module pragma is not terse enough, it'd be too much to copy/paste? I can see that scenario. Can we at least agree on my #1, maybe my #2, and extend it after that? #1 is about two lines of change. I'll do it pretty soon. I just haven't gotten to it yet. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 17:44:01 +1100 > > Calling convention is almost a linking issue it seems pretty good idea to move it to the makefile somehow since it reduces portability otherwise > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 3:37 pm > > > You mean like: > > > module("foo") > module_calling_convention("foo", "__stdcall") > % default calling convention for module foo > > > or > calling_convention("foocall", "__stdcall") > calling_convention("barcall", "__cdecl") > > > foo.m3: > <*foocall*> PROCEDURE Foo()... > <*barcall*> PROCEDURE Bar()... > > > Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. > > > The integration of quake and Modula-3..like.. "confuses" me. > That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. > > If I look for analogies however..in C and C++ you can do something like easily enough > Makefile: > !if WIN32 > CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl > !else > CFLAGS=-DFOOCALL= -DBARCALL= > !endif > > > so maybe not a bad idea? > > > > > To repeat myself, we already have the following valid working syntax, on NT386: > > > foo.i3 > <*__stdcall*> PROCEDURE Foo()... > > foo.m3 > <*__stdcall*> PROCEDURE Foo()... > > They have to match I believe. > Of course the procedure doesn't necessarily occur in the .i3 file. > > > My proposal is two part. > > 1) Accept the existing syntax on all platforms. > The interpretion is "do nothing" on most platforms. > > > 2) Allow the existing pragmas on interface/module also: > > <*__stdcall*> INTERFACE Foo... > > <*__stdcall*> MODULE Foo... > > > #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. > > > #2 allows for less repetition. > > > This will let me use the possibly more efficient non-default calling convention for hand.c replacement. > > > And possibly avoid having two nearly identical OpenGL.i3 files. > > > - Jay > > > ---------------------------------------- >> From: darko at darko.org >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] calling conventions (small proposal) >> Date: Tue, 23 Feb 2010 15:03:55 +1100 >> >> Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? >> >> -original message- >> Subject: RE: [M3devel] calling conventions (small proposal) >> From: Jay K >> Date: 23/02/2010 12:20 pm >> >> >> Two parts (sort of). >> >> >> 1) >> We do have what you describe -- __stdcall C code that Modula-3 calls. >> And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. >> I hope to get rid of that duplication. Later rather than earlier. >> >> >> >> 2) >> I want to write Modula-3 code that is __stdcall. >> We already have this, in platform specific code, e.g. the parameter to CreateThread. >> However I want to write code that is "otherwise" portable. >> In particular the replacements for hand.c >> >> >> Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. >> >> >> >> 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). >> >> >> 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. >> >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 20:05:46 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> >>> >>> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >>> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 22 Feb 2010, at 17:59, Jay K wrote: >>> >>> There is an analog to Modula-3. >>> Setting the calling convention on platforms that have them. >>> "Doing nothing" on others. >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 17:45:12 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> This is C code... >>> >>> On 22 Feb 2010, at 16:10, Jay K wrote: >>> >>>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> >>> example of mostly portable + pragma: >>> >>> ? >>> hand.c: >>> ? >>> #if !defined(_MSC_VER) && !defined(__stdcall) >>> #define __stdcall /* nothing */ >>> #endif >>> ? >>> void __stdcall set_singleton >>> ANSI(( ulong a, ulong* s)) >>> KR((a, s) ulong a; ulong* s;) >>> { >>> ulong a_word = a / SET_GRAIN; >>> ulong a_bit = a % SET_GRAIN; >>> s[a_word] |= (1UL << a_bit); >>> } >>> ? >>> >>> (gcc on Windows #defines __stdcall to __attribute__(something)) >>> ? >>> >>> Not the best example -- this function doesn't seem well motivated. >>> We probably need a CG.i3 function to do div and mod in one go, since >>> the processors usually expose that. >>> Though this case is with a co! nstant power of two, so.. >>> And m3front would be a little pressed to notice the opportunity? >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 11:01:57 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> Pragmas should never give errors. >>> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 22 Feb 2010, at 04:52, Jay K wrote: >>> >>> I wouldn't mind >>> - an error >>> - or a way to mark a pragma as needing an error vs. being ok with a warning >>> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >>> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >>> the syntax is, but there is a legitimate need to note calling conventions, >>> a syntax is already in use. I'd rather not invent a new syntax. >>> >>> >>> The word "ignore" isn't relevant. >>> Sorry if I was confusing. >>> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >>> but that most platforms interpret them as doing nothing. >>> The pragmas already exist. >>> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 16:52:20 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> The compiler does continue to compile having warned that the pragma has no meaning. >>> >>> So, yes, they are ignored, but I want a warning. >>> >>> I even want a warning if I write <**>. >>> >>> >>> On 21 Feb 2010, at 16:47, Darko wrote: >>> >>> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >>> >>> >>> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >>> >>> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >>> >>> On 21 Feb 2010, at 16:16, Jay K wrote: >>> >>> To be clear, I don't propose ignoring all unrecognized pragmas. >>> Just calling conventions. >>> You could interpret it as: >>> The pragmas *are* recognized, on all targets, but they have no meaning on most. >>> The meaning is "do nothing". >>> >>> >>> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >>> with I386_NT source. And they all mean nothing. This lets people maintain >>> one portable code base, and they *don't* even need to do so much as: >>> #ifndef _X86_ >>> #define __stdcall /* nothing */ >>> #define __cdecl /* nothing */ >>> #define __fastcall /* nothing */ >>> #endif >>> >>> >>> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >>> The rest are a pointless proliferation of synonyms. >>> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >>> a few minutes, that's not the issue). >>> >>> >>> Separate file would work, but I'd really rather stuff be all together. >>> Once you separate things, one version goes stale. >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 15:54:13 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> Accepting and silently ignoring sounds very dangerous! >>> >>> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >>> >>> Silence is deadly! >>> >>> On 21 Feb 2010, at 15:09, Darko wrote: >>> >>> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >>> >>> >>> >>> On 21/02/2010, at 10:52 PM, Jay K wrote: >>> >>> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >>> at least __stdcall, and __cdecl >>> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >>> >>> This is a very small change. >>> >>> >>> This is will allow: >>> a) possibly merging the two nearly identical OpenGL.i3 files >>> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >>> I intend to that for hand.c's replacement, soon. >>> >>> >>> Maybe experiment as to the perf. >>> __stdcall is supposed to be faster, because the code is smaller. >>> But __cdecl might be able to compete by using stores to the stack instead of pushes? >>> I'd have to see how that compares in size, and it does increase stack usage som! e. >>> ! >>> >>> Probably not worth large scale experimenting/changing, but maybe nice to mark >>> new functions/interfaces as __stdcall (see next point). >>> >>> >>> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >>> what with all the C<=>Modula-3 transitions. And not worth it given other >>> more valuable work to do. >>> >>> >>> 2) The calling convention pragmas should be allowed on an interface, to set >>> the default for an interface. >>> >>> 2b) and I guess as well on a module, for unexported functions >>> >>> I assert that other than __stdcall and __cdecl on NT386, nothing else is >>> particularly interesting here. There is __fastcall, maybe interesting. >>> It has different meanings to different compilers. >>> I'd rather keep this all fairly constrained. >>> >>> No other platform has more than one calling convention, so this doesn't >>> have be to further generalized. B! esides, ! as long as no platform uses >>> the same name to mean multipl e things, ok. >>> Mac68K Classic? >>> Mac68K CFM? >>> Win16? >>> MS-DOS? >>> >>> >>> (I did recently acquire a working Mac68K, as well it is easily >>> run on a modern PPC Mac; far down the list, but...) >>> >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > From hendrik at topoi.pooq.com Tue Feb 23 19:19:38 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 23 Feb 2010 13:19:38 -0500 Subject: [M3devel] Style question about error messages Message-ID: <20100223181937.GA22300@topoi.pooq.com> Somewhere in my program after it has trued and failed to read the input file, I have the code Wr.PutText(Stdio.stderr, "No input file.\n"); Now presumably this message could be more detailed, but that's not waht I'm asking. What happens to me when I compile this code is the warning: "../src/Main.m3", line 63: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure Now presumably this is an indication that I ought to wrap the whole thing in a TRY clause. But what am I supposed to do if the attempt to produce an error message fails? Write an error message? What have other people done in this situation? --hendrik From hosking at cs.purdue.edu Tue Feb 23 20:15:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Feb 2010 14:15:32 -0500 Subject: [M3devel] Style question about error messages In-Reply-To: <20100223181937.GA22300@topoi.pooq.com> References: <20100223181937.GA22300@topoi.pooq.com> Message-ID: You can just record that exception as fatal in that code block with the <*FATAL Thread.Alerted*> pragma. On 23 Feb 2010, at 13:19, hendrik at topoi.pooq.com wrote: > Somewhere in my program after it has trued and failed to read the > input file, I have the code > > Wr.PutText(Stdio.stderr, "No input file.\n"); > > Now presumably this message could be more detailed, but that's not waht > I'm asking. What happens to me when I compile this code is the warning: > > "../src/Main.m3", line 63: warning: potentially unhandled exceptions: > Thread.Alerted, Wr.Failure > > Now presumably this is an indication that I ought to wrap the whole > thing in a TRY clause. But what am I supposed to do if the attempt to > produce an error message fails? Write an error message? > > What have other people done in this situation? > > --hendrik From rcolebur at SCIRES.COM Tue Feb 23 22:05:57 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 23 Feb 2010 16:05:57 -0500 Subject: [M3devel] Style question about error messages In-Reply-To: References: <20100223181937.GA22300@topoi.pooq.com> Message-ID: Hendrik: I have run into this situation also. If you have code that runs on multiple platforms, you have to think through the best way to handle. For example, code might work differently say between Unix and Windows. Indeed, if you have a Windows GUI mode program and try to write to stdout there is some magic that is used to allocate a console writer on the fly. Also, if you know you aren't using Alerts, you might be ok using the FATAL pragma as Tony suggests, but then for Wr.Failure you may want to take a different course. Also, depending on your program, you may want to trap both of these so you can clean up any other resource use before terminating the program. If you want more specifics, I can dig into some of my code for examples. Regards, Randy -----Original Message----- From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Tuesday, February 23, 2010 2:16 PM To: hendrik at topoi.pooq.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Style question about error messages You can just record that exception as fatal in that code block with the <*FATAL Thread.Alerted*> pragma. On 23 Feb 2010, at 13:19, hendrik at topoi.pooq.com wrote: > Somewhere in my program after it has trued and failed to read the > input file, I have the code > > Wr.PutText(Stdio.stderr, "No input file.\n"); > > Now presumably this message could be more detailed, but that's not waht > I'm asking. What happens to me when I compile this code is the warning: > > "../src/Main.m3", line 63: warning: potentially unhandled exceptions: > Thread.Alerted, Wr.Failure > > Now presumably this is an indication that I ought to wrap the whole > thing in a TRY clause. But what am I supposed to do if the attempt to > produce an error message fails? Write an error message? > > What have other people done in this situation? > > --hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. From jay.krell at cornell.edu Wed Feb 24 00:14:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 23:14:51 +0000 Subject: [M3devel] hand.c/set_singleton? Message-ID: I think hand.c is worth shrinking. And converting where easy to Modula-3. Agreed? It is "exercise" at least -- learn and get comfortable making changes, as long as they don't make anything worse. With that in mind, any hints on this: void set_singleton(size_t a, size_t* s) { size_t a_word = a / SET_GRAIN; size_t a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } Leave it alone? It works, not worth changing? Deal with it in m3front? In parse.c? I changed m3back to generate a bts instruction, which achieves "all four" operations in one instruction -- div (shift), mod (and), shift, or. The semantic mapping seems to be 100%. If set_singleton were a common operation, which I doubt, it seems like a major gain. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 00:33:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 23:33:29 +0000 Subject: [M3devel] AMD64_LINUX/Tinderbox Message-ID: AMD64_LINUX seems stuck in m3core's use of LONGCARD. Presumably a problem in Tinderbox, not the actual cm3 code. Maybe because there is only one job instead of two? Please fix? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 24 04:33:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Feb 2010 22:33:54 -0500 Subject: [M3devel] hand.c/set_singleton? In-Reply-To: References: Message-ID: We don't want this in m3front. On 23 Feb 2010, at 18:14, Jay K wrote: > I think hand.c is worth shrinking. > And converting where easy to Modula-3. > Agreed? > It is "exercise" at least -- learn and get comfortable making changes, as long as they don't make anything worse. > > > With that in mind, any hints on this: > > > void set_singleton(size_t a, size_t* s) > { > size_t a_word = a / SET_GRAIN; > size_t a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > > > Leave it alone? It works, not worth changing? > Deal with it in m3front? > In parse.c? > > > I changed m3back to generate a bts instruction, which achieves "all four" operations in one instruction -- div (shift), mod (and), shift, or. The semantic mapping seems to be 100%. If set_singleton were a common operation, which I doubt, it seems like a major gain. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 24 11:01:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 24 Feb 2010 11:01:30 +0100 Subject: [M3devel] AMD64_LINUX/Tinderbox In-Reply-To: References: Message-ID: <20100224110130.a810t555sgccoksg@mail.elegosoft.com> Quoting Jay K : > AMD64_LINUX seems stuck in m3core's use of LONGCARD. Sorry, I didn't notice this; I'm rather focused on Hudson and the release branch. > Presumably a problem in Tinderbox, not the actual cm3 code. > > Maybe because there is only one job instead of two? Well, yes. There is no old release for platform AMD64_LINUX, so the release-build job cannot run :-/ We should probably change the lastok-build job script to perform an upgrade in case of a failure. We wouldn't notice the incompatible change any more then though. > Please fix? I'll have a look at the scripts, perhaps tonight. I'd rather complete the release, use Hudson for the trunk then and disable the tinderbox job on birch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 24 13:41:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 12:41:12 +0000 Subject: [M3devel] portable/less portable test variations Message-ID: I'd like to write tests that, given different command line parameters, will either output totally portable results, or only somewhat portable, where "somewhat" probably means either portable to particular wordsize or portable to wordsize+endian. Worst case, completely platform specific. We'd have 1, 3, or 5 checked in expected results. Or possibly 1+n (portable + n platforms). This case is less useful, because it takes away the ability to compare, e.g. LINUXLIBC6 to NT386. The test would run twice, with and without the command line option. I guess it is about as much work to implement as to describe, but I've let it drag out. I have tests that would benefit from this. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 14:15:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 13:15:06 +0000 Subject: [M3devel] RTHook.Set* or RTSet.*? Message-ID: Again, I think hand.c's should largely be moved to Modula-3 code. e.g. all the "set_*" functions. (rough uncompiled unfinished) proposal #1 aka "RTHooks". premise: If the compiler generates calls to it, it ought to be in RTHooks. RTHooks.i3 TYPE Set = UNTRACED REF Word.T TYPE SetBoolean = Word.T; (* a full 32 or 64 bits; C would have returned at least 32 *) TYPE SetSize = CARDINAL; (* probably too much layering *) TYPE SetIndex = CARDINAL; (* probably too much layering *) CONST SetTRUE = 1; CONST SetFALSE = 0; PROCEDURE SetMember(set: Set; element: SetIndex): SetBoolean; (* SetTRUE IFF element IN set, else SetFALSE *) PROCEDURE SetUnion(inA, inB, out: Set; setSize: SetSize); (* out := inA + inB *) PROCEDURE SetIntersection(inA, inB, out: Set; setSize: SetSize); (* out := inA * inB *) PROCEDURE SetDifference(inA, inB, out: Set; setSize: SetSize); (* out := inA - inB *) PROCEDURE SetSymmetricDifference(inA, inB, out: Set; setSize: SetSize); (* out := inA xor inB *) PROCEDURE SetGE(inA, inB: Set; setSize: SetSize): SetBoolean; (* ... *) or longer SetGreaterOrEqual? etc. MODULE RTSet (m3-libs/m3core/src/runtime/common/RTSet.m3) EXPORTS RTHooks; ... You might also say: PROCEDURE SetMember(VAR set: Word.T; element: SetIndex): SetBoolean; esp. e.g. on the outputs. and to capture the invalidity of NULL? (rough uncompiled unfinished) proposal #2 aka "RTSet" premise: It seems right. RTSet.i3: (m3-libs/m3ore/src/runtime/common/RTSet.i3, or m3-libs/m3core/src/set?) It seems prudent to keep the "RT" prefix for global namespace reasons. It seems "RT" implies "runtime" directory though. I'd worry that calling it just Set.i3 could clash with other code. Notice that the existing names in hand.c cannot clash with any Modula-3 code, due to the single underscore. Perhaps perhaps perhaps this is a great reason to leave this all alone, because using C enables chosing identifiers in a separate namespace?? TYPE T = UNTRACED REF Word.T TYPE Boolean = Word.T; (* a full 32 or 64 bits; C would have returned at least 32 *) TYPE Size = CARDINAL; (* probably too much layering *) TYPE Index = CARDINAL; (* probably too much layering *) CONST True = 1; CONST False = 0; PROCEDURE Member aka In(set: T; element: Index): Boolean; (* True IFF element IN set, else False *) PROCEDURE Union aka Plus(inA, inB, out: T; size: Size); (* out := inA + inB *) PROCEDURE Intersect aka Intersection aka Times(inA, inB, out: T; size: Size); (* out := inA * inB *) PROCEDURE Difference aka Sub aka Subtract(inA, inB, out: T; size: Size); (* out := inA - inB *) PROCEDURE SymmetricDifference aka Xor(inA, inB, out: T; size: Size); (* out := inA xor inB *) PROCEDURE GE(inA, inB: T; size: Size): Boolean; (* ... *) etc. I'm undecided on the names. But I think I prefer: Union, Intersect, Difference, SymmetricDifference, Member, GE, EQ, NE, LT, LE, GT. It definitely looks nicer to put things in RTSet. (Assuming people believe "name scoping" is a good idea. There are counter arguments -- one flat global namespace is more conducive to search...) But the precedent of putting "everthing" in RTHooks seem clear. Though it is violated by hand.c..because it doesn't matter. You could declare them as extern in RTHooks.i3 and it wouldn't make any difference. The names are "never" referenced by Modula-3 code. Well, ok, m3back.m3 has the strings. I guess I'll do whittle at it a little more before doing this -- remove the tables, at least the NT386 exported ones. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 14:41:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 13:41:15 +0000 Subject: [M3devel] TInt.ToInt overflow In-Reply-To: References: <20100222225722.056AE2474001@birch.elegosoft.com>, ,,,,<48085E62-6C4C-4ECD-B1CB-F94CE7C5B10E@cs.purdue.edu>, , , , , , , , , , , , , <6A1F915C-A970-4485-8293-9E523DB278BA@cs.purdue.edu>, , , , <72B5DA75-B33A-4414-9E14-6625FA5816FB@cs.purdue.edu>, , <09B1E13B-15E0-452B-83E7-1F976049793C@cs.purdue.edu>, , Message-ID: Tony, it looks like basically all/many negative values are representeded as large positive values. Something is chopping the sign maybe? Here are the errors I get compiling m3core if I don't "ignore" overflow from TInt.ToInt. (for values that are under Integer.Word32.max). It isn't always clear how the source traffics in these numbers. I could get callstacks if it really helps. "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocStats.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 452: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 463: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 464: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 471: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 549: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 550: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 555: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 558: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 561: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 566: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 569: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 574: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 577: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 592: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 593: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 801: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 952: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 964: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 970: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1016: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1071: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1077: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1089: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1090: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1092: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1094: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1186: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1208: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1209: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1242: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immdiate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1702: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1724: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2056: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2257: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2259: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2365: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2386: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2398: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2418: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2420: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2425: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2442: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2482: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2498: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2520: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2525: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2541: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2543: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2697: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 78: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 79: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 86: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 87: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 99: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 81: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 82: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 89: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 96: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 101: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 103: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 108: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 119: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 "..\src\convert\Convert.m3", line 496: pushOp: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 "..\src\convert\Convert.m3", line 503: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: RE: [M3commit] CVS Update: cm3 Date: Tue, 23 Feb 2010 23:08:32 +0000 I'll have to show you where the values are coming from. I don't know offhand. Could be from m3back, or m3front, I don't know. This stuff largely is runnable/testable from arbitrary hosts. cd scripts/python ./do-cm3-std.py realclean NT386 ./do-cm3-std.py buildship NT386 to get the data we are interested in, would want to change this code e.g.: C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386): IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN Note that most of the uses of ToInt in m3back don't do that, e.g.: IF shiftCount.loc = OLoc.imm THEN IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm)); END; ins.imsize := 1; And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday. But some are not, I didn't go here randomly. bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value. - Jay From: hosking at cs.purdue.edu Date: Tue, 23 Feb 2010 14:00:07 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 I guess I am uncertain what it is you are trying to achieve. The Modula-3 frontend never generates unsigned integers. Everything is signed. If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes. On 23 Feb 2010, at 13:15, Jay K wrote: So we need TWord.ToBytes? - Jay From: hosking at cs.purdue.edu Date: Tue, 23 Feb 2010 12:39:49 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3commit] CVS Update: cm3 Actually, on second thought, of course it cannot be fixed. The signed value 128 *does* require 2 bytes to represent. (char)128 == -128. (short)128 == 128. These TInt functions should be interpreted as having C arithmetic semantics. On 23 Feb 2010, at 08:35, Tony Hosking wrote: That can be fixed... On 22 Feb 2010, at 21:30, Jay K wrote: ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte? I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad. - Jay ---------------------------------------- From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 21:10:10 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 On 22 Feb 2010, at 20:30, Jay K wrote: I'm still a bit leary of Chop and ToBytes. Chop is just the same as a C cast. i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1. ToBytes simply returns the significant bytes. I *suspect* we need a bit more in TWord to make this all hold together. I don't see the need. I think this speaks to confusion on your part... Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.) I don't entirely ignore ToInt's boolean. I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error. I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise. Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such. (I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.) What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it. And then rewriting hand.c in Modula-3. And then other stuff. ..Jay ________________________________ From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 20:03:03 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 P.S. The assumption is that results from operations that overflow should be discarded. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 20:01, Tony Hosking wrote: Jay, If you want that behavior, just do: TInt.Chop(x, BYTESIZE(INTEGER), x); TInt.ToInt(x, i) On 22 Feb 2010, at 23:57, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/02/22 23:57:21 Modified files: cm3/m3-sys/m3back/src/: M3BackInt.m3 Log message: remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 24 15:43:18 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 24 Feb 2010 09:43:18 -0500 Subject: [M3devel] TInt.ToInt overflow In-Reply-To: References: <20100222225722.056AE2474001@birch.elegosoft.com>, , , , , <48085E62-6C4C-4ECD-B1CB-F94CE7C5B10E@cs.purdue.edu>, , , , , , , , , , , , , <6A1F915C-A970-4485-8293-9E523DB278BA@cs.purdue.edu>, , , , <72B5DA75-B33A-4414-9E14-6625FA5816FB@cs.purdue.edu>, , <09B1E13B-15E0-452B-83E7-1F976049793C@cs.purdue.edu>, , Message-ID: <9635E921-3B9F-4A95-B4BC-0ACBCCE36D3A@cs.purdue.edu> I suspect that your backend code is not obeying the type conversions in the CG code. Here is line 202 from RTAllocator -- it has a lot of conversions (with implied sign extension). Does this give any clues? -----LINE 202 ----- declare_temp 4 4 Struct T v.159 load_integer Int.32 0 load v.159 0 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 0 1 store v.159 0 Int.32 Word.8 load v.67 0 Addr Addr load_indirect 0 Int.32 Int.32 check_range Int.32 0 1048575 1 load v.159 0 Word.32 Int.32 swap Int.32 Int.32 insert_mn Int.32 1 20 store v.159 0 Int.32 Word.32 load_integer Int.32 1 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 5 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 6 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 7 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 0 1 store v.159 3 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 1 1 store v.159 3 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 2 6 store v.159 3 Int.32 Word.8 load v.65 0 Addr Addr load_integer Int.32 4 index_address Int.32 -1 load_address v.159 0 copy 1 Int.32 F On 24 Feb 2010, at 08:41, Jay K wrote: > Tony, it looks like basically all/many negative values are representeded as large positive values. > Something is chopping the sign maybe? > Here are the errors I get compiling m3core if I don't "ignore" overflow from TInt.ToInt. > (for values that are under Integer.Word32.max). > It isn't always clear how the source traffics in these numbers. I could get callstacks if it really helps. > > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocStats.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 452: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 463: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 464: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 471: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 549: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 550: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 555: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 558: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 561: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 566: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 569: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 574: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 577: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 592: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 593: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 801: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 952: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 964: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 970: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1016: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1071: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1077: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1089: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1090: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1092: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1094: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1186: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1208: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1209: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1242: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immdiate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1702: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1724: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2056: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2257: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2259: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2365: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2386: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2398: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2418: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2420: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2425: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2442: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2482: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2498: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2520: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2525: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2541: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2543: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2697: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 78: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 79: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 86: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 87: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 99: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 81: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 82: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 89: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 96: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 101: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 103: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 108: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 119: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 > "..\src\convert\Convert.m3", line 496: pushOp: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 > "..\src\convert\Convert.m3", line 503: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Tue, 23 Feb 2010 23:08:32 +0000 > > I'll have to show you where the values are coming from. I don't know offhand. > Could be from m3back, or m3front, I don't know. > > This stuff largely is runnable/testable from arbitrary hosts. > cd scripts/python > ./do-cm3-std.py realclean NT386 > ./do-cm3-std.py buildship NT386 > > > to get the data we are interested in, would want to change this code e.g.: > > > C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386): IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN > > > Note that most of the uses of ToInt in m3back don't do that, e.g.: > > > IF shiftCount.loc = OLoc.imm THEN > IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN > t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm)); > END; > ins.imsize := 1; > > > And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday. > But some are not, I didn't go here randomly. > bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Tue, 23 Feb 2010 14:00:07 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I guess I am uncertain what it is you are trying to achieve. The Modula-3 frontend never generates unsigned integers. Everything is signed. If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes. > > > On 23 Feb 2010, at 13:15, Jay K wrote: > > So we need TWord.ToBytes? > > - Jay > > From: hosking at cs.purdue.edu > Date: Tue, 23 Feb 2010 12:39:49 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3commit] CVS Update: cm3 > > Actually, on second thought, of course it cannot be fixed. The signed value 128 *does* require 2 bytes to represent. (char)128 == -128. (short)128 == 128. > These TInt functions should be interpreted as having C arithmetic semantics. > > On 23 Feb 2010, at 08:35, Tony Hosking wrote: > > That can be fixed... > > On 22 Feb 2010, at 21:30, Jay K wrote: > > > ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte? > I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad. > > > - Jay > > > ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 21:10:10 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On 22 Feb 2010, at 20:30, Jay K wrote: > > I'm still a bit leary of Chop and ToBytes. > > Chop is just the same as a C cast. > i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1. > > ToBytes simply returns the significant bytes. > > I *suspect* we need a bit more in TWord to make this all hold together. > > I don't see the need. I think this speaks to confusion on your part... > > Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.) > > > I don't entirely ignore ToInt's boolean. > I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error. > > > I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise. > > > Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such. > (I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.) > > > What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it. > > > And then rewriting hand.c in Modula-3. > > > And then other stuff. > > > ..Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:03:03 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > P.S. The assumption is that results from operations that overflow should be discarded. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 20:01, Tony Hosking wrote: > > Jay, If you want that behavior, just do: > > TInt.Chop(x, BYTESIZE(INTEGER), x); > TInt.ToInt(x, i) > > On 22 Feb 2010, at 23:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/02/22 23:57:21 > > Modified files: > cm3/m3-sys/m3back/src/: M3BackInt.m3 > > Log message: > remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord) > > > > > > > > From jay.krell at cornell.edu Thu Feb 25 14:24:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Feb 2010 13:24:14 +0000 Subject: [M3devel] TInt/TWord/m3back Message-ID: Tony, it should now be much closer to your intent. I grant maybe the constants are misplaced, and I should try again to use ToBytes. I'm worried though. It used to be I could do: TInt.Add(Int{4,FF,FF,FF,7}, One) and be told it overflowed, in 4 bytes of precision. Now it'll just do it in 8 and no overflow. And chop always succeeds. Maybe: PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = BEGIN IF And (r [n-1], SignMask) = 0 THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; END; RETURN TRUE; END CheckChop; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 25 18:20:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 12:20:49 -0500 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: References: Message-ID: <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. On 25 Feb 2010, at 08:24, Jay K wrote: > Tony, it should now be much closer to your intent. > I grant maybe the constants are misplaced, and I should try again to use ToBytes. > > > I'm worried though. > It used to be I could do: > > > TInt.Add(Int{4,FF,FF,FF,7}, One) > and be told it overflowed, in 4 bytes of precision. You must check explicitly that there is no overflow. This is easy enough. TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) > Now it'll just do it in 8 and no overflow. > > > And chop always succeeds. > > Maybe: > > > PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = > BEGIN > IF And (r [n-1], SignMask) = 0 > THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; > ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; > END; > RETURN TRUE; > END CheckChop; > > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 00:18:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Feb 2010 23:18:38 +0000 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> References: , <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> Message-ID: Ok, I think maybe I should go back to the version where the type carries precision and each function is a small wrapper over TInt where I extend, call TInt, and then checked truncate. Or at least call TInt and checked truncate, maybe no need for extend. Something like that. That will still leave the hard work in TInt. I had hoped TInt could do "everything" for me. It is a little disappointing -- it was for doing "target math", which is what I want, but now it is just for doing 64bit math on any host. Probably should be called Int64.. On the other hand, m3back historically just did host INTEGER math, no overflow checks. So maybe ok asis. Adding the overflow checks found overflow in user source though, so I think a good thing. I'll probably just go back a day or so, as described, where each function in M3BackInt/M3BackWord is about one line. No need for th TInt/TWord changes then, even though they were acceptable. - Jay From: hosking at cs.purdue.edu Date: Thu, 25 Feb 2010 12:20:49 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] TInt/TWord/m3back This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. On 25 Feb 2010, at 08:24, Jay K wrote: Tony, it should now be much closer to your intent. I grant maybe the constants are misplaced, and I should try again to use ToBytes. I'm worried though. It used to be I could do: TInt.Add(Int{4,FF,FF,FF,7}, One) and be told it overflowed, in 4 bytes of precision. You must check explicitly that there is no overflow. This is easy enough. TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) Now it'll just do it in 8 and no overflow. And chop always succeeds. Maybe: PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = BEGIN IF And (r [n-1], SignMask) = 0 THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; END; RETURN TRUE; END CheckChop; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 01:06:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 00:06:28 +0000 Subject: [M3devel] TInt/TWord/specified precision Message-ID: Tony, the TInt/TWord cleanup cost me a lot of time, and still more to do. They used to provide target math to a specified precision. Now always to a fixed large precision. Historically M3back did host math, no overflow checking. It "had" to change, at least to split Target.Int into two host integers, in order to accomodate 64bit integers, but preferably to sometimes keep them together to do constant folding. (Arguably 64bit integer support initially only from 64bit host, then have working LONGINT, then use LONGINT, but no.) Adding overflow checking at the same time caught actual borderline bugs in user code -- code that depended on silent overflow. m3front won't catch those I guess because it never? folds constants? Maybe it should be willing to do so as long as there is no overflow, and then if it is hits overflow, back off and generate code to do the work? But also warn? I'm left very much desiring the functionaly that TInt did have. I have a few options. M3BackInt as it recently was, a thin layer over TInt. The constants could remain in TInt. Introducing TIntN, which is TInt but with n=specified precision, at runtime (Not TInt8, TInt32, just one TIntN that adapts at runtime, just like TInt used to do). The only difference between TIntN and M3BackInt is the name and location. It would be in m3middle. Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, and SignExtend and ZeroExtend that give a source precision. These functions would exist either way, just in TIntN, TWordN, or TInt. But I think still useful to wrap the type in a type that carries the precision. Now, also, I wonder if TInt, with its lost functionality, should be renamed, say to TInt64 or Int64? TInt used to do more and it was a little more complicated but useful. Are you sure it shouldn't go back to how it was? If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, if it keeps the individual layers thinner, simpler, easier to get correct. Doesn't analogy to TFloat suggest it was better before? TFloat doesn't support just one large precision type, it supports parameterizing itself in order to simulate various floating types. Granted, I haven't looked at what all it provides and I don't believe m3back folds constant float math at compile time, but it could. At least stuff not dependent on various "modes". 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. I'd have to think a bit, but it's probably something like floating constants with the same exponent and a mantissa that holds the full value can be folded. Bunch of examples is that if I convert a bunch of 32bit integers to double and do only add and subtract, it can all be folded at compile time. Multiplication and division cannot in general be done, though sometimes. Comparison to the same set can be done. Anyway, my current best idea is to introduce TIntN, TWordN, but I have a while to think about it before I do anything. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 26 03:44:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 21:44:40 -0500 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: References: , <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> Message-ID: <8CAB3AD8-444C-4BB0-956A-73D24C6C237C@cs.purdue.edu> But TInt will do what you want. You just need to check bounds. TInt does mean "target INTEGER": is the way one does arithmetic on a host that doesn't support the range of the target. You cannot do constant folding safely without checking for overflow otherwise you violate the intent of the language (i.e., that some targets might check for overflow...) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 25 Feb 2010, at 18:18, Jay K wrote: > Ok, I think maybe I should go back to the version where the type carries precision and each function is a small wrapper over TInt where I extend, call TInt, and then checked truncate. > Or at least call TInt and checked truncate, maybe no need for extend. > Something like that. > > > That will still leave the hard work in TInt. > > > I had hoped TInt could do "everything" for me. > It is a little disappointing -- it was for doing "target math", which is what I want, but now it is just for doing 64bit math on any host. Probably should be called Int64.. > > > On the other hand, m3back historically just did host INTEGER math, no overflow checks. So maybe ok asis. > Adding the overflow checks found overflow in user source though, so I think a good thing. > I'll probably just go back a day or so, as described, where each function in M3BackInt/M3BackWord is about one line. No need for th TInt/TWord changes then, even though they were acceptable. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 25 Feb 2010 12:20:49 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/m3back > > This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. > > On 25 Feb 2010, at 08:24, Jay K wrote: > > Tony, it should now be much closer to your intent. > I grant maybe the constants are misplaced, and I should try again to use ToBytes. > > > I'm worried though. > It used to be I could do: > > > TInt.Add(Int{4,FF,FF,FF,7}, One) > and be told it overflowed, in 4 bytes of precision. > > You must check explicitly that there is no overflow. This is easy enough. > > TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) > > Now it'll just do it in 8 and no overflow. > > > And chop always succeeds. > > Maybe: > > > PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = > BEGIN > IF And (r [n-1], SignMask) = 0 > THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; > ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; > END; > RETURN TRUE; > END CheckChop; > > ? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 26 03:48:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 21:48:11 -0500 Subject: [M3devel] TInt/TWord/specified precision In-Reply-To: References: Message-ID: The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed, m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold. I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard. I do not want to complicate TInt any more than it is now. On 25 Feb 2010, at 19:06, Jay K wrote: > Tony, the TInt/TWord cleanup cost me a lot of time, and > still more to do. > > > They used to provide target math to a specified precision. > > > Now always to a fixed large precision. > > > Historically M3back did host math, no overflow checking. > It "had" to change, at least to split Target.Int into > two host integers, in order to accomodate 64bit integers, > but preferably to sometimes keep them together to do constant folding. > (Arguably 64bit integer support initially only from 64bit host, > then have working LONGINT, then use LONGINT, but no.) > > > Adding overflow checking at the same time caught actual > borderline bugs in user code -- code that depended on silent overflow. > > > m3front won't catch those I guess because it never? folds constants? > Maybe it should be willing to do so as long as there is no overflow, > and then if it is hits overflow, back off and generate code to do the work? > But also warn? > > > I'm left very much desiring the functionaly that TInt did have. > > > I have a few options. > M3BackInt as it recently was, a thin layer over TInt. > The constants could remain in TInt. > > > Introducing TIntN, which is TInt but with n=specified precision, > at runtime (Not TInt8, TInt32, just one TIntN that adapts > at runtime, just like TInt used to do). > > > The only difference between TIntN and M3BackInt is the name and location. > It would be in m3middle. > > > Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, > and SignExtend and ZeroExtend that give a source precision. > These functions would exist either way, just in TIntN, TWordN, or TInt. > > > But I think still useful to wrap the type in a type that carries the precision. > > > Now, also, I wonder if TInt, with its lost functionality, should > be renamed, say to TInt64 or Int64? > > > TInt used to do more and it was a little more complicated but useful. > Are you sure it shouldn't go back to how it was? > If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, > if it keeps the individual layers thinner, simpler, easier to get correct. > > > Doesn't analogy to TFloat suggest it was better before? > > TFloat doesn't support just one large precision type, it supports > parameterizing itself in order to simulate various floating types. > Granted, I haven't looked at what all it provides and I don't believe > m3back folds constant float math at compile time, but it could. > At least stuff not dependent on various "modes". > 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. > I'd have to think a bit, but it's probably something like floating > constants with the same exponent and a mantissa that holds > the full value can be folded. Bunch of examples is that if I > convert a bunch of 32bit integers to double and do only > add and subtract, it can all be folded at compile time. > Multiplication and division cannot in general be done, though sometimes. > Comparison to the same set can be done. > > > Anyway, my current best idea is to introduce TIntN, TWordN, but I have > a while to think about it before I do anything. > > - Jay > From jay.krell at cornell.edu Fri Feb 26 11:41:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 10:41:05 +0000 Subject: [M3devel] TInt/TWord/specified precision In-Reply-To: References: , Message-ID: If I have to a range check after basically every single operation, if I can never just call Add, but always Add and then Something, that merits a better type/interface/implementation that does that for me. I was thinking maybe the check is at "chop time", but that would allow things like LAST(INTEGER) + 1 - 1 to work, and they probably should not, even if arguably they should. I think currently I let this through. I think the previous M3BackInt.m3 shall be TIntN.m3. I'll proceed that way. - Jay > From: hosking at cs.purdue.edu > Date: Thu, 25 Feb 2010 21:48:11 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/specified precision > > The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed, > > m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold. > > I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard. > > I do not want to complicate TInt any more than it is now. > > On 25 Feb 2010, at 19:06, Jay K wrote: > > > Tony, the TInt/TWord cleanup cost me a lot of time, and > > still more to do. > > > > > > They used to provide target math to a specified precision. > > > > > > Now always to a fixed large precision. > > > > > > Historically M3back did host math, no overflow checking. > > It "had" to change, at least to split Target.Int into > > two host integers, in order to accomodate 64bit integers, > > but preferably to sometimes keep them together to do constant folding. > > (Arguably 64bit integer support initially only from 64bit host, > > then have working LONGINT, then use LONGINT, but no.) > > > > > > Adding overflow checking at the same time caught actual > > borderline bugs in user code -- code that depended on silent overflow. > > > > > > m3front won't catch those I guess because it never? folds constants? > > Maybe it should be willing to do so as long as there is no overflow, > > and then if it is hits overflow, back off and generate code to do the work? > > But also warn? > > > > > > I'm left very much desiring the functionaly that TInt did have. > > > > > > I have a few options. > > M3BackInt as it recently was, a thin layer over TInt. > > The constants could remain in TInt. > > > > > > Introducing TIntN, which is TInt but with n=specified precision, > > at runtime (Not TInt8, TInt32, just one TIntN that adapts > > at runtime, just like TInt used to do). > > > > > > The only difference between TIntN and M3BackInt is the name and location. > > It would be in m3middle. > > > > > > Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, > > and SignExtend and ZeroExtend that give a source precision. > > These functions would exist either way, just in TIntN, TWordN, or TInt. > > > > > > But I think still useful to wrap the type in a type that carries the precision. > > > > > > Now, also, I wonder if TInt, with its lost functionality, should > > be renamed, say to TInt64 or Int64? > > > > > > TInt used to do more and it was a little more complicated but useful. > > Are you sure it shouldn't go back to how it was? > > If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, > > if it keeps the individual layers thinner, simpler, easier to get correct. > > > > > > Doesn't analogy to TFloat suggest it was better before? > > > > TFloat doesn't support just one large precision type, it supports > > parameterizing itself in order to simulate various floating types. > > Granted, I haven't looked at what all it provides and I don't believe > > m3back folds constant float math at compile time, but it could. > > At least stuff not dependent on various "modes". > > 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. > > I'd have to think a bit, but it's probably something like floating > > constants with the same exponent and a mantissa that holds > > the full value can be folded. Bunch of examples is that if I > > convert a bunch of 32bit integers to double and do only > > add and subtract, it can all be folded at compile time. > > Multiplication and division cannot in general be done, though sometimes. > > Comparison to the same set can be done. > > > > > > Anyway, my current best idea is to introduce TIntN, TWordN, but I have > > a while to think about it before I do anything. > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 13:59:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 12:59:54 +0000 Subject: [M3devel] examples Message-ID: I think the release branch is missing the change to move examples. Update it? (I say this based on differences in the scripts.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 05:48:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 04:48:36 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> Message-ID: Tony, I just don't understand what is wrong with TIntN, TWordN. They are what TInt/TWord did for a long time after all. ? Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Fri, 26 Feb 2010 19:51:15 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > On 26 Feb 2010, at 13:48, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/02/26 13:48:34 >> >> Modified files: >> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >> Wrx86.i3 Wrx86.m3 m3makefile >> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >> TWordN.i3 TWordN.m3 Target.i3 >> Target.m3 m3makefile >> Removed files: >> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >> M3BackWord.m3 >> >> Log message: >> introduce type Target.IntN which is Int plus a precision >> just like the old Target.Int >> (previously M3BackInt.Int) >> >> make TIntN and TWordN support it >> they are just thin wrappers over TInt, TWord >> previously named M3BackInt, M3BackWord >> >> add small amount of support to TInt: >> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >> These could, if desired, go into their only users: TIntN, TWordN. >> (with the understanding that that Target.Int is "revealed" to them.) >> >> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >> >> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >> This is "just" additions. >> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >> (A little unsatisfactory that N is bytes instead of bits.) >> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >> >> While at it, in TIntN, rename things slightly: >> FromInt => FromHostInteger >> ToInt => ToHostInteger >> >> "Int" is "Target.Int" >> "HostInteger" is "INTEGER" >> >> again, TInt/TWord/m3front/m3middle not much affected. >> >> One fishy/uncertain thing in all of this, something to test out, is cross builds >> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >> really need INTEGER to be 4 bytes throughout m3back? >> (I know that mklib has little endian dependency.) > From hosking at cs.purdue.edu Sat Feb 27 07:16:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 01:16:32 -0500 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> Message-ID: <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> The solution is not to push upstream into m3middle. I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. -- T On 26 Feb 2010, at 23:48, Jay K wrote: > > Tony, I just don't understand what is wrong with TIntN, TWordN. > They are what TInt/TWord did for a long time after all. ? > Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Fri, 26 Feb 2010 19:51:15 -0500 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >> >> On 26 Feb 2010, at 13:48, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>> Wrx86.i3 Wrx86.m3 m3makefile >>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>> TWordN.i3 TWordN.m3 Target.i3 >>> Target.m3 m3makefile >>> Removed files: >>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>> M3BackWord.m3 >>> >>> Log message: >>> introduce type Target.IntN which is Int plus a precision >>> just like the old Target.Int >>> (previously M3BackInt.Int) >>> >>> make TIntN and TWordN support it >>> they are just thin wrappers over TInt, TWord >>> previously named M3BackInt, M3BackWord >>> >>> add small amount of support to TInt: >>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>> These could, if desired, go into their only users: TIntN, TWordN. >>> (with the understanding that that Target.Int is "revealed" to them.) >>> >>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>> >>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>> This is "just" additions. >>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>> (A little unsatisfactory that N is bytes instead of bits.) >>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>> >>> While at it, in TIntN, rename things slightly: >>> FromInt => FromHostInteger >>> ToInt => ToHostInteger >>> >>> "Int" is "Target.Int" >>> "HostInteger" is "INTEGER" >>> >>> again, TInt/TWord/m3front/m3middle not much affected. >>> >>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>> really need INTEGER to be 4 bytes throughout m3back? >>> (I know that mklib has little endian dependency.) >> From jay.krell at cornell.edu Sat Feb 27 08:34:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 07:34:52 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> Message-ID: > As I understand it your stuff in m3back is mostly working. > I took a look at the code there and I see a number of issues Tony, I don't know of anything that isn't working. Please let me know. All 64bit operations should work. atomic32 should work. Not yet atomic8/16/64, soon. Oh there is an alignment issue once atomic64 is there. It's present on other platforms too, for different reasons (incorrect max_align). Thanks, - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 01:16:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > The solution is not to push upstream into m3middle. > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > -- T > > On 26 Feb 2010, at 23:48, Jay K wrote: > >> >> Tony, I just don't understand what is wrong with TIntN, TWordN. >> They are what TInt/TWord did for a long time after all. ? >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Fri, 26 Feb 2010 19:51:15 -0500 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >>> >>> On 26 Feb 2010, at 13:48, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>>> Wrx86.i3 Wrx86.m3 m3makefile >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>>> TWordN.i3 TWordN.m3 Target.i3 >>>> Target.m3 m3makefile >>>> Removed files: >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>>> M3BackWord.m3 >>>> >>>> Log message: >>>> introduce type Target.IntN which is Int plus a precision >>>> just like the old Target.Int >>>> (previously M3BackInt.Int) >>>> >>>> make TIntN and TWordN support it >>>> they are just thin wrappers over TInt, TWord >>>> previously named M3BackInt, M3BackWord >>>> >>>> add small amount of support to TInt: >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>>> These could, if desired, go into their only users: TIntN, TWordN. >>>> (with the understanding that that Target.Int is "revealed" to them.) >>>> >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>>> >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>>> This is "just" additions. >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>>> (A little unsatisfactory that N is bytes instead of bits.) >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>>> >>>> While at it, in TIntN, rename things slightly: >>>> FromInt => FromHostInteger >>>> ToInt => ToHostInteger >>>> >>>> "Int" is "Target.Int" >>>> "HostInteger" is "INTEGER" >>>> >>>> again, TInt/TWord/m3front/m3middle not much affected. >>>> >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>>> really need INTEGER to be 4 bytes throughout m3back? >>>> (I know that mklib has little endian dependency.) >>> > From jay.krell at cornell.edu Sat Feb 27 13:24:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 12:24:30 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, Message-ID: And now again it doesn't work. new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\Codex86.m3", line 430 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f310 0x466a46 immOp1 + 0x475 in ..\src\Codex86.m3 0x12f400 0x467108 immOp + 0x662 in ..\src\Codex86.m3 0x12f444 0x47d5c7 doimm + 0x255 in ..\src\Stackx86.m3 0x12f470 0x43ff5e if_false + 0x222 in ..\src\M3x86.m3 0x12f49c 0x64138b if_false + 0x101 in ..\src\M3CG_Check.m3 0x12f4c8 0x501a8f If_false + 0xa8 in ..\src\misc\CG.m3 0x12f4e8 0x5c2466 PrepNoBranch + 0x66 in ..\src\exprs\Expr.m3 0x12f510 0x5c1e3e PrepBranch + 0xcc in ..\src\exprs\Expr.m3 0x12f564 0x5e4392 Compile + 0x104 in ..\src\stmts\IfStmt.m3 0x12f594 0x536610 Compile + 0x63 in ..\src\stmts\Stmt.m3 ......... ......... ... more frames ... *** execution of [, ] failed *** I'm going to move m3back to how it was, but leave m3middle alone. With TIntN still in m3back. I skimmed through most of your changes and they seemed ok, but I'll have to apply them slowly/piecemeal and see which work. - Jay > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 07:34:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > > > As I understand it your stuff in m3back is mostly working. > > I took a look at the code there and I see a number of issues > > > Tony, I don't know of anything that isn't working. > Please let me know. > All 64bit operations should work. atomic32 should work. > Not yet atomic8/16/64, soon. > Oh there is an alignment issue once atomic64 is there. > It's present on other platforms too, for different reasons (incorrect max_align). > > > Thanks, > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 01:16:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > The solution is not to push upstream into m3middle. > > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > > > -- T > > > > On 26 Feb 2010, at 23:48, Jay K wrote: > > > >> > >> Tony, I just don't understand what is wrong with TIntN, TWordN. > >> They are what TInt/TWord did for a long time after all. ? > >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>> > >>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>> TWordN.i3 TWordN.m3 Target.i3 > >>>> Target.m3 m3makefile > >>>> Removed files: > >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>> M3BackWord.m3 > >>>> > >>>> Log message: > >>>> introduce type Target.IntN which is Int plus a precision > >>>> just like the old Target.Int > >>>> (previously M3BackInt.Int) > >>>> > >>>> make TIntN and TWordN support it > >>>> they are just thin wrappers over TInt, TWord > >>>> previously named M3BackInt, M3BackWord > >>>> > >>>> add small amount of support to TInt: > >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>> > >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>> > >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>> This is "just" additions. > >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>> > >>>> While at it, in TIntN, rename things slightly: > >>>> FromInt => FromHostInteger > >>>> ToInt => ToHostInteger > >>>> > >>>> "Int" is "Target.Int" > >>>> "HostInteger" is "INTEGER" > >>>> > >>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>> > >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>> really need INTEGER to be 4 bytes throughout m3back? > >>>> (I know that mklib has little endian dependency.) > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 17:10:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 11:10:32 -0500 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> Message-ID: Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. On 27 Feb 2010, at 02:34, Jay K wrote: > >> As I understand it your stuff in m3back is mostly working. >> I took a look at the code there and I see a number of issues > > > Tony, I don't know of anything that isn't working. > Please let me know. > All 64bit operations should work. atomic32 should work. > Not yet atomic8/16/64, soon. > Oh there is an alignment issue once atomic64 is there. > It's present on other platforms too, for different reasons (incorrect max_align). > > > Thanks, > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 27 Feb 2010 01:16:32 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] TInt/TWord/N >> >> The solution is not to push upstream into m3middle. >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. >> >> -- T >> >> On 26 Feb 2010, at 23:48, Jay K wrote: >> >>> >>> Tony, I just don't understand what is wrong with TIntN, TWordN. >>> They are what TInt/TWord did for a long time after all. ? >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 >>>> To: jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >>>> >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>>>> >>>>> Modified files: >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>>>> Wrx86.i3 Wrx86.m3 m3makefile >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>>>> TWordN.i3 TWordN.m3 Target.i3 >>>>> Target.m3 m3makefile >>>>> Removed files: >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>>>> M3BackWord.m3 >>>>> >>>>> Log message: >>>>> introduce type Target.IntN which is Int plus a precision >>>>> just like the old Target.Int >>>>> (previously M3BackInt.Int) >>>>> >>>>> make TIntN and TWordN support it >>>>> they are just thin wrappers over TInt, TWord >>>>> previously named M3BackInt, M3BackWord >>>>> >>>>> add small amount of support to TInt: >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>>>> These could, if desired, go into their only users: TIntN, TWordN. >>>>> (with the understanding that that Target.Int is "revealed" to them.) >>>>> >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>>>> >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>>>> This is "just" additions. >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>>>> (A little unsatisfactory that N is bytes instead of bits.) >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>>>> >>>>> While at it, in TIntN, rename things slightly: >>>>> FromInt => FromHostInteger >>>>> ToInt => ToHostInteger >>>>> >>>>> "Int" is "Target.Int" >>>>> "HostInteger" is "INTEGER" >>>>> >>>>> again, TInt/TWord/m3front/m3middle not much affected. >>>>> >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>>>> really need INTEGER to be 4 bytes throughout m3back? >>>>> (I know that mklib has little endian dependency.) >>>> >> From jay.krell at cornell.edu Sat Feb 27 20:11:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 19:11:18 +0000 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , Message-ID: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 20:54:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 14:54:40 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , Message-ID: P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 21:50:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 20:50:40 +0000 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , ,,<7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, ,,, , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , Message-ID: > Target.Int values would always be interpreted based on their associated type They kind of mostly are? Except..I mean..you know..I bury a size in them, which is a step. But the signnedness is not buried in them and I might get that wrong sometimes. It is often, you know, the operation and not the type. "Shift is always unsigned." But Add isn't. But with "half range cardinals", I'm not sure it matters. 16_40000000 * 2 overflows the same for INTEGER and CARDINAL LAST(INTEGER) + 1 ditto. Some operations do vary and they are handled correctly I think: abs, mul, div. Actually this is somewhat wrong: signed and unsigned multiplication I don't think needs to vary the way it does. They are the same in the lower bits. The compiler doesn't need to be so picky I believe. In particular, in the following C: int F1(int a, int b) { return a * b; } unsigned F2(unsigned a, unsigned b) { return a * b; } __int64 F3(int a, int b) { return a * (__int64)b; } unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } only one of them does unsigned multiplication, the last. (and notice that it does it inline with one instruction; something our compiler will be harder pressed to do given the lack of mixed operations! but you could leave it to a smart optimizer) > Is64, IsWord, IsInt, Target.FloatType In familiar territory (C and C++), I like switches because they "evaluate simultaneously", at least however the compiler can figure it. That is: if foo == 1 else if foo == 2 else if foo == 3 else if foo == 4 else if foo == 5 unless the compiler is very smart is always go to penalize 5 comparisons for "5", plus the compiler might assume I'm meaning to optimize the earlier cases as being more common, but then I have to worry about the ordering to get the common cases earlier whereas if I write switch (foo) case 1: ... case 2: ... case 3: ... case 4: ... case 5: ... I'll let the compiler chose between table lookup, linear search, binary search. "table lookup" being "simultaneous evaluation", binary search being nice I also don't like "if ladders" because if I'm stepping through unoptimized code line by line, it is tedious. [mostly omitted aside: I go out of my way when writing command line parsers in C to have a switch statement instead of an if/elseif/elseif ladder] However In Modula-3, I've gotten warnings when I miss cases, so there is overhead of always writing "else". Partly this because I don't know Modula-3 well. The use of FloatType[type] was already there, and it is good to have equivalence classes to reduce the number of cases listed and allow for more to be added later, "silently". I also don't like "data based interfaces", I prefer function calls, that's why Is64 instead of is foo IN Types64. (but FloatType[type] was already there) Granted, I lament the lack of inlining in m3back. I'm worried about nomenclature if/when this is extended to 64bit architectures. I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. I think I just drifted away from using TInt.Min/Max{8,16,32,64}. I'll see if any uses remain. Eh maybe just: C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); Some places were in extract/insert, and looked wrong. Yes definitely more eyes on m3back appreciated. Heck more eyes on cm3 appreciated! We have way too few. :( There were many style changes along with making things not work. I didn't want to sift through it all so I put it all back. Now to ponder sifting through it more slowly from a working baseline. Also I often favor mvar.mvar_type over mvar.type, so I can plain text search for mvar_type, and not just "type". I realize that you can't throw out all contexta all the time, but, there is something to be said for flatter namespaces. Nothing scales like plain text search. No language aware search work adequately. Let alone the matter of existance of languages x tools. I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. I would certainly be ok with TypeIsFloat to make it more consistently function call based, thoug I know I put in some cases too -- for the "simultaneous evaluation" property. - Jay From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 14:54:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] max_align P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 22:24:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 16:24:41 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , Message-ID: <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> On 27 Feb 2010, at 15:50, Jay K wrote: > > Target.Int values would always be interpreted based on their associated type > > > They kind of mostly are? > Except..I mean..you know..I bury a size in them, which is a step. No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: add Int.32 the semantics are: take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. e.g., in C, (int)a + (int)b So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! > But the signnedness is not buried in them and I might get that wrong sometimes. > It is often, you know, the operation and not the type. > "Shift is always unsigned." > But Add isn't. > But with "half range cardinals", I'm not sure it matters. > 16_40000000 * 2 overflows the same for INTEGER and CARDINAL > LAST(INTEGER) + 1 ditto. > > > Some operations do vary and they are handled correctly I think: abs, mul, div. > Actually this is somewhat wrong: signed and unsigned multiplication I don't think > needs to vary the way it does. They are the same in the lower bits. > The compiler doesn't need to be so picky I believe. In particular, in the following C: > int F1(int a, int b) { return a * b; } > unsigned F2(unsigned a, unsigned b) { return a * b; } > __int64 F3(int a, int b) { return a * (__int64)b; } > unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } > > > only one of them does unsigned multiplication, the last. > (and notice that it does it inline with one instruction; something > our compiler will be harder pressed to do given the lack of mixed operations! > but you could leave it to a smart optimizer) > > > > Is64, IsWord, IsInt, Target.FloatType > > > In familiar territory (C and C++), > I like switches because they "evaluate simultaneously", at least however the compiler can figure it. > > > That is: > > > if foo == 1 > else if foo == 2 > else if foo == 3 > else if foo == 4 > else if foo == 5 > > unless the compiler is very smart is always go to penalize 5 comparisons for "5", > plus the compiler might assume I'm meaning to optimize the earlier cases > as being more common, but then I have to worry about the ordering > to get the common cases earlier whereas > if I write > switch (foo) > case 1: ... > case 2: ... > case 3: ... > case 4: ... > case 5: ... > > > I'll let the compiler chose between table lookup, linear search, binary search. > "table lookup" being "simultaneous evaluation", binary search being nice > > > I also don't like "if ladders" because if I'm stepping through unoptimized > code line by line, it is tedious. > [mostly omitted aside: I go out of my way when writing command line > parsers in C to have a switch statement instead of an if/elseif/elseif ladder] > > > However > In Modula-3, I've gotten warnings when I miss cases, so there is overhead > of always writing "else". > Partly this because I don't know Modula-3 well. You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. > The use of FloatType[type] was already there, and it is good > to have equivalence classes to reduce the number of cases listed > and allow for more to be added later, "silently". Again, with CASE you can still select for those, without having a cascade of IF. > > I also don't like "data based interfaces", I prefer function calls, > that's why Is64 instead of is foo IN Types64. > (but FloatType[type] was already there) > Granted, I lament the lack of inlining in m3back. Function call is overkill. Use the types! > I'm worried about nomenclature if/when this is extended to 64bit architectures. > I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. > I think I just drifted away from using TInt.Min/Max{8,16,32,64}. The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. > I'll see if any uses remain. > Eh maybe just: > C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); > > > Some places were in extract/insert, and looked wrong. > > > Yes definitely more eyes on m3back appreciated. > Heck more eyes on cm3 appreciated! We have way too few. :( > There were many style changes along with making things not work. > I didn't want to sift through it all so I put it all back. > Now to ponder sifting through it more slowly from a working baseline. > > > Also I often favor mvar.mvar_type over mvar.type, so I can plain text > search for mvar_type, and not just "type". I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). > I realize that you can't throw out all contexta all the time, but, > there is something to be said for flatter namespaces. > Nothing scales like plain text search. > No language aware search work adequately. > Let alone the matter of existance of languages x tools. > > > I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. > I would certainly be ok with TypeIsFloat to make it more consistently function call based, > thoug I know I put in some cases too -- for the "simultaneous evaluation" property. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 14:54:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] max_align > > P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 27 Feb 2010, at 14:11, Jay K wrote: > > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 23:12:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 22:12:21 +0000 Subject: [M3devel] max_align In-Reply-To: <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , ,,<7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, ,,, , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , , <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> Message-ID: ok..I'll maybe reply more later. But what does it mean to load_int(type1, value1) load_int(type2, value2) add(type3) It seems like both the values and the operations have types. I do try to consider all types, with "ELSE <* ASSERT FALSE *>", be it an if ladder or a switch. Perhaps that is too little thought? I admit, ZType, IType, AType, etc., I can't keep them straight. I "know" that floats are handled specially by m3back and so I can ignore them in most code and that the backend traffics only rarely in 8 or 16 bit types, so the four most interesting types are Int32, Int64, Word32, Word64. As well, since my agenda is currently 64bit longint, I just need to add word64/int64 to the existing paths. (m3back is so geared against int8/word8/int16/word16 that it takes special pain to widen all function results, lest they be generated by a C compiler, and the historical command indict the C compiler's behavior, I edited out the subjectivity; and the 8 bits produced by setccop are always immediately widened; I have to revisit that soon, I think the code can be much better. That is part of the evidence to what it traffics in.) - Jay Subject: Re: [M3devel] max_align From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 16:24:41 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 27 Feb 2010, at 15:50, Jay K wrote: > Target.Int values would always be interpreted based on their associated type They kind of mostly are? Except..I mean..you know..I bury a size in them, which is a step. No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: add Int.32 the semantics are: take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. e.g., in C, (int)a + (int)b So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! But the signnedness is not buried in them and I might get that wrong sometimes. It is often, you know, the operation and not the type. "Shift is always unsigned." But Add isn't. But with "half range cardinals", I'm not sure it matters. 16_40000000 * 2 overflows the same for INTEGER and CARDINAL LAST(INTEGER) + 1 ditto. Some operations do vary and they are handled correctly I think: abs, mul, div. Actually this is somewhat wrong: signed and unsigned multiplication I don't think needs to vary the way it does. They are the same in the lower bits. The compiler doesn't need to be so picky I believe. In particular, in the following C: int F1(int a, int b) { return a * b; } unsigned F2(unsigned a, unsigned b) { return a * b; } __int64 F3(int a, int b) { return a * (__int64)b; } unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } only one of them does unsigned multiplication, the last. (and notice that it does it inline with one instruction; something our compiler will be harder pressed to do given the lack of mixed operations! but you could leave it to a smart optimizer) > Is64, IsWord, IsInt, Target.FloatType In familiar territory (C and C++), I like switches because they "evaluate simultaneously", at least however the compiler can figure it. That is: if foo == 1 else if foo == 2 else if foo == 3 else if foo == 4 else if foo == 5 unless the compiler is very smart is always go to penalize 5 comparisons for "5", plus the compiler might assume I'm meaning to optimize the earlier cases as being more common, but then I have to worry about the ordering to get the common cases earlier whereas if I write switch (foo) case 1: ... case 2: ... case 3: ... case 4: ... case 5: ... I'll let the compiler chose between table lookup, linear search, binary search. "table lookup" being "simultaneous evaluation", binary search being nice I also don't like "if ladders" because if I'm stepping through unoptimized code line by line, it is tedious. [mostly omitted aside: I go out of my way when writing command line parsers in C to have a switch statement instead of an if/elseif/elseif ladder] However In Modula-3, I've gotten warnings when I miss cases, so there is overhead of always writing "else". Partly this because I don't know Modula-3 well. You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. The use of FloatType[type] was already there, and it is good to have equivalence classes to reduce the number of cases listed and allow for more to be added later, "silently". Again, with CASE you can still select for those, without having a cascade of IF. I also don't like "data based interfaces", I prefer function calls, that's why Is64 instead of is foo IN Types64. (but FloatType[type] was already there) Granted, I lament the lack of inlining in m3back. Function call is overkill. Use the types! I'm worried about nomenclature if/when this is extended to 64bit architectures. I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. I think I just drifted away from using TInt.Min/Max{8,16,32,64}. The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. I'll see if any uses remain. Eh maybe just: C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); Some places were in extract/insert, and looked wrong. Yes definitely more eyes on m3back appreciated. Heck more eyes on cm3 appreciated! We have way too few. :( There were many style changes along with making things not work. I didn't want to sift through it all so I put it all back. Now to ponder sifting through it more slowly from a working baseline. Also I often favor mvar.mvar_type over mvar.type, so I can plain text search for mvar_type, and not just "type". I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). I realize that you can't throw out all contexta all the time, but, there is something to be said for flatter namespaces. Nothing scales like plain text search. No language aware search work adequately. Let alone the matter of existance of languages x tools. I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. I would certainly be ok with TypeIsFloat to make it more consistently function call based, thoug I know I put in some cases too -- for the "simultaneous evaluation" property. - Jay From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 14:54:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] max_align P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 27 23:52:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 27 Feb 2010 23:52:50 +0100 Subject: [M3devel] examples In-Reply-To: References: Message-ID: <20100227235250.mbm07ehhwsokskg4@mail.elegosoft.com> Quoting Jay K : > > I think the release branch is missing the change to move examples. > > Update it? Yes, please do. Olaf > (I say this based on differences in the scripts.) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 28 00:08:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 18:08:07 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , , <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> Message-ID: <21DE2D25-A591-4E8E-AF8C-0E050CE471D4@cs.purdue.edu> On 27 Feb 2010, at 17:12, Jay K wrote: > ok..I'll maybe reply more later. > > > But what does it mean to > > > load_int(type1, value1) Take value, cast to type1 (may involve sign extend from low bits/truncation of high bits), push on stack. > load_int(type2, value2) Take value, cast to type2 (may involve sign extend from low bits/truncation of high bits), push on stack. > add(type3) Add values on stack, interpreted as type3 (perhaps sign extended/truncated), with result of type3. > It seems like both the values and the operations have types. The types say how the bits of the operands are to be interpreted. > I do try to consider all types, with "ELSE <* ASSERT FALSE *>", be it an if ladder or a switch. > Perhaps that is too little thought? > I admit, ZType, IType, AType, etc., I can't keep them straight. > I "know" that floats are handled specially by m3back and so I can ignore them in most code > and that the backend traffics only rarely in 8 or 16 bit types, so the four most interesting > types are Int32, Int64, Word32, Word64. Correct. > As well, since my agenda is currently 64bit longint, I just need to add word64/int64 to > the existing paths. Right. > (m3back is so geared against int8/word8/int16/word16 that it takes special pain > to widen all function results, lest they be generated by a C compiler, and the > historical command indict the C compiler's behavior, I edited out the subjectivity; > and the 8 bits produced by setccop are always > immediately widened; I have to revisit that soon, I think the code can be much better. > That is part of the evidence to what it traffics in.) Yes, the front-end never usually generates stack values of 8/16 bits. All integer operations are in the 32/64-bit types. > > > - Jay > > > Subject: Re: [M3devel] max_align > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 16:24:41 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > On 27 Feb 2010, at 15:50, Jay K wrote: > > > Target.Int values would always be interpreted based on their associated type > > > They kind of mostly are? > Except..I mean..you know..I bury a size in them, which is a step. > > No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: > > add Int.32 > > the semantics are: > > take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. > > e.g., in C, (int)a + (int)b > > So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. > > I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! > > But the signnedness is not buried in them and I might get that wrong sometimes. > It is often, you know, the operation and not the type. > "Shift is always unsigned." > But Add isn't. > But with "half range cardinals", I'm not sure it matters. > 16_40000000 * 2 overflows the same for INTEGER and CARDINAL > LAST(INTEGER) + 1 ditto. > > > Some operations do vary and they are handled correctly I think: abs, mul, div. > Actually this is somewhat wrong: signed and unsigned multiplication I don't think > needs to vary the way it does. They are the same in the lower bits. > The compiler doesn't need to be so picky I believe. In particular, in the following C: > int F1(int a, int b) { return a * b; } > unsigned F2(unsigned a, unsigned b) { return a * b; } > __int64 F3(int a, int b) { return a * (__int64)b; } > unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } > > > only one of them does unsigned multiplication, the last. > (and notice that it does it inline with one instruction; something > our compiler will be harder pressed to do given the lack of mixed operations! > but you could leave it to a smart optimizer) > > > > Is64, IsWord, IsInt, Target.FloatType > > > In familiar territory (C and C++), > I like switches because they "evaluate simultaneously", at least however the compiler can figure it. > > > That is: > > > if foo == 1 > else if foo == 2 > else if foo == 3 > else if foo == 4 > else if foo == 5 > > unless the compiler is very smart is always go to penalize 5 comparisons for "5", > plus the compiler might assume I'm meaning to optimize the earlier cases > as being more common, but then I have to worry about the ordering > to get the common cases earlier whereas > if I write > switch (foo) > case 1: ... > case 2: ... > case 3: ... > case 4: ... > case 5: ... > > > I'll let the compiler chose between table lookup, linear search, binary search. > "table lookup" being "simultaneous evaluation", binary search being nice > > > I also don't like "if ladders" because if I'm stepping through unoptimized > code line by line, it is tedious. > [mostly omitted aside: I go out of my way when writing command line > parsers in C to have a switch statement instead of an if/elseif/elseif ladder] > > > However > In Modula-3, I've gotten warnings when I miss cases, so there is overhead > of always writing "else". > Partly this because I don't know Modula-3 well. > > You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. > > The use of FloatType[type] was already there, and it is good > to have equivalence classes to reduce the number of cases listed > and allow for more to be added later, "silently". > > Again, with CASE you can still select for those, without having a cascade of IF. > > > I also don't like "data based interfaces", I prefer function calls, > that's why Is64 instead of is foo IN Types64. > (but FloatType[type] was already there) > Granted, I lament the lack of inlining in m3back. > > Function call is overkill. Use the types! > > I'm worried about nomenclature if/when this is extended to 64bit architectures. > I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. > > No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. > > I think I just drifted away from using TInt.Min/Max{8,16,32,64}. > > The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. > > I'll see if any uses remain. > Eh maybe just: > C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); > > > Some places were in extract/insert, and looked wrong. > > > Yes definitely more eyes on m3back appreciated. > Heck more eyes on cm3 appreciated! We have way too few. :( > There were many style changes along with making things not work. > I didn't want to sift through it all so I put it all back. > Now to ponder sifting through it more slowly from a working baseline. > > > Also I often favor mvar.mvar_type over mvar.type, so I can plain text > search for mvar_type, and not just "type". > > I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). > > I realize that you can't throw out all contexta all the time, but, > there is something to be said for flatter namespaces. > Nothing scales like plain text search. > No language aware search work adequately. > Let alone the matter of existance of languages x tools. > > > I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. > I would certainly be ok with TypeIsFloat to make it more consistently function call based, > thoug I know I put in some cases too -- for the "simultaneous evaluation" property. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 14:54:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] max_align > > P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 27 Feb 2010, at 14:11, Jay K wrote: > > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 28 09:56:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 28 Feb 2010 08:56:08 +0000 Subject: [M3devel] r_test, pr_test, pb_test Message-ID: Olaf, I think pr_test and pb_test are cryptic, and there is no explanation what "pr" and "pb" stand for (as opposed to p_test, e_test, c_test, which have comment). I propose run_flags_test build_flags_test or program_with_run_flags program_with_build_flags program_with_compiler_flags or somesuch. I'm guessing "r" means "run flags", "b" means "build flags. I'll probably do something here very soon, since I'm adding another type of test. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 28 10:54:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 28 Feb 2010 09:54:44 +0000 Subject: [M3devel] portable/less portable test variations Message-ID: I commited something here. The function in m3tests/m3makefile is "mixed_portability_test". p227 uses it. The test can be run with no parameters, in which case the output is "fully portable" (the same on all targets) and the output is compared with the "unadorned" stdout.pgm, etc. And it can be run with the flag -include-less-portable-output, in which case we probe for, e.g.: stdout.pgm32 stdout.pgm-little_endian32 stdout.pgm-little_endian (or "64" or "big") The automated tests will run both variations. As well, the preexisting recent default was to probe, as we had a few cases that needed "stdout.pgm64". We should clean this up so those are called out specifically. This way, e.g. PPC can be compared to SPARC, I386_* can be compared amongst each other, with more coverage than might be had if just all platforms compared against all platforms and the coverage constrained. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: portable/less portable test variations Date: Wed, 24 Feb 2010 12:41:12 +0000 I'd like to write tests that, given different command line parameters, will either output totally portable results, or only somewhat portable, where "somewhat" probably means either portable to particular wordsize or portable to wordsize+endian. Worst case, completely platform specific. We'd have 1, 3, or 5 checked in expected results. Or possibly 1+n (portable + n platforms). This case is less useful, because it takes away the ability to compare, e.g. LINUXLIBC6 to NT386. The test would run twice, with and without the command line option. I guess it is about as much work to implement as to describe, but I've let it drag out. I have tests that would benefit from this. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 28 12:55:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 28 Feb 2010 12:55:38 +0100 Subject: [M3devel] r_test, pr_test, pb_test In-Reply-To: References: Message-ID: <20100228125538.29yb34mrs4wsoo4o@mail.elegosoft.com> Quoting Jay K : > Olaf, I think pr_test and pb_test are cryptic, and there is > no explanation what "pr" and "pb" stand for (as opposed > to p_test, e_test, c_test, which have comment). > > I propose > > run_flags_test > build_flags_test > > or > > program_with_run_flags > program_with_build_flags > program_with_compiler_flags > > or somesuch. > > I'm guessing "r" means "run flags", "b" means "build flags. > > I'll probably do something here very soon, since I'm adding another > type of test. Yes. I must have forgotten to document it better. They are there to run a program or its build with additional flags or options. You can easily see their use at the test instances though: pr_test ("p2", "p213", "runtime arguments: @M3paranoidgc", "@M3paranoidgc") pr_test ("p2", "p214", "runtime arguments: @M3noincremental", "@M3noincremental") pr_test ("p2", "p215", "runtime arguments: @M3nogenerational", "@M3nogenerational") pr_test ("p2", "p216", "runtime arguments: @M3nogc", "@M3nogc") pb_test ("p2", "p217", ".M3SHIP program", "-no-m3ship-resolution") pb_test ("p2", "p218", ".M3SHIP Program", "-no-m3ship-resolution") pb_test ("p2", "p219", ".M3SHIP Program group-writable", "-no-m3ship-resolution -group-writable") pb_test ("p2", "p220", ".M3SHIP library", "-no-m3ship-resolution") pb_test ("p2", "p221", ".M3SHIP Library", "-no-m3ship-resolution") pb_test ("p2", "p222", ".M3SHIP Library", "-no-m3ship-resolution -group-writable") % The following test won't run until FSUtils.RmRec() is fixed %pb_test ("p2", "p223", ".M3SHIP Library", "-no-m3ship-resolution -group-writable") Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 08:41:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 07:41:04 +0000 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1264972487.4240.4.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: Let's say I have: TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; TYPE FOOA = ARRAY [0..1] OF FOO; And I have a platform with max_align = 32 and a platform with max_align = 64. One platform will make FOOA be 24 bytes, the other 32. One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. Can that pickle be read/written by the two platforms? And how does the code know/detect the difference? That is, if a platform changed from max_align = 32 to 64, would the pickle code work just as well on the "same" platform as on the "different" platforms? I very recently changed NT386 max_align from 32 to 64, and I believe the remaining active platforms with max_align = 32 should also be 64. It would "only" affect pickles with LONGINT or LONGFLOAT, as well as "lining up" such structs with C. Such alignment shold make us not need the extra "unaligned double" switch on most platforms (some mystery still on some platforms) as well as perhaps be needed for some atomic operations, esp. maybe on LONGINT on 32bit x86. - Jay > From: dragisha at m3w.org > To: rodney_bates at lcwb.coop > Date: Sun, 31 Jan 2010 22:14:47 +0100 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > I've not changed my code, that is for sure.... But now I am not sure > some parent type (esp MUTEX here an there) was not changed... I'll take > a look on this again sometime soon and report my findings. > > Thanks for clues. > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > Dragi?a Duri? wrote: > > > I've asked this before, but didn't catch answer: > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> I suggest we can probably get by with platform-independent > > >> packing/alignment settings. > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > does not read that pickle anymore.... > > > > And you are certain your program that tries to read still contains > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > Someone remembers moment when this incompatible changes were made? > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 1 09:11:38 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 1 Feb 2010 03:11:38 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> That shouldn't affect things since the pickler picks apart the structures and ships the individual primitives. Right? On 1 Feb 2010, at 02:41, Jay K wrote: > Let's say I have: > > > TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; > TYPE FOOA = ARRAY [0..1] OF FOO; > > > And I have a platform with max_align = 32 and a platform with max_align = 64. > One platform will make FOOA be 24 bytes, the other 32. > One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. > Can that pickle be read/written by the two platforms? > And how does the code know/detect the difference? > That is, if a platform changed from max_align = 32 to 64, would the pickle code work just > as well on the "same" platform as on the "different" platforms? > > > I very recently changed NT386 max_align from 32 to 64, and I believe > the remaining active platforms with max_align = 32 should also be 64. > It would "only" affect pickles with LONGINT or LONGFLOAT, as well > as "lining up" such structs with C. > > > Such alignment shold make us not need the extra "unaligned double" switch > on most platforms (some mystery still on some platforms) as well as > perhaps be needed for some atomic operations, esp. maybe on > LONGINT on 32bit x86. > > > - Jay > > > > From: dragisha at m3w.org > > To: rodney_bates at lcwb.coop > > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] platform-independent packing/alignment? > > > > I've not changed my code, that is for sure.... But now I am not sure > > some parent type (esp MUTEX here an there) was not changed... I'll take > > a look on this again sometime soon and report my findings. > > > > Thanks for clues. > > > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > > > Dragi?a Duri? wrote: > > > > I've asked this before, but didn't catch answer: > > > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > > >> I suggest we can probably get by with platform-independent > > > >> packing/alignment settings. > > > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > > does not read that pickle anymore.... > > > > > > And you are certain your program that tries to read still contains > > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > > > > Someone remembers moment when this incompatible changes were made? > > -- > > Dragi?a Duri? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Mon Feb 1 09:19:06 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 01 Feb 2010 00:19:06 -0800 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> Message-ID: <20100201081906.583961A2099@async.async.caltech.edu> For what it's worth... I recall someone (Dragisa?) just complained that he was having problems unpickling data structures... I have never had much luck pickling and unpickling MUTEXes, using a few (not very different) M3 compilers. I just leave them out of my pickles. It makes the pickles a lot more compatible across versions. I'm not talking recent CM3 versions here but a variety of old versions. Implementors have seemed to modify MUTEX quite a bit. What's the point of pickling it anyhow? If it's an active mutex the unpickling will surely lead to garbage, if there are wait queues and things.. then you wind up un/pickling Thread structures too. Mika Tony Hosking writes: > >--Apple-Mail-4--1058110347 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/plain; > charset=utf-8 > >That shouldn't affect things since the pickler picks apart the = >structures and ships the individual primitives. Right? > >On 1 Feb 2010, at 02:41, Jay K wrote: > >> Let's say I have: >> =20 >> =20 >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; >> TYPE FOOA =3D ARRAY [0..1] OF FOO; >> =20 >> =20 >> And I have a platform with max_align =3D 32 and a platform with = >max_align =3D 64. >> One platform will make FOOA be 24 bytes, the other 32. >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = >won't. >> Can that pickle be read/written by the two platforms? >> And how does the code know/detect the difference? >> That is, if a platform changed from max_align =3D 32 to 64, would the = >pickle code work just >> as well on the "same" platform as on the "different" platforms? >> =20 >> =20 >> I very recently changed NT386 max_align from 32 to 64, and I believe >> the remaining active platforms with max_align =3D 32 should also be = >64. >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well >> as "lining up" such structs with C. >> =20 >> =20 >> Such alignment shold make us not need the extra "unaligned double" = >switch >> on most platforms (some mystery still on some platforms) as well as >> perhaps be needed for some atomic operations, esp. maybe on >> LONGINT on 32bit x86. >> =20 >> =20 >> - Jay >>=20 >> =20 >> > From: dragisha at m3w.org >> > To: rodney_bates at lcwb.coop >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] platform-independent packing/alignment? >> >=20 >> > I've not changed my code, that is for sure.... But now I am not sure >> > some parent type (esp MUTEX here an there) was not changed... I'll = >take >> > a look on this again sometime soon and report my findings. >> >=20 >> > Thanks for clues. >> >=20 >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: >> > >=20 >> > > Dragi=C5=A1a Duri=C4=87 wrote: >> > > > I've asked this before, but didn't catch answer: >> > > >=20 >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: >> > > >> I suggest we can probably get by with platform-independent >> > > >> packing/alignment settings. >> > > >=20 >> > > > Some time ago I've used pickles (CM3) to save some data... My = >program >> > > > does not read that pickle anymore....=20 >> > >=20 >> > > And you are certain your program that tries to read still contains >> > > exact structurally equivalent types to all the types in the = >pickle? >> > >=20 >> > > >=20 >> > > > Someone remembers moment when this incompatible changes were = >made?=20 >> > --=20 >> > Dragi=C5=A1a Duri=C4=87 >> >=20 > > >--Apple-Mail-4--1058110347 >Content-Transfer-Encoding: quoted-printable >Content-Type: text/html; > charset=utf-8 > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = >after-white-space; ">That shouldn't affect things since the pickler = >picks apart the structures and ships the individual primitives. = > Right?
>
On 1 Feb 2010, at 02:41, Jay K wrote:

class=3D"Apple-interchange-newline">
class=3D"Apple-style-span" style=3D"border-collapse: separate; = >font-family: Helvetica; font-size: medium; font-style: normal; = >font-variant: normal; font-weight: normal; letter-spacing: normal; = >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = >white-space: normal; widows: 2; word-spacing: 0px; = >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = >auto; -webkit-text-stroke-width: 0px; ">
style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = >FOO;
 
 
And I have a platform with max_align = >=3D 32 and a platform with max_align =3D 64.
One platform will = >make FOOA be 24 bytes, the other 32.
  One platform will = >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = >pickle be read/written by the two platforms?
And how does the code = >know/detect the difference?
That is, if a platform changed from = >max_align =3D 32 to 64, would the pickle code work just
as = >well on the "same" platform as on the "different" = >platforms?
 
 
I very recently changed NT386 = >max_align from 32 to 64, and I believe
the remaining active platforms = >with max_align =3D 32 should also be 64.
It would "only" affect = >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = >structs with C.
 
 
Such alignment shold make us not = >need the extra "unaligned double" switch
on most platforms (some = >mystery still on some platforms) as well as
perhaps be needed for = >some atomic operations, esp. maybe on
LONGINT on 32bit = >x86.
 
 
 - Jay

 
> From:class=3D"Apple-converted-space"> href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To:class=3D"Apple-converted-space"> href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC:class=3D"Apple-converted-space"> href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = >Subject: Re: [M3devel] platform-independent = >packing/alignment?
>class=3D"Apple-converted-space"> 
> I've not changed = >my code, that is for sure.... But now I am not sure
> some parent = >type (esp MUTEX here an there) was not changed... I'll take
> a = >look on this again sometime soon and report my findings.
>class=3D"Apple-converted-space"> 
> Thanks for = >clues.
> 
> = >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = >> 
> > = >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = >but didn't catch answer:
> > >class=3D"Apple-converted-space"> 
> > > On Sun, = >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = >we can probably get by with platform-independent
> > >> = >packing/alignment settings.
> > >class=3D"Apple-converted-space"> 
> > > Some = >time ago I've used pickles (CM3) to save some data... My program
> = >> > does not read that pickle anymore....class=3D"Apple-converted-space"> 
> >class=3D"Apple-converted-space"> 
> > And you are = >certain your program that tries to read still contains
> > = >exact structurally equivalent types to all the types in the = >pickle?
> >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > > Someone = >remembers moment when this incompatible changes were made?class=3D"Apple-converted-space"> 
> --class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = >Duri=C4=87 <href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
>class=3D"Apple-converted-space"> 
>

= > >--Apple-Mail-4--1058110347-- From dragisha at m3w.org Mon Feb 1 09:41:48 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Mon, 01 Feb 2010 09:41:48 +0100 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <20100201081906.583961A2099@async.async.caltech.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> Message-ID: <1265013708.4240.16.camel@faramir.m3w.org> MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that code being same even if changes were made to it's basic structure... Or not... On the second thought, MUTEX is basically fixed, but it's revealations can vary. Thus making it incompatible over pickles/versions. I've not looked at my code/data yet, but MUTEX was only an idea what went... It is OODBMS package, and mutex is not used for persistent data, only for tables/indexes. Thus, problem (at leat for me) remains and it is not pickled MUTEX. On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/plain; > > charset=utf-8 > > > >That shouldn't affect things since the pickler picks apart the = > >structures and ships the individual primitives. Right? > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > >> Let's say I have: > >> =20 > >> =20 > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > >> =20 > >> =20 > >> And I have a platform with max_align =3D 32 and a platform with = > >max_align =3D 64. > >> One platform will make FOOA be 24 bytes, the other 32. > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > >won't. > >> Can that pickle be read/written by the two platforms? > >> And how does the code know/detect the difference? > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > >pickle code work just > >> as well on the "same" platform as on the "different" platforms? > >> =20 > >> =20 > >> I very recently changed NT386 max_align from 32 to 64, and I believe > >> the remaining active platforms with max_align =3D 32 should also be = > >64. > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > >> as "lining up" such structs with C. > >> =20 > >> =20 > >> Such alignment shold make us not need the extra "unaligned double" = > >switch > >> on most platforms (some mystery still on some platforms) as well as > >> perhaps be needed for some atomic operations, esp. maybe on > >> LONGINT on 32bit x86. > >> =20 > >> =20 > >> - Jay > >>=20 > >> =20 > >> > From: dragisha at m3w.org > >> > To: rodney_bates at lcwb.coop > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > >> >=20 > >> > I've not changed my code, that is for sure.... But now I am not sure > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > >take > >> > a look on this again sometime soon and report my findings. > >> >=20 > >> > Thanks for clues. > >> >=20 > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > >> > >=20 > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > >> > > > I've asked this before, but didn't catch answer: > >> > > >=20 > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > >> > > >> I suggest we can probably get by with platform-independent > >> > > >> packing/alignment settings. > >> > > >=20 > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > >program > >> > > > does not read that pickle anymore....=20 > >> > >=20 > >> > > And you are certain your program that tries to read still contains > >> > > exact structurally equivalent types to all the types in the = > >pickle? > >> > >=20 > >> > > >=20 > >> > > > Someone remembers moment when this incompatible changes were = > >made?=20 > >> > --=20 > >> > Dragi=C5=A1a Duri=C4=87 > >> >=20 > > > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/html; > > charset=utf-8 > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > >after-white-space; ">That shouldn't affect things since the pickler = > >picks apart the structures and ships the individual primitives. = > > Right?
> >
On 1 Feb 2010, at 02:41, Jay K wrote:

>class=3D"Apple-interchange-newline">
>class=3D"Apple-style-span" style=3D"border-collapse: separate; = > >font-family: Helvetica; font-size: medium; font-style: normal; = > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > >white-space: normal; widows: 2; word-spacing: 0px; = > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > >auto; -webkit-text-stroke-width: 0px; ">
>style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > >FOO;
 
 
And I have a platform with max_align = > >=3D 32 and a platform with max_align =3D 64.
One platform will = > >make FOOA be 24 bytes, the other 32.
  One platform will = > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > >pickle be read/written by the two platforms?
And how does the code = > >know/detect the difference?
That is, if a platform changed from = > >max_align =3D 32 to 64, would the pickle code work just
as = > >well on the "same" platform as on the "different" = > >platforms?
 
 
I very recently changed NT386 = > >max_align from 32 to 64, and I believe
the remaining active platforms = > >with max_align =3D 32 should also be 64.
It would "only" affect = > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > >structs with C.
 
 
Such alignment shold make us not = > >need the extra "unaligned double" switch
on most platforms (some = > >mystery still on some platforms) as well as
perhaps be needed for = > >some atomic operations, esp. maybe on
LONGINT on 32bit = > >x86.
 
 
 - Jay

 
> From: >class=3D"Apple-converted-space">  >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: >class=3D"Apple-converted-space">  >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: >class=3D"Apple-converted-space">  >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > >Subject: Re: [M3devel] platform-independent = > >packing/alignment?
> >class=3D"Apple-converted-space"> 
> I've not changed = > >my code, that is for sure.... But now I am not sure
> some parent = > >type (esp MUTEX here an there) was not changed... I'll take
> a = > >look on this again sometime soon and report my findings.
> >class=3D"Apple-converted-space"> 
> Thanks for = > >clues.
> 
> = > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > >> 
> > = > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > >but didn't catch answer:
> > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > >we can probably get by with platform-independent
> > >> = > >packing/alignment settings.
> > > >class=3D"Apple-converted-space"> 
> > > Some = > >time ago I've used pickles (CM3) to save some data... My program
> = > >> > does not read that pickle anymore.... >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > And you are = > >certain your program that tries to read still contains
> > = > >exact structurally equivalent types to all the types in the = > >pickle?
> > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > > Someone = > >remembers moment when this incompatible changes were made? >class=3D"Apple-converted-space"> 
> -- >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > >Duri=C4=87 < >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> >class=3D"Apple-converted-space"> 
 >>

= > > > >--Apple-Mail-4--1058110347-- -- Dragi?a Duri? From wagner at elegosoft.com Mon Feb 1 11:52:15 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 11:52:15 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org> Message-ID: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Quoting Tony Hosking : > Surely we are close. What stability issues are there on the release branch? Jay seems to have been hardworking to bring the release branch up-to-date. The last changes are about a week old now though. See FreeBSD or any other target for a list: http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes On this platform CVSup, db, odbc and m3gdb are still failing/missing: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ CVSup also fails on Linux, 32 and 64 bit: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ Windows shows even more test failures: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ Solaris seems to have some severe problems: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ Darwin, PPC_Linux and OPENBSD haven't been built/tested for month (no servers available) as has FreeBSD4 (I still want to set that up again on one of our machines, but didn't get round till now). So I'd say there's still a lot of tedious work before we can schedule another release package build. Anybody able and willing to fix some of the problems reported above is encouraged to do so. Olaf > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > >> I don't want to be a buzz kill, but it's almost February 2010, and >> 5.8 stable is still not out. Are there still any issues left? >> Anything that can be ignored until after release? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 12:37:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 11:37:39 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: I hadn't looked and hadn't realized. I'll look. I thought things were as about up to date as they would get (no LONGINT on NT386, no Atomic, but "revised LONGINT" on others -- m3front matching current, at least before more atomic changes). There is the cvsup problem I was ignoring. The bug report was good but didn't have e.g. the cvsup file. I'll look at these things. Fwiw, Modula-3 has really been quite stable for like 15 years now, very few changes (too few), very few regressions, but definitely some. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 1 13:13:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 12:13:57 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , , , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com>, Message-ID: The NT386 problems are "path related" and trying to do anything with postgres. I'm look at the others. FreeBSD I would suspect is missing some odbc packages but haven't really looked. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Mon, 1 Feb 2010 11:37:39 +0000 Subject: Re: [M3devel] 5.8 Release? I hadn't looked and hadn't realized. I'll look. I thought things were as about up to date as they would get (no LONGINT on NT386, no Atomic, but "revised LONGINT" on others -- m3front matching current, at least before more atomic changes). There is the cvsup problem I was ignoring. The bug report was good but didn't have e.g. the cvsup file. I'll look at these things. Fwiw, Modula-3 has really been quite stable for like 15 years now, very few changes (too few), very few regressions, but definitely some. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 1 15:54:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 14:54:06 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar to LINUXLIBC, SOLgnu/SOLsun. PPC_DARWIN I can make available too. I'm also still planning on making several more available. Some are already running. Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. - Jay > Date: Mon, 1 Feb 2010 11:52:15 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 5.8 Release? > > Quoting Tony Hosking : > > > Surely we are close. What stability issues are there on the release branch? > > Jay seems to have been hardworking to bring the release branch up-to-date. > The last changes are about a week old now though. See FreeBSD or any other > target for a list: > > > http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > > On this platform CVSup, db, odbc and m3gdb are still failing/missing: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > > CVSup also fails on Linux, 32 and 64 bit: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > > Windows shows even more test failures: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > > Solaris seems to have some severe problems: > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > (no servers available) as has FreeBSD4 (I still want to set that up again > on one of our machines, but didn't get round till now). > > So I'd say there's still a lot of tedious work before we can schedule > another release package build. > > Anybody able and willing to fix some of the problems reported above > is encouraged to do so. > > Olaf > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > > 305 N. University Street | West Lafayette | IN 47907 | USA > > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > > > >> I don't want to be a buzz kill, but it's almost February 2010, and > >> 5.8 stable is still not out. Are there still any issues left? > >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 1 16:40:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 16:40:23 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: <20100201164023.6vbecip2fwwk0g0c@mail.elegosoft.com> Quoting Jay K : > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > to LINUXLIBC, SOLgnu/SOLsun. > > PPC_DARWIN I can make available too. > > I'm also still planning on making several more available. > > Some are already running. I just reported the status from Hudson. I haven't done anything there recently, so no idea why tests don't run if the servers are available. > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. Only if he allows ssh access from birch.elegosoft.com. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 1 19:23:22 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 01 Feb 2010 19:23:22 +0100 Subject: [M3devel] 5.8 Release? In-Reply-To: References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com> Message-ID: <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> Recent commits seem to have made matters worse: http://hudson.modula3.com:8080/ And PPC_DARWIN should now be back online. Olaf Quoting Jay K : > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > to LINUXLIBC, SOLgnu/SOLsun. > > PPC_DARWIN I can make available too. > > I'm also still planning on making several more available. > > Some are already running. > > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. > > - Jay > >> Date: Mon, 1 Feb 2010 11:52:15 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] 5.8 Release? >> >> Quoting Tony Hosking : >> >> > Surely we are close. What stability issues are there on the >> release branch? >> >> Jay seems to have been hardworking to bring the release branch up-to-date. >> The last changes are about a week old now though. See FreeBSD or any other >> target for a list: >> >> >> http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes >> >> On this platform CVSup, db, odbc and m3gdb are still failing/missing: >> >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ >> >> CVSup also fails on Linux, 32 and 64 bit: >> >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ >> >> Windows shows even more test failures: >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ >> >> Solaris seems to have some severe problems: >> >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ >> >> Darwin, PPC_Linux and OPENBSD haven't been built/tested for month >> (no servers available) as has FreeBSD4 (I still want to set that up again >> on one of our machines, but didn't get round till now). >> >> So I'd say there's still a lot of tedious work before we can schedule >> another release package build. >> >> Anybody able and willing to fix some of the problems reported above >> is encouraged to do so. >> >> Olaf >> >> > Antony Hosking | Associate Professor | Computer Science | Purdue >> University >> > 305 N. University Street | West Lafayette | IN 47907 | USA >> > Office +1 765 494 6001 | Mobile +1 765 427 5484 >> > >> > On 30 Jan 2010, at 19:19, Martin Bishop wrote: >> > >> >> I don't want to be a buzz kill, but it's almost February 2010, and >> >> 5.8 stable is still not out. Are there still any issues left? >> >> Anything that can be ignored until after release? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Mon Feb 1 20:30:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 19:30:36 +0000 Subject: [M3devel] 5.8 Release? In-Reply-To: <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> References: <4B64CC88.6070409@esoteriq.org>, , <20100201115215.lyff2ab2o888ws8k@mail.elegosoft.com>, , <20100201192322.6gb37lei68s0c04o@mail.elegosoft.com> Message-ID: Sorry, those should already be fixed. - Jay > Date: Mon, 1 Feb 2010 19:23:22 +0100 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] 5.8 Release? > > Recent commits seem to have made matters worse: > > http://hudson.modula3.com:8080/ > > > And PPC_DARWIN should now be back online. > > Olaf > > Quoting Jay K : > > > > Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > > > > Olaf, I386_OPENBSD, PPC_LINUX, should be fairly available -- similar > > to LINUXLIBC, SOLgnu/SOLsun. > > > > PPC_DARWIN I can make available too. > > > > I'm also still planning on making several more available. > > > > Some are already running. > > > > Tony has I386_DARWIN in Tinderbox, should be easy enough to put in Hudson. > > > > - Jay > > > >> Date: Mon, 1 Feb 2010 11:52:15 +0100 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] 5.8 Release? > >> > >> Quoting Tony Hosking : > >> > >> > Surely we are close. What stability issues are there on the > >> release branch? > >> > >> Jay seems to have been hardworking to bring the release branch up-to-date. > >> The last changes are about a week old now though. See FreeBSD or any other > >> target for a list: > >> > >> > >> http://hudson.modula3.com:8080/view/AMD64_FREEBSD/job/cm3-build-AMD64_FREEBSD/changes > >> > >> On this platform CVSup, db, odbc and m3gdb are still failing/missing: > >> > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/12/testReport/ > >> > >> CVSup also fails on Linux, 32 and 64 bit: > >> > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_LINUX/297/testReport/ > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-LINUXLIBC6/147/testReport/ > >> > >> Windows shows even more test failures: > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-NT386/154/testReport/ > >> > >> Solaris seems to have some severe problems: > >> > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLgnu/87/testReport/ > >> http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-SOLsun/83/testReport/ > >> > >> Darwin, PPC_Linux and OPENBSD haven't been built/tested for month > >> (no servers available) as has FreeBSD4 (I still want to set that up again > >> on one of our machines, but didn't get round till now). > >> > >> So I'd say there's still a lot of tedious work before we can schedule > >> another release package build. > >> > >> Anybody able and willing to fix some of the problems reported above > >> is encouraged to do so. > >> > >> Olaf > >> > >> > Antony Hosking | Associate Professor | Computer Science | Purdue > >> University > >> > 305 N. University Street | West Lafayette | IN 47907 | USA > >> > Office +1 765 494 6001 | Mobile +1 765 427 5484 > >> > > >> > On 30 Jan 2010, at 19:19, Martin Bishop wrote: > >> > > >> >> I don't want to be a buzz kill, but it's almost February 2010, and > >> >> 5.8 stable is still not out. Are there still any issues left? > >> >> Anything that can be ignored until after release? > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Mon Feb 1 20:37:48 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 1 Feb 2010 14:37:48 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1265013708.4240.16.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> <1265013708.4240.16.camel@faramir.m3w.org> Message-ID: For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. Regards, Randy Coleburn -----Original Message----- From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Monday, February 01, 2010 3:42 AM To: Mika Nystrom Cc: m3devel at elegosoft.com Subject: Re: [M3devel] platform-independent packing/alignment? MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that code being same even if changes were made to it's basic structure... Or not... On the second thought, MUTEX is basically fixed, but it's revealations can vary. Thus making it incompatible over pickles/versions. I've not looked at my code/data yet, but MUTEX was only an idea what went... It is OODBMS package, and mutex is not used for persistent data, only for tables/indexes. Thus, problem (at leat for me) remains and it is not pickled MUTEX. On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > > Tony Hosking writes: > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/plain; > > charset=utf-8 > > > >That shouldn't affect things since the pickler picks apart the = > >structures and ships the individual primitives. Right? > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > >> Let's say I have: > >> =20 > >> =20 > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > >> =20 > >> =20 > >> And I have a platform with max_align =3D 32 and a platform with = > >max_align =3D 64. > >> One platform will make FOOA be 24 bytes, the other 32. > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > >won't. > >> Can that pickle be read/written by the two platforms? > >> And how does the code know/detect the difference? > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > >pickle code work just > >> as well on the "same" platform as on the "different" platforms? > >> =20 > >> =20 > >> I very recently changed NT386 max_align from 32 to 64, and I believe > >> the remaining active platforms with max_align =3D 32 should also be = > >64. > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > >> as "lining up" such structs with C. > >> =20 > >> =20 > >> Such alignment shold make us not need the extra "unaligned double" = > >switch > >> on most platforms (some mystery still on some platforms) as well as > >> perhaps be needed for some atomic operations, esp. maybe on > >> LONGINT on 32bit x86. > >> =20 > >> =20 > >> - Jay > >>=20 > >> =20 > >> > From: dragisha at m3w.org > >> > To: rodney_bates at lcwb.coop > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > >> >=20 > >> > I've not changed my code, that is for sure.... But now I am not sure > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > >take > >> > a look on this again sometime soon and report my findings. > >> >=20 > >> > Thanks for clues. > >> >=20 > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > >> > >=20 > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > >> > > > I've asked this before, but didn't catch answer: > >> > > >=20 > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > >> > > >> I suggest we can probably get by with platform-independent > >> > > >> packing/alignment settings. > >> > > >=20 > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > >program > >> > > > does not read that pickle anymore....=20 > >> > >=20 > >> > > And you are certain your program that tries to read still contains > >> > > exact structurally equivalent types to all the types in the = > >pickle? > >> > >=20 > >> > > >=20 > >> > > > Someone remembers moment when this incompatible changes were = > >made?=20 > >> > --=20 > >> > Dragi=C5=A1a Duri=C4=87 > >> >=20 > > > > > >--Apple-Mail-4--1058110347 > >Content-Transfer-Encoding: quoted-printable > >Content-Type: text/html; > > charset=utf-8 > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > >after-white-space; ">That shouldn't affect things since the pickler = > >picks apart the structures and ships the individual primitives. = > > Right?
> >
On 1 Feb 2010, at 02:41, Jay K wrote:

>class=3D"Apple-interchange-newline">
>class=3D"Apple-style-span" style=3D"border-collapse: separate; = > >font-family: Helvetica; font-size: medium; font-style: normal; = > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > >white-space: normal; widows: 2; word-spacing: 0px; = > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > >auto; -webkit-text-stroke-width: 0px; ">
>style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > >FOO;
 
 
And I have a platform with max_align = > >=3D 32 and a platform with max_align =3D 64.
One platform will = > >make FOOA be 24 bytes, the other 32.
  One platform will = > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > >pickle be read/written by the two platforms?
And how does the code = > >know/detect the difference?
That is, if a platform changed from = > >max_align =3D 32 to 64, would the pickle code work just
as = > >well on the "same" platform as on the "different" = > >platforms?
 
 
I very recently changed NT386 = > >max_align from 32 to 64, and I believe
the remaining active platforms = > >with max_align =3D 32 should also be 64.
It would "only" affect = > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > >structs with C.
 
 
Such alignment shold make us not = > >need the extra "unaligned double" switch
on most platforms (some = > >mystery still on some platforms) as well as
perhaps be needed for = > >some atomic operations, esp. maybe on
LONGINT on 32bit = > >x86.
 
 
 - Jay

 
> From: >class=3D"Apple-converted-space">  >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: >class=3D"Apple-converted-space">  >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: >class=3D"Apple-converted-space">  >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > >Subject: Re: [M3devel] platform-independent = > >packing/alignment?
> >class=3D"Apple-converted-space"> 
> I've not changed = > >my code, that is for sure.... But now I am not sure
> some parent = > >type (esp MUTEX here an there) was not changed... I'll take
> a = > >look on this again sometime soon and report my findings.
> >class=3D"Apple-converted-space"> 
> Thanks for = > >clues.
> 
> = > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > >> 
> > = > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > >but didn't catch answer:
> > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > >we can probably get by with platform-independent
> > >> = > >packing/alignment settings.
> > > >class=3D"Apple-converted-space"> 
> > > Some = > >time ago I've used pickles (CM3) to save some data... My program
> = > >> > does not read that pickle anymore.... >class=3D"Apple-converted-space"> 
> > >class=3D"Apple-converted-space"> 
> > And you are = > >certain your program that tries to read still contains
> > = > >exact structurally equivalent types to all the types in the = > >pickle?
> > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > > Someone = > >remembers moment when this incompatible changes were made? >class=3D"Apple-converted-space"> 
> -- >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > >Duri=C4=87 < >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> >class=3D"Apple-converted-space"> 
 >>

= > > > >--Apple-Mail-4--1058110347-- -- Dragi?a Duri? From jay.krell at cornell.edu Mon Feb 1 20:46:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 1 Feb 2010 19:46:38 +0000 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , , <1264972487.4240.4.camel@faramir.m3w.org>, , <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu>, <20100201081906.583961A2099@async.async.caltech.edu>, <1265013708.4240.16.camel@faramir.m3w.org>, Message-ID: You *might* imagine pickling a mutex, held or not, like to "freeze"/"suspend" a running system, possibly to move to another system, where it is "resumed". But in reality, that won't work. If changing alignment/padding won't break pickles, I again suggest that "max_align" be raised to at least 64 for all architectures. So that double and longint are aligned. Or that max_align be thrown out entirely and have the architectures all declare things correctly..which they likely already are. > recreates the MUTEX in the environment of the reading program Just with "NEW(MUTEX)" right? No attempt to put it back in the same state, I assume. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Mon, 1 Feb 2010 14:37:48 -0500 > Subject: Re: [M3devel] platform-independent packing/alignment? > > For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Monday, February 01, 2010 3:42 AM > To: Mika Nystrom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > > On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > > For what it's worth... > > > > I recall someone (Dragisa?) just complained that he was having problems > > unpickling data structures... > > > > I have never had much luck pickling and unpickling MUTEXes, using a few > > (not very different) M3 compilers. I just leave them out of my pickles. > > It makes the pickles a lot more compatible across versions. I'm not > > talking recent CM3 versions here but a variety of old versions. > > Implementors have seemed to modify MUTEX quite a bit. What's the point > > of pickling it anyhow? If it's an active mutex the unpickling will > > surely lead to garbage, if there are wait queues and things.. then you > > wind up un/pickling Thread structures too. > > > > Mika > > > > Tony Hosking writes: > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/plain; > > > charset=utf-8 > > > > > >That shouldn't affect things since the pickler picks apart the = > > >structures and ships the individual primitives. Right? > > > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > > > >> Let's say I have: > > >> =20 > > >> =20 > > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > > >> =20 > > >> =20 > > >> And I have a platform with max_align =3D 32 and a platform with = > > >max_align =3D 64. > > >> One platform will make FOOA be 24 bytes, the other 32. > > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > > >won't. > > >> Can that pickle be read/written by the two platforms? > > >> And how does the code know/detect the difference? > > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > > >pickle code work just > > >> as well on the "same" platform as on the "different" platforms? > > >> =20 > > >> =20 > > >> I very recently changed NT386 max_align from 32 to 64, and I believe > > >> the remaining active platforms with max_align =3D 32 should also be = > > >64. > > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > > >> as "lining up" such structs with C. > > >> =20 > > >> =20 > > >> Such alignment shold make us not need the extra "unaligned double" = > > >switch > > >> on most platforms (some mystery still on some platforms) as well as > > >> perhaps be needed for some atomic operations, esp. maybe on > > >> LONGINT on 32bit x86. > > >> =20 > > >> =20 > > >> - Jay > > >>=20 > > >> =20 > > >> > From: dragisha at m3w.org > > >> > To: rodney_bates at lcwb.coop > > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > > >> >=20 > > >> > I've not changed my code, that is for sure.... But now I am not sure > > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > > >take > > >> > a look on this again sometime soon and report my findings. > > >> >=20 > > >> > Thanks for clues. > > >> >=20 > > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > >> > >=20 > > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > > >> > > > I've asked this before, but didn't catch answer: > > >> > > >=20 > > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> > > >> I suggest we can probably get by with platform-independent > > >> > > >> packing/alignment settings. > > >> > > >=20 > > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > > >program > > >> > > > does not read that pickle anymore....=20 > > >> > >=20 > > >> > > And you are certain your program that tries to read still contains > > >> > > exact structurally equivalent types to all the types in the = > > >pickle? > > >> > >=20 > > >> > > >=20 > > >> > > > Someone remembers moment when this incompatible changes were = > > >made?=20 > > >> > --=20 > > >> > Dragi=C5=A1a Duri=C4=87 > > >> >=20 > > > > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/html; > > > charset=utf-8 > > > > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > > >after-white-space; ">That shouldn't affect things since the pickler = > > >picks apart the structures and ships the individual primitives. = > > > Right?
> > >
On 1 Feb 2010, at 02:41, Jay K wrote:

> >class=3D"Apple-interchange-newline">
> >class=3D"Apple-style-span" style=3D"border-collapse: separate; = > > >font-family: Helvetica; font-size: medium; font-style: normal; = > > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > > >white-space: normal; widows: 2; word-spacing: 0px; = > > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > > >auto; -webkit-text-stroke-width: 0px; ">
> >style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > > >FOO;
 
 
And I have a platform with max_align = > > >=3D 32 and a platform with max_align =3D 64.
One platform will = > > >make FOOA be 24 bytes, the other 32.
  One platform will = > > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > > >pickle be read/written by the two platforms?
And how does the code = > > >know/detect the difference?
That is, if a platform changed from = > > >max_align =3D 32 to 64, would the pickle code work just
as = > > >well on the "same" platform as on the "different" = > > >platforms?
 
 
I very recently changed NT386 = > > >max_align from 32 to 64, and I believe
the remaining active platforms = > > >with max_align =3D 32 should also be 64.
It would "only" affect = > > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > > >structs with C.
 
 
Such alignment shold make us not = > > >need the extra "unaligned double" switch
on most platforms (some = > > >mystery still on some platforms) as well as
perhaps be needed for = > > >some atomic operations, esp. maybe on
LONGINT on 32bit = > > >x86.
 
 
 - Jay

 
> From: > >class=3D"Apple-converted-space">  > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: > >class=3D"Apple-converted-space">  > >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: > >class=3D"Apple-converted-space">  > >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > > >Subject: Re: [M3devel] platform-independent = > > >packing/alignment?
> > >class=3D"Apple-converted-space"> 
> I've not changed = > > >my code, that is for sure.... But now I am not sure
> some parent = > > >type (esp MUTEX here an there) was not changed... I'll take
> a = > > >look on this again sometime soon and report my findings.
> > >class=3D"Apple-converted-space"> 
> Thanks for = > > >clues.
> 
> = > > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > > >> 
> > = > > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > > >but didn't catch answer:
> > > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > > >we can probably get by with platform-independent
> > >> = > > >packing/alignment settings.
> > > > >class=3D"Apple-converted-space"> 
> > > Some = > > >time ago I've used pickles (CM3) to save some data... My program
> = > > >> > does not read that pickle anymore.... > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > And you are = > > >certain your program that tries to read still contains
> > = > > >exact structurally equivalent types to all the types in the = > > >pickle?
> > > >class=3D"Apple-converted-space"> 
> > > > >class=3D"Apple-converted-space"> 
> > > Someone = > > >remembers moment when this incompatible changes were made? > >class=3D"Apple-converted-space"> 
> -- > >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > > >Duri=C4=87 < > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> > >class=3D"Apple-converted-space"> 
 > >>

= > > > > > >--Apple-Mail-4--1058110347-- > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 1 20:52:55 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 13:52:55 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> Message-ID: <4B673117.5060105@lcwb.coop> Jay K wrote: > Let's say I have: > > > TYPE FOO = RECORD a: LONGFLOAT; b: UINT32; END; > TYPE FOOA = ARRAY [0..1] OF FOO; > > > And I have a platform with max_align = 32 and a platform with max_align > = 64. > One platform will make FOOA be 24 bytes, the other 32. > One platform will pad out FOO to be align the 8 byte LONGFLOAT, one won't. > Can that pickle be read/written by the two platforms? > And how does the code know/detect the difference? > That is, if a platform changed from max_align = 32 to 64, would the > pickle code work just > as well on the "same" platform as on the "different" platforms? > Yes, this will work fine. The header of the pickle file has a compact binary encoding of a copy of the RTPacking.T value for the target where the pickle was written. This contains target characteristics like max_align. Reading a pickle compares the RTPacking.T value of the reading machine with that in the pickle header and reconstructs the layout on both machines, then does any necessary conversion. > > I very recently changed NT386 max_align from 32 to 64, and I believe > the remaining active platforms with max_align = 32 should also be 64. > It would "only" affect pickles with LONGINT or LONGFLOAT, as well > as "lining up" such structs with C. > > > Such alignment shold make us not need the extra "unaligned double" switch > on most platforms (some mystery still on some platforms) as well as > perhaps be needed for some atomic operations, esp. maybe on > LONGINT on 32bit x86. > > > - Jay > > > > From: dragisha at m3w.org > > To: rodney_bates at lcwb.coop > > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] platform-independent packing/alignment? > > > > I've not changed my code, that is for sure.... But now I am not sure > > some parent type (esp MUTEX here an there) was not changed... I'll take > > a look on this again sometime soon and report my findings. > > > > Thanks for clues. > > > > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > > > > > Dragi?a Duri? wrote: > > > > I've asked this before, but didn't catch answer: > > > > > > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > > >> I suggest we can probably get by with platform-independent > > > >> packing/alignment settings. > > > > > > > > Some time ago I've used pickles (CM3) to save some data... My program > > > > does not read that pickle anymore.... > > > > > > And you are certain your program that tries to read still contains > > > exact structurally equivalent types to all the types in the pickle? > > > > > > > > > > > Someone remembers moment when this incompatible changes were made? > > -- > > Dragi?a Duri? > > From rodney_bates at lcwb.coop Mon Feb 1 21:00:51 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 14:00:51 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <20100201081906.583961A2099@async.async.caltech.edu> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop>, <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> Message-ID: <4B6732F3.4020601@lcwb.coop> I too have had trouble pickling MUTEXs or subtypes thereof, even when writing and reading on the same target. I think it was some runaway recursion in pickle code, maybe even while writing. I just worked around it by eliminating the MUTEXs from the pickle. But eventually, somebody may want to pickle an elaborate subtype of MUTEX and find it hard to separate them, so we should someday fix this. Mika Nystrom wrote: > For what it's worth... > > I recall someone (Dragisa?) just complained that he was having problems > unpickling data structures... > > I have never had much luck pickling and unpickling MUTEXes, using a few > (not very different) M3 compilers. I just leave them out of my pickles. > It makes the pickles a lot more compatible across versions. I'm not > talking recent CM3 versions here but a variety of old versions. > Implementors have seemed to modify MUTEX quite a bit. What's the point > of pickling it anyhow? If it's an active mutex the unpickling will > surely lead to garbage, if there are wait queues and things.. then you > wind up un/pickling Thread structures too. > > Mika > From rcolebur at SCIRES.COM Mon Feb 1 21:02:49 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 1 Feb 2010 15:02:49 -0500 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: References: , , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , , <1264972487.4240.4.camel@faramir.m3w.org>, , <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu>, <20100201081906.583961A2099@async.async.caltech.edu>, <1265013708.4240.16.camel@faramir.m3w.org>, Message-ID: Right, you can't put it back in the same state; you just create a new one. Here is an example showing a case where I had a field named "PrivateMutex" that was embedded in an object that needed to be pickled. TYPE PrivateMutex = MUTEX BRANDED Brand & ".PrivateMutex" OBJECT END; (*|***********************************************************************************) (* Pickle Procedures *) (*|***********************************************************************************) TYPE Special = Pickle.Special OBJECT OVERRIDES write := WriteSpecial; read := ReadSpecial; END; (* Special *) PROCEDURE WriteSpecial (self: Special; <*UNUSED*>ref: REFANY; <*UNUSED*>writer: Pickle.Writer ) RAISES {Pickle.Error, <*NOWARN*>Wr.Failure, Thread.Alerted} = (* Special pickle writer for LiteConfig.PrivateMutex objects. *) BEGIN (* WriteSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN (* omit writing the mutex field *) ELSE RAISE Pickle.Error("LiteConfig.WriteSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END WriteSpecial; PROCEDURE ReadSpecial (self: Special; reader: Pickle.Reader; id: Pickle.RefID ): REFANY RAISES {Pickle.Error, <*NOWARN*>Rd.EndOfFile, Rd.Failure, Thread.Alerted} = (* Special pickle reader for LiteConfig.PrivateMutex objects. *) BEGIN (* ReadSpecial *) IF self.sc = TYPECODE(PrivateMutex) THEN WITH m = NEW(PrivateMutex) DO reader.noteRef(m, id); RETURN m; END; (* with *) ELSE RAISE Pickle.Error("LiteConfig.ReadSpecial asked to process unrecognized typecode."); (* should never happen *) END; (* if *) END ReadSpecial; BEGIN (* LiteConfig *) Pickle.RegisterSpecial(NEW(Special, sc := TYPECODE(PrivateMutex))); END LiteConfig. From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, February 01, 2010 2:47 PM To: Coleburn, Randy; m3devel Subject: RE: [M3devel] platform-independent packing/alignment? You *might* imagine pickling a mutex, held or not, like to "freeze"/"suspend" a running system, possibly to move to another system, where it is "resumed". But in reality, that won't work. If changing alignment/padding won't break pickles, I again suggest that "max_align" be raised to at least 64 for all architectures. So that double and longint are aligned. Or that max_align be thrown out entirely and have the architectures all declare things correctly..which they likely already are. > recreates the MUTEX in the environment of the reading program Just with "NEW(MUTEX)" right? No attempt to put it back in the same state, I assume. - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Mon, 1 Feb 2010 14:37:48 -0500 > Subject: Re: [M3devel] platform-independent packing/alignment? > > For MUTEX, you need to write a special pickler procedure that deals with them the way you want. For most of my code, I simply include a tag on output (writing) that is interpreted on input (reading) by my special pickler code that recreates the MUTEX in the environment of the reading program. If anyone wants the code, let me know and I'll send an example. > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Monday, February 01, 2010 3:42 AM > To: Mika Nystrom > Cc: m3devel at elegosoft.com > Subject: Re: [M3devel] platform-independent packing/alignment? > > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > > On Mon, 2010-02-01 at 00:19 -0800, Mika Nystrom wrote: > > For what it's worth... > > > > I recall someone (Dragisa?) just complained that he was having problems > > unpickling data structures... > > > > I have never had much luck pickling and unpickling MUTEXes, using a few > > (not very different) M3 compilers. I just leave them out of my pickles. > > It makes the pickles a lot more compatible across versions. I'm not > > talking recent CM3 versions here but a variety of old versions. > > Implementors have seemed to modify MUTEX quite a bit. What's the point > > of pickling it anyhow? If it's an active mutex the unpickling will > > surely lead to garbage, if there are wait queues and things.. then you > > wind up un/pickling Thread structures too. > > > > Mika > > > > Tony Hosking writes: > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/plain; > > > charset=utf-8 > > > > > >That shouldn't affect things since the pickler picks apart the = > > >structures and ships the individual primitives. Right? > > > > > >On 1 Feb 2010, at 02:41, Jay K wrote: > > > > > >> Let's say I have: > > >> =20 > > >> =20 > > >> TYPE FOO =3D RECORD a: LONGFLOAT; b: UINT32; END; > > >> TYPE FOOA =3D ARRAY [0..1] OF FOO; > > >> =20 > > >> =20 > > >> And I have a platform with max_align =3D 32 and a platform with = > > >max_align =3D 64. > > >> One platform will make FOOA be 24 bytes, the other 32. > > >> One platform will pad out FOO to be align the 8 byte LONGFLOAT, one = > > >won't. > > >> Can that pickle be read/written by the two platforms? > > >> And how does the code know/detect the difference? > > >> That is, if a platform changed from max_align =3D 32 to 64, would the = > > >pickle code work just > > >> as well on the "same" platform as on the "different" platforms? > > >> =20 > > >> =20 > > >> I very recently changed NT386 max_align from 32 to 64, and I believe > > >> the remaining active platforms with max_align =3D 32 should also be = > > >64. > > >> It would "only" affect pickles with LONGINT or LONGFLOAT, as well > > >> as "lining up" such structs with C. > > >> =20 > > >> =20 > > >> Such alignment shold make us not need the extra "unaligned double" = > > >switch > > >> on most platforms (some mystery still on some platforms) as well as > > >> perhaps be needed for some atomic operations, esp. maybe on > > >> LONGINT on 32bit x86. > > >> =20 > > >> =20 > > >> - Jay > > >>=20 > > >> =20 > > >> > From: dragisha at m3w.org > > >> > To: rodney_bates at lcwb.coop > > >> > Date: Sun, 31 Jan 2010 22:14:47 +0100 > > >> > CC: m3devel at elegosoft.com > > >> > Subject: Re: [M3devel] platform-independent packing/alignment? > > >> >=20 > > >> > I've not changed my code, that is for sure.... But now I am not sure > > >> > some parent type (esp MUTEX here an there) was not changed... I'll = > > >take > > >> > a look on this again sometime soon and report my findings. > > >> >=20 > > >> > Thanks for clues. > > >> >=20 > > >> > On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote: > > >> > >=20 > > >> > > Dragi=C5=A1a Duri=C4=87 wrote: > > >> > > > I've asked this before, but didn't catch answer: > > >> > > >=20 > > >> > > > On Sun, 2010-01-31 at 12:21 +0000, Jay K wrote: > > >> > > >> I suggest we can probably get by with platform-independent > > >> > > >> packing/alignment settings. > > >> > > >=20 > > >> > > > Some time ago I've used pickles (CM3) to save some data... My = > > >program > > >> > > > does not read that pickle anymore....=20 > > >> > >=20 > > >> > > And you are certain your program that tries to read still contains > > >> > > exact structurally equivalent types to all the types in the = > > >pickle? > > >> > >=20 > > >> > > >=20 > > >> > > > Someone remembers moment when this incompatible changes were = > > >made?=20 > > >> > --=20 > > >> > Dragi=C5=A1a Duri=C4=87 > > >> >=20 > > > > > > > > >--Apple-Mail-4--1058110347 > > >Content-Transfer-Encoding: quoted-printable > > >Content-Type: text/html; > > > charset=utf-8 > > > > > > > >break-word; -webkit-nbsp-mode: space; -webkit-line-break: = > > >after-white-space; ">That shouldn't affect things since the pickler = > > >picks apart the structures and ships the individual primitives. = > > > Right?
> > >
On 1 Feb 2010, at 02:41, Jay K wrote:

> >class=3D"Apple-interchange-newline">
> >class=3D"Apple-style-span" style=3D"border-collapse: separate; = > > >font-family: Helvetica; font-size: medium; font-style: normal; = > > >font-variant: normal; font-weight: normal; letter-spacing: normal; = > > >line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; = > > >white-space: normal; widows: 2; word-spacing: 0px; = > > >-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = > > >0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = > > >auto; -webkit-text-stroke-width: 0px; ">
> >style=3D"font-size: 10pt; font-family: Verdana; ">Let's say I = > > >have:
 
 
TYPE FOO =3D RECORD a: LONGFLOAT; b: = > > >UINT32; END;
TYPE FOOA =3D ARRAY [0..1] OF = > > >FOO;
 
 
And I have a platform with max_align = > > >=3D 32 and a platform with max_align =3D 64.
One platform will = > > >make FOOA be 24 bytes, the other 32.
  One platform will = > > >pad out FOO to be align the 8 byte LONGFLOAT, one won't.
Can that = > > >pickle be read/written by the two platforms?
And how does the code = > > >know/detect the difference?
That is, if a platform changed from = > > >max_align =3D 32 to 64, would the pickle code work just
as = > > >well on the "same" platform as on the "different" = > > >platforms?
 
 
I very recently changed NT386 = > > >max_align from 32 to 64, and I believe
the remaining active platforms = > > >with max_align =3D 32 should also be 64.
It would "only" affect = > > >pickles with LONGINT or LONGFLOAT, as well
as "lining up" such = > > >structs with C.
 
 
Such alignment shold make us not = > > >need the extra "unaligned double" switch
on most platforms (some = > > >mystery still on some platforms) as well as
perhaps be needed for = > > >some atomic operations, esp. maybe on
LONGINT on 32bit = > > >x86.
 
 
 - Jay

 
> From: > >class=3D"Apple-converted-space">  > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org
> To: > >class=3D"Apple-converted-space">  > >href=3D"mailto:rodney_bates at lcwb.coop">rodney_bates at lcwb.coop
> = > > >Date: Sun, 31 Jan 2010 22:14:47 +0100
> CC: > >class=3D"Apple-converted-space">  > >href=3D"mailto:m3devel at elegosoft.com">m3devel at elegosoft.com
> = > > >Subject: Re: [M3devel] platform-independent = > > >packing/alignment?
> > >class=3D"Apple-converted-space"> 
> I've not changed = > > >my code, that is for sure.... But now I am not sure
> some parent = > > >type (esp MUTEX here an there) was not changed... I'll take
> a = > > >look on this again sometime soon and report my findings.
> > >class=3D"Apple-converted-space"> 
> Thanks for = > > >clues.
> 
> = > > >On Sun, 2010-01-31 at 14:00 -0600, Rodney M. Bates wrote:
> = > > >> 
> > = > > >Dragi=C5=A1a Duri=C4=87 wrote:
> > > I've asked this before, = > > >but didn't catch answer:
> > > > >class=3D"Apple-converted-space"> 
> > > On Sun, = > > >2010-01-31 at 12:21 +0000, Jay K wrote:
> > >> I suggest = > > >we can probably get by with platform-independent
> > >> = > > >packing/alignment settings.
> > > > >class=3D"Apple-converted-space"> 
> > > Some = > > >time ago I've used pickles (CM3) to save some data... My program
> = > > >> > does not read that pickle anymore.... > >class=3D"Apple-converted-space"> 
> > > >class=3D"Apple-converted-space"> 
> > And you are = > > >certain your program that tries to read still contains
> > = > > >exact structurally equivalent types to all the types in the = > > >pickle?
> > > >class=3D"Apple-converted-space"> 
> > > > >class=3D"Apple-converted-space"> 
> > > Someone = > > >remembers moment when this incompatible changes were made? > >class=3D"Apple-converted-space"> 
> -- > >class=3D"Apple-converted-space"> 
> Dragi=C5=A1a = > > >Duri=C4=87 < > >href=3D"mailto:dragisha at m3w.org">dragisha at m3w.org>
> > >class=3D"Apple-converted-space"> 
 > >>

= > > > > > >--Apple-Mail-4--1058110347-- > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Feb 1 21:23:53 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 01 Feb 2010 14:23:53 -0600 Subject: [M3devel] platform-independent packing/alignment? In-Reply-To: <1265013708.4240.16.camel@faramir.m3w.org> References: , <1264955387.4240.2.camel@faramir.m3w.org> <4B65E148.4090105@lcwb.coop> , <1264972487.4240.4.camel@faramir.m3w.org> <7BE1321A-C077-490D-8B17-D5FE8DFF1A5B@cs.purdue.edu> <20100201081906.583961A2099@async.async.caltech.edu> <1265013708.4240.16.camel@faramir.m3w.org> Message-ID: <4B673859.8070405@lcwb.coop> One thing I recall is that there are about 3 signatures for some builtin types that are hard-coded as constants rather than computed, and pm3 vs. cm3 pickles have them with values differing in some rather bizarre byte-ordering differences. In at least one of them, the order was also inconsistent with the general algorithm used to construct most signatures. As I recall, I fixed cm3 pickles to recognize/read both sets of signature values. So if you are using recent pickle code from cm3, this would not be the cause of your problem, nor would it be if you have not written a pickle in pm3-compiled code and tried to read it in cm3-compiled code. I also recall putting in some better messages when things failed, such as giving the value of an unrecognized signature. Do you get any interesting messages when pickle reading fails? Dragi?a Duri? wrote: > MUTEX is primitive type whose typecode is fixed by compiler, IIRC - that > code being same even if changes were made to it's basic structure... Or > not... On the second thought, MUTEX is basically fixed, but it's > revealations can vary. Thus making it incompatible over > pickles/versions. > > I've not looked at my code/data yet, but MUTEX was only an idea what > went... It is OODBMS package, and mutex is not used for persistent data, > only for tables/indexes. Thus, problem (at leat for me) remains and it > is not pickled MUTEX. > From Highjinks at gmx.com Wed Feb 3 00:33:40 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 00:33:40 +0100 (CET) Subject: [M3devel] Shorthand type declarations? Message-ID: <20100202193708.97d69f8c.Highjinks@gmx.com> Alright, I'm finally getting the hang of things. One quick question.. Is there a shorthand for declaring a whole bunch of types as one type? i.e.... TYPE Window, Pixmap, Cursor = unsigned_int; Or something similiar? Doing this TYPE Window = unsigned_int; Pixmap = unsigned_int; Cursor = unsigned_int; etc... Adds up to whole lot of typing.(No pun intended) Any tips would be most welcome. -- Chris From rodney_bates at lcwb.coop Wed Feb 3 04:37:33 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 02 Feb 2010 21:37:33 -0600 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100202193708.97d69f8c.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> Message-ID: <4B68EF7D.7040009@lcwb.coop> Chris wrote: > Alright, I'm finally getting the hang of things. > > One quick question.. > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > TYPE > Window, Pixmap, Cursor = unsigned_int; > > Or something similiar? > > Doing this > TYPE > Window = unsigned_int; > Pixmap = unsigned_int; > Cursor = unsigned_int; > etc... > Adds up to whole lot of typing.(No pun intended) Unfortunately, this is the shortest you can get. I suppose the language designers thought that, while a whole lot of variables with the same type were a likely case: VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , that more than just a few type names that are synonyms for the same type would not be common. You may think me certifiably masochist, but I go the more longhanded way and write: TYPE Window = unsigned_int; TYPE Pixmap = unsigned_int; TYPE Cursor = unsigned_int; , sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, almost every time. > > Any tips would be most welcome. > From jay.krell at cornell.edu Wed Feb 3 06:28:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 05:28:50 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <4B68EF7D.7040009@lcwb.coop> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop> Message-ID: This is not where Modula-3 falls down due to verbosity. Many C and C++ programmers discourage such terseness: int a, b, c(), d(); typedef int T1, T2; preferring: int a; int b; int c(); int d(); typedef int T1; typedef int T2; Where is falls down, perhaps, is not using curly braces. (And perhaps for gyrations needed for safety, see my recent NTObjFile.m3 changes. Can they be safe and not duplicate code, or only one?) My editor is geared toward curly braces and helps using them tremendously. I can't switch editors. I've tried many times. I find the terseness Modula-3 does allow: PROCEDURE(VAR a, b:INTEGER); TYPE A = RECORD c, d: INTEGER:= 0; END. ambiguous. I don't know if a and b are both VAR. I don't know if c and d both have the initializer. I'd prefer to see: PROCEDURE(VAR a: INTEGER; VAR b:INTEGER); TYPE A = RECORD c: INTEGER := 0; d: INTEGER:= 0; END. (and I'm not sure that is equivalent, but I do know what it means.) (newlines omited in RECORD just for *email brevity*: RECORD should have a newline per field!) I would be in favor of removing all these shorthands from the cm3 tree, and maybe even warning about them. But they surely are all well defined if you know the language well. It is meant to be a small language, but goes a bit too far here I think. - Jay > Date: Tue, 2 Feb 2010 21:37:33 -0600 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > > > Chris wrote: > > Alright, I'm finally getting the hang of things. > > > > One quick question.. > > > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > > > TYPE > > Window, Pixmap, Cursor = unsigned_int; > > > > Or something similiar? > > > > Doing this > > TYPE > > Window = unsigned_int; > > Pixmap = unsigned_int; > > Cursor = unsigned_int; > > etc... > > Adds up to whole lot of typing.(No pun intended) > > Unfortunately, this is the shortest you can get. I suppose the language designers > thought that, while a whole lot of variables with the same type were a likely > case: > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > that more than just a few type names that are synonyms for the same type would not be common. > > You may think me certifiably masochist, but I go the more longhanded way and write: > > TYPE Window = unsigned_int; > TYPE Pixmap = unsigned_int; > TYPE Cursor = unsigned_int; , > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > almost every time. > > > > > > Any tips would be most welcome. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 3 09:37:52 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 3 Feb 2010 03:37:52 -0500 Subject: [M3devel] Shorthand type declarations? In-Reply-To: References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop> Message-ID: <6E17449F-8762-4AA0-951A-0D3455432A3F@cs.purdue.edu> On 3 Feb 2010, at 00:28, Jay K wrote: > This is not where Modula-3 falls down due to verbosity. > > > Many C and C++ programmers discourage such terseness: > int a, b, c(), d(); > typedef int T1, T2; > > > preferring: > int a; > int b; > int c(); > int d(); > typedef int T1; > typedef int T2; > > > Where is falls down, perhaps, is not using curly braces. > (And perhaps for gyrations needed for safety, see my recent NTObjFile.m3 changes. > Can they be safe and not duplicate code, or only one?) > > > My editor is geared toward curly braces and helps using them tremendously. > I can't switch editors. I've tried many times. ... emacs... :-) > I find the terseness Modula-3 does allow: > PROCEDURE(VAR a, b:INTEGER); Both are VAR. VAR distributes over the list. > TYPE A = RECORD c, d: INTEGER:= 0; END. They both get 0. := distributes over the list. > ambiguous. > > I don't know if a and b are both VAR. > I don't know if c and d both have the initializer. > I'd prefer to see: > PROCEDURE(VAR a: INTEGER; VAR b:INTEGER); > TYPE A = RECORD c: INTEGER := 0; d: INTEGER:= 0; END. > > > (and I'm not sure that is equivalent, but I do know what it means.) > (newlines omited in RECORD just for *email brevity*: RECORD should have a newline per field!) > > I would be in favor of removing all these shorthands from the cm3 tree, > and maybe even warning about them. But they surely are all well defined > if you know the language well. It is meant to be a small language, > but goes a bit too far here I think. I've never really found this to be the case. Perhaps because I learnt to program in Pascal. > > > - Jay > > > > Date: Tue, 2 Feb 2010 21:37:33 -0600 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Shorthand type declarations? > > > > > > > > Chris wrote: > > > Alright, I'm finally getting the hang of things. > > > > > > One quick question.. > > > > > > Is there a shorthand for declaring a whole bunch of types as one type? i.e.... > > > > > > TYPE > > > Window, Pixmap, Cursor = unsigned_int; > > > > > > Or something similiar? > > > > > > Doing this > > > TYPE > > > Window = unsigned_int; > > > Pixmap = unsigned_int; > > > Cursor = unsigned_int; > > > etc... > > > Adds up to whole lot of typing.(No pun intended) > > > > Unfortunately, this is the shortest you can get. I suppose the language designers > > thought that, while a whole lot of variables with the same type were a likely > > case: > > > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > > > that more than just a few type names that are synonyms for the same type would not be common. > > > > You may think me certifiably masochist, but I go the more longhanded way and write: > > > > TYPE Window = unsigned_int; > > TYPE Pixmap = unsigned_int; > > TYPE Cursor = unsigned_int; , > > > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > > almost every time. > > > > > > > > > > Any tips would be most welcome. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Feb 3 09:59:12 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 09:59:12 +0100 (CET) Subject: [M3devel] Shorthand type declarations? In-Reply-To: <4B68EF7D.7040009@lcwb.coop> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> Message-ID: <20100203050242.0a7e924b.Highjinks@gmx.com> On Tue, 02 Feb 2010 21:37:33 -0600 "Rodney M. Bates" wrote: > > > > Unfortunately, this is the shortest you can get. I suppose the language designers > thought that, while a whole lot of variables with the same type were a likely > case: > > VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > > that more than just a few type names that are synonyms for the same type would not be common. > > You may think me certifiably masochist, but I go the more longhanded way and write: > > TYPE Window = unsigned_int; > TYPE Pixmap = unsigned_int; > TYPE Cursor = unsigned_int; , > > sacrificing writeability in favor of readability. (Yes, I repeat VAR and CONST too, > almost every time. > > The reason I asked is because I'm doing the interface for /usr/include/xcb/xproto.h There are a lot of of typedefs in there that are defined as the same base type. I've shortened the Iterator types by using... TYPE T = UNTRACED ROOT OBJECT END; TYPE XCB_Iterator = T OBJECT Rem : INTEGER; Index : INTEGER END; TYPE XCBAtom = unsigned_int; TYPE Atom_Iterator = XCB_Iterator OBJECT Atom_Data : UNTRACED REF XCBAtom; END; But even this is gonna kill me. Heh. xproto.h is a HUGE file. -- Chris From wagner at elegosoft.com Wed Feb 3 09:59:45 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 03 Feb 2010 09:59:45 +0100 Subject: [M3devel] m3gdb build on AMD64_FREEBSD Message-ID: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Any chance to make m3gdb build on 64 bit FreeBSD? This is the only package that's still failing on that platform: http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText (search for m3gdb in the listing) A quick look doesn't really enlighten me as to what is wrong... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Wed Feb 3 10:18:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 03 Feb 2010 10:18:14 +0100 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203050242.0a7e924b.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> Message-ID: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Quoting Chris : > On Tue, 02 Feb 2010 21:37:33 -0600 > "Rodney M. Bates" wrote: > >> Unfortunately, this is the shortest you can get. I suppose the >> language designers >> thought that, while a whole lot of variables with the same type >> were a likely >> case: >> >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , >> >> that more than just a few type names that are synonyms for the same >> type would not be common. >> >> You may think me certifiably masochist, but I go the more >> longhanded way and write: >> >> TYPE Window = unsigned_int; >> TYPE Pixmap = unsigned_int; >> TYPE Cursor = unsigned_int; , >> >> sacrificing writeability in favor of readability. (Yes, I repeat >> VAR and CONST too, >> almost every time. > > The reason I asked is because I'm doing the interface for > /usr/include/xcb/xproto.h > > There are a lot of of typedefs in there that are defined as the same > base type. > > I've shortened the Iterator types by using... > > TYPE T = UNTRACED ROOT OBJECT END; > TYPE XCB_Iterator = T OBJECT > Rem : INTEGER; > Index : INTEGER > END; > > TYPE XCBAtom = unsigned_int; > TYPE Atom_Iterator = XCB_Iterator OBJECT > Atom_Data : UNTRACED REF XCBAtom; > END; > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. What exactly is gained by defining all those aliases for unsigned_int? In M3 all the types are structurally equivalent, so you can use a Cursor where a Window would be required etc. It looks like a bit of facelifting to me. And if it's only for readability and proper naming, all those should surely be named Handle, shouldn't they? The same level of abstraction could be achieved by defining just one XProtoHandle as unsigned_int, couldn't it? I think I just have never understood the usefulness of interfaces too large to remember, but that may be a general problem with X... Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 3 12:45:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:45:12 +0000 Subject: [M3devel] m3gdb build on AMD64_FREEBSD In-Reply-To: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> References: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Message-ID: I haven't looked but maybe we need a newer gdb? Personally I wish we could output enough information so that regular gdb could work better... Also we shouldn't bother mangling acceptable identifiers when there is no clash.. - Jay > Date: Wed, 3 Feb 2010 09:59:45 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] m3gdb build on AMD64_FREEBSD > > Any chance to make m3gdb build on 64 bit FreeBSD? > This is the only package that's still failing on that platform: > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText > > (search for m3gdb in the listing) > > A quick look doesn't really enlighten me as to what is wrong... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 3 12:55:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:55:22 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: > so you can use a Cursor where a Window would be required etc Win32 does opaque unique types something like: #define DECLARE_HANDLE(foo) struct tag##foo; typedef struct tag##foo* foo; DECLARE_HANDLE(HWND) DECLARE_HANDLE(HCURSOR) DECLARE_HANDLE(HRGN) DECLARE_HANDLE(HPEN) Some of the objects are indeed "bases" of others, but that can't be easily captured. It gets documented and you can cast. And then opaque non-unique is also common: typedef void* HANDLE; That is used for files, events, mutexes, semaphores, processes, threads, etc. And there is a lot of commonality. They all work with CloseHandle, WaitForSingleObject, WaitForMultipleObjects, DuplicateHandle, etc. - Jay > Date: Wed, 3 Feb 2010 10:18:14 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > Quoting Chris : > > > On Tue, 02 Feb 2010 21:37:33 -0600 > > "Rodney M. Bates" wrote: > > > >> Unfortunately, this is the shortest you can get. I suppose the > >> language designers > >> thought that, while a whole lot of variables with the same type > >> were a likely > >> case: > >> > >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > >> > >> that more than just a few type names that are synonyms for the same > >> type would not be common. > >> > >> You may think me certifiably masochist, but I go the more > >> longhanded way and write: > >> > >> TYPE Window = unsigned_int; > >> TYPE Pixmap = unsigned_int; > >> TYPE Cursor = unsigned_int; , > >> > >> sacrificing writeability in favor of readability. (Yes, I repeat > >> VAR and CONST too, > >> almost every time. > > > > The reason I asked is because I'm doing the interface for > > /usr/include/xcb/xproto.h > > > > There are a lot of of typedefs in there that are defined as the same > > base type. > > > > I've shortened the Iterator types by using... > > > > TYPE T = UNTRACED ROOT OBJECT END; > > TYPE XCB_Iterator = T OBJECT > > Rem : INTEGER; > > Index : INTEGER > > END; > > > > TYPE XCBAtom = unsigned_int; > > TYPE Atom_Iterator = XCB_Iterator OBJECT > > Atom_Data : UNTRACED REF XCBAtom; > > END; > > > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. > > What exactly is gained by defining all those aliases for unsigned_int? > In M3 all the types are structurally equivalent, so you can use a Cursor > where a Window would be required etc. It looks like a bit of facelifting > to me. > > And if it's only for readability and proper naming, all those should > surely be named Handle, shouldn't they? > > The same level of abstraction could be achieved by defining just one > XProtoHandle as unsigned_int, couldn't it? > > I think I just have never understood the usefulness of interfaces > too large to remember, but that may be a general problem with X... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 3 12:51:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 11:51:32 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: Chris many of the X headers these days are generated from XML using Python. Seriously -- you need Python to build X these days. You should look into adding a little to that system for Modula-3. Cloning headers is tedious, therefore error-prone, therefore a recipe for bugs. Please try to avoid it. If you really can't go the XML route, there is also a fork of gcc that is supposed to be adequate for header parsing, and spits out XML. Look for "gccxml" or such. Maybe it is old/dead now? There is also swig, which is a partial C compiler. Not a great idea to attempt. But it is there, you might try it. I'd be far more interested in wrapping Qt than X though... - Jay > Date: Wed, 3 Feb 2010 10:18:14 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > Quoting Chris : > > > On Tue, 02 Feb 2010 21:37:33 -0600 > > "Rodney M. Bates" wrote: > > > >> Unfortunately, this is the shortest you can get. I suppose the > >> language designers > >> thought that, while a whole lot of variables with the same type > >> were a likely > >> case: > >> > >> VAR x, y, z, u, v, w, h, i, j, h, ... : INTEGER; , > >> > >> that more than just a few type names that are synonyms for the same > >> type would not be common. > >> > >> You may think me certifiably masochist, but I go the more > >> longhanded way and write: > >> > >> TYPE Window = unsigned_int; > >> TYPE Pixmap = unsigned_int; > >> TYPE Cursor = unsigned_int; , > >> > >> sacrificing writeability in favor of readability. (Yes, I repeat > >> VAR and CONST too, > >> almost every time. > > > > The reason I asked is because I'm doing the interface for > > /usr/include/xcb/xproto.h > > > > There are a lot of of typedefs in there that are defined as the same > > base type. > > > > I've shortened the Iterator types by using... > > > > TYPE T = UNTRACED ROOT OBJECT END; > > TYPE XCB_Iterator = T OBJECT > > Rem : INTEGER; > > Index : INTEGER > > END; > > > > TYPE XCBAtom = unsigned_int; > > TYPE Atom_Iterator = XCB_Iterator OBJECT > > Atom_Data : UNTRACED REF XCBAtom; > > END; > > > > But even this is gonna kill me. Heh. xproto.h is a HUGE file. > > What exactly is gained by defining all those aliases for unsigned_int? > In M3 all the types are structurally equivalent, so you can use a Cursor > where a Window would be required etc. It looks like a bit of facelifting > to me. > > And if it's only for readability and proper naming, all those should > surely be named Handle, shouldn't they? > > The same level of abstraction could be achieved by defining just one > XProtoHandle as unsigned_int, couldn't it? > > I think I just have never understood the usefulness of interfaces > too large to remember, but that may be a general problem with X... > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Feb 3 20:08:05 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 03 Feb 2010 13:08:05 -0600 Subject: [M3devel] m3gdb build on AMD64_FREEBSD In-Reply-To: References: <20100203095945.aqvwt9gdcg8s0cog@mail.elegosoft.com> Message-ID: <4B69C995.4010902@lcwb.coop> Jay K wrote: > I haven't looked but maybe we need a newer gdb? If you mean stock gdb, you can use the latest available. If you mean an m3gdb derived from a later gdb, that has been on my list for a while. Maybe when gdb 7.1 is out (very soon) and I am through moving house and get my old one sold (who knows?) Having done this, I think three times, I can say it will be quit a bit of work, and it looks like there are more/bigger changes to gdb than ever before, especially reverse debugging, which would be really nice. > Personally I wish we could output enough information > so that regular gdb could work better... There is very little room for improvement in just changing/ expanding the debug output produced by the compiler. To get much of anything at all would involve changing the debug info format from stabs (very old, cobbled up, and limited) to dwarf-2 (apparently the best now in use). I am even prepared for the possibility that the latest gdb will have dropped stabs altogether. This is also a big job. I have been thinking about it for a long time. But it still can't do all that much using stock gdb. > Also we shouldn't bother mangling acceptable identifiers when > there is no clash.. Having separate compilation, there are many cases where it would be impossible for the compiler to know whether there are clashes or not. Also, I'm not sure how feasible it would be to remove the uid portion from mangled variable names, given Modula-3's structural type rules. Maybe dwarf-2 would allow it to work. > > - Jay > > > Date: Wed, 3 Feb 2010 09:59:45 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: [M3devel] m3gdb build on AMD64_FREEBSD > > > > Any chance to make m3gdb build on 64 bit FreeBSD? > > This is the only package that's still failing on that platform: > > > > > > > http://hudson.modula3.com:8080/job/cm3-test-all-pkgs-AMD64_FREEBSD/15/consoleText > > > > (search for m3gdb in the listing) > > > > A quick look doesn't really enlighten me as to what is wrong... > > > > Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 > 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: > DE163214194 > > From jay.krell at cornell.edu Wed Feb 3 21:49:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 20:49:30 +0000 Subject: [M3devel] NT386 int64/longint Message-ID: I've actually been able to compile a fair amount of code now, and at a very cursory glance, it looks reasonably correct. e.g. all of m3core -- including the long/word stuff and Convert.m3. This is using an approach where I "split" operands and then loop over the parts. Variables become two variables. Registers become two registers. Immediates become two immediates. However I seem unable to get the bookkeeping within the backend correct. I had to remove various asserts. Not great. In some places I believe more asserts are clearly correct, but yet they fail when I put them in. Some of the asserts are suspicous to me and further investigation makes me suspicious of some of the existing code in m3back. But I'm not very confident here. I'd have to demonstrate incorrect codegen before making changes. For example the first releaseall in call_indirect seems wrong. It seems like releaseall should only be called when the virtual stack must be empty. But it always has depth at least one there. The second one seems correct. I think it is also overkill in that it need only release volatile registers. I'm also not sure if the virtual stack should really even be empty there. Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2). Perhaps there are assumptions regarding how the front end works. For example I have various add/mult/div making function calls and that seems to be unexpected. I'm also not sure why in_proc_call is limited to two. And, why that is enforced with an assert instead of a subrange. Perhaps I can model int64/longint mostly as a struct. I'll look into that. Or maybe I can somewhat "start over" with the current approach. What is already commited is very safe and conservative and a useful step, depending on what the end result is. One of the problems with the current approach is that if we zero extend a 32bit cardinal, we waste a register for the upper half zero. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Highjinks at gmx.com Wed Feb 3 22:10:58 2010 From: Highjinks at gmx.com (Chris) Date: Wed, 3 Feb 2010 22:10:58 +0100 (CET) Subject: [M3devel] Shorthand type declarations? In-Reply-To: References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> Message-ID: <20100203171429.533b2e69.Highjinks@gmx.com> On Wed, 3 Feb 2010 11:51:32 +0000 Jay K wrote: > > Chris many of the X headers these days are generated from XML using Python. > > Seriously -- you need Python to build X these days. > > You should look into adding a little to that system for Modula-3. > > Cloning headers is tedious, therefore error-prone, therefore a recipe for bugs. > > Please try to avoid it. > If you really can't go the XML route, there is also a fork of gcc > > that is supposed to be adequate for header parsing, and spits out XML. > > Look for "gccxml" or such. Maybe it is old/dead now? I've never really done much in the way of autogenerating Interfaces and such. Perhaps now is the time for me to look into it. > > > There is also swig, which is a partial C compiler. > > Not a great idea to attempt. > > But it is there, you might try it. > > > > I'd be far more interested in wrapping Qt than X though... Oh, dont worry, QT will get a binding, as will GTK. If not by me, then someone else will do it. The reason I'm doing this interface to XCB is because that is the way X is moving. Future applications will depend less and less on XLib and more on XCB. Also, I dont use QT, or GTK. There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, wxWindows, etc... I'm starting out with XCB, Cairo/Pango, XKB for X. The OpenGL binding will be updated next, along with it's GLX and GLUT bindings. These are the basic X Libs that lots of other X apps depend on. Then I'll start doing QT/GTK(if someone hasnt already beaten me to it. Nice thing with QT and GTK is that they are in fact cross platform. Therefor I wouldn't classify them as "X Windows" bindings. Just as GUI toolkits. Nice ones at that. Whoa! I've got ALOT of work to do. Be back soon. -- Chris From hendrik at topoi.pooq.com Wed Feb 3 22:51:56 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 3 Feb 2010 16:51:56 -0500 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203171429.533b2e69.Highjinks@gmx.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com> <4B68EF7D.7040009@lcwb.coop> <20100203050242.0a7e924b.Highjinks@gmx.com> <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com> <20100203171429.533b2e69.Highjinks@gmx.com> Message-ID: <20100203215156.GA20509@topoi.pooq.com> On Wed, Feb 03, 2010 at 10:10:58PM +0100, Chris wrote: > On Wed, 3 Feb 2010 11:51:32 +0000 > Jay K wrote: > > There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, > wxWindows, etc... wxWindows is more than a UI toolkit; it's a complete environment for writing cross-platform C (or is it C++) programs -- right down to specifying how you have to write your main program. I think Modula 3 already provides a main program on Windows, right? -- hendrik From jay.krell at cornell.edu Wed Feb 3 23:09:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 3 Feb 2010 22:09:45 +0000 Subject: [M3devel] Shorthand type declarations? In-Reply-To: <20100203215156.GA20509@topoi.pooq.com> References: <20100202193708.97d69f8c.Highjinks@gmx.com>, <4B68EF7D.7040009@lcwb.coop>, <20100203050242.0a7e924b.Highjinks@gmx.com>, <20100203101814.a286t9yp8kgoo84s@mail.elegosoft.com>, , <20100203171429.533b2e69.Highjinks@gmx.com>, <20100203215156.GA20509@topoi.pooq.com> Message-ID: I think that is a lesser concern. I think a larger issue is what the binding should look like and if it can be generated. And if we import the library into our tree (probably not). And then how we configure, like, is the thing on the system. Do we generate the headers in the build? Maybe. That is good in that they match and don't go stale. Bad in that it hurts cross builds. Possibly generate, checkin, and then regenerate if possible and compare to what is checked in. (But now I've digressed to lesser concerns as well. The important part is figuring out what the binding should look like and how to generate it. Less important how often to regenerate it.) Of course Modula-3 provides main. Likely wxWindows doesn't absolutely require special main. Likely any binding can just have you add some function call from your Modula-3 main. Absolute terrible worst case if you can teach the Modula-3 compiler to not provide main. In fact that's not a bad idea for other reasons -- for better interop with existing code. Basically we should have a flag to RTLinker__InitRuntime that specifies if it returns or runs Main__M3(1) or however that works. Or an alternate RTLinker__InitRuntimeEx. wxWindows is C++. There are Python bindings. These libraries often provide cross-platform threading/synchronization, I/O, etc. And sometimes IDEs, right. There are many such efforts. Any binding effort imho could limit itself to just the gui parts. The other parts ok, but I'm suspicious that Modula-3's container/string/i/o/threading libraries aren't so bad/ugly, whereas its GUI library at least looks awful and Olaf says the Win32 port is incomplete, so more work merited there it seems vs. other library parts. - Jay ---------------------------------------- > Date: Wed, 3 Feb 2010 16:51:56 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Shorthand type declarations? > > On Wed, Feb 03, 2010 at 10:10:58PM +0100, Chris wrote: >> On Wed, 3 Feb 2010 11:51:32 +0000 >> Jay K wrote: >> >> There are a bunch of bindings that SHOULD be written. OpenMotif, SDL, >> wxWindows, etc... > > wxWindows is more than a UI toolkit; it's a complete environment for > writing cross-platform C (or is it C++) programs -- right down to > specifying how you have to write your main program. > > I think Modula 3 already provides a main program on Windows, right? > > -- hendrik From jay.krell at cornell.edu Fri Feb 5 13:21:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 5 Feb 2010 12:21:10 +0000 Subject: [M3devel] NT386 int64/longint Message-ID: nevermind, it's looking much better now. A few more days though. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: NT386 int64/longint Date: Wed, 3 Feb 2010 20:49:30 +0000 I've actually been able to compile a fair amount of code now, and at a very cursory glance, it looks reasonably correct. e.g. all of m3core -- including the long/word stuff and Convert.m3. This is using an approach where I "split" operands and then loop over the parts. Variables become two variables. Registers become two registers. Immediates become two immediates. However I seem unable to get the bookkeeping within the backend correct. I had to remove various asserts. Not great. In some places I believe more asserts are clearly correct, but yet they fail when I put them in. Some of the asserts are suspicous to me and further investigation makes me suspicious of some of the existing code in m3back. But I'm not very confident here. I'd have to demonstrate incorrect codegen before making changes. For example the first releaseall in call_indirect seems wrong. It seems like releaseall should only be called when the virtual stack must be empty. But it always has depth at least one there. The second one seems correct. I think it is also overkill in that it need only release volatile registers. I'm also not sure if the virtual stack should really even be empty there. Maybe I'm compiling Foo(1 + 2, bar(1 + abc()) + 2). Perhaps there are assumptions regarding how the front end works. For example I have various add/mult/div making function calls and that seems to be unexpected. I'm also not sure why in_proc_call is limited to two. And, why that is enforced with an assert instead of a subrange. Perhaps I can model int64/longint mostly as a struct. I'll look into that. Or maybe I can somewhat "start over" with the current approach. What is already commited is very safe and conservative and a useful step, depending on what the end result is. One of the problems with the current approach is that if we zero extend a 32bit cardinal, we waste a register for the upper half zero. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 6 13:29:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 6 Feb 2010 12:29:39 +0000 Subject: [M3devel] front end function about a "virtual stack" Message-ID: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 6 19:07:23 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 6 Feb 2010 13:07:23 -0500 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: References: Message-ID: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: > Tony, can you confirm something? > It's hard to explain. > > > The NT36 backend of course maintains > a bunch of information as to which registers are in use. > > > For example, at the start of the function, it > marks all registers as not in use. > (It always preserves all volatile registers I believe. > Obviously it could do better. It should only > mark non-volatile registers as in use, see > which registers it uses in the function, and > then only preserve/restore the nonvolatile ones > that it uses.) > > > As well when it generates a function call it > marks them as all not in use too. > But in that case, it checks itself. > Again, it is a bit dumb -- nonvolatile registers > would be ok to still be in use. > > > Now, all is ok. > But then, I've introduced function calls where > they weren't before -- multiply, divide, mod etc. > > > Upon generating the call to mod (for example), > I get an assertion failure, because registers > are still in use. In this case it is a nonvolatile > register, but I think that's largely luck. > > > In particular I think the location that > will be stored to after the mod is in a register. > That is reasonable. > You know..as a compiler, given: > *(a + b) = f(); > > > you might generate code to evaluate a + b first, > put it in a (non volatile) register, then call f(), > or you might call f() first. > > > A simpler approach is to call all the functions first, > so you have more easy use of registers. > > > But then imagine > *(a + b) = (c % d); > > > is there a function call in there or not? > It depends. > > > So then my question is, like, when does the > frontend assume a "stack based code generator"'s > stack can/should/will be empty? > Does it endeavor to make it so? > > > That is, is it very reasonable to for the NT386 > backend to assume its stack is empty when > it calls a function, because the front end > colludes to make it so, but then > the front end doesn't do similar for things > like multiply/divide? > > > I can deal with this pretty easily either way. > Around function calls I introduce that weren't > previously there I can save whatever volatile > registers are in use. > > > But I'd like to understand. > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 07:49:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 06:49:11 +0000 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> References: , <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> Message-ID: > But, there have always been calls for mod/div Not on NT386. - Jay Subject: Re: front end function about a "virtual stack" From: hosking at cs.purdue.edu Date: Sat, 6 Feb 2010 13:07:23 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 08:02:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 07:02:24 +0000 Subject: [M3devel] front end function about a "virtual stack" In-Reply-To: <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> References: , <57707F4C-543F-4A74-8D55-664580723AD6@cs.purdue.edu> Message-ID: I think I have this aspect dealt with now. Convert.m3: -----LINE 129 ----- load tv.25[_nDigits] 0 Int.32 Int.32 check_range 0 n:8,x:0,0,0,0,0,0,0,0 64 n:4,x:40,0,0,0,0,0,0,0 2 00000435: 8B5DFC MOV EBX tv.25[_nDigits] 00000438: 83FB40 CMP EBX $64 0000043B: 7600 JBE rel8 L.68 0000043D: B822100000 MOV EAX $4130 00000442: E800000000 CALL L.0 loophole Int.32 Int.32 load_address tv.31[_result] 0 00000447: 8D75AE LEA ESI tv.31[_result] swap Int.32 Addr index_address Int.32 1 0000044A: 03F3 ADD ESI EBX ** result location in ESI * load tv.35[_base] 0 Word.8 Int.32 loophole Int.32 Int.64 0000044C: 33D2 XOR EDX EDX 0000044E: 8A5514 MOV EDX tv.35[_base]:Word.8 00000451: 33FF XOR EDI EDI load tv.34[_value] 0 Int.64 Int.64 swap Int.64 Int.64 mod Int.64 X P call_64 m3_mod64 2 import_procedure m3_mod64 2 Int.64 "__stdcall" p.31[m3_mod64] declare_param * 8 8 Word.64 0 F F 100 tv.201[T$201] 8 declare_param * 8 8 Word.64 0 F F 100 tv.202[T$202] 16 start_call_direct p.31[_m3_mod64 at 16] 0 Int.64 load_stack_param Word.64 1 00000453: 8B4D0C MOV ECX tv.34[_value] 00000456: 8B4510 MOV EAX tv.34[_value]+4 00000459: 50 PUSH EAX 0000045A: 51 PUSH ECX load_stack_param Word.64 0 0000045B: 57 PUSH EDI 0000045C: 52 PUSH EDX declare_temp 4 4 Addr F tv.203[T$203] -92 0000045D: 8975A4 MOV tv.203[T$203] ESI ** ESI saved unnecessarily in temporary to satisfy us ** call_direct p.31[_m3_mod64 at 16] Int.64 00000460: FF1500000000 CALL p.31[_m3_mod64 at 16] loophole Int.64 Int.32 loophole Int.32 Int.32 load_address gv.2[_MM_Convert] 52 00000466: 8D3534000000 LEA ESI gv.2[_MM_Convert]+52 swap Int.32 Addr index_address Int.32 1 0000046C: 03F0 ADD ESI EAX load_indirect 0 Word.8 Int.32 0000046E: 33DB XOR EBX EBX 00000470: 8A5E00 MOV EBX ESI^[0:Word.8] store_indirect 0 Int.32 Word.8 00000473: 8B75A4 MOV ESI tv.203[T$203]:Addr ** ESI refetched from temporary ** free_temp tv.203[T$203] 00000476: 885E00 MOV ESI^[0:Word.8] EBX -----LINE 130 ----- Pretty wasteful. Instead it should just compute the destination when it does the store. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3devel at elegosoft.com Subject: RE: front end function about a "virtual stack" Date: Sun, 7 Feb 2010 06:49:11 +0000 > But, there have always been calls for mod/div Not on NT386. - Jay Subject: Re: front end function about a "virtual stack" From: hosking at cs.purdue.edu Date: Sat, 6 Feb 2010 13:07:23 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing. On 6 Feb 2010, at 07:29, Jay K wrote: Tony, can you confirm something? It's hard to explain. The NT36 backend of course maintains a bunch of information as to which registers are in use. For example, at the start of the function, it marks all registers as not in use. (It always preserves all volatile registers I believe. Obviously it could do better. It should only mark non-volatile registers as in use, see which registers it uses in the function, and then only preserve/restore the nonvolatile ones that it uses.) As well when it generates a function call it marks them as all not in use too. But in that case, it checks itself. Again, it is a bit dumb -- nonvolatile registers would be ok to still be in use. Now, all is ok. But then, I've introduced function calls where they weren't before -- multiply, divide, mod etc. Upon generating the call to mod (for example), I get an assertion failure, because registers are still in use. In this case it is a nonvolatile register, but I think that's largely luck. In particular I think the location that will be stored to after the mod is in a register. That is reasonable. You know..as a compiler, given: *(a + b) = f(); you might generate code to evaluate a + b first, put it in a (non volatile) register, then call f(), or you might call f() first. A simpler approach is to call all the functions first, so you have more easy use of registers. But then imagine *(a + b) = (c % d); is there a function call in there or not? It depends. So then my question is, like, when does the frontend assume a "stack based code generator"'s stack can/should/will be empty? Does it endeavor to make it so? That is, is it very reasonable to for the NT386 backend to assume its stack is empty when it calls a function, because the front end colludes to make it so, but then the front end doesn't do similar for things like multiply/divide? I can deal with this pretty easily either way. Around function calls I introduce that weren't previously there I can save whatever volatile registers are in use. But I'd like to understand. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:08:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:08:11 +0000 Subject: [M3devel] initializing LONGINT doesn't work Message-ID: Maybe not fully up to date, Linux/x86: jay at xlin2:~/t$ cat src/Main.m3 MODULE Main; VAR a := 1L; BEGIN END Main. jay at xlin2:~/t$ /cm3/bin/cm3 --- building in LINUXLIBC6 --- new source -> compiling Main.m3 "../src/Main.m3", line 3: warning: not used (a) "../src/Main.m3", line 1: ** INTERNAL CG ERROR *** unable to stuff bit field val ue?? *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/misc/CG.m3", line 1013 *** Aborted jay at xlin2:~/t$ - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:09:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Message-ID: Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:16:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: Message-ID: Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 14:39:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 13:39:25 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: , Message-ID: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 16:12:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 15:12:13 +0000 Subject: [M3devel] NT386 longint=64bits In-Reply-To: <20100207150232.B9F282474001@birch.elegosoft.com> References: <20100207150232.B9F282474001@birch.elegosoft.com> Message-ID: LONGINT on NT386 is now 64bits. It could use more testing. See m3-sys\m3tests\src\p2\p227. Add more there. Try it on NT386 and others. Disassemble the output (or use cm3 -debug and look at the *log (not *.log) files in the output directory, very useful). It doesn't run in the automated runs though, yet. There are two known problems: converting between INTEGER and LONGINT doesn't sign extend I'm not sure if LONGINT to INTEGER range checks either. In fact I didn't test any of the range checking, but it layers on top of simple compares. You cannot initialize a global LONGINT to other than 0; this bug is on all platforms. I'm hoping Tony fixes that. I think I need to make a change in m3back for this too though, to use the change I put in m3objfile (append vs. appendBytes). It'd be nifty if the front end could deal with the conversion. Generate the compares to 0, oring with FFFFFFFF00000... But I'll get to before too long either way. There are also obvious missing optimizations, some of which are easily fixed, some are not. In particular, some of the code is in the "wrong" place, such as to miss out on constant folding. Including division by constants. The fix is just to move the code later after constant cases are handled. I'll get to this stuff before too long. There are a few "support" functions. For example 64bit multiply calls out to a function. If you do a 64bit multiply in C, that calls a function too. We call the same function, where applicable. And m3core/src/Csupport/Common/hand.c has a few functions. I'm particularly nervous about extract/insert, but they seem to work. If you find a problem and really must go back to 32bit LONGINT, see the change below in Target.m3. Maybe make it a command line option. - Jay > Date: Sun, 7 Feb 2010 16:02:32 +0000 > To: m3commit at elegosoft.com > From: jkrell at elego.de > Subject: [M3commit] CVS Update: cm3 > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/02/07 16:02:32 > > Modified files: > cm3/m3-sys/m3middle/src/: Target.m3 > > Log message: > and bang: longint is now 64bits on NT386 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 7 19:55:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 13:55:13 -0500 Subject: [M3devel] atomic problem In-Reply-To: References: , Message-ID: <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: > ok, better now, but: > > == package /home/jay/dev2/cm3/m3-sys/m3staloneback == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - > DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in LINUXLIBC6 --- > ignoring ../src/m3overrides > new source -> compiling Main.m3 > -> linking m3back > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_xor_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:16:45 +0000 > Subject: Re: [M3devel] atomic problem > > Probably an out of date m3cg. > I'll see. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:09:57 +0000 > Subject: [M3devel] atomic problem > > Could be I'm out of date or building in the wrong order. > I'll maybe dig into it. > Linux/x86: > > new source -> compiling AtomicWideChar.m3 > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW > ideChar__Load': > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler > error: in expand_expr_real_1, at expr.c:7290 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc > new source -> compiling hand.c > new source -> compiling dtoa.c > new source -> compiling libgcc.c > new source -> compiling RTIOc.c > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 7 20:08:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 19:08:27 +0000 Subject: [M3devel] atomic problem In-Reply-To: <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> References: , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> Message-ID: It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. We can probably adjust m3cc/m3makefile. The platforms.quake file won't do, since native builds don't use it. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 13:55:13 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 7 20:32:44 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 14:32:44 -0500 Subject: [M3devel] atomic problem In-Reply-To: References: , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu> Message-ID: I think -march=native works too assuming you are on a modern x86. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 14:08, Jay K wrote: > It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. > Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. > We can probably adjust m3cc/m3makefile. > The platforms.quake file won't do, since native builds don't use it. > > - Jay > > From: hosking at cs.purdue.edu > Date: Sun, 7 Feb 2010 13:55:13 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] atomic problem > > -march=i686 > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 7 Feb 2010, at 08:39, Jay K wrote: > > ok, better now, but: > > == package /home/jay/dev2/cm3/m3-sys/m3staloneback == > +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - > DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ > --- building in LINUXLIBC6 --- > ignoring ../src/m3overrides > new source -> compiling Main.m3 > -> linking m3back > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_or_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_sub_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_add_2' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_xor_1' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > d_and_4' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com > pare_and_swap_8' > /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an > > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:16:45 +0000 > Subject: Re: [M3devel] atomic problem > > Probably an out of date m3cg. > I'll see. > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Sun, 7 Feb 2010 13:09:57 +0000 > Subject: [M3devel] atomic problem > > Could be I'm out of date or building in the wrong order. > I'll maybe dig into it. > Linux/x86: > > new source -> compiling AtomicWideChar.m3 > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW > ideChar__Load': > ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler > error: in expand_expr_real_1, at expr.c:7290 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc > new source -> compiling hand.c > new source -> compiling dtoa.c > new source -> compiling libgcc.c > new source -> compiling RTIOc.c > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 00:51:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 23:51:11 +0000 Subject: [M3devel] atomic problem In-Reply-To: References: , , , , , , , <05294CB0-C143-40C6-90AF-3EAEA586FEBC@cs.purdue.edu>, , Message-ID: I don't like such "non-determinism". Granted, it isn't really non-deterministic. I want to know which other machines things will run on, not just have them run on the machine on which they are built. Building things yourself is nice, but not doing it is also nice too. And not doing it on every machine even if you do build it yourself is nice. Which "reminds", or rather "convinces" me..we should just never do native builds in m3cc and m3gdb. We should pass imho what we believe to be the platform, but with carefully chosing which processor. Gotta test like every platform though. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 14:32:44 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem I think -march=native works too assuming you are on a modern x86. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 14:08, Jay K wrote: It looks like i586 suffices. I checked that in to the LINUXLIBC6 config file. Probably I386_DARWIN, FreeBSD4, NetBSD2_i386 etc. need updating. We can probably adjust m3cc/m3makefile. The platforms.quake file won't do, since native builds don't use it. - Jay From: hosking at cs.purdue.edu Date: Sun, 7 Feb 2010 13:55:13 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomic problem -march=i686 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 7 Feb 2010, at 08:39, Jay K wrote: ok, better now, but: == package /home/jay/dev2/cm3/m3-sys/m3staloneback == +++ /cm3/bin/cm3 -build -DROOT=/home/jay/dev2/cm3 -DCM3_VERSION_TEXT=d5.8.2 - DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in LINUXLIBC6 --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking m3back /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_or_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_sub_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_add_2' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_xor_1' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an d_and_4' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_bool_com pare_and_swap_8' /cm3/pkg/m3core/LINUXLIBC6/libm3core.so: undefined reference to `__sync_fetch_an - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:16:45 +0000 Subject: Re: [M3devel] atomic problem Probably an out of date m3cg. I'll see. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Sun, 7 Feb 2010 13:09:57 +0000 Subject: [M3devel] atomic problem Could be I'm out of date or building in the wrong order. I'll maybe dig into it. Linux/x86: new source -> compiling AtomicWideChar.m3 ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg: In function 'AtomicW ideChar__Load': ../LINUXLIBC6/AtomicWideChar.m3 => ../src/atomic/Atomic.mg:0: internal compiler error: in expand_expr_real_1, at expr.c:7290 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: AtomicWideChar.mc new source -> compiling hand.c new source -> compiling dtoa.c new source -> compiling libgcc.c new source -> compiling RTIOc.c -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 00:59:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 7 Feb 2010 23:59:11 +0000 Subject: [M3devel] 386?486?586?686?etc.? Message-ID: Any opinions/counter-opinions on which processors we should support? Presumably it doesn't vary per platform. Like, it wouldn't be Linux/586 and FreeBSD/486 or such. Unless maybe there is clear data about what the kernels support? The atomic stuff is pushing things to i586. I believe before 486 and possibly 386 worked. 686 is probably reasonable. I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. We might even drop "x87" support and use SSE/SSE2/SSE3? (Trolling for work in m3back? :) ) Or make it a different set of platforms? I686_LINUX? I686SSE2_LINUX? etc.? But I don't like such combinatorial work -- supporting more combinations. Maybe, uh, drop all existing 32bit platforms and go with I686_*?? "Darwin" can pretty much imply modern processors. Assuming Apple hardware...granted, I had Darwin/x86 on non-Apple hardware. None of this makes a huge difference. I mean, in that, there's almost no changes that follow from these decisions. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 8 01:11:02 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 7 Feb 2010 19:11:02 -0500 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: <29775A29-715B-4BD9-8DDA-EBA6235AB931@cs.purdue.edu> We probably should provide pthread-mutex-based atomics for targets that don't support the intrinsic atomics. Initially, I suggest we simply provide stubs that fail for the gcc-intrinsic functions. Thoughts? I doubt there are any older-than-Pentium processors that we need to worry about. On 7 Feb 2010, at 18:59, Jay K wrote: > Any opinions/counter-opinions on which processors we should support? > Presumably it doesn't vary per platform. > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > Unless maybe there is clear data about what the kernels support? > > > The atomic stuff is pushing things to i586. > I believe before 486 and possibly 386 worked. > 686 is probably reasonable. > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. > > > We might even drop "x87" support and use SSE/SSE2/SSE3? > (Trolling for work in m3back? :) ) > Or make it a different set of platforms? > I686_LINUX? > I686SSE2_LINUX? > etc.? > > > But I don't like such combinatorial work -- supporting more combinations. > Maybe, uh, drop all existing 32bit platforms and go with I686_*?? > > > "Darwin" can pretty much imply modern processors. > Assuming Apple hardware...granted, I had Darwin/x86 on non-Apple hardware. > > None of this makes a huge difference. > I mean, in that, there's almost no changes that follow from these decisions. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Mon Feb 8 04:58:48 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 7 Feb 2010 22:58:48 -0500 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: <20100208035847.GB13743@topoi.pooq.com> On Sun, Feb 07, 2010 at 11:59:11PM +0000, Jay K wrote: > > Any opinions/counter-opinions on which processors we should support? > > Presumably it doesn't vary per platform. > > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > > Unless maybe there is clear data about what the kernels support? > > > > > > The atomic stuff is pushing things to i586. > I believe before 486 and possibly 386 worked. > > 686 is probably reasonable. > > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. I'm still running an old 100 MHz Pentium and using it on a daily basis. Debian has dropped support for the 386 with, as far as I know, no complaints. -- hendrik. From jay.krell at cornell.edu Mon Feb 8 15:03:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Feb 2010 14:03:30 +0000 Subject: [M3devel] hand.c to Modula-3? Message-ID: Just a note that hand.c could be mostly/easily be written in Modula-3 instead of C. The main problem is the names. Might be a fun little project for someone. We should also change the gcc backend to use memcmp instead of set_ne/set_eq. Or even the frontend. (There might be an extra efficiency to be had in that a) we don't need -1/0/+1, just a boolean b) we know it is a whole number of ulongs). Probably set_ne/set_eq are rare though. m3back compares to an empty set often, but it is small and the front end implements small sets as a single integer. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 8 16:22:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 8 Feb 2010 15:22:21 +0000 Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: <20100208035847.GB13743@topoi.pooq.com> References: , <20100208035847.GB13743@topoi.pooq.com> Message-ID: Wow. What for? And with Modula-3? What OS? I think Pentium will be ok. I think ultimately, if people really need, we should have separate targets. As I've been saying, like: I386_FREEBSD_USERTHREADS, I586_FREEBSD, etc. Esp. to enable easier "release engineering", such as when we do more cross builds, adding new targets will be cheaper. But we'd want some sort of system where if nobody downloads and installs and minimally tests a release, it is in some low grade classification. Certain ones we'd test automatically, like whatever we have available in Hudson. -Jay > Date: Sun, 7 Feb 2010 22:58:48 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] 386?486?586?686?etc.? > > On Sun, Feb 07, 2010 at 11:59:11PM +0000, Jay K wrote: > > > > Any opinions/counter-opinions on which processors we should support? > > > > Presumably it doesn't vary per platform. > > > > Like, it wouldn't be Linux/586 and FreeBSD/486 or such. > > > > Unless maybe there is clear data about what the kernels support? > > > > The atomic stuff is pushing things to i586. > > I believe before 486 and possibly 386 worked. > > > > 686 is probably reasonable. > > > > I think it is Pentium II or Pentium Pro or newer, stuff like 15 years old already. > > I'm still running an old 100 MHz Pentium and using it on a daily basis. > > Debian has dropped support for the 386 with, as far as I know, no > complaints. > > -- hendrik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Feb 10 21:15:18 2010 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 10 Feb 2010 21:15:18 +0100 (CET) Subject: [M3devel] 386?486?586?686?etc.? In-Reply-To: References: Message-ID: On Sun, 7 Feb 2010, Jay K wrote: > We might even drop "x87" support and use SSE/SSE2/SSE3? > ?(Trolling for work in m3back? :) ) > ?Or make it a different set of platforms? > ?? I686_LINUX? > ?? I686SSE2_LINUX? > ?? etc.? The SSE's do not support transcendental functions. But they are nice for basic floating point arithmetic, if you rely on the low precision of the IEEE formats. I assume that this is the reason, why LLVM uses SSE instead of FPU instructions where possible. From jay.krell at cornell.edu Thu Feb 11 09:53:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 08:53:08 +0000 Subject: [M3devel] optimizing for size or speed? Message-ID: There are all kinds of equivalent code sequences. For the maintainer of m3back to chose among. Given for example: int F(int a) { return a << 2; } Visual C++ optimizing for size uses: shl eax, 2 ; 3 bytes optimizing for speed gives: add eax, eax ; 2 bytes add eax, eax ; 2 bytes given a << 3, the choices are, obviously: shl eax, 3 ; 3 bytes or add eax, eax add eax, eax add eax, eax 6 bytes, double the size thoughts? I think go for size over speed. Smaller files, less I/O, both in the build and less code to pagein at runtime. At some point higher instruction counts saturate the ability of the processors to "run ahead"? However it might be nice to give the user a choice? But then you invite increased testing cost. Though maybe not too prohibitive. (for shift by one, size/speed both give add eax, eax; I'll do that) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 11 13:03:09 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 11 Feb 2010 07:03:09 -0500 Subject: [M3devel] optimizing for size or speed? In-Reply-To: References: Message-ID: <20100211120309.GB27402@topoi.pooq.com> On Thu, Feb 11, 2010 at 08:53:08AM +0000, Jay K wrote: > > There are all kinds of equivalent code sequences. > For the maintainer of m3back to chose among. In case of doubt, go for size; size all by itself costs time in cache misses, paging, etc. Besides, it's possible to measure space. -- hendrik From jay.krell at cornell.edu Thu Feb 11 13:05:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:05:53 +0000 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) Message-ID: TInt/TWord proposal TInt needs to be a "complete" replacement for INTEGER and LONGINT. Plus overflow checking. Not just for the frontend, but also m3back. TWord needs to be a "complete" replacement for Word and Long. Therefore not likely any overflow checking. But in reality you might need all four: signed with silent overflow signed with nonsilent overflow unsigned with silent overflow unsigned with nonsilent overflow You can provide silent overflow by computing the result and leaving it to the caller to ignore the BOOLEAN or not. However in practise I don't think I needed silent overflow at all. The only places I allow it, I think really I'm confusing TInt with TWord, because TWord doesn't provide the right interface. Settle on bits or bytes for sizes. Enshrine it mostly in the public interface. It maybe already is, granted. But more so -- external users can construct the things. Operations with mixed sizes shall not be allowed. <=== ***** Just as INTEGER, LONGINT, Word, Long don't allow. There would be some conversion functions, granted. SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. Constants Zero, One, MOne, etc. shall probably be replaced with an array of 8 each, or maybe just 1, 2, 4, 8 -- the number of bytes in the size. "M" for "minus" is the wrong term. It should N or Neg or Negative. Something like: TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) TYPE ByteCount = [1..8]; (* wasteful, darn *) CONST Invalid = Target.Int{-1,IntBytes{0,..}}; CONST ZeroBytes = IntBytes{0,..}; CONST OneBytes = IntBytes{1,0,..}; CONST NegativeOneBytes = IntBytes{16_FF,..}; CONST ThirtyTwoBytes = IntBytes{32,0,..}; etc. CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, Invalid, Target.Int{8,ZeroBytes}}; CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, Invalid, Target.Int{8,OneBytes}}; etc. TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] MAYBE as a possible simplification to the user: Introduce InternalTInt which is today's TInt and then: TInt implies Target.Integer.bytes TWord implies Target.Integer.bytes new TLongint implies Target.Longint.bytes new TLong implies Target.Longint.bytes I really thing the short name "Long" is bad. There is no indication of unsignedness in it. It should be ULong or UnsignedLong or LongWord. "Word" is to INTEGER as what is to LONGINT? I don't think Long is the answer. I'll start another thread on this. m3back maintains a stack of mixed types, but I think it works out ok. All that being said, I think what is there works and isn't terrible and we don't need to solve lots of problems here. I do think the variable sizing is a bit of a problem though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:09:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:09:13 +0000 Subject: [M3devel] "Word" is to INTEGER as what is to LONGINT? Message-ID: "Word" is to INTEGER as what is to LONGINT? I don't think Long is a good answer. It is the current answer. "Word" and "INTEGER" are not "related". "Related" might be "UnsignedInteger" or "Integer" or "IntegerOps" or "SilentOverflowInteger" I'm not proposing changing the name "Word". But whatever is the LONGINT replacement...maybe "LongWord" or "UnsignedLong"? I don't think "Long" is the correct answer. Or does "word" not imply "unsigned" or "silent overflow", merely "integer sized"? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:11:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:11:14 +0000 Subject: [M3devel] atomics questions Message-ID: What if some atomic operations aren't available? If none are available, then they can all fallback to one giant lock. But what if some are and some aren't? A lock per type? That fails with like union { short s[2]; int i; } u; and platform has atomic int but not atomic short. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:15:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:15:03 +0000 Subject: [M3devel] use of date and bc in m3tests Message-ID: Anyone: C:\dev2\cm3.2\m3-sys\m3tests\src\m3makefile Please try to remove the uses of date and bc. Thanks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:34:53 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:34:53 +0000 Subject: [M3devel] replacing hand.c with Modula-3? Message-ID: I see no great reason for hand.c to be in C. It should be easy to rewrite in Modula-3, using the Word interface. The only question really is, what to call things? M3_BUILTIN__set_union, etc.? I think I see M3_BUILTIN somewhere. RTHooks__set_union, etc.? SomethingElse__set_union? SomethingElse__somethingElse while we're at it? M3Set__Union M3Set__Singleton -- probably not even worth being a function M3Set__Intersect etc.? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 13:41:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 12:41:12 +0000 Subject: [M3devel] optimizing for size or speed? In-Reply-To: <20100211120309.GB27402@topoi.pooq.com> References: , <20100211120309.GB27402@topoi.pooq.com> Message-ID: cache -- good point I had forgotten, thanks. Still: use the divide instruction, which is smallest, or multiply by reciprocal (which is generally a multiply and a shift) (Given a 32x32=>64 multiply operation. x86 doesn't even have 32x32=>32, only 32x32=>64, I believe.) Any 32bit division by a constant can be optimized this way and every C compiler knows it. multiply by a constant using multiply instruction, or decompose into some adds? The AMD64 optimization guide suggests speed optimizations where they give a sequence for multiplication for every constant up to 32, some are just to use mul. But many are one or two other instructions. Multiply by 5 is: lea eax,[eax+eax*4] Multiply by 10 is: lea eax,[eax+eax*4] add eax,eax The AMD64 manual even advises to inline 64bit shifts by a non-constant. But I can't get Visual C++ to do that. It always calls a function. - Jay > Date: Thu, 11 Feb 2010 07:03:09 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] optimizing for size or speed? > > On Thu, Feb 11, 2010 at 08:53:08AM +0000, Jay K wrote: > > > > There are all kinds of equivalent code sequences. > > For the maintainer of m3back to chose among. > > In case of doubt, go for size; size all by itself costs time in cache > misses, paging, etc. > > Besides, it's possible to measure space. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 14:23:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 13:23:45 +0000 Subject: [M3devel] assertion failure in atomics Message-ID: Tony if you don't have enough to do already: VAR <*NOWARN*>a := 1; <*NOWARN*>b := 2; <*NOWARN*>c := 3; <*NOWARN*>d := 4; <*NOWARN*>A := 5L; <*NOWARN*>B := 6L; <*NOWARN*>C := 7L; <*NOWARN*>D := 8L; bool:BOOLEAN; PROCEDURE Test_AtomicInteger_CompareSwap() = BEGIN bool := AtomicInteger.CompareSwap(a, b, c); END Test_AtomicInteger_CompareSwap; C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 --- building in NT386 --- new source -> compiling Main.m3 "..\Main.m3", line 83: incompatible types (var) *** *** runtime error: *** An array subscript was out of range. *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", line 19 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil tinAtomic\CompareSwap.mg 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 ......... ......... ... more frames ... 1) The test is in error, wrong type on one of the params. 2) This could be specific to using m3back. 3) I'll poke around more. 4) Too bad we don't get line numbers in the stacks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 16:00:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 15:00:39 +0000 Subject: [M3devel] assertion failure in atomics In-Reply-To: References: Message-ID: Type-incorrect code seems to tend to assert. But type-correct code gets through the frontend ok. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 11 Feb 2010 13:23:45 +0000 Subject: [M3devel] assertion failure in atomics Tony if you don't have enough to do already: VAR <*NOWARN*>a := 1; <*NOWARN*>b := 2; <*NOWARN*>c := 3; <*NOWARN*>d := 4; <*NOWARN*>A := 5L; <*NOWARN*>B := 6L; <*NOWARN*>C := 7L; <*NOWARN*>D := 8L; bool:BOOLEAN; PROCEDURE Test_AtomicInteger_CompareSwap() = BEGIN bool := AtomicInteger.CompareSwap(a, b, c); END Test_AtomicInteger_CompareSwap; C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 --- building in NT386 --- new source -> compiling Main.m3 "..\Main.m3", line 83: incompatible types (var) *** *** runtime error: *** An array subscript was out of range. *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", line 19 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil tinAtomic\CompareSwap.mg 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 ......... ......... ... more frames ... 1) The test is in error, wrong type on one of the params. 2) This could be specific to using m3back. 3) I'll poke around more. 4) Too bad we don't get line numbers in the stacks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 11 16:35:43 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 11 Feb 2010 16:35:43 +0100 Subject: [M3devel] use of date and bc in m3tests In-Reply-To: References: Message-ID: <20100211163543.l5ohnxt6qswcgc84@mail.elegosoft.com> Quoting Jay K : > Anyone: > > C:\dev2\cm3.2\m3-sys\m3tests\src\m3makefile > > Please try to remove the uses of date and bc. > > Thanks. I happend to see this some minutes ago (lots of other unread M3 mails in my box I'm afraid). AFAIK date and bc are only used in the quake code to time the tests. There are several things that can be done: 1. They can be used conditionally, depending on the existence of date and bc on the test system. That should be possible in quake. Of course test time reporting will then not work if they are missing. 2. Somebody can write simple M3 or C programs that will be used instead. Should not be too difficult, but somewhat redundant. 3. Ideally, quake itself should be able to time the execution of procedures and to do simple arithmetic. That would be the best solution. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Thu Feb 11 17:53:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:53:24 -0500 Subject: [M3devel] atomics questions In-Reply-To: References: Message-ID: <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> On 11 Feb 2010, at 07:11, Jay K wrote: > What if some atomic operations aren't available? > > > If none are available, then they can all fallback to one giant lock. > Correct. > > But what if some are and some aren't? > A lock per type? Yes. Definitely. No unions in M3. > > That fails with like > union { > short s[2]; > int i; > } u; > > > and platform has atomic int but not atomic short. We do have atomic WIDECHARl > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 11 17:52:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:52:12 -0500 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) In-Reply-To: References: Message-ID: Steady on. I have it fixed. CHeckin coming. No need for more. On 11 Feb 2010, at 07:05, Jay K wrote: > TInt/TWord proposal > > > TInt needs to be a "complete" replacement for INTEGER and LONGINT. > Plus overflow checking. > Not just for the frontend, but also m3back. > > > TWord needs to be a "complete" replacement for Word and Long. > Therefore not likely any overflow checking. > > > But in reality you might need all four: > signed with silent overflow > signed with nonsilent overflow > unsigned with silent overflow > unsigned with nonsilent overflow > > > You can provide silent overflow by computing the result > and leaving it to the caller to ignore the BOOLEAN or not. > > > However in practise I don't think I needed silent overflow at all. > The only places I allow it, I think really I'm confusing TInt with TWord, > because TWord doesn't provide the right interface. > > > Settle on bits or bytes for sizes. > Enshrine it mostly in the public interface. > It maybe already is, granted. > But more so -- external users can construct the things. > > > Operations with mixed sizes shall not be allowed. <=== ***** > Just as INTEGER, LONGINT, Word, Long don't allow. > > > There would be some conversion functions, granted. > SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. > > > Constants Zero, One, MOne, etc. shall probably be > replaced with an array of 8 each, or maybe just > 1, 2, 4, 8 -- the number of bytes in the size. > > > "M" for "minus" is the wrong term. > It should N or Neg or Negative. > > > Something like: > TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) > TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) > TYPE ByteCount = [1..8]; (* wasteful, darn *) > > CONST Invalid = Target.Int{-1,IntBytes{0,..}}; > > CONST ZeroBytes = IntBytes{0,..}; > CONST OneBytes = IntBytes{1,0,..}; > CONST NegativeOneBytes = IntBytes{16_FF,..}; > CONST ThirtyTwoBytes = IntBytes{32,0,..}; > etc. > > CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, > Invalid, Target.Int{8,ZeroBytes}}; > > CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, > Invalid, Target.Int{8,OneBytes}}; > etc. > > > TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] > > > MAYBE as a possible simplification to the user: > > Introduce InternalTInt which is today's TInt and then: > TInt implies Target.Integer.bytes > TWord implies Target.Integer.bytes > new TLongint implies Target.Longint.bytes > new TLong implies Target.Longint.bytes > > > I really thing the short name "Long" is bad. > There is no indication of unsignedness in it. > It should be ULong or UnsignedLong or LongWord. > > > "Word" is to INTEGER as what is to LONGINT? > I don't think Long is the answer. > I'll start another thread on this. > > > m3back maintains a stack of mixed types, but I think it works out ok. > > > All that being said, I think what is there works and isn't terrible > and we don't need to solve lots of problems here. > > > I do think the variable sizing is a bit of a problem though. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 11 17:54:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 11 Feb 2010 11:54:59 -0500 Subject: [M3devel] assertion failure in atomics In-Reply-To: References: Message-ID: I figured we'd shake some of these problems out fairly soon. I need to get the TInt/TWord stuff checked in before I move on this. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 11 Feb 2010, at 08:23, Jay K wrote: > Tony if you don't have enough to do already: > > VAR > <*NOWARN*>a := 1; > <*NOWARN*>b := 2; > <*NOWARN*>c := 3; > <*NOWARN*>d := 4; > <*NOWARN*>A := 5L; > <*NOWARN*>B := 6L; > <*NOWARN*>C := 7L; > <*NOWARN*>D := 8L; > bool:BOOLEAN; > > PROCEDURE Test_AtomicInteger_CompareSwap() = > BEGIN > bool := AtomicInteger.CompareSwap(a, b, c); > END Test_AtomicInteger_CompareSwap; > > > C:\dev2\cm3.2\m3-sys\m3tests\src\p2\p226>cm3 > --- building in NT386 --- > new source -> compiling Main.m3 > "..\Main.m3", line 83: incompatible types (var) > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "..\NT386\CompareSwapInt.m3 => ..\src\builtinAtomic\CompareSwap.mg", > line 19 > *** > Stack trace: > FP PC Procedure > --------- --------- ------------------------------- > 0x12f3c4 0x597b9a Check + 0x19a in ..\NT386\CompareSwapInt.m3 => ..\src\buil > tinAtomic\CompareSwap.mg > 0x12f410 0x5cd6c6 Check + 0x762 in ..\src\exprs\CallExpr.m3 > 0x12f434 0x5bed4b TypeCheck + 0x65 in ..\src\exprs\Expr.m3 > 0x12f478 0x5c0570 CheckMethod + 0xd5 in ..\src\stmts\AssignStmt.m3 > 0x12f498 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 > 0x12f4c4 0x531400 Check + 0x265 in ..\src\stmts\BlockStmt.m3 > 0x12f4e4 0x5320e7 TypeCheck + 0x48 in ..\src\stmts\Stmt.m3 > 0x12f554 0x4e73c4 CheckBody + 0x67d in ..\src\values\Procedure.m3 > 0x12f580 0x4d0cce TypeCheck + 0x16e in ..\src\misc\Scope.m3 > 0x12f5c4 0x4c159b TypeCheck + 0x305 in ..\src\values\Module.m3 > ......... ......... ... more frames ... > > > 1) The test is in error, wrong type on one of the params. > 2) This could be specific to using m3back. > 3) I'll poke around more. > 4) Too bad we don't get line numbers in the stacks. > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 11 23:46:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 11 Feb 2010 22:46:51 +0000 Subject: [M3devel] TInt/TWord proposal (at least what I was thinking..) In-Reply-To: References: , Message-ID: To be clear, I'm not working on this, was just thinking about it. - Jay Subject: Re: [M3devel] TInt/TWord proposal (at least what I was thinking..) From: hosking at cs.purdue.edu Date: Thu, 11 Feb 2010 11:52:12 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu Steady on. I have it fixed. CHeckin coming. No need for more. On 11 Feb 2010, at 07:05, Jay K wrote: TInt/TWord proposal TInt needs to be a "complete" replacement for INTEGER and LONGINT. Plus overflow checking. Not just for the frontend, but also m3back. TWord needs to be a "complete" replacement for Word and Long. Therefore not likely any overflow checking. But in reality you might need all four: signed with silent overflow signed with nonsilent overflow unsigned with silent overflow unsigned with nonsilent overflow You can provide silent overflow by computing the result and leaving it to the caller to ignore the BOOLEAN or not. However in practise I don't think I needed silent overflow at all. The only places I allow it, I think really I'm confusing TInt with TWord, because TWord doesn't provide the right interface. Settle on bits or bytes for sizes. Enshrine it mostly in the public interface. It maybe already is, granted. But more so -- external users can construct the things. Operations with mixed sizes shall not be allowed. <=== ***** Just as INTEGER, LONGINT, Word, Long don't allow. There would be some conversion functions, granted. SignedTruncate, UnsignedTruncate, SignExtend, ZeroExtend. Constants Zero, One, MOne, etc. shall probably be replaced with an array of 8 each, or maybe just 1, 2, 4, 8 -- the number of bytes in the size. "M" for "minus" is the wrong term. It should N or Neg or Negative. Something like: TYPE BitCount = [8, 16, 32, 64]; (* not legal, darn *) TYPE ByteCount = [1, 2, 4, 8]; (* also not legal, darn *) TYPE ByteCount = [1..8]; (* wasteful, darn *) CONST Invalid = Target.Int{-1,IntBytes{0,..}}; CONST ZeroBytes = IntBytes{0,..}; CONST OneBytes = IntBytes{1,0,..}; CONST NegativeOneBytes = IntBytes{16_FF,..}; CONST ThirtyTwoBytes = IntBytes{32,0,..}; etc. CONST Zero = ARRAY ByteCount OF { Target.Int{1,ZeroBytes}, Target.Int{2,ZeroBytes}, Invalid, Target.Int{4,ZeroBytes}, Invalid, Invalid, Invalid, Target.Int{8,ZeroBytes}}; CONST One = ARRAY ByteCount OF { Target.Int{1,OneBytes}, Target.Int{2,OneBytes}, Invalid, Target.Int{4,OneBytes}, Invalid, Invalid, Invalid, Target.Int{8,OneBytes}}; etc. TInt.Zero becomes replaced by, e.g. TInt.Zero[Target.Integer.bytes] or TInt.Zero[Target.Longint.bytes] MAYBE as a possible simplification to the user: Introduce InternalTInt which is today's TInt and then: TInt implies Target.Integer.bytes TWord implies Target.Integer.bytes new TLongint implies Target.Longint.bytes new TLong implies Target.Longint.bytes I really thing the short name "Long" is bad. There is no indication of unsignedness in it. It should be ULong or UnsignedLong or LongWord. "Word" is to INTEGER as what is to LONGINT? I don't think Long is the answer. I'll start another thread on this. m3back maintains a stack of mixed types, but I think it works out ok. All that being said, I think what is there works and isn't terrible and we don't need to solve lots of problems here. I do think the variable sizing is a bit of a problem though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 09:45:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 08:45:17 +0000 Subject: [M3devel] atomics questions In-Reply-To: <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> References: , <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> Message-ID: loophole allows for union, right? I know there is widechar, point was, if some hypothetical platform without atomic widechar. - Jay From: hosking at cs.purdue.edu Date: Thu, 11 Feb 2010 11:53:24 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] atomics questions On 11 Feb 2010, at 07:11, Jay K wrote: What if some atomic operations aren't available? If none are available, then they can all fallback to one giant lock. Correct. But what if some are and some aren't? A lock per type? Yes. Definitely. No unions in M3. That fails with like union { short s[2]; int i; } u; and platform has atomic int but not atomic short. We do have atomic WIDECHARl - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 10:17:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 09:17:14 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Message-ID: Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 10:57:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 09:57:08 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: Message-ID: Hm. I think there's a bigger problem here. I think, not sure, but i think compare_exhcange needs to take a "Var", not an address on the stack. See how it is storing the address to the stack and comparing that. Wrong. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Fri, 12 Feb 2010 09:17:14 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 15:20:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 14:20:39 +0000 Subject: [M3devel] m3back atomic current summary Message-ID: "m3back atomics summary" After a while of looking at this, I conclude that the atomics interface has a bunch of functionality that doesn't map all that well to what x86 provides, and vice versa. In particular x86 allows lock mem or reg lock mem xor reg lock mem and reg lock not mem lock neg mem and several others but the requirement of the atomic interface to return the new value makes these not line up. The new value doesn't come back in a register and rereading memory will not be atomic. Now I see why the C compiler's _InterlockedOr and such use _InterlockedCompareExchange in a small loop. Any xchg with a memory operand on x86 is always atomic. fetch_and_op for add/sub can probably be more efficient using xadd. You get back the old value but you can do the add a second time. I understand the point isn't necessarily to expose whatever x86 can do, but also to provide an interface that can be reasonably implemented across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). It's possible the front end (or backend) should notice if the return value is ignored, such as by preceding it with EVAL, and then those can be implemented more efficiently. The NT386 backend does not have the level of sophistication required to do that. I'm torn on even providing this stuff. It's all very tricky to use. However any "systems" language should probobably provide for a portable efficient lock package, that others can then easily use. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 15:26:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 14:26:25 +0000 Subject: [M3devel] m3back atomic current summary In-Reply-To: References: Message-ID: aha, Visual C++ does do this optimization: void __fastcall xInterlockedOr(long* a, long b) { _InterlockedOr(a, b); } long __fastcall yInterlockedOr(long* a, long b) { return _InterlockedOr(a, b); } void __fastcall xInterlockedXor(long* a, long b) { _InterlockedXor(a, b); } long __fastcall yInterlockedXor(long* a, long b) { return _InterlockedXor(a, b); } yelds: ; 1 : void __fastcall xInterlockedOr(long* a, long b) { _InterlockedOr(a, b); } 00000 f0 09 11 lock or DWORD PTR [ecx], edx 00003 c3 ret 0 ; 2 : long __fastcall yInterlockedOr(long* a, long b) { return _InterlockedOr(a, b); } 00010 56 push esi 00011 8b 01 mov eax, DWORD PTR [ecx] $LN3@: 00013 8b f0 mov esi, eax 00015 0b f2 or esi, edx 00017 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 0001b 75 f6 jne SHORT $LN3@ 0001d 5e pop esi 0001e c3 ret 0 ; 3 : void __fastcall xInterlockedXor(long* a, long b) { _InterlockedXor(a, b); } 00020 f0 31 11 lock xor DWORD PTR [ecx], edx ; 4 : long __fastcall yInterlockedXor(long* a, long b) { return _InterlockedXor(a, b); } 00030 56 push esi 00031 8b 01 mov eax, DWORD PTR [ecx] $LN3@: 00033 8b f0 mov esi, eax 00035 33 f2 xor esi, edx 00037 f0 0f b1 31 lock cmpxchg DWORD PTR [ecx], esi 0003b 75 f6 jne SHORT $LN3@ 0003d 5e pop esi 0003e c3 ret 0 cool. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com; hosking at cs.purdue.edu Date: Fri, 12 Feb 2010 14:20:39 +0000 Subject: [M3devel] m3back atomic current summary "m3back atomics summary" After a while of looking at this, I conclude that the atomics interface has a bunch of functionality that doesn't map all that well to what x86 provides, and vice versa. In particular x86 allows lock mem or reg lock mem xor reg lock mem and reg lock not mem lock neg mem and several others but the requirement of the atomic interface to return the new value makes these not line up. The new value doesn't come back in a register and rereading memory will not be atomic. Now I see why the C compiler's _InterlockedOr and such use _InterlockedCompareExchange in a small loop. Any xchg with a memory operand on x86 is always atomic. fetch_and_op for add/sub can probably be more efficient using xadd. You get back the old value but you can do the add a second time. I understand the point isn't necessarily to expose whatever x86 can do, but also to provide an interface that can be reasonably implemented across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). It's possible the front end (or backend) should notice if the return value is ignored, such as by preceding it with EVAL, and then those can be implemented more efficiently. The NT386 backend does not have the level of sophistication required to do that. I'm torn on even providing this stuff. It's all very tricky to use. However any "systems" language should probobably provide for a portable efficient lock package, that others can then easily use. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 15:49:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 09:49:14 -0500 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: Message-ID: <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. The C source: int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) { return AO_compare_and_swap_full(addr, *old, new); } generates: .globl _Atomic__CompareSwap_ordered _Atomic__CompareSwap_ordered: LFB526: pushq %rbp LCFI42: movq %rsp, %rbp LCFI43: movq (%rsi), %rax lock; cmpxchgq %rdx, (%rdi); setz %al movsbl %al,%eax leave ret LFE526: .align 4,0x90 On 12 Feb 2010, at 04:17, Jay K wrote: > Tony, currently I have atomic.compare_and_exchange generating e.g.: > > > load_address gv.2[_MM_Main] 56 > 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 > load_address gv.2[_MM_Main] 152 > 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 > load gv.2[_MM_Main] 156 Int.32 Int.32 > compare_exchange Int.32 Int.32 Int.32 > 0000019A: 8BC7 MOV EAX EDI > 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 > declare_temp 4 4 Addr F tv.35[T$35] -4 > 000001A2: 8975FC MOV tv.35[T$35] ESI > 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX > > > This might not be correct, but it is close. > > > Now, the thing is, the eax register is special to lock cmpxchg. > It always holds the comparison value. > > The point is, if cg.compare_exchange took its parameters as > parameters instead of on the stack, it could chose the > right register right away, instead of as above where it > choses the wrong one and then must mov it. > > Easy to change it like that? > > > I realize this is an m3back deficiency. > It does the register allocation too early. > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 15:42:04 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 09:42:04 -0500 Subject: [M3devel] atomics questions In-Reply-To: References: , <1A55C55C-2519-499F-8659-F046DF578759@cs.purdue.edu> Message-ID: No, the values must have the same BITSIZE or you get an error. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 12 Feb 2010, at 03:45, Jay K wrote: > loophole allows for union, right? > I know there is widechar, point was, if some hypothetical platform without atomic widechar. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 11 Feb 2010 11:53:24 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] atomics questions > > On 11 Feb 2010, at 07:11, Jay K wrote: > > What if some atomic operations aren't available? > > > If none are available, then they can all fallback to one giant lock. > > > Correct. > > > But what if some are and some aren't? > > > > A lock per type? > > Yes. Definitely. No unions in M3. > > > That fails with like > union { > short s[2]; > int i; > } u; > > > and platform has atomic int but not atomic short. > > We do have atomic WIDECHARl > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 16:16:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 10:16:50 -0500 Subject: [M3devel] m3back atomic current summary In-Reply-To: References: Message-ID: <69C6DDBB-3300-4B60-9FDC-E06BAF0A955E@cs.purdue.edu> Jay, I don't understand your issues here. On 12 Feb 2010, at 09:20, Jay K wrote: > "m3back atomics summary" > > After a while of looking at this, I conclude > that the atomics interface has a bunch > of functionality that doesn't map all that > well to what x86 provides, and vice versa. > > > In particular x86 allows > lock mem or reg > lock mem xor reg > lock mem and reg > lock not mem > lock neg mem > and several others > > > but the requirement of the atomic interface > to return the new value makes these not line up. Which new value? There is no *requirement* that CompareSwap return the actual value in the register: The CompareSwap operation may fail spuriously, that is return false while leaving the value in "expected" unchanged. A consequence of spurious failure is that nearly all uses of CompareSwap will be in a loop: > The new value doesn't come back in a register > and rereading memory will not be atomic. Again, I don't understand this. > Now I see why the C compiler's _InterlockedOr and such > use _InterlockedCompareExchange in a small loop. > > > Any xchg with a memory operand on x86 is always atomic. > > > fetch_and_op for add/sub can probably be more efficient using xadd. > You get back the old value but you can do the add a second time. > > > I understand the point isn't necessarily to expose whatever x86 can do, > but also to provide an interface that can be reasonably implemented > across various hardware (mips, alpha, powerpc, sparc, arm, hppa, ia64, maybe 68k). > > > It's possible the front end (or backend) should notice if the return value > is ignored, such as by preceding it with EVAL, and then those can be > implemented more efficiently. > The NT386 backend does not have the level of sophistication required to do that. > > > I'm torn on even providing this stuff. > It's all very tricky to use. > However any "systems" language should probobably > provide for a portable efficient lock package, that > others can then easily use. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 12 18:42:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 12 Feb 2010 17:42:05 +0000 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> References: , <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Message-ID: It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack. We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be. We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register. Again, if m3back were multi pass or somehow smarter, it'd be moot. I'll be looking into make it one or both of these maybe sometime soon. - Jay From: hosking at cs.purdue.edu Date: Fri, 12 Feb 2010 09:49:14 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. The C source: int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) { return AO_compare_and_swap_full(addr, *old, new); } generates: .globl _Atomic__CompareSwap_ordered _Atomic__CompareSwap_ordered: LFB526: pushq %rbp LCFI42: movq %rsp, %rbp LCFI43: movq (%rsi), %rax lock; cmpxchgq %rdx, (%rdi); setz %al movsbl %al,%eax leave ret LFE526: .align 4,0x90 On 12 Feb 2010, at 04:17, Jay K wrote: Tony, currently I have atomic.compare_and_exchange generating e.g.: load_address gv.2[_MM_Main] 56 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 load_address gv.2[_MM_Main] 152 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 load gv.2[_MM_Main] 156 Int.32 Int.32 compare_exchange Int.32 Int.32 Int.32 0000019A: 8BC7 MOV EAX EDI 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 declare_temp 4 4 Addr F tv.35[T$35] -4 000001A2: 8975FC MOV tv.35[T$35] ESI 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX This might not be correct, but it is close. Now, the thing is, the eax register is special to lock cmpxchg. It always holds the comparison value. The point is, if cg.compare_exchange took its parameters as parameters instead of on the stack, it could chose the right register right away, instead of as above where it choses the wrong one and then must mov it. Easy to change it like that? I realize this is an m3back deficiency. It does the register allocation too early. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 12 19:35:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 12 Feb 2010 13:35:27 -0500 Subject: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? In-Reply-To: References: , <6F9C6C88-13C2-4F8B-820E-95CBF1C52490@cs.purdue.edu> Message-ID: Let's be explicit here. You want compare_exchange to take an explicit Var? For which argument? The memory location being manipulated or the expected value? compare_exchange (t: MType; u: ZType; r: IType; success, failure: MemoryOrder); (* tmp := Mem[s2.A].t; IF (tmp = Mem[s1.A].t) THEN Mem [s2.A].t := s0.u; s2.r := 1; pop(2); ELSE Mem [s1.A].t := tmp; s2.r := 0; pop(2); END; This is permitted to fail spuriously, leaving Mem [s1.A] unchanged. *) So, you want s1 to be a Var or s2? On 12 Feb 2010, at 12:42, Jay K wrote: > It is easier to generate more efficient code if the variable is passed as a parameter to cg.compare_exchange instead of on the stack. > We can defer register allocation until we know we must use eax, instead of allocating it "wherever" and then moving it to eax once we know that is where it is needed, as it always will be. > We can also generate more efficient code for fetch_op if passed function parameters since we don't need to get the address in a register. > > Again, if m3back were multi pass or somehow smarter, it'd be moot. > I'll be looking into make it one or both of these maybe sometime soon. > > - Jay > > From: hosking at cs.purdue.edu > Date: Fri, 12 Feb 2010 09:49:14 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cg.compare_exchange should take more parameters in function call, fewer on stack? > > Here's what Boehm produces in his libatomic package. Don't know if it helps or answers your question. > > The C source: > > int Atomic__CompareSwap_ordered (volatile AO_t *addr, AO_t *old, AO_t new) > { return AO_compare_and_swap_full(addr, *old, new); } > > generates: > > .globl _Atomic__CompareSwap_ordered > _Atomic__CompareSwap_ordered: > LFB526: > pushq %rbp > LCFI42: > movq %rsp, %rbp > LCFI43: > movq (%rsi), %rax > lock; cmpxchgq %rdx, (%rdi); setz %al > movsbl %al,%eax > leave > ret > LFE526: > .align 4,0x90 > > > > On 12 Feb 2010, at 04:17, Jay K wrote: > > Tony, currently I have atomic.compare_and_exchange generating e.g.: > > > load_address gv.2[_MM_Main] 56 > 0000018E: 8D3538000000 LEA ESI gv.2[_MM_Main]+56 > load_address gv.2[_MM_Main] 152 > 00000194: 8D3D98000000 LEA EDI gv.2[_MM_Main]+152 > load gv.2[_MM_Main] 156 Int.32 Int.32 > compare_exchange Int.32 Int.32 Int.32 > 0000019A: 8BC7 MOV EAX EDI > 0000019C: 8B1D9C000000 MOV EBX gv.2[_MM_Main]+156 > declare_temp 4 4 Addr F tv.35[T$35] -4 > 000001A2: 8975FC MOV tv.35[T$35] ESI > 000001A5: F00FB15DFC LOCK CMPXCHG tv.35[T$35]:Addr EBX > > > This might not be correct, but it is close. > > > Now, the thing is, the eax register is special to lock cmpxchg. > It always holds the comparison value. > > The point is, if cg.compare_exchange took its parameters as > parameters instead of on the stack, it could chose the > right register right away, instead of as above where it > choses the wrong one and then must mov it. > > Easy to change it like that? > > > I realize this is an m3back deficiency. > It does the register allocation too early. > > - Jay > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 13 16:25:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 13 Feb 2010 16:25:26 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed Message-ID: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. But I don't seem to be able to upgrade to the current head of the release branch even with the upgrade script: http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console What do I miss? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Sun Feb 14 13:55:42 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 14 Feb 2010 12:55:42 +0000 Subject: [M3devel] m3back/longint/atomics Message-ID: As far as I know/can remember, longint and atomics should all work now on NT386. Atomics only currently for 32bit types. There are still a few small inefficiencies to maybe deal with. I'll add 64bit shortly and maybe 8 and 16. We should probably add *a lot* more test coverage in p226 and p227. e.g. longint multiply/add/sub/divide, not just insert/extract like I did a bunch of. Still to fix the Win32 m3core/libm3 to not always truncate file sizes. Still maybe to do something about rd/wr...? Still to wonder about NT386/longint support in the release branch? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 15 09:29:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Feb 2010 08:29:07 +0000 Subject: [M3devel] int64 division? Message-ID: Tony, there's something wrong with 64bit division. This program fails on LINUXLIBC6. I fixed it for NT386 (wrong parameter order) but the two are wildly divergent. MODULE Main; PROCEDURE NotConstL(a: LONGINT): LONGINT = BEGIN RETURN a; END NotConstL; BEGIN <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *> <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *> END Main. (gdb) x/200i Main_M3 0x804b03e : push %ebp 0x804b03f : mov %esp,%ebp 0x804b041 : push %ebx 0x804b042 : sub $0x14,%esp 0x804b045 : call 0x804b04a 0x804b04a : pop %ebx 0x804b04b : add $0x3a50a,%ebx 0x804b051 : mov 0x8(%ebp),%eax 0x804b054 : xor $0x1,%eax 0x804b057 : test %al,%al 0x804b059 : jne 0x804b100 0x804b05f : sub $0x8,%esp 0x804b062 : push $0x0 0x804b064 : push $0x1 0x804b066 : call 0x804b024 0x804b06b : add $0x10,%esp 0x804b06e : mov %eax,0xfffffff0(%ebp) 0x804b071 : mov %edx,0xfffffff4(%ebp) 0x804b074 : mov 0xfffffff0(%ebp),%eax 0x804b077 : mov 0xfffffff4(%ebp),%edx 0x804b07a : push $0x80000000 0x804b07f : push $0x0 0x804b081 : push %edx 0x804b082 : push %eax 0x804b0d0 : push %edx 0x804b0d1 : push %eax 0x804b0d2 : call 0x804bbd4 0x804b0d7 : add $0x10,%esp Right here this can't be correct. 64bit results are returned in the edx:eax pair, edx is high, eax low. (32bit results are turned in just eax.) It looks like m3_divL returned the correct value but whatever is happening here is trashing the results. 0x804b0da : mov %eax,%edx 0x804b0dc : sar $0x1f,%edx 0x804b0df : mov %edx,%ecx 0x804b0e1 : xor $0x7fffffff,%ecx 0x804b0e7 : xor $0xffffffff,%eax 0x804b0ea : or %ecx,%eax 0x804b0ec : test %eax,%eax 0x804b0ee : je 0x804b100 0x804b0f0 : sub $0xc,%esp 0x804b0f3 : push $0x140 0x804b0f8 : call 0x804b10b <_m3_fault> 0x804b0fd : add $0x10,%esp 0x804b100 : mov 0xfffffc74(%ebx),%eax 0x804b106 : mov 0xfffffffc(%ebp),%ebx 0x804b109 : leave 0x804b10a : ret 0x804b10b <_m3_fault>: push %ebp 0x804b10c <_m3_fault+1>: mov %esp,%ebp 0x804b10e <_m3_fault+3>: push %ebx I'll dig a bit more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 15 09:39:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 15 Feb 2010 08:39:07 +0000 Subject: [M3devel] int64 division? In-Reply-To: References: Message-ID: Should be ok now. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Mon, 15 Feb 2010 08:29:07 +0000 Subject: [M3devel] int64 division? Tony, there's something wrong with 64bit division. This program fails on LINUXLIBC6. I fixed it for NT386 (wrong parameter order) but the two are wildly divergent. MODULE Main; PROCEDURE NotConstL(a: LONGINT): LONGINT = BEGIN RETURN a; END NotConstL; BEGIN <* ASSERT FIRST(LONGINT) = (FIRST(LONGINT) DIV NotConstL(1L)) *> <* ASSERT LAST(LONGINT) = (LAST(LONGINT) DIV NotConstL(1L)) *> END Main. (gdb) x/200i Main_M3 0x804b03e : push %ebp 0x804b03f : mov %esp,%ebp 0x804b041 : push %ebx 0x804b042 : sub $0x14,%esp 0x804b045 : call 0x804b04a 0x804b04a : pop %ebx 0x804b04b : add $0x3a50a,%ebx 0x804b051 : mov 0x8(%ebp),%eax 0x804b054 : xor $0x1,%eax 0x804b057 : test %al,%al 0x804b059 : jne 0x804b100 0x804b05f : sub $0x8,%esp 0x804b062 : push $0x0 0x804b064 : push $0x1 0x804b066 : call 0x804b024 0x804b06b : add $0x10,%esp 0x804b06e : mov %eax,0xfffffff0(%ebp) 0x804b071 : mov %edx,0xfffffff4(%ebp) 0x804b074 : mov 0xfffffff0(%ebp),%eax 0x804b077 : mov 0xfffffff4(%ebp),%edx 0x804b07a : push $0x80000000 0x804b07f : push $0x0 0x804b081 : push %edx 0x804b082 : push %eax 0x804b0d0 : push %edx 0x804b0d1 : push %eax 0x804b0d2 : call 0x804bbd4 0x804b0d7 : add $0x10,%esp Right here this can't be correct. 64bit results are returned in the edx:eax pair, edx is high, eax low. (32bit results are turned in just eax.) It looks like m3_divL returned the correct value but whatever is happening here is trashing the results. 0x804b0da : mov %eax,%edx 0x804b0dc : sar $0x1f,%edx 0x804b0df : mov %edx,%ecx 0x804b0e1 : xor $0x7fffffff,%ecx 0x804b0e7 : xor $0xffffffff,%eax 0x804b0ea : or %ecx,%eax 0x804b0ec : test %eax,%eax 0x804b0ee : je 0x804b100 0x804b0f0 : sub $0xc,%esp 0x804b0f3 : push $0x140 0x804b0f8 : call 0x804b10b <_m3_fault> 0x804b0fd : add $0x10,%esp 0x804b100 : mov 0xfffffc74(%ebx),%eax 0x804b106 : mov 0xfffffffc(%ebp),%ebx 0x804b109 : leave 0x804b10a : ret 0x804b10b <_m3_fault>: push %ebp 0x804b10c <_m3_fault+1>: mov %esp,%ebp 0x804b10e <_m3_fault+3>: push %ebx I'll dig a bit more. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Feb 16 15:18:12 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 15:18:12 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com> Message-ID: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Quoting Olaf Wagner : > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > But I don't seem to be able to upgrade to the current head of the > release branch even with the upgrade script: > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > What do I miss? FYI The update to the current release branch tip of 5.8 requires an RC4 build as an intermediate step. It is not possible to update directly from older versions. This has been confirmed on FreeBSD4 and PPC_LINUX. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 16 15:37:26 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 15:37:26 +0100 Subject: [M3devel] release engineering: RC5 Message-ID: <20100216153726.168giuvpusskw444@mail.elegosoft.com> It took me some time to get the regression testing via Hudson up-to-date again, but it should be OK now. Can we rollout RC5 (which will hopefully become the final release) now? Is anybody still working on changes/fixes for the release? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Tue Feb 16 16:12:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 16 Feb 2010 16:12:52 +0100 Subject: [M3devel] m3back/longint/atomics In-Reply-To: References: Message-ID: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Quoting Jay K : > > As far as I know/can remember, longint and atomics should all work > now on NT386. > > Atomics only currently for 32bit types. > There are still a few small inefficiencies to maybe deal with. > I'll add 64bit shortly and maybe 8 and 16. > > > We should probably add *a lot* more test coverage in p226 and p227. > > e.g. longint multiply/add/sub/divide, not just insert/extract like I > did a bunch of. Any volunteers to increase the test coverage? > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > > Still maybe to do something about rd/wr...? > > Still to wonder about NT386/longint support in the release branch? Should we / will you merge this stuff to the release branch? Or should we release without it? How local are the changes? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 17 02:46:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 01:46:49 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Message-ID: > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 02:44:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 01:44:00 +0000 Subject: [M3devel] m3back/longint/atomics In-Reply-To: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Message-ID: NT386/longint changes are almost entirely in the m3back package. There is also some small easy stuff in m3-libs/m3core/src/Csupport/common/hand.c. It'd be really great if anyone could test any of this and if anyone could review the diff between release and head. Not just me. The changes for longint are quite large, even if local. I can port them, in the case of m3back, just copy, and make sure the atomics stuff doesn't cause problems (it should be unused). There is also a small change in m3front so that longint can be initialized. That affects all platforms. And a small change in m3cc/parse.c for div/mod of longint on non-NT386. I have to test mod yet but my fix probably helps it. It'd be really great if anyone could do anything with this stuff. ie. for now in head, then could easily port to release. We can of course release either way, depending on how satisfied people are with 32bit longint on NT386. i.e. longint isn't useful portably, but it is useful on non-NT386 platforms. - Jay > Date: Tue, 16 Feb 2010 16:12:52 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] m3back/longint/atomics > > Quoting Jay K : > > > > > As far as I know/can remember, longint and atomics should all work > > now on NT386. > > > > Atomics only currently for 32bit types. > > There are still a few small inefficiencies to maybe deal with. > > I'll add 64bit shortly and maybe 8 and 16. > > > > > > We should probably add *a lot* more test coverage in p226 and p227. > > > > e.g. longint multiply/add/sub/divide, not just insert/extract like I > > did a bunch of. > > Any volunteers to increase the test coverage? > > > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > > > > Still maybe to do something about rd/wr...? > > > > Still to wonder about NT386/longint support in the release branch? > > Should we / will you merge this stuff to the release branch? > Or should we release without it? How local are the changes? > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 08:54:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com> Message-ID: I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 08:56:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 07:56:35 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, Message-ID: oops looks like I deleted my fixes. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 17 09:55:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 08:55:36 +0000 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, , , Message-ID: ok should be better now, I only tested LINUXLIBC6 5.4.0 to current. I can look at and fix more later. But this is "controversial" stuff and has to end somewhere. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:56:35 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed oops looks like I deleted my fixes. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Wed, 17 Feb 2010 07:54:04 +0000 Subject: Re: [M3devel] FreeBSD4 update on releng branch failed I can build current release from LINUXLIBC6 release 5.4.0 now. Some of the fixes are applicable to PPC_LINUX. I can test it against an older release. I could probably easily make it work back to older versions and more targets. I had removed some of the workarounds, but they were fairly clean. Stuff like not using -m32 on older cm3cg, etc. You cannot build current m3core/libm3 with old cm3 or old cm3cg. I used "upgrade.py" which foists current config files on older compiler, and, you know, doesn't build m3core/libm3 until after it has a current compiler. - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Subject: RE: [M3devel] FreeBSD4 update on releng branch failed Date: Wed, 17 Feb 2010 01:46:49 +0000 > It is not possible to update directly from older versions. Maybe nice to "fix". I'll try to get to it. - Jay > Date: Tue, 16 Feb 2010 15:18:12 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > Quoting Olaf Wagner : > > > Yesterday I've finally added a Hudson slave again for the FreeBSD4 platform. > > But I don't seem to be able to upgrade to the current head of the > > release branch even with the upgrade script: > > > > http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console > > > > What do I miss? > > FYI > > The update to the current release branch tip of 5.8 requires an RC4 > build as an intermediate step. It is not possible to update directly from > older versions. > > This has been confirmed on FreeBSD4 and PPC_LINUX. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 17 11:33:37 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 17 Feb 2010 11:33:37 +0100 Subject: [M3devel] FreeBSD4 update on releng branch failed In-Reply-To: References: <20100213162526.x0yj9qzg0sowcc8k@mail.elegosoft.com>, , , <20100216151812.v40rk2hus48k84s4@mail.elegosoft.com>, , , Message-ID: <20100217113337.amzp2ojjusgw844k@mail.elegosoft.com> Quoting Jay K : > > ok should be better now, I only tested LINUXLIBC6 5.4.0 to current. > > I can look at and fix more later. > > But this is "controversial" stuff and has to end somewhere. Jay, no need to do more. I didn't mean that you should start fixing immediately; my mail was just to document the fact in the lists. Once 5.8 is out we can forget about older releases, too, I think. Olaf > > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 17 Feb 2010 07:56:35 +0000 > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > > > oops looks like I deleted my fixes. > > - Jay > > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Date: Wed, 17 Feb 2010 07:54:04 +0000 > Subject: Re: [M3devel] FreeBSD4 update on releng branch failed > > > > I can build current release from LINUXLIBC6 release 5.4.0 now. > Some of the fixes are applicable to PPC_LINUX. > I can test it against an older release. > > I could probably easily make it work back to older versions and more targets. > I had removed some of the workarounds, but they were fairly clean. > Stuff like not using -m32 on older cm3cg, etc. > > You cannot build current m3core/libm3 with old cm3 or old cm3cg. > I used "upgrade.py" which foists current config files on older > compiler, and, you know, doesn't build m3core/libm3 until after it > has a current compiler. > > - Jay > > > > From: jay.krell at cornell.edu > To: wagner at elegosoft.com; m3devel at elegosoft.com > Subject: RE: [M3devel] FreeBSD4 update on releng branch failed > Date: Wed, 17 Feb 2010 01:46:49 +0000 > > > > > It is not possible to update directly from older versions. > > Maybe nice to "fix". > I'll try to get to it. > > - Jay > > >> Date: Tue, 16 Feb 2010 15:18:12 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] FreeBSD4 update on releng branch failed >> >> Quoting Olaf Wagner : >> >> > Yesterday I've finally added a Hudson slave again for the >> FreeBSD4 platform. >> > But I don't seem to be able to upgrade to the current head of the >> > release branch even with the upgrade script: >> > >> > >> http://hudson.modula3.com:8080/view/FreeBSD4/job/cm3-build-FreeBSD4/77/console >> > >> > What do I miss? >> >> FYI >> >> The update to the current release branch tip of 5.8 requires an RC4 >> build as an intermediate step. It is not possible to update directly from >> older versions. >> >> This has been confirmed on FreeBSD4 and PPC_LINUX. >> >> Olaf >> -- >> Olaf Wagner -- elego Software Solutions GmbH >> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany >> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 >> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 >> > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 17 12:07:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 11:07:02 +0000 Subject: [M3devel] hand.c : m3_div Message-ID: Tony, presumably one of these will do: C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\tree.def /* Division for integer result that rounds the quotient toward zero. */ DEFTREECODE (TRUNC_DIV_EXPR, "trunc_div_expr", tcc_binary, 2) /* Division for integer result that rounds the quotient toward infinity. */ DEFTREECODE (CEIL_DIV_EXPR, "ceil_div_expr", tcc_binary, 2) /* Division for integer result that rounds toward minus infinity. */ DEFTREECODE (FLOOR_DIV_EXPR, "floor_div_expr", tcc_binary, 2) /* Division for integer result that rounds toward nearest integer. */ DEFTREECODE (ROUND_DIV_EXPR, "round_div_expr", tcc_binary, 2) /* Four kinds of remainder that go with the four kinds of division. */ DEFTREECODE (TRUNC_MOD_EXPR, "trunc_mod_expr", tcc_binary, 2) DEFTREECODE (CEIL_MOD_EXPR, "ceil_mod_expr", tcc_binary, 2) DEFTREECODE (FLOOR_MOD_EXPR, "floor_mod_expr", tcc_binary, 2) DEFTREECODE (ROUND_MOD_EXPR, "round_mod_expr", tcc_binary, 2) I can look into it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 17 15:52:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 17 Feb 2010 09:52:17 -0500 Subject: [M3devel] hand.c : m3_div In-Reply-To: References: Message-ID: <5C81AD48-5F6F-4741-AD07-D7D26CD1DC7B@cs.purdue.edu> Yes, I've wondered that for some time, but never been certain what code they produce.... There's no way to generate the ones we would want from C. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 17 Feb 2010, at 06:07, Jay K wrote: > Tony, presumably one of these will do: > > > C:\dev2\cm3.2\m3-sys\m3cc\gcc\gcc\tree.def > > /* Division for integer result that rounds the quotient toward zero. */ > DEFTREECODE (TRUNC_DIV_EXPR, "trunc_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds the quotient toward infinity. */ > DEFTREECODE (CEIL_DIV_EXPR, "ceil_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds toward minus infinity. */ > DEFTREECODE (FLOOR_DIV_EXPR, "floor_div_expr", tcc_binary, 2) > > /* Division for integer result that rounds toward nearest integer. */ > DEFTREECODE (ROUND_DIV_EXPR, "round_div_expr", tcc_binary, 2) > > /* Four kinds of remainder that go with the four kinds of division. */ > > DEFTREECODE (TRUNC_MOD_EXPR, "trunc_mod_expr", tcc_binary, 2) > DEFTREECODE (CEIL_MOD_EXPR, "ceil_mod_expr", tcc_binary, 2) > DEFTREECODE (FLOOR_MOD_EXPR, "floor_mod_expr", tcc_binary, 2) > DEFTREECODE (ROUND_MOD_EXPR, "round_mod_expr", tcc_binary, 2) > > > I can look into it. > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 00:47:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 17 Feb 2010 23:47:11 +0000 Subject: [M3devel] replacing hand.c with Modula-3? Message-ID: ? I have a little more reduction to do here (e.g. remove table or tables, at least the exported NT386-specific one; replace set_eq and ne with memcmp even for m3cg), but stuff will remain. It'd be nifty if Modula-3 functions/variables could be explicitly named for compat but I'll just go ahead and change the names and break compat. We break compat in other ways and it seems ok, unless people object (e.g. I removed m3_div because current backend doesn't generate calls to it, but it could/should be preserved for compat with older binaries). - Jay ________________________________ > From: jay > > > I see no great reason for hand.c to be in C. > > It should be easy to rewrite in Modula-3, using the Word interface. > > The only question really is, what to call things? > > M3_BUILTIN__set_union, etc.? > > I think I see M3_BUILTIN somewhere. > > RTHooks__set_union, etc.? > > SomethingElse__set_union? > > SomethingElse__somethingElse while we're at it? > > > > > M3Set__Union > > M3Set__Singleton -- probably not even worth being a function > > M3Set__Intersect > > etc.? > > > > > > - Jay > From hosking at cs.purdue.edu Thu Feb 18 03:03:33 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 17 Feb 2010 21:03:33 -0500 Subject: [M3devel] replacing hand.c with Modula-3? In-Reply-To: References: Message-ID: <15D830F3-ACF0-435D-B27B-BC42D2833621@cs.purdue.edu> Let's not get into the compatibility rathole. Better to stay clean w.r.to current builds. On 17 Feb 2010, at 18:47, Jay K wrote: > > ? > > > I have a little more reduction to do here (e.g. remove table or tables, at least the exported NT386-specific one; replace set_eq and ne with memcmp even for m3cg), but stuff will remain. > > > It'd be nifty if Modula-3 functions/variables could be explicitly named for compat but I'll just go ahead and change the names and break compat. We break compat in other ways and it seems ok, unless people object (e.g. I removed m3_div because current backend doesn't generate calls to it, but it could/should be preserved for compat with older binaries). > > > > - Jay > > ________________________________ >> From: jay >> >> >> I see no great reason for hand.c to be in C. >> >> It should be easy to rewrite in Modula-3, using the Word interface. >> >> The only question really is, what to call things? >> >> M3_BUILTIN__set_union, etc.? >> >> I think I see M3_BUILTIN somewhere. >> >> RTHooks__set_union, etc.? >> >> SomethingElse__set_union? >> >> SomethingElse__somethingElse while we're at it? >> >> >> >> >> M3Set__Union >> >> M3Set__Singleton -- probably not even worth being a function >> >> M3Set__Intersect >> >> etc.? >> >> >> >> >> >> - Jay >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 18 11:45:58 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 11:45:58 +0100 Subject: [M3devel] Auto-discard notification In-Reply-To: References: Message-ID: <20100218114558.rn033djp4wgs0wsg@mail.elegosoft.com> You need to subscribe to the list to be able to post to it. However, I can quickly answer some of your questions: o You need to use the script upgrade.sh or upgrade.py to perform a full core system upgrade from source. This bootstraps the compiler and runtime libraries using an existing compiler and installs everything it has built. "install-cm3-compiler.sh upgrade" will just install a compiler from your workspace. o Failures in the packages odbc, postgres95, and db are most likely due to missing libraries on your system. Just install the needed third party packages for this software with the appropriate tools for your system (e.g. pkg_add, apt-get, ...) and adapt the library paths in the cm3 config files if they still aren't found. Have a look at /usr/local/cm3/bin/cm3.cfg and its includes. o If the packages are missing, that should not be a problem, too, as long as you don't need their functionality. Hope this helps, Olaf Quoting m3devel-bounces at elegosoft.com: > The attached message has been automatically discarded. My CM3 build was getting pretty old, so I decided to re-install from scratch, and came across a number of problems whose solution wasn't obvious. Could someone please confirm that I got the answers right? (This was on a current x86 Linux box.) I installed from the cm3-bin-core tarfile, which gave me a basic m3 compiler and linker. I then tried installing from the cm3-src-all tarfile, with the command: install-cm3-compiler.sh upgrade since I wanted to force a compiler upgrade for various reasons. Should I have used do-cm3-core.sh buildship as well? Could I have used do-cm3-core.sh instead, if I didn't want to rebuild the compiler? I then tried: do-cm3-std.sh buildship which failed on the packages odbc, postgres95, and db (smalldb built correctly). This is where I ran into real problems, since I couldn't find any documentation on the packages to be built, or a way of restarting a failed build. I finally decided that pkginfo.txt was the one, and edited it. Re-running do-cm3-std then got me a working system. Was this the right approach, and does the pkginfo.txt format allow for commenting out lines (I just deleted the successful packages), and if so what is the comment symbol (; ? # ?). Is there an easier way to restart a failed build? Is any of this documented anywhere? -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 18 12:26:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 11:26:19 +0000 Subject: [M3devel] other users of TInt Message-ID: I'll get to this soon... == package C:\dev2\cm3.2\m3-sys\m3tools == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling M3Lexer.i3 new source -> compiling M3Lexer.m3 "..\src\M3Lexer.m3", line 123: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 123: incompatible types (i) "..\src\M3Lexer.m3", line 126: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 126: incompatible types (i) "..\src\M3Lexer.m3", line 130: too many actual parameters: TWord.New "..\src\M3Lexer.m3", line 130: incompatible types (i) 6 errors encountered new source -> compiling M3AST.i3 new source -> compiling M3AST.m3 new source -> compiling M3Parse.m3 new source -> compiling M3Scope.i3 new source -> compiling M3Scope.m3 new source -> compiling M3Type.i3 new source -> compiling M3Type.m3 "..\src\M3Type.m3", line 48: unknown qualification '.' (x) "..\src\M3Type.m3", line 48: not enough values specified "..\src\M3Type.m3", line 251: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 251: incompatible types (i) "..\src\M3Type.m3", line 292: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 292: incompatible types (i) 6 errors encountered new source -> compiling M3Const.i3 new source -> compiling M3Builtin.i3 new source -> compiling M3ArrVal.i3 new source -> compiling M3RecVal.i3 new source -> compiling M3SetVal.i3 new source -> compiling M3Const.m3 "..\src\M3Const.m3", line 865: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 865: incompatible types (i) "..\src\M3Const.m3", line 1164: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1164: incompatible types (i) "..\src\M3Const.m3", line 1174: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1174: incompatible types (i) 6 errors encountered new source -> compiling M3SetVal.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Feb 18 12:57:34 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 12:57:34 +0100 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> Message-ID: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> If I understand Jay correctly, it wouldn't be too difficult to bring the m3ack LONGINT changes for Windows into the release branch, but more testing would be needed. Randy, you're the only one I remember offhand who actively uses M3 on Windows except for Jay. Could you have a closer look at it? (Changes are only on the trunk right now.) Or is anybody else here lurking and eager to do some Windows-based tests? If nobody volunteers, I'm afraid we will have to release without 64bit LONGINT on Windows. Olaf Quoting Jay K : > NT386/longint changes are almost entirely in the m3back package. > > There is also some small easy stuff in > m3-libs/m3core/src/Csupport/common/hand.c. > > It'd be really great if anyone could test any of this and if > anyone could review the diff between release and head. > > Not just me. > > The changes for longint are quite large, even if local. > > I can port them, in the case of m3back, just copy, and make sure > the atomics stuff doesn't cause problems (it should be unused). > > There is also a small change in m3front so that longint can be initialized. > That affects all platforms. > > And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > I have to test mod yet but my fix probably helps it. > > It'd be really great if anyone could do anything with this stuff. > ie. for now in head, then could easily port to release. > > We can of course release either way, depending on how satisfied people > are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > is useful on non-NT386 platforms. > > - Jay > >> Date: Tue, 16 Feb 2010 16:12:52 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3back/longint/atomics >> >> Quoting Jay K : >> >> > >> > As far as I know/can remember, longint and atomics should all work >> > now on NT386. >> > >> > Atomics only currently for 32bit types. >> > There are still a few small inefficiencies to maybe deal with. >> > I'll add 64bit shortly and maybe 8 and 16. >> > >> > >> > We should probably add *a lot* more test coverage in p226 and p227. >> > >> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >> > did a bunch of. >> >> Any volunteers to increase the test coverage? >> >> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >> > >> > Still maybe to do something about rd/wr...? >> > >> > Still to wonder about NT386/longint support in the release branch? >> >> Should we / will you merge this stuff to the release branch? >> Or should we release without it? How local are the changes? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hendrik at topoi.pooq.com Thu Feb 18 12:51:17 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 18 Feb 2010 06:51:17 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> Message-ID: <20100218115116.GA2336@topoi.pooq.com> On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. I'm somewhat interested in getting my programs working on Windows, but I haven't yet installed *anything* on the pristine XP on my netbook. I'm hesitant about connecting it to the net; the only antivirus I have is refraining from using Windows, and it works fairly well(!). As far as I know, I have no way of reinstalling Windows if my Windows is damaged. I/m mostly interested in getting my software into a state where Windows nonprogrammers can use it; I use Linux myself. What would I need to do (from scratch; I'm not a Windows user; I just happened not to delete Windows when I installed Linux)? The machine is A 32-bit intel, and so it just might not be relevant to testing 64-bit LONGINT. -- hendrik From jay.krell at cornell.edu Thu Feb 18 15:11:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:11:33 +0000 Subject: [M3devel] other users of TInt In-Reply-To: References: Message-ID: Sorry, it looks like I was out of sync. Still something wierd to track down.. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Date: Thu, 18 Feb 2010 11:26:19 +0000 Subject: [M3devel] other users of TInt I'll get to this soon... == package C:\dev2\cm3.2\m3-sys\m3tools == +++ C:\cm3\bin\cm3.exe -build -DROOT=C:/dev2/cm3.2 -DCM3_VERSION_TEXT=d5.8.2 -DCM3_VERSION_NUMBER=050802 -DCM3_LAST_CHANGED=2009-07-15 +++ --- building in NT386 --- ignoring ..\src\m3overrides new source -> compiling M3Lexer.i3 new source -> compiling M3Lexer.m3 "..\src\M3Lexer.m3", line 123: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 123: incompatible types (i) "..\src\M3Lexer.m3", line 126: too many actual parameters: TInt.New "..\src\M3Lexer.m3", line 126: incompatible types (i) "..\src\M3Lexer.m3", line 130: too many actual parameters: TWord.New "..\src\M3Lexer.m3", line 130: incompatible types (i) 6 errors encountered new source -> compiling M3AST.i3 new source -> compiling M3AST.m3 new source -> compiling M3Parse.m3 new source -> compiling M3Scope.i3 new source -> compiling M3Scope.m3 new source -> compiling M3Type.i3 new source -> compiling M3Type.m3 "..\src\M3Type.m3", line 48: unknown qualification '.' (x) "..\src\M3Type.m3", line 48: not enough values specified "..\src\M3Type.m3", line 251: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 251: incompatible types (i) "..\src\M3Type.m3", line 292: too many actual parameters: TInt.FromInt "..\src\M3Type.m3", line 292: incompatible types (i) 6 errors encountered new source -> compiling M3Const.i3 new source -> compiling M3Builtin.i3 new source -> compiling M3ArrVal.i3 new source -> compiling M3RecVal.i3 new source -> compiling M3SetVal.i3 new source -> compiling M3Const.m3 "..\src\M3Const.m3", line 865: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 865: incompatible types (i) "..\src\M3Const.m3", line 1164: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1164: incompatible types (i) "..\src\M3Const.m3", line 1174: too many actual parameters: TInt.FromInt "..\src\M3Const.m3", line 1174: incompatible types (i) 6 errors encountered new source -> compiling M3SetVal.m3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 15:14:01 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:14:01 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218115116.GA2336@topoi.pooq.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com>, , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <20100218115116.GA2336@topoi.pooq.com> Message-ID: Henrik, if you won't install anything, then you can't test anything. Modula-3 is not going to break your XP install. Nor is Visual C++. > machine is A 32-bit intel, and so it just might not be relevant to > testing 64-bit LONGINT. False! LONGINT is 64bits on all platforms. We have no 64bit Windows target currently. - Jay > Date: Thu, 18 Feb 2010 06:51:17 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > > If I understand Jay correctly, it wouldn't be too difficult to bring > > the m3ack LONGINT changes for Windows into the release branch, but > > more testing would be needed. > > > > Randy, you're the only one I remember offhand who actively uses M3 > > on Windows except for Jay. Could you have a closer look at it? > > (Changes are only on the trunk right now.) > > > > Or is anybody else here lurking and eager to do some Windows-based tests? > > > > If nobody volunteers, I'm afraid we will have to release without 64bit > > LONGINT on Windows. > > I'm somewhat interested in getting my programs working on Windows, but I > haven't yet installed *anything* on the pristine XP on my netbook. I'm > hesitant about connecting it to the net; the only antivirus I have is > refraining from using Windows, and it works fairly well(!). As far as I > know, I have no way of reinstalling Windows if my Windows is damaged. > > I/m mostly interested in getting my software into a state where Windows > nonprogrammers can use it; I use Linux myself. > > What would I need to do (from scratch; I'm not a Windows user; I just > happened not to delete Windows when I installed Linux)? The > machine is A 32-bit intel, and so it just might not be relevant to > testing 64-bit LONGINT. > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Feb 18 15:21:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 14:21:37 +0000 Subject: [M3devel] other users of TInt In-Reply-To: References: , Message-ID: > Still something wierd to track down.. typo in test case, oops -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Feb 18 15:26:43 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 18 Feb 2010 09:26:43 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> Message-ID: <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> I can certainly run some tests on Windows. I don't have any code that uses longint, so either someone needs to identify which existing programs I can build and run to do the tests, OR I suppose I can write something if you can give me an idea of how extensive the tests you want. I've been trying to keep my system updated to the latest sources on the main trunk, but I've been swamped lately and I'm afraid I'm a few weeks stale right now. I'll remedy that shortly. Regards, Randy ________________________________ From: Olaf Wagner [wagner at elegosoft.com] Sent: Thursday, February 18, 2010 6:57 AM To: Jay K Cc: m3devel Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics If I understand Jay correctly, it wouldn't be too difficult to bring the m3ack LONGINT changes for Windows into the release branch, but more testing would be needed. Randy, you're the only one I remember offhand who actively uses M3 on Windows except for Jay. Could you have a closer look at it? (Changes are only on the trunk right now.) Or is anybody else here lurking and eager to do some Windows-based tests? If nobody volunteers, I'm afraid we will have to release without 64bit LONGINT on Windows. Olaf Quoting Jay K : > NT386/longint changes are almost entirely in the m3back package. > > There is also some small easy stuff in > m3-libs/m3core/src/Csupport/common/hand.c. > > It'd be really great if anyone could test any of this and if > anyone could review the diff between release and head. > > Not just me. > > The changes for longint are quite large, even if local. > > I can port them, in the case of m3back, just copy, and make sure > the atomics stuff doesn't cause problems (it should be unused). > > There is also a small change in m3front so that longint can be initialized. > That affects all platforms. > > And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > I have to test mod yet but my fix probably helps it. > > It'd be really great if anyone could do anything with this stuff. > ie. for now in head, then could easily port to release. > > We can of course release either way, depending on how satisfied people > are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > is useful on non-NT386 platforms. > > - Jay > >> Date: Tue, 16 Feb 2010 16:12:52 +0100 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] m3back/longint/atomics >> >> Quoting Jay K : >> >> > >> > As far as I know/can remember, longint and atomics should all work >> > now on NT386. >> > >> > Atomics only currently for 32bit types. >> > There are still a few small inefficiencies to maybe deal with. >> > I'll add 64bit shortly and maybe 8 and 16. >> > >> > >> > We should probably add *a lot* more test coverage in p226 and p227. >> > >> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >> > did a bunch of. >> >> Any volunteers to increase the test coverage? >> >> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >> > >> > Still maybe to do something about rd/wr...? >> > >> > Still to wonder about NT386/longint support in the release branch? >> >> Should we / will you merge this stuff to the release branch? >> Or should we release without it? How local are the changes? >> >> Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Feb 18 15:40:05 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 18 Feb 2010 09:40:05 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218115116.GA2336@topoi.pooq.com> References: <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <20100218115116.GA2336@topoi.pooq.com> Message-ID: <357B777B-B964-418C-98A8-83AF9F6DB54F@mimectl> Hendrik: You can get a FREE antivirus for Windows from several sources. Microsoft has one, but I use AVG. Here is a link to the AVG download: http://download.cnet.com/AVG-Anti-Virus-Free-Edition/3000-2239_4-10320142.html?part=dl-10044820&subj=dl&tag=button&cdlPid=11014801 I don't think installing CM3 will "damage" your system. You will need some sort of C compiler/linker though because there is some C code that gets compiled and cm3 doesn't come with its own linker. I use the FREE Microsoft Visual Studio C++ 2008 Express Edition. Here is a link to the download: http://www.microsoft.com/express/downloads/#2008-Visual-CPP I have some scripts in cm3/scripts/dev/windows that may be useful to you on Windows. If you just want to get a working cm3 on your windows system, I could build you a minimal (or a full) distribution and ZIP it up and send to you. Then you would just unzip to a folder, say C:\cm3. There is nothing to "install" here that can mess up your registry. You will still need the Visual C++ Express to get the Microsoft Linker if you want to build any new programs. Regards, Randy ________________________________ From: hendrik at topoi.pooq.com [hendrik at topoi.pooq.com] Sent: Thursday, February 18, 2010 6:51 AM To: m3devel at elegosoft.com Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics On Thu, Feb 18, 2010 at 12:57:34PM +0100, Olaf Wagner wrote: > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. I'm somewhat interested in getting my programs working on Windows, but I haven't yet installed *anything* on the pristine XP on my netbook. I'm hesitant about connecting it to the net; the only antivirus I have is refraining from using Windows, and it works fairly well(!). As far as I know, I have no way of reinstalling Windows if my Windows is damaged. I/m mostly interested in getting my software into a state where Windows nonprogrammers can use it; I use Linux myself. What would I need to do (from scratch; I'm not a Windows user; I just happened not to delete Windows when I installed Linux)? The machine is A 32-bit intel, and so it just might not be relevant to testing 64-bit LONGINT. -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Feb 18 15:34:02 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 18 Feb 2010 09:34:02 -0500 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: References: <20100218115116.GA2336@topoi.pooq.com> Message-ID: <20100218143402.GA12076@topoi.pooq.com> On Thu, Feb 18, 2010 at 02:14:01PM +0000, Jay K wrote: > > Henrik, if you won't install anything, then you can't test anything. > > Modula-3 is not going to break your XP install. > > Nor is Visual C++. I'm not afraid of Modula 3 or Visual C++. I'm worried about the stuff I might encounter while wanfering the net wondering what it is I have to do. Randy's reply will probably get me started. > > > > > machine is A 32-bit intel, and so it just might not be relevant to > > testing 64-bit LONGINT. > > > False! > > LONGINT is 64bits on all platforms. > > We have no 64bit Windows target currently. Ah. I've heard of a 64-bit Windows. Evidently not relevant to us now. -- hendrik From wagner at elegosoft.com Thu Feb 18 17:20:56 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 18 Feb 2010 17:20:56 +0100 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> References: , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com> , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com> <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl> Message-ID: <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> Quoting "Coleburn, Randy" : > I can certainly run some tests on Windows. > > I don't have any code that uses longint, so either someone needs to > identify which existing programs I can build and run to do the > tests, OR I suppose I can write something if you can give me an idea > of how extensive the tests you want. This sounds good! Some things that come to mind for LONGINT immeditately: o standard integer arithmetic (+, -, *, DIV, MOD) at runtime, with and without overflows etc. o constant declarations o constant expressions o assignability (should be rather strict; I'd have to check the mail archive for the details) o pickles It would be great if you could add some tests to m3tests that are valid on all platforms. I expect that some should already be in place, but haven't checked yet... Hm, a quick search for longint in http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ for example doesn't find anything. Has nobody added any LONGINT test yet? Probably I'm looking for the wrong string... A complete regression with cm3 and other programs you may have available would be great, too, just to make sure that the backend changes don't break any old functionality. Olaf > > I've been trying to keep my system updated to the latest sources on > the main trunk, but I've been swamped lately and I'm afraid I'm a > few weeks stale right now. I'll remedy that shortly. > > Regards, > Randy > > ________________________________ > From: Olaf Wagner [wagner at elegosoft.com] > Sent: Thursday, February 18, 2010 6:57 AM > To: Jay K > Cc: m3devel > Subject: [M3devel] More testing needed for m3back, was: RE: > m3back/longint/atomics > > If I understand Jay correctly, it wouldn't be too difficult to bring > the m3ack LONGINT changes for Windows into the release branch, but > more testing would be needed. > > Randy, you're the only one I remember offhand who actively uses M3 > on Windows except for Jay. Could you have a closer look at it? > (Changes are only on the trunk right now.) > > Or is anybody else here lurking and eager to do some Windows-based tests? > > If nobody volunteers, I'm afraid we will have to release without 64bit > LONGINT on Windows. > > Olaf > > Quoting Jay K : > >> NT386/longint changes are almost entirely in the m3back package. >> >> There is also some small easy stuff in >> m3-libs/m3core/src/Csupport/common/hand.c. >> >> It'd be really great if anyone could test any of this and if >> anyone could review the diff between release and head. >> >> Not just me. >> >> The changes for longint are quite large, even if local. >> >> I can port them, in the case of m3back, just copy, and make sure >> the atomics stuff doesn't cause problems (it should be unused). >> >> There is also a small change in m3front so that longint can be initialized. >> That affects all platforms. >> >> And a small change in m3cc/parse.c for div/mod of longint on non-NT386. >> I have to test mod yet but my fix probably helps it. >> >> It'd be really great if anyone could do anything with this stuff. >> ie. for now in head, then could easily port to release. >> >> We can of course release either way, depending on how satisfied people >> are with 32bit longint on NT386. i.e. longint isn't useful portably, but it >> is useful on non-NT386 platforms. >> >> - Jay >> >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] m3back/longint/atomics >>> >>> Quoting Jay K : >>> >>> > >>> > As far as I know/can remember, longint and atomics should all work >>> > now on NT386. >>> > >>> > Atomics only currently for 32bit types. >>> > There are still a few small inefficiencies to maybe deal with. >>> > I'll add 64bit shortly and maybe 8 and 16. >>> > >>> > >>> > We should probably add *a lot* more test coverage in p226 and p227. >>> > >>> > e.g. longint multiply/add/sub/divide, not just insert/extract like I >>> > did a bunch of. >>> >>> Any volunteers to increase the test coverage? >>> >>> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. >>> > >>> > Still maybe to do something about rd/wr...? >>> > >>> > Still to wonder about NT386/longint support in the release branch? >>> >>> Should we / will you merge this stuff to the release branch? >>> Or should we release without it? How local are the changes? >>> >>> Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Feb 18 22:26:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 18 Feb 2010 21:26:19 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> References: , , <20100216161252.wwycpn1ao8gw4c0k@mail.elegosoft.com>, , , <20100218125734.6p8p8x1m4gcgkgko@mail.elegosoft.com>, <65D59F71-BF5D-467D-8B6A-6599BE3D7EE0@mimectl>, <20100218172056.0ot3l6vmogwwoc08@mail.elegosoft.com> Message-ID: I added some testing, found/fixed bugs in the gcc backend (initializing constants, division). They should be in the automated tests already. However don't let this stop you from doing everything/anything you can think of. I didn't do all that much and you can save time and get more done by not worrying about the duplication. Pickles I didn't do anything with at all, so if you really want to avoid/delay duplication, start with them. - Jay > Date: Thu, 18 Feb 2010 17:20:56 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Quoting "Coleburn, Randy" : > > > I can certainly run some tests on Windows. > > > > I don't have any code that uses longint, so either someone needs to > > identify which existing programs I can build and run to do the > > tests, OR I suppose I can write something if you can give me an idea > > of how extensive the tests you want. > > This sounds good! > > Some things that come to mind for LONGINT immeditately: > > o standard integer arithmetic (+, -, *, DIV, MOD) at runtime, > with and without overflows etc. > o constant declarations > o constant expressions > o assignability (should be rather strict; I'd have to check the mail > archive for the details) > o pickles > > It would be great if you could add some tests to m3tests that are > valid on all platforms. I expect that some should already be in place, > but haven't checked yet... > > Hm, a quick search for longint in > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > for example doesn't find anything. Has nobody added any LONGINT > test yet? Probably I'm looking for the wrong string... > > A complete regression with cm3 and other programs you may have available > would be great, too, just to make sure that the backend changes > don't break any old functionality. > > Olaf > > > > > I've been trying to keep my system updated to the latest sources on > > the main trunk, but I've been swamped lately and I'm afraid I'm a > > few weeks stale right now. I'll remedy that shortly. > > > > Regards, > > Randy > > > > ________________________________ > > From: Olaf Wagner [wagner at elegosoft.com] > > Sent: Thursday, February 18, 2010 6:57 AM > > To: Jay K > > Cc: m3devel > > Subject: [M3devel] More testing needed for m3back, was: RE: > > m3back/longint/atomics > > > > If I understand Jay correctly, it wouldn't be too difficult to bring > > the m3ack LONGINT changes for Windows into the release branch, but > > more testing would be needed. > > > > Randy, you're the only one I remember offhand who actively uses M3 > > on Windows except for Jay. Could you have a closer look at it? > > (Changes are only on the trunk right now.) > > > > Or is anybody else here lurking and eager to do some Windows-based tests? > > > > If nobody volunteers, I'm afraid we will have to release without 64bit > > LONGINT on Windows. > > > > Olaf > > > > Quoting Jay K : > > > >> NT386/longint changes are almost entirely in the m3back package. > >> > >> There is also some small easy stuff in > >> m3-libs/m3core/src/Csupport/common/hand.c. > >> > >> It'd be really great if anyone could test any of this and if > >> anyone could review the diff between release and head. > >> > >> Not just me. > >> > >> The changes for longint are quite large, even if local. > >> > >> I can port them, in the case of m3back, just copy, and make sure > >> the atomics stuff doesn't cause problems (it should be unused). > >> > >> There is also a small change in m3front so that longint can be initialized. > >> That affects all platforms. > >> > >> And a small change in m3cc/parse.c for div/mod of longint on non-NT386. > >> I have to test mod yet but my fix probably helps it. > >> > >> It'd be really great if anyone could do anything with this stuff. > >> ie. for now in head, then could easily port to release. > >> > >> We can of course release either way, depending on how satisfied people > >> are with 32bit longint on NT386. i.e. longint isn't useful portably, but it > >> is useful on non-NT386 platforms. > >> > >> - Jay > >> > >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] m3back/longint/atomics > >>> > >>> Quoting Jay K : > >>> > >>> > > >>> > As far as I know/can remember, longint and atomics should all work > >>> > now on NT386. > >>> > > >>> > Atomics only currently for 32bit types. > >>> > There are still a few small inefficiencies to maybe deal with. > >>> > I'll add 64bit shortly and maybe 8 and 16. > >>> > > >>> > > >>> > We should probably add *a lot* more test coverage in p226 and p227. > >>> > > >>> > e.g. longint multiply/add/sub/divide, not just insert/extract like I > >>> > did a bunch of. > >>> > >>> Any volunteers to increase the test coverage? > >>> > >>> > Still to fix the Win32 m3core/libm3 to not always truncate file sizes. > >>> > > >>> > Still maybe to do something about rd/wr...? > >>> > > >>> > Still to wonder about NT386/longint support in the release branch? > >>> > >>> Should we / will you merge this stuff to the release branch? > >>> Or should we release without it? How local are the changes? > >>> > >>> Olaf > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > > > > > > > > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Fri Feb 19 04:07:36 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 03:07:36 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <683477.25152.qm@web23602.mail.ird.yahoo.com> Hi all: great news to hear about a release coming soon, but how about testing NT386GNU or derivatives of it, would be hard to set up (I might try a friend's machine). As I understood that was a great port to new Modula-3 programmers coming into the M3 world from win world. This doesn't have the all packages but is this a must to give have a check to release this port? Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 ? Is there any chance to bring those platforms in final release? Any difficulties to start trying that? Thanks in advance --- El jue, 18/2/10, Jay K escribi?: > De: Jay K > Asunto: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Olaf" , "m3devel" > Fecha: jueves, 18 de febrero, 2010 16:26 > > > > > > I added some testing, found/fixed bugs in the gcc > backend (initializing constants, division). > > They should be in the automated tests already. > > However don't let this stop you from doing > everything/anything you can think of. > > I didn't do all that much and you can save time and get > more done by not worrying > > about the duplication. > > Pickles I didn't do anything with at all, so if you > really want to avoid/delay duplication, > > start with them. > > > > - Jay > > > > Date: Thu, 18 Feb 2010 17:20:56 +0100 > > From: wagner at elegosoft.com > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > > > Quoting "Coleburn, Randy" > : > > > > > I can certainly run some tests on Windows. > > > > > > I don't have any code that uses longint, so > either someone needs to > > > identify which existing programs I can build and > run to do the > > > tests, OR I suppose I can write something if you > can give me an idea > > > of how extensive the tests you want. > > > > This sounds good! > > > > Some things that come to mind for LONGINT > immeditately: > > > > o standard integer arithmetic (+, -, *, DIV, MOD) at > runtime, > > with and without overflows etc. > > o constant declarations > > o constant expressions > > o assignability (should be rather strict; I'd have > to check the mail > > archive for the details) > > o pickles > > > > It would be great if you could add some tests to > m3tests that are > > valid on all platforms. I expect that some should > already be in place, > > but haven't checked yet... > > > > Hm, a quick search for longint in > > > > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > > for example doesn't find anything. Has nobody > added any LONGINT > > test yet? Probably I'm looking for the wrong > string... > > > > A complete regression with cm3 and other programs you > may have available > > would be great, too, just to make sure that the > backend changes > > don't break any old functionality. > > > > Olaf > > > > > > > > I've been trying to keep my system updated to > the latest sources on > > > the main trunk, but I've been swamped lately > and I'm afraid I'm a > > > few weeks stale right now. I'll remedy that > shortly. > > > > > > Regards, > > > Randy > > > > > > ________________________________ > > > From: Olaf Wagner [wagner at elegosoft.com] > > > Sent: Thursday, February 18, 2010 6:57 AM > > > To: Jay K > > > Cc: m3devel > > > Subject: [M3devel] More testing needed for > m3back, was: RE: > > > m3back/longint/atomics > > > > > > If I understand Jay correctly, it wouldn't be > too difficult to bring > > > the m3ack LONGINT changes for Windows into the > release branch, but > > > more testing would be needed. > > > > > > Randy, you're the only one I remember offhand > who actively uses M3 > > > on Windows except for Jay. Could you have a > closer look at it? > > > (Changes are only on the trunk right now.) > > > > > > Or is anybody else here lurking and eager to do > some Windows-based tests? > > > > > > If nobody volunteers, I'm afraid we will have > to release without 64bit > > > LONGINT on Windows. > > > > > > Olaf > > > > > > Quoting Jay K : > > > > > >> NT386/longint changes are almost entirely in > the m3back package. > > >> > > >> There is also some small easy stuff in > > >> m3-libs/m3core/src/Csupport/common/hand.c. > > >> > > >> It'd be really great if anyone could test > any of this and if > > >> anyone could review the diff between release > and head. > > >> > > >> Not just me. > > >> > > >> The changes for longint are quite large, even > if local. > > >> > > >> I can port them, in the case of m3back, just > copy, and make sure > > >> the atomics stuff doesn't cause problems > (it should be unused). > > >> > > >> There is also a small change in m3front so > that longint can be initialized. > > >> That affects all platforms. > > >> > > >> And a small change in m3cc/parse.c for > div/mod of longint on non-NT386. > > >> I have to test mod yet but my fix probably > helps it. > > >> > > >> It'd be really great if anyone could do > anything with this stuff. > > >> ie. for now in head, then could easily port > to release. > > >> > > >> We can of course release either way, > depending on how satisfied people > > >> are with 32bit longint on NT386. i.e. longint > isn't useful portably, but it > > >> is useful on non-NT386 platforms. > > >> > > >> - Jay > > >> > > >>> Date: Tue, 16 Feb 2010 16:12:52 +0100 > > >>> From: wagner at elegosoft.com > > >>> To: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] > m3back/longint/atomics > > >>> > > >>> Quoting Jay K > : > > >>> > > >>> > > > >>> > As far as I know/can remember, > longint and atomics should all work > > >>> > now on NT386. > > >>> > > > >>> > Atomics only currently for 32bit > types. > > >>> > There are still a few small > inefficiencies to maybe deal with. > > >>> > I'll add 64bit shortly and maybe > 8 and 16. > > >>> > > > >>> > > > >>> > We should probably add *a lot* more > test coverage in p226 and p227. > > >>> > > > >>> > e.g. longint > multiply/add/sub/divide, not just insert/extract like I > > >>> > did a bunch of. > > >>> > > >>> Any volunteers to increase the test > coverage? > > >>> > > >>> > Still to fix the Win32 m3core/libm3 > to not always truncate file sizes. > > >>> > > > >>> > Still maybe to do something about > rd/wr...? > > >>> > > > >>> > Still to wonder about NT386/longint > support in the release branch? > > >>> > > >>> Should we / will you merge this stuff to > the release branch? > > >>> Or should we release without it? How > local are the changes? > > >>> > > >>> Olaf > > > -- > > > Olaf Wagner -- elego Software Solutions GmbH > > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > Berlin, Germany > > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 fax: +49 30 23 45 86 95 > > > > http://www.elegosoft.com | > > > > Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > > > Handelregister: Amtsgericht Charlottenburg HRB > 77719 | USt-IdNr: DE163214194 > > > > > > > > > > > > > > -- > > Olaf Wagner -- elego Software Solutions GmbH > > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, > Germany > > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 > fax: +49 30 23 45 86 95 > > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf > Wagner | Sitz: Berlin > > Handelregister: Amtsgericht Charlottenburg HRB 77719 | > USt-IdNr: DE163214194 > > > > From jay.krell at cornell.edu Fri Feb 19 05:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 04:54:03 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <683477.25152.qm@web23602.mail.ird.yahoo.com> References: , <683477.25152.qm@web23602.mail.ird.yahoo.com> Message-ID: https://projects.elego.de/cm3/ticket/1080 can you provide the cvsup configuration file? Thanks. Can you try building with user threads and see if it occurs? Or on another platform? This is definitely something we want to look into. NT386GNU is there and worked for me, but it is slow. It had 64bit longint way ahead of NT386, but NT386 is there now. There is also NT386MINGNU. More testing definitely appreciated. Thanks, - Jay ---------------------------------------- > Date: Fri, 19 Feb 2010 03:07:36 +0000 > From: dabenavidesd at yahoo.es > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > > Hi all: > great news to hear about a release coming soon, but how about testing NT386GNU or derivatives of it, would be hard to set up (I might try a friend's machine). > As I understood that was a great port to new Modula-3 programmers coming into the M3 world from win world. This doesn't have the all packages but is this a must to give have a check to release this port? > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 ? > Is there any chance to bring those platforms in final release? > Any difficulties to start trying that? > Thanks in advance > > --- El jue, 18/2/10, Jay K escribi?: > >> De: Jay K >> Asunto: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics >> Para: "Olaf" , "m3devel" >> Fecha: jueves, 18 de febrero, 2010 16:26 >> >> >> >> >> >> I added some testing, found/fixed bugs in the gcc >> backend (initializing constants, division). >> >> They should be in the automated tests already. >> >> However don't let this stop you from doing >> everything/anything you can think of. >> >> I didn't do all that much and you can save time and get >> more done by not worrying >> >> about the duplication. >> >> Pickles I didn't do anything with at all, so if you >> really want to avoid/delay duplication, >> >> start with them. >> >> >> >> - Jay >> >> >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 >>> From: wagner at elegosoft.com >>> To: m3devel at elegosoft.com >>> Subject: Re: [M3devel] More testing needed for m3back, >> was: RE: m3back/longint/atomics >>> >>> Quoting "Coleburn, Randy" >> : >>> >>>> I can certainly run some tests on Windows. >>>> >>>> I don't have any code that uses longint, so >> either someone needs to >>>> identify which existing programs I can build and >> run to do the >>>> tests, OR I suppose I can write something if you >> can give me an idea >>>> of how extensive the tests you want. >>> >>> This sounds good! >>> >>> Some things that come to mind for LONGINT >> immeditately: >>> >>> o standard integer arithmetic (+, -, *, DIV, MOD) at >> runtime, >>> with and without overflows etc. >>> o constant declarations >>> o constant expressions >>> o assignability (should be rather strict; I'd have >> to check the mail >>> archive for the details) >>> o pickles >>> >>> It would be great if you could add some tests to >> m3tests that are >>> valid on all platforms. I expect that some should >> already be in place, >>> but haven't checked yet... >>> >>> Hm, a quick search for longint in >>> >>> >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ >>> >>> for example doesn't find anything. Has nobody >> added any LONGINT >>> test yet? Probably I'm looking for the wrong >> string... >>> >>> A complete regression with cm3 and other programs you >> may have available >>> would be great, too, just to make sure that the >> backend changes >>> don't break any old functionality. >>> >>> Olaf >>> >>>> >>>> I've been trying to keep my system updated to >> the latest sources on >>>> the main trunk, but I've been swamped lately >> and I'm afraid I'm a >>>> few weeks stale right now. I'll remedy that >> shortly. >>>> >>>> Regards, >>>> Randy >>>> >>>> ________________________________ >>>> From: Olaf Wagner [wagner at elegosoft.com] >>>> Sent: Thursday, February 18, 2010 6:57 AM >>>> To: Jay K >>>> Cc: m3devel >>>> Subject: [M3devel] More testing needed for >> m3back, was: RE: >>>> m3back/longint/atomics >>>> >>>> If I understand Jay correctly, it wouldn't be >> too difficult to bring >>>> the m3ack LONGINT changes for Windows into the >> release branch, but >>>> more testing would be needed. >>>> >>>> Randy, you're the only one I remember offhand >> who actively uses M3 >>>> on Windows except for Jay. Could you have a >> closer look at it? >>>> (Changes are only on the trunk right now.) >>>> >>>> Or is anybody else here lurking and eager to do >> some Windows-based tests? >>>> >>>> If nobody volunteers, I'm afraid we will have >> to release without 64bit >>>> LONGINT on Windows. >>>> >>>> Olaf >>>> >>>> Quoting Jay K : >>>> >>>>> NT386/longint changes are almost entirely in >> the m3back package. >>>>> >>>>> There is also some small easy stuff in >>>>> m3-libs/m3core/src/Csupport/common/hand.c. >>>>> >>>>> It'd be really great if anyone could test >> any of this and if >>>>> anyone could review the diff between release >> and head. >>>>> >>>>> Not just me. >>>>> >>>>> The changes for longint are quite large, even >> if local. >>>>> >>>>> I can port them, in the case of m3back, just >> copy, and make sure >>>>> the atomics stuff doesn't cause problems >> (it should be unused). >>>>> >>>>> There is also a small change in m3front so >> that longint can be initialized. >>>>> That affects all platforms. >>>>> >>>>> And a small change in m3cc/parse.c for >> div/mod of longint on non-NT386. >>>>> I have to test mod yet but my fix probably >> helps it. >>>>> >>>>> It'd be really great if anyone could do >> anything with this stuff. >>>>> ie. for now in head, then could easily port >> to release. >>>>> >>>>> We can of course release either way, >> depending on how satisfied people >>>>> are with 32bit longint on NT386. i.e. longint >> isn't useful portably, but it >>>>> is useful on non-NT386 platforms. >>>>> >>>>> - Jay >>>>> >>>>>> Date: Tue, 16 Feb 2010 16:12:52 +0100 >>>>>> From: wagner at elegosoft.com >>>>>> To: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] >> m3back/longint/atomics >>>>>> >>>>>> Quoting Jay K >> : >>>>>> >>>>>>> >>>>>>> As far as I know/can remember, >> longint and atomics should all work >>>>>>> now on NT386. >>>>>>> >>>>>>> Atomics only currently for 32bit >> types. >>>>>>> There are still a few small >> inefficiencies to maybe deal with. >>>>>>> I'll add 64bit shortly and maybe >> 8 and 16. >>>>>>> >>>>>>> >>>>>>> We should probably add *a lot* more >> test coverage in p226 and p227. >>>>>>> >>>>>>> e.g. longint >> multiply/add/sub/divide, not just insert/extract like I >>>>>>> did a bunch of. >>>>>> >>>>>> Any volunteers to increase the test >> coverage? >>>>>> >>>>>>> Still to fix the Win32 m3core/libm3 >> to not always truncate file sizes. >>>>>>> >>>>>>> Still maybe to do something about >> rd/wr...? >>>>>>> >>>>>>> Still to wonder about NT386/longint >> support in the release branch? >>>>>> >>>>>> Should we / will you merge this stuff to >> the release branch? >>>>>> Or should we release without it? How >> local are the changes? >>>>>> >>>>>> Olaf >>>> -- >>>> Olaf Wagner -- elego Software Solutions GmbH >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, Germany >>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >> 869 fax: +49 30 23 45 86 95 >>>> >> http://www.elegosoft.com | >> >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin >>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | USt-IdNr: DE163214194 >>>> >>>> >>> >>> >>> >>> -- >>> Olaf Wagner -- elego Software Solutions GmbH >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, >> Germany >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 >> fax: +49 30 23 45 86 95 >>> http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf >> Wagner | Sitz: Berlin >>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | >> USt-IdNr: DE163214194 >>> >> >> > > > From dabenavidesd at yahoo.es Fri Feb 19 07:20:10 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 06:20:10 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <621322.72118.qm@web23603.mail.ird.yahoo.com> HI: thanks for answering so fast! Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup more or less it makes you to do cvsupd -b /diska/cvsup/base/ which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: (First command and executing after it the client with .sup file given there in the web page) % telnet 192.168.0.3 5999 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. OK 17 0 2009-07-20 14:06:34 CVSup server ready Connection closed by foreign host. (After, second command it doesn't wait anything or if some client request, it just finish like this) % telnet 192.168.0.3 5999 Trying 192.168.0.3... Connected to 192.168.0.3. Escape character is '^]'. Connection closed by foreign host. % pwd seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. (m3gdb) file LINUXLIBC6/cvsupd Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (m3gdb) break src/Main.m3:BecomeDaemon No source file named src/Main.m3. Make breakpoint pending on future shared library load? (y or [n]) y Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log (m3gdb) set follow-fork-mode child (m3gdb) run Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log Signal Stop Print Pass to program Description SIG64 No No Yes Real-time event 64 [Thread debugging using libthread_db enabled] [Nuevo LWP 5074] [Nuevo Thread -1221278032 (LWP 5074)] In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. Thanks in advance, --- El jue, 18/2/10, Jay K escribi?: > De: Jay K > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Daniel (M3)" , "Olaf" , "m3devel" > Fecha: jueves, 18 de febrero, 2010 23:54 > > https://projects.elego.de/cm3/ticket/1080 > can you provide the cvsup configuration file? Thanks. > Can you try building with user threads and see if it > occurs? > Or on another platform? > > > This is definitely something we want to look into. > > > NT386GNU is there and worked for me, but it is slow. > It had 64bit longint way ahead of NT386, but NT386 is there > now. > There is also NT386MINGNU. > > > More testing definitely appreciated. > > > Thanks, > - Jay > > > ---------------------------------------- > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > From: dabenavidesd at yahoo.es > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > To: wagner at elegosoft.com; > m3devel at elegosoft.com; > jay.krell at cornell.edu > > > > Hi all: > > great news to hear about a release coming soon, but > how about testing NT386GNU or derivatives of it, would be > hard to set up (I might try a friend's machine). > > As I understood that was a great port to new Modula-3 > programmers coming into the M3 world from win world. This > doesn't have the all packages but is this a must to give > have a check to release this port? > > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 > ? > > Is there any chance to bring those platforms in final > release? > > Any difficulties to start trying that? > > Thanks in advance > > > > --- El jue, 18/2/10, Jay K escribi?: > > > >> De: Jay K > >> Asunto: Re: [M3devel] More testing needed for > m3back, was: RE: m3back/longint/atomics > >> Para: "Olaf" , "m3devel" > >> Fecha: jueves, 18 de febrero, 2010 16:26 > >> > >> > >> > >> > >> > >> I added some testing, found/fixed bugs in the gcc > >> backend (initializing constants, division). > >> > >> They should be in the automated tests already. > >> > >> However don't let this stop you from doing > >> everything/anything you can think of. > >> > >> I didn't do all that much and you can save time > and get > >> more done by not worrying > >> > >> about the duplication. > >> > >> Pickles I didn't do anything with at all, so if > you > >> really want to avoid/delay duplication, > >> > >> start with them. > >> > >> > >> > >> - Jay > >> > >> > >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 > >>> From: wagner at elegosoft.com > >>> To: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] More testing needed for > m3back, > >> was: RE: m3back/longint/atomics > >>> > >>> Quoting "Coleburn, Randy" > >> : > >>> > >>>> I can certainly run some tests on > Windows. > >>>> > >>>> I don't have any code that uses longint, > so > >> either someone needs to > >>>> identify which existing programs I can > build and > >> run to do the > >>>> tests, OR I suppose I can write something > if you > >> can give me an idea > >>>> of how extensive the tests you want. > >>> > >>> This sounds good! > >>> > >>> Some things that come to mind for LONGINT > >> immeditately: > >>> > >>> o standard integer arithmetic (+, -, *, DIV, > MOD) at > >> runtime, > >>> with and without overflows etc. > >>> o constant declarations > >>> o constant expressions > >>> o assignability (should be rather strict; I'd > have > >> to check the mail > >>> archive for the details) > >>> o pickles > >>> > >>> It would be great if you could add some tests > to > >> m3tests that are > >>> valid on all platforms. I expect that some > should > >> already be in place, > >>> but haven't checked yet... > >>> > >>> Hm, a quick search for longint in > >>> > >>> > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > >>> > >>> for example doesn't find anything. Has nobody > >> added any LONGINT > >>> test yet? Probably I'm looking for the wrong > >> string... > >>> > >>> A complete regression with cm3 and other > programs you > >> may have available > >>> would be great, too, just to make sure that > the > >> backend changes > >>> don't break any old functionality. > >>> > >>> Olaf > >>> > >>>> > >>>> I've been trying to keep my system updated > to > >> the latest sources on > >>>> the main trunk, but I've been swamped > lately > >> and I'm afraid I'm a > >>>> few weeks stale right now. I'll remedy > that > >> shortly. > >>>> > >>>> Regards, > >>>> Randy > >>>> > >>>> ________________________________ > >>>> From: Olaf Wagner [wagner at elegosoft.com] > >>>> Sent: Thursday, February 18, 2010 6:57 AM > >>>> To: Jay K > >>>> Cc: m3devel > >>>> Subject: [M3devel] More testing needed > for > >> m3back, was: RE: > >>>> m3back/longint/atomics > >>>> > >>>> If I understand Jay correctly, it wouldn't > be > >> too difficult to bring > >>>> the m3ack LONGINT changes for Windows into > the > >> release branch, but > >>>> more testing would be needed. > >>>> > >>>> Randy, you're the only one I remember > offhand > >> who actively uses M3 > >>>> on Windows except for Jay. Could you have > a > >> closer look at it? > >>>> (Changes are only on the trunk right > now.) > >>>> > >>>> Or is anybody else here lurking and eager > to do > >> some Windows-based tests? > >>>> > >>>> If nobody volunteers, I'm afraid we will > have > >> to release without 64bit > >>>> LONGINT on Windows. > >>>> > >>>> Olaf > >>>> > >>>> Quoting Jay K : > >>>> > >>>>> NT386/longint changes are almost > entirely in > >> the m3back package. > >>>>> > >>>>> There is also some small easy stuff > in > >>>>> > m3-libs/m3core/src/Csupport/common/hand.c. > >>>>> > >>>>> It'd be really great if anyone could > test > >> any of this and if > >>>>> anyone could review the diff between > release > >> and head. > >>>>> > >>>>> Not just me. > >>>>> > >>>>> The changes for longint are quite > large, even > >> if local. > >>>>> > >>>>> I can port them, in the case of > m3back, just > >> copy, and make sure > >>>>> the atomics stuff doesn't cause > problems > >> (it should be unused). > >>>>> > >>>>> There is also a small change in > m3front so > >> that longint can be initialized. > >>>>> That affects all platforms. > >>>>> > >>>>> And a small change in m3cc/parse.c > for > >> div/mod of longint on non-NT386. > >>>>> I have to test mod yet but my fix > probably > >> helps it. > >>>>> > >>>>> It'd be really great if anyone could > do > >> anything with this stuff. > >>>>> ie. for now in head, then could easily > port > >> to release. > >>>>> > >>>>> We can of course release either way, > >> depending on how satisfied people > >>>>> are with 32bit longint on NT386. i.e. > longint > >> isn't useful portably, but it > >>>>> is useful on non-NT386 platforms. > >>>>> > >>>>> - Jay > >>>>> > >>>>>> Date: Tue, 16 Feb 2010 16:12:52 > +0100 > >>>>>> From: wagner at elegosoft.com > >>>>>> To: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] > >> m3back/longint/atomics > >>>>>> > >>>>>> Quoting Jay K > >> : > >>>>>> > >>>>>>> > >>>>>>> As far as I know/can > remember, > >> longint and atomics should all work > >>>>>>> now on NT386. > >>>>>>> > >>>>>>> Atomics only currently for > 32bit > >> types. > >>>>>>> There are still a few small > >> inefficiencies to maybe deal with. > >>>>>>> I'll add 64bit shortly and > maybe > >> 8 and 16. > >>>>>>> > >>>>>>> > >>>>>>> We should probably add *a lot* > more > >> test coverage in p226 and p227. > >>>>>>> > >>>>>>> e.g. longint > >> multiply/add/sub/divide, not just insert/extract > like I > >>>>>>> did a bunch of. > >>>>>> > >>>>>> Any volunteers to increase the > test > >> coverage? > >>>>>> > >>>>>>> Still to fix the Win32 > m3core/libm3 > >> to not always truncate file sizes. > >>>>>>> > >>>>>>> Still maybe to do something > about > >> rd/wr...? > >>>>>>> > >>>>>>> Still to wonder about > NT386/longint > >> support in the release branch? > >>>>>> > >>>>>> Should we / will you merge this > stuff to > >> the release branch? > >>>>>> Or should we release without it? > How > >> local are the changes? > >>>>>> > >>>>>> Olaf > >>>> -- > >>>> Olaf Wagner -- elego Software Solutions > GmbH > >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 > >> Berlin, Germany > >>>> phone: +49 30 23 45 86 96 mobile: +49 177 > 2345 > >> 869 fax: +49 30 23 45 86 95 > >>>> > >> http://www.elegosoft.com | > >> > >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: > Berlin > >>>> Handelregister: Amtsgericht Charlottenburg > HRB > >> 77719 | USt-IdNr: DE163214194 > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> Olaf Wagner -- elego Software Solutions GmbH > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > Berlin, > >> Germany > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 > 869 > >> fax: +49 30 23 45 86 95 > >>> http://www.elegosoft.com | > Gesch?ftsf?hrer: Olaf > >> Wagner | Sitz: Berlin > >>> Handelregister: Amtsgericht Charlottenburg HRB > 77719 | > >> USt-IdNr: DE163214194 > >>> > >> > >> > > > > > > > > > From jay.krell at cornell.edu Fri Feb 19 09:50:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 08:50:36 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <621322.72118.qm@web23603.mail.ird.yahoo.com> References: , <621322.72118.qm@web23603.mail.ird.yahoo.com> Message-ID: - Our system isn't multithreaded enough to benefit from multicore. There are too many globals. Modula-3 allows for and takes advantage of programmers writing "separate headers" in the fashion that all C/C++ programmers do anyway (but which the C/C++ compiler can't take advantage of, but instead parses over and over and over) but it doesn't discourage you to have interfaces that merely manage globals. We might be able to win with a coarse grained parallelism: multiple processes instead of threads - Cygwin is so slow, and has been for so long, I have no hope for it getting much better. Maybe the gcc Makefiles won't create so many processes at some point. It does work to an impressive degree, but is also very slow. NT386 has always been very fast. The other Posix systems are getting better, my newer Intel Mac is closer in speed to NT386 than older PPC Mac. But NT386 is still much faster (on old machine). - to build with user threads, you have tweak m3-libs/m3core/src/threads.quake and build the whole system -- BUT you don't need a new compiler Just: edit that file cd $CVSROOT/scripts/python ./do-cm3-std.py realclean ./do-cm3-std.py buildship I again really strongly suggest we should either: - have multiple platforms, so there are regular builds, people can just install I386_LINUX_USERTHREADS, I386_FREEBSD_USERTHREADS, etc. - make it an @M3 option You cannot just drop in a replacement m3core.so. The types aren't sufficiently the same. - Jay ---------------------------------------- > Date: Fri, 19 Feb 2010 06:20:10 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > HI: > thanks for answering so fast! > Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. > First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup > > more or less it makes you to do > cvsupd -b /diska/cvsup/base/ > which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) > Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: > > (First command and executing after it the client with .sup file given there in the web page) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > OK 17 0 2009-07-20 14:06:34 CVSup server ready > Connection closed by foreign host. > > (After, second command it doesn't wait anything or if some client request, it just finish like this) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > > > Connection closed by foreign host. > % pwd > > > seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. > (m3gdb) file LINUXLIBC6/cvsupd > Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) break src/Main.m3:BecomeDaemon > No source file named src/Main.m3. > Make breakpoint pending on future shared library load? (y or [n]) y > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > (m3gdb) set follow-fork-mode child > (m3gdb) run > Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > Signal Stop Print Pass to program Description > SIG64 No No Yes Real-time event 64 > [Thread debugging using libthread_db enabled] > [Nuevo LWP 5074] > [Nuevo Thread -1221278032 (LWP 5074)] > > > In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. > I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. > > About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. > > Thanks in advance, > > --- El jue, 18/2/10, Jay K escribi?: > >> De: Jay K >> Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics >> Para: "Daniel (M3)" , "Olaf" , "m3devel" >> Fecha: jueves, 18 de febrero, 2010 23:54 >> >> https://projects.elego.de/cm3/ticket/1080 >> can you provide the cvsup configuration file? Thanks. >> Can you try building with user threads and see if it >> occurs? >> Or on another platform? >> >> >> This is definitely something we want to look into. >> >> >> NT386GNU is there and worked for me, but it is slow. >> It had 64bit longint way ahead of NT386, but NT386 is there >> now. >> There is also NT386MINGNU. >> >> >> More testing definitely appreciated. >> >> >> Thanks, >> - Jay >> >> >> ---------------------------------------- >>> Date: Fri, 19 Feb 2010 03:07:36 +0000 >>> From: dabenavidesd at yahoo.es >>> Subject: Re: [M3devel] More testing needed for m3back, >> was: RE: m3back/longint/atomics >>> To: wagner at elegosoft.com; >> m3devel at elegosoft.com; >> jay.krell at cornell.edu >>> >>> Hi all: >>> great news to hear about a release coming soon, but >> how about testing NT386GNU or derivatives of it, would be >> hard to set up (I might try a friend's machine). >>> As I understood that was a great port to new Modula-3 >> programmers coming into the M3 world from win world. This >> doesn't have the all packages but is this a must to give >> have a check to release this port? >>> Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 >> ? >>> Is there any chance to bring those platforms in final >> release? >>> Any difficulties to start trying that? >>> Thanks in advance >>> >>> --- El jue, 18/2/10, Jay K escribi?: >>> >>>> De: Jay K >>>> Asunto: Re: [M3devel] More testing needed for >> m3back, was: RE: m3back/longint/atomics >>>> Para: "Olaf" , "m3devel" >>>> Fecha: jueves, 18 de febrero, 2010 16:26 >>>> >>>> >>>> >>>> >>>> >>>> I added some testing, found/fixed bugs in the gcc >>>> backend (initializing constants, division). >>>> >>>> They should be in the automated tests already. >>>> >>>> However don't let this stop you from doing >>>> everything/anything you can think of. >>>> >>>> I didn't do all that much and you can save time >> and get >>>> more done by not worrying >>>> >>>> about the duplication. >>>> >>>> Pickles I didn't do anything with at all, so if >> you >>>> really want to avoid/delay duplication, >>>> >>>> start with them. >>>> >>>> >>>> >>>> - Jay >>>> >>>> >>>>> Date: Thu, 18 Feb 2010 17:20:56 +0100 >>>>> From: wagner at elegosoft.com >>>>> To: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] More testing needed for >> m3back, >>>> was: RE: m3back/longint/atomics >>>>> >>>>> Quoting "Coleburn, Randy" >>>> : >>>>> >>>>>> I can certainly run some tests on >> Windows. >>>>>> >>>>>> I don't have any code that uses longint, >> so >>>> either someone needs to >>>>>> identify which existing programs I can >> build and >>>> run to do the >>>>>> tests, OR I suppose I can write something >> if you >>>> can give me an idea >>>>>> of how extensive the tests you want. >>>>> >>>>> This sounds good! >>>>> >>>>> Some things that come to mind for LONGINT >>>> immeditately: >>>>> >>>>> o standard integer arithmetic (+, -, *, DIV, >> MOD) at >>>> runtime, >>>>> with and without overflows etc. >>>>> o constant declarations >>>>> o constant expressions >>>>> o assignability (should be rather strict; I'd >> have >>>> to check the mail >>>>> archive for the details) >>>>> o pickles >>>>> >>>>> It would be great if you could add some tests >> to >>>> m3tests that are >>>>> valid on all platforms. I expect that some >> should >>>> already be in place, >>>>> but haven't checked yet... >>>>> >>>>> Hm, a quick search for longint in >>>>> >>>>> >>>> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ >>>>> >>>>> for example doesn't find anything. Has nobody >>>> added any LONGINT >>>>> test yet? Probably I'm looking for the wrong >>>> string... >>>>> >>>>> A complete regression with cm3 and other >> programs you >>>> may have available >>>>> would be great, too, just to make sure that >> the >>>> backend changes >>>>> don't break any old functionality. >>>>> >>>>> Olaf >>>>> >>>>>> >>>>>> I've been trying to keep my system updated >> to >>>> the latest sources on >>>>>> the main trunk, but I've been swamped >> lately >>>> and I'm afraid I'm a >>>>>> few weeks stale right now. I'll remedy >> that >>>> shortly. >>>>>> >>>>>> Regards, >>>>>> Randy >>>>>> >>>>>> ________________________________ >>>>>> From: Olaf Wagner [wagner at elegosoft.com] >>>>>> Sent: Thursday, February 18, 2010 6:57 AM >>>>>> To: Jay K >>>>>> Cc: m3devel >>>>>> Subject: [M3devel] More testing needed >> for >>>> m3back, was: RE: >>>>>> m3back/longint/atomics >>>>>> >>>>>> If I understand Jay correctly, it wouldn't >> be >>>> too difficult to bring >>>>>> the m3ack LONGINT changes for Windows into >> the >>>> release branch, but >>>>>> more testing would be needed. >>>>>> >>>>>> Randy, you're the only one I remember >> offhand >>>> who actively uses M3 >>>>>> on Windows except for Jay. Could you have >> a >>>> closer look at it? >>>>>> (Changes are only on the trunk right >> now.) >>>>>> >>>>>> Or is anybody else here lurking and eager >> to do >>>> some Windows-based tests? >>>>>> >>>>>> If nobody volunteers, I'm afraid we will >> have >>>> to release without 64bit >>>>>> LONGINT on Windows. >>>>>> >>>>>> Olaf >>>>>> >>>>>> Quoting Jay K : >>>>>> >>>>>>> NT386/longint changes are almost >> entirely in >>>> the m3back package. >>>>>>> >>>>>>> There is also some small easy stuff >> in >>>>>>> >> m3-libs/m3core/src/Csupport/common/hand.c. >>>>>>> >>>>>>> It'd be really great if anyone could >> test >>>> any of this and if >>>>>>> anyone could review the diff between >> release >>>> and head. >>>>>>> >>>>>>> Not just me. >>>>>>> >>>>>>> The changes for longint are quite >> large, even >>>> if local. >>>>>>> >>>>>>> I can port them, in the case of >> m3back, just >>>> copy, and make sure >>>>>>> the atomics stuff doesn't cause >> problems >>>> (it should be unused). >>>>>>> >>>>>>> There is also a small change in >> m3front so >>>> that longint can be initialized. >>>>>>> That affects all platforms. >>>>>>> >>>>>>> And a small change in m3cc/parse.c >> for >>>> div/mod of longint on non-NT386. >>>>>>> I have to test mod yet but my fix >> probably >>>> helps it. >>>>>>> >>>>>>> It'd be really great if anyone could >> do >>>> anything with this stuff. >>>>>>> ie. for now in head, then could easily >> port >>>> to release. >>>>>>> >>>>>>> We can of course release either way, >>>> depending on how satisfied people >>>>>>> are with 32bit longint on NT386. i.e. >> longint >>>> isn't useful portably, but it >>>>>>> is useful on non-NT386 platforms. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>>> Date: Tue, 16 Feb 2010 16:12:52 >> +0100 >>>>>>>> From: wagner at elegosoft.com >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] >>>> m3back/longint/atomics >>>>>>>> >>>>>>>> Quoting Jay K >>>> : >>>>>>>> >>>>>>>>> >>>>>>>>> As far as I know/can >> remember, >>>> longint and atomics should all work >>>>>>>>> now on NT386. >>>>>>>>> >>>>>>>>> Atomics only currently for >> 32bit >>>> types. >>>>>>>>> There are still a few small >>>> inefficiencies to maybe deal with. >>>>>>>>> I'll add 64bit shortly and >> maybe >>>> 8 and 16. >>>>>>>>> >>>>>>>>> >>>>>>>>> We should probably add *a lot* >> more >>>> test coverage in p226 and p227. >>>>>>>>> >>>>>>>>> e.g. longint >>>> multiply/add/sub/divide, not just insert/extract >> like I >>>>>>>>> did a bunch of. >>>>>>>> >>>>>>>> Any volunteers to increase the >> test >>>> coverage? >>>>>>>> >>>>>>>>> Still to fix the Win32 >> m3core/libm3 >>>> to not always truncate file sizes. >>>>>>>>> >>>>>>>>> Still maybe to do something >> about >>>> rd/wr...? >>>>>>>>> >>>>>>>>> Still to wonder about >> NT386/longint >>>> support in the release branch? >>>>>>>> >>>>>>>> Should we / will you merge this >> stuff to >>>> the release branch? >>>>>>>> Or should we release without it? >> How >>>> local are the changes? >>>>>>>> >>>>>>>> Olaf >>>>>> -- >>>>>> Olaf Wagner -- elego Software Solutions >> GmbH >>>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, >> 13355 >>>> Berlin, Germany >>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 >> 2345 >>>> 869 fax: +49 30 23 45 86 95 >>>>>> >>>> http://www.elegosoft.com | >>>> >>>>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: >> Berlin >>>>>> Handelregister: Amtsgericht Charlottenburg >> HRB >>>> 77719 | USt-IdNr: DE163214194 >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olaf Wagner -- elego Software Solutions GmbH >>>>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 >> Berlin, >>>> Germany >>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 >> 869 >>>> fax: +49 30 23 45 86 95 >>>>> http://www.elegosoft.com | >> Gesch?ftsf?hrer: Olaf >>>> Wagner | Sitz: Berlin >>>>> Handelregister: Amtsgericht Charlottenburg HRB >> 77719 | >>>> USt-IdNr: DE163214194 >>>>> >>>> >>>> >>> >>> >>> >> >> >> > > > From jay.krell at cornell.edu Fri Feb 19 11:43:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 10:43:02 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <621322.72118.qm@web23603.mail.ird.yahoo.com> References: , <621322.72118.qm@web23603.mail.ird.yahoo.com> Message-ID: Daniel, if you really last tried this in 2008, please try again. I'm not sure we had cvsup in our tree in 2008 though. Even if you tried it in 2009, try again? http://aivwiki.alma.cl/index.php/Installing_CVSup points to a particular non-current Modula-3 and a particular cvsup. We have cvsup in our tree now. Which did you use? Please try ours. -Jay > Date: Fri, 19 Feb 2010 06:20:10 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > HI: > thanks for answering so fast! > Well, more or less I tried to understand what was happening on cvsup LINUXLIBC6 on late 2008 quickly and half a year ago more carefully. > First I tried with system level threads and the first connection worked to retrieve files as I remember in this example case: http://aivwiki.alma.cl/index.php/Installing_CVSup > > more or less it makes you to do > cvsupd -b /diska/cvsup/base/ > which works for first client login as is written in the web page (that happened in my late 2008 try seeing the above url case as pointed by the person who tried and reported this at that time) > Then you had to use background command to cvsupd (where I think the problem appears but not in the first process, but in the forked, if forked or in both) copying/pasting the two commands from the url of case above mentioned > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > This doesn't work (for me in both tries) and the reason is the problem is when the process forks so there might somehow a "small" error because process forked won't work as expectedly (I don't even if it dies on system) or if and runtime error is given. I just grabbed this output from terminal: > > (First command and executing after it the client with .sup file given there in the web page) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > OK 17 0 2009-07-20 14:06:34 CVSup server ready > Connection closed by foreign host. > > (After, second command it doesn't wait anything or if some client request, it just finish like this) > % telnet 192.168.0.3 5999 > Trying 192.168.0.3... > Connected to 192.168.0.3. > Escape character is '^]'. > > > Connection closed by foreign host. > % pwd > > > seeing docs from and now not found http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > Directorio de trabajo /home/test/code/cm3-cvs/m3-tools/cvsup/server. > (m3gdb) file LINUXLIBC6/cvsupd > Reading symbols from /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". > > (m3gdb) break src/Main.m3:BecomeDaemon > No source file named src/Main.m3. > Make breakpoint pending on future shared library load? (y or [n]) y > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) pendiente. > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > (m3gdb) set follow-fork-mode child > (m3gdb) run > Starting program: /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd -b /home/test/code/cvsup/base/ -C 5 -l /home/test/code/cvsup/log > Signal Stop Print Pass to program Description > SIG64 No No Yes Real-time event 64 > [Thread debugging using libthread_db enabled] > [Nuevo LWP 5074] > [Nuevo Thread -1221278032 (LWP 5074)] > > > In the above m3gdb session I did last year a session on it; I didn't find quite easy to follow track of forked process to see the stacks of the forked process, I didn't tried too hard. But I know gdb has a feature to allow you doing that, but I merely looked into gdb docs quickly, and thinking it now I should retry to see if m3gdb could get these days into that. Hints here or some advise would be appreciated, perhaps Rodney has a better idea of status of this feature on current m3gdb. > I don't know how to build with user-level threads, first I think I must recompile from bootstrap switched to user-level threads, right? I would appreciate any help on how to do that. > > About the case of NT386GNU and alternatives, I expect this tools gets optimized over the time more and more, which is the case for other platforms systems, current multi-core machines shows the speed up as you might have compared in over all compile time with older systems (wouldn't be a bad idea to grab those statistics from m3quake) to compare results in M3 terms and probably in over-all process if possible. There could be a similar performance or at least a constant reduction in number of seconds each time it gets a better platform. > > Thanks in advance, > > --- El jue, 18/2/10, Jay K escribi?: > > > De: Jay K > > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Para: "Daniel (M3)" , "Olaf" , "m3devel" > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > https://projects.elego.de/cm3/ticket/1080 > > can you provide the cvsup configuration file? Thanks. > > Can you try building with user threads and see if it > > occurs? > > Or on another platform? > > > > > > This is definitely something we want to look into. > > > > > > NT386GNU is there and worked for me, but it is slow. > > It had 64bit longint way ahead of NT386, but NT386 is there > > now. > > There is also NT386MINGNU. > > > > > > More testing definitely appreciated. > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > From: dabenavidesd at yahoo.es > > > Subject: Re: [M3devel] More testing needed for m3back, > > was: RE: m3back/longint/atomics > > > To: wagner at elegosoft.com; > > m3devel at elegosoft.com; > > jay.krell at cornell.edu > > > > > > Hi all: > > > great news to hear about a release coming soon, but > > how about testing NT386GNU or derivatives of it, would be > > hard to set up (I might try a friend's machine). > > > As I understood that was a great port to new Modula-3 > > programmers coming into the M3 world from win world. This > > doesn't have the all packages but is this a must to give > > have a check to release this port? > > > Any news from cvsup ticket #1080 https://projects.elego.de/cm3/ticket/1080 > > ? > > > Is there any chance to bring those platforms in final > > release? > > > Any difficulties to start trying that? > > > Thanks in advance > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > >> De: Jay K > > >> Asunto: Re: [M3devel] More testing needed for > > m3back, was: RE: m3back/longint/atomics > > >> Para: "Olaf" , "m3devel" > > >> Fecha: jueves, 18 de febrero, 2010 16:26 > > >> > > >> > > >> > > >> > > >> > > >> I added some testing, found/fixed bugs in the gcc > > >> backend (initializing constants, division). > > >> > > >> They should be in the automated tests already. > > >> > > >> However don't let this stop you from doing > > >> everything/anything you can think of. > > >> > > >> I didn't do all that much and you can save time > > and get > > >> more done by not worrying > > >> > > >> about the duplication. > > >> > > >> Pickles I didn't do anything with at all, so if > > you > > >> really want to avoid/delay duplication, > > >> > > >> start with them. > > >> > > >> > > >> > > >> - Jay > > >> > > >> > > >>> Date: Thu, 18 Feb 2010 17:20:56 +0100 > > >>> From: wagner at elegosoft.com > > >>> To: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] More testing needed for > > m3back, > > >> was: RE: m3back/longint/atomics > > >>> > > >>> Quoting "Coleburn, Randy" > > >> : > > >>> > > >>>> I can certainly run some tests on > > Windows. > > >>>> > > >>>> I don't have any code that uses longint, > > so > > >> either someone needs to > > >>>> identify which existing programs I can > > build and > > >> run to do the > > >>>> tests, OR I suppose I can write something > > if you > > >> can give me an idea > > >>>> of how extensive the tests you want. > > >>> > > >>> This sounds good! > > >>> > > >>> Some things that come to mind for LONGINT > > >> immeditately: > > >>> > > >>> o standard integer arithmetic (+, -, *, DIV, > > MOD) at > > >> runtime, > > >>> with and without overflows etc. > > >>> o constant declarations > > >>> o constant expressions > > >>> o assignability (should be rather strict; I'd > > have > > >> to check the mail > > >>> archive for the details) > > >>> o pickles > > >>> > > >>> It would be great if you could add some tests > > to > > >> m3tests that are > > >>> valid on all platforms. I expect that some > > should > > >> already be in place, > > >>> but haven't checked yet... > > >>> > > >>> Hm, a quick search for longint in > > >>> > > >>> > > >> http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > >>> > > >>> for example doesn't find anything. Has nobody > > >> added any LONGINT > > >>> test yet? Probably I'm looking for the wrong > > >> string... > > >>> > > >>> A complete regression with cm3 and other > > programs you > > >> may have available > > >>> would be great, too, just to make sure that > > the > > >> backend changes > > >>> don't break any old functionality. > > >>> > > >>> Olaf > > >>> > > >>>> > > >>>> I've been trying to keep my system updated > > to > > >> the latest sources on > > >>>> the main trunk, but I've been swamped > > lately > > >> and I'm afraid I'm a > > >>>> few weeks stale right now. I'll remedy > > that > > >> shortly. > > >>>> > > >>>> Regards, > > >>>> Randy > > >>>> > > >>>> ________________________________ > > >>>> From: Olaf Wagner [wagner at elegosoft.com] > > >>>> Sent: Thursday, February 18, 2010 6:57 AM > > >>>> To: Jay K > > >>>> Cc: m3devel > > >>>> Subject: [M3devel] More testing needed > > for > > >> m3back, was: RE: > > >>>> m3back/longint/atomics > > >>>> > > >>>> If I understand Jay correctly, it wouldn't > > be > > >> too difficult to bring > > >>>> the m3ack LONGINT changes for Windows into > > the > > >> release branch, but > > >>>> more testing would be needed. > > >>>> > > >>>> Randy, you're the only one I remember > > offhand > > >> who actively uses M3 > > >>>> on Windows except for Jay. Could you have > > a > > >> closer look at it? > > >>>> (Changes are only on the trunk right > > now.) > > >>>> > > >>>> Or is anybody else here lurking and eager > > to do > > >> some Windows-based tests? > > >>>> > > >>>> If nobody volunteers, I'm afraid we will > > have > > >> to release without 64bit > > >>>> LONGINT on Windows. > > >>>> > > >>>> Olaf > > >>>> > > >>>> Quoting Jay K : > > >>>> > > >>>>> NT386/longint changes are almost > > entirely in > > >> the m3back package. > > >>>>> > > >>>>> There is also some small easy stuff > > in > > >>>>> > > m3-libs/m3core/src/Csupport/common/hand.c. > > >>>>> > > >>>>> It'd be really great if anyone could > > test > > >> any of this and if > > >>>>> anyone could review the diff between > > release > > >> and head. > > >>>>> > > >>>>> Not just me. > > >>>>> > > >>>>> The changes for longint are quite > > large, even > > >> if local. > > >>>>> > > >>>>> I can port them, in the case of > > m3back, just > > >> copy, and make sure > > >>>>> the atomics stuff doesn't cause > > problems > > >> (it should be unused). > > >>>>> > > >>>>> There is also a small change in > > m3front so > > >> that longint can be initialized. > > >>>>> That affects all platforms. > > >>>>> > > >>>>> And a small change in m3cc/parse.c > > for > > >> div/mod of longint on non-NT386. > > >>>>> I have to test mod yet but my fix > > probably > > >> helps it. > > >>>>> > > >>>>> It'd be really great if anyone could > > do > > >> anything with this stuff. > > >>>>> ie. for now in head, then could easily > > port > > >> to release. > > >>>>> > > >>>>> We can of course release either way, > > >> depending on how satisfied people > > >>>>> are with 32bit longint on NT386. i.e. > > longint > > >> isn't useful portably, but it > > >>>>> is useful on non-NT386 platforms. > > >>>>> > > >>>>> - Jay > > >>>>> > > >>>>>> Date: Tue, 16 Feb 2010 16:12:52 > > +0100 > > >>>>>> From: wagner at elegosoft.com > > >>>>>> To: m3devel at elegosoft.com > > >>>>>> Subject: Re: [M3devel] > > >> m3back/longint/atomics > > >>>>>> > > >>>>>> Quoting Jay K > > >> : > > >>>>>> > > >>>>>>> > > >>>>>>> As far as I know/can > > remember, > > >> longint and atomics should all work > > >>>>>>> now on NT386. > > >>>>>>> > > >>>>>>> Atomics only currently for > > 32bit > > >> types. > > >>>>>>> There are still a few small > > >> inefficiencies to maybe deal with. > > >>>>>>> I'll add 64bit shortly and > > maybe > > >> 8 and 16. > > >>>>>>> > > >>>>>>> > > >>>>>>> We should probably add *a lot* > > more > > >> test coverage in p226 and p227. > > >>>>>>> > > >>>>>>> e.g. longint > > >> multiply/add/sub/divide, not just insert/extract > > like I > > >>>>>>> did a bunch of. > > >>>>>> > > >>>>>> Any volunteers to increase the > > test > > >> coverage? > > >>>>>> > > >>>>>>> Still to fix the Win32 > > m3core/libm3 > > >> to not always truncate file sizes. > > >>>>>>> > > >>>>>>> Still maybe to do something > > about > > >> rd/wr...? > > >>>>>>> > > >>>>>>> Still to wonder about > > NT386/longint > > >> support in the release branch? > > >>>>>> > > >>>>>> Should we / will you merge this > > stuff to > > >> the release branch? > > >>>>>> Or should we release without it? > > How > > >> local are the changes? > > >>>>>> > > >>>>>> Olaf > > >>>> -- > > >>>> Olaf Wagner -- elego Software Solutions > > GmbH > > >>>> Gustav-Meyer-Allee 25 / Geb?ude 12, > > 13355 > > >> Berlin, Germany > > >>>> phone: +49 30 23 45 86 96 mobile: +49 177 > > 2345 > > >> 869 fax: +49 30 23 45 86 95 > > >>>> > > >> http://www.elegosoft.com | > > >> > > >>>> Gesch?ftsf?hrer: Olaf Wagner | Sitz: > > Berlin > > >>>> Handelregister: Amtsgericht Charlottenburg > > HRB > > >> 77719 | USt-IdNr: DE163214194 > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Olaf Wagner -- elego Software Solutions GmbH > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 > > Berlin, > > >> Germany > > >>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 > > 869 > > >> fax: +49 30 23 45 86 95 > > >>> http://www.elegosoft.com | > > Gesch?ftsf?hrer: Olaf > > >> Wagner | Sitz: Berlin > > >>> Handelregister: Amtsgericht Charlottenburg HRB > > 77719 | > > >> USt-IdNr: DE163214194 > > >>> > > >> > > >> > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Fri Feb 19 15:04:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 19 Feb 2010 15:04:50 +0100 Subject: [M3devel] Reliable CM3 builds, was: Re: Auto-discard notification / CM3 build In-Reply-To: <20100219135528.2061552yxuem8800@webmail.netcom.co.uk> References: <20100218114558.rn033djp4wgs0wsg@mail.elegosoft.com> <20100219135528.2061552yxuem8800@webmail.netcom.co.uk> Message-ID: <20100219150450.jh85hsh5skkc04ko@mail.elegosoft.com> Quoting cwr at netcom.co.uk: > Quoting Olaf Wagner : > >> You need to subscribe to the list to be able to post to it. > > Oh well, I was hoping to set up a reliable automatic build process > for CM2, but it looks as if that's not possible. Thanks anyway. I don't really follow you here. If you're talking about CM3, the Hudson continuous integration of the current release branch has been working well for several months now: http://hudson.modula3.com:8080/ I'd call that automatic reliable build process :-) Of course there are problems now and then, but they usually are fixed quickly. The Hudson resources will be retargeted at the main line trunk as soon as the release is finally complete. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dabenavidesd at yahoo.es Fri Feb 19 16:08:04 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 19 Feb 2010 15:08:04 +0000 (GMT) Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: Message-ID: <168033.59265.qm@web23601.mail.ird.yahoo.com> Hi: Thanks for your answer. Yes, I tried it in late 2008 as in the web page resulted. Then on mid 2009 with cm3's tree cvsup. I was thinking in a command line switch like to cm3 -DNO_PTHREADS (or cm3 -DUSER_THREADS). Does something like that exist? Yes, I will try it building again to see where it gets with current (cvs release ranch). Do you know which branch I should use cvs like cvs tag release_branch_cm3_5_8 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 ? Thanks in advance, --- El vie, 19/2/10, Jay K escribi?: > De: Jay K > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > Para: "Daniel (M3)" , "Olaf" , "m3devel" > Fecha: viernes, 19 de febrero, 2010 05:43 > > > > > > Daniel, if you really last tried this in 2008, please > try again. > > I'm not sure we had cvsup in our tree in 2008 though. > > Even if you tried it in 2009, try again? > > http://aivwiki.alma.cl/index.php/Installing_CVSup > points to a particular non-current Modula-3 and a particular > cvsup. > > We have cvsup in our tree now. Which did you use? Please > try ours. > > > > -Jay > > > > Date: Fri, 19 Feb 2010 06:20:10 +0000 > > From: dabenavidesd at yahoo.es > > To: wagner at elegosoft.com; m3devel at elegosoft.com; > jay.krell at cornell.edu > > Subject: Re: [M3devel] More testing needed for m3back, > was: RE: m3back/longint/atomics > > > > HI: > > thanks for answering so fast! > > Well, more or less I tried to understand what was > happening on cvsup LINUXLIBC6 on late 2008 quickly and half > a year ago more carefully. > > First I tried with system level threads and the first > connection worked to retrieve files as I remember in this > example case: > http://aivwiki.alma.cl/index.php/Installing_CVSup > > > > more or less it makes you to do > > cvsupd -b /diska/cvsup/base/ > > which works for first client login as is written in > the web page (that happened in my late 2008 try seeing the > above url case as pointed by the person who tried and > reported this at that time) > > Then you had to use background command to cvsupd > (where I think the problem appears but not in the first > process, but in the forked, if forked or in both) > copying/pasting the two commands from the url of case above > mentioned > > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > > This doesn't work (for me in both tries) and the > reason is the problem is when the process forks so there > might somehow a "small" error because process > forked won't work as expectedly (I don't even if it > dies on system) or if and runtime error is given. I just > grabbed this output from terminal: > > > > (First command and executing after it the client with > .sup file given there in the web page) > > % telnet 192.168.0.3 5999 > > Trying 192.168.0.3... > > Connected to 192.168.0.3. > > Escape character is '^]'. > > OK 17 0 2009-07-20 14:06:34 CVSup server ready > > Connection closed by foreign host. > > > > (After, second command it doesn't wait anything or > if some client request, it just finish like this) > > % telnet 192.168.0.3 5999 > > Trying 192.168.0.3... > > Connected to 192.168.0.3. > > Escape character is '^]'. > > > > > > Connection closed by foreign host. > > % pwd > > > > > > seeing docs from and now not found > http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > > Directorio de trabajo > /home/test/code/cm3-cvs/m3-tools/cvsup/server. > > (m3gdb) file LINUXLIBC6/cvsupd > > Reading symbols from > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > > Using host libthread_db library > "/lib/tls/i686/cmov/libthread_db.so.1". > > > > (m3gdb) break src/Main.m3:BecomeDaemon > > No source file named src/Main.m3. > > Make breakpoint pending on future shared library load? > (y or [n]) y > > > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) > pendiente. > > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 > -l /home/test/code/cvsup/log > > (m3gdb) set follow-fork-mode child > > (m3gdb) run > > Starting program: > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd > -b /home/test/code/cvsup/base/ -C 5 -l > /home/test/code/cvsup/log > > Signal Stop Print Pass to program Description > > SIG64 No No Yes Real-time event 64 > > [Thread debugging using libthread_db enabled] > > [Nuevo LWP 5074] > > [Nuevo Thread -1221278032 (LWP 5074)] > > > > > > In the above m3gdb session I did last year a session > on it; I didn't find quite easy to follow track of > forked process to see the stacks of the forked process, I > didn't tried too hard. But I know gdb has a feature to > allow you doing that, but I merely looked into gdb docs > quickly, and thinking it now I should retry to see if m3gdb > could get these days into that. Hints here or some advise > would be appreciated, perhaps Rodney has a better idea of > status of this feature on current m3gdb. > > I don't know how to build with user-level threads, > first I think I must recompile from bootstrap switched to > user-level threads, right? I would appreciate any help on > how to do that. > > > > About the case of NT386GNU and alternatives, I expect > this tools gets optimized over the time more and more, which > is the case for other platforms systems, current multi-core > machines shows the speed up as you might have compared in > over all compile time with older systems (wouldn't be a > bad idea to grab those statistics from m3quake) to compare > results in M3 terms and probably in over-all process if > possible. There could be a similar performance or at least a > constant reduction in number of seconds each time it gets a > better platform. > > > > Thanks in advance, > > > > --- El jue, 18/2/10, Jay K > escribi?: > > > > > De: Jay K > > > Asunto: RE: [M3devel] More testing needed for > m3back, was: RE: m3back/longint/atomics > > > Para: "Daniel (M3)" > , "Olaf" > , "m3devel" > > > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > > > https://projects.elego.de/cm3/ticket/1080 > > > can you provide the cvsup configuration file? > Thanks. > > > Can you try building with user threads and see if > it > > > occurs? > > > Or on another platform? > > > > > > > > > This is definitely something we want to look > into. > > > > > > > > > NT386GNU is there and worked for me, but it is > slow. > > > It had 64bit longint way ahead of NT386, but > NT386 is there > > > now. > > > There is also NT386MINGNU. > > > > > > > > > More testing definitely appreciated. > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > > From: dabenavidesd at yahoo.es > > > > Subject: Re: [M3devel] More testing needed > for m3back, > > > was: RE: m3back/longint/atomics > > > > To: wagner at elegosoft.com; > > > m3devel at elegosoft.com; > > > jay.krell at cornell.edu > > > > > > > > Hi all: > > > > great news to hear about a release coming > soon, but > > > how about testing NT386GNU or derivatives of it, > would be > > > hard to set up (I might try a friend's > machine). > > > > As I understood that was a great port to new > Modula-3 > > > programmers coming into the M3 world from win > world. This > > > doesn't have the all packages but is this a > must to give > > > have a check to release this port? > > > > Any news from cvsup ticket #1080 > https://projects.elego.de/cm3/ticket/1080 > > > ? > > > > Is there any chance to bring those platforms > in final > > > release? > > > > Any difficulties to start trying that? > > > > Thanks in advance > > > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > > > >> De: Jay K > > > >> Asunto: Re: [M3devel] More testing > needed for > > > m3back, was: RE: m3back/longint/atomics > > > >> Para: "Olaf" , > "m3devel" > > > >> Fecha: jueves, 18 de febrero, 2010 > 16:26 > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> I added some testing, found/fixed bugs > in the gcc > > > >> backend (initializing constants, > division). > > > >> > > > >> They should be in the automated tests > already. > > > >> > > > >> However don't let this stop you from > doing > > > >> everything/anything you can think of. > > > >> > > > >> I didn't do all that much and you > can save time > > > and get > > > >> more done by not worrying > > > >> > > > >> about the duplication. > > > >> > > > >> Pickles I didn't do anything with at > all, so if > > > you > > > >> really want to avoid/delay duplication, > > > >> > > > >> start with them. > > > >> > > > >> > > > >> > > > >> - Jay > > > >> > > > >> > > > >>> Date: Thu, 18 Feb 2010 17:20:56 > +0100 > > > >>> From: wagner at elegosoft.com > > > >>> To: m3devel at elegosoft.com > > > >>> Subject: Re: [M3devel] More testing > needed for > > > m3back, > > > >> was: RE: m3back/longint/atomics > > > >>> > > > >>> Quoting "Coleburn, Randy" > > > >> : > > > >>> > > > >>>> I can certainly run some tests > on > > > Windows. > > > >>>> > > > >>>> I don't have any code that > uses longint, > > > so > > > >> either someone needs to > > > >>>> identify which existing programs > I can > > > build and > > > >> run to do the > > > >>>> tests, OR I suppose I can write > something > > > if you > > > >> can give me an idea > > > >>>> of how extensive the tests you > want. > > > >>> > > > >>> This sounds good! > > > >>> > > > >>> Some things that come to mind for > LONGINT > > > >> immeditately: > > > >>> > > > >>> o standard integer arithmetic (+, -, > *, DIV, > > > MOD) at > > > >> runtime, > > > >>> with and without overflows etc. > > > >>> o constant declarations > > > >>> o constant expressions > > > >>> o assignability (should be rather > strict; I'd > > > have > > > >> to check the mail > > > >>> archive for the details) > > > >>> o pickles > > > >>> > > > >>> It would be great if you could add > some tests > > > to > > > >> m3tests that are > > > >>> valid on all platforms. I expect > that some > > > should > > > >> already be in place, > > > >>> but haven't checked yet... > > > >>> > > > >>> Hm, a quick search for longint in > > > >>> > > > >>> > > > >> > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > >>> > > > >>> for example doesn't find > anything. Has nobody > > > >> added any LONGINT > > > >>> test yet? Probably I'm looking > for the wrong > > > >> string... > > > >>> > > > >>> A complete regression with cm3 and > other > > > programs you > > > >> may have available > > > >>> would be great, too, just to make > sure that > > > the > > > >> backend changes > > > >>> don't break any old > functionality. > > > >>> > > > >>> Olaf > > > >>> > > > >>>> > > > >>>> I've been trying to keep my > system updated > > > to > > > >> the latest sources on > > > >>>> the main trunk, but I've > been swamped > > > lately > > > >> and I'm afraid I'm a > > > >>>> few weeks stale right now. > I'll remedy > > > that > > > >> shortly. > > > >>>> > > > >>>> Regards, > > > >>>> Randy > > > >>>> > > > >>>> > ________________________________ > > > >>>> From: Olaf Wagner > [wagner at elegosoft.com] > > > >>>> Sent: Thursday, February 18, > 2010 6:57 AM > > > >>>> To: Jay K > > > >>>> Cc: m3devel > > > >>>> Subject: [M3devel] More testing > needed > > > for > > > >> m3back, was: RE: > > > >>>> m3back/longint/atomics > > > >>>> > > > >>>> If I understand Jay correctly, > it wouldn't > > > be > > > >> too difficult to bring > > > >>>> the m3ack LONGINT changes for > Windows into > > > the > > > >> release branch, but > > > >>>> more testing would be needed. > > > >>>> > > > >>>> Randy, you're the only one I > remember > > > offhand > > > >> who actively uses M3 > > > >>>> on Windows except for Jay. Could > you have > > > a > > > >> closer look at it? > > > >>>> (Changes are only on the trunk > right > > > now.) > > > >>>> > > > >>>> Or is anybody else here lurking > and eager > > > to do > > > >> some Windows-based tests? > > > >>>> > > > >>>> If nobody volunteers, I'm > afraid we will > > > have > > > >> to release without 64bit > > > >>>> LONGINT on Windows. > > > >>>> > > > >>>> Olaf > > > >>>> > > > >>>> Quoting Jay K : > > > >>>> > > > >>>>> NT386/longint changes are > almost > > > entirely in > > > >> the m3back package. > > > >>>>> > > > >>>>> There is also some small > easy stuff > > > in > > > >>>>> > > > m3-libs/m3core/src/Csupport/common/hand.c. > > > >>>>> > > > >>>>> It'd be really great if > anyone could > > > test > > > >> any of this and if > > > >>>>> anyone could review the diff > between > > > release > > > >> and head. > > > >>>>> > > > >>>>> Not just me. > > > >>>>> > > > >>>>> The changes for longint are > quite > > > large, even > > > >> if local. > > > >>>>> > > > >>>>> I can port them, in the case > of > > > m3back, just > > > >> copy, and make sure > > > >>>>> the atomics stuff > doesn't cause > > > problems > > > >> (it should be unused). > > > >>>>> > > > >>>>> There is also a small change > in > > > m3front so > > > >> that longint can be initialized. > > > >>>>> That affects all platforms. > > > >>>>> > > > >>>>> And a small change in > m3cc/parse.c > > > for > > > >> div/mod of longint on non-NT386. > > > >>>>> I have to test mod yet but > my fix > > > probably > > > >> helps it. > > > >>>>> > > > >>>>> It'd be really great if > anyone could > > > do > > > >> anything with this stuff. > > > >>>>> ie. for now in head, then > could easily > > > port > > > >> to release. > > > >>>>> > > > >>>>> We can of course release > either way, > > > >> depending on how satisfied people > > > >>>>> are with 32bit longint on > NT386. i.e. > > > longint > > > >> isn't useful portably, but it > > > >>>>> is useful on non-NT386 > platforms. > > > >>>>> > > > >>>>> - Jay > > > >>>>> > > > >>>>>> Date: Tue, 16 Feb 2010 > 16:12:52 > > > +0100 > > > >>>>>> From: > wagner at elegosoft.com > > > >>>>>> To: > m3devel at elegosoft.com > > > >>>>>> Subject: Re: [M3devel] > > > >> m3back/longint/atomics > > > >>>>>> > > > >>>>>> Quoting Jay K > > > >> : > > > >>>>>> > > > >>>>>>> > > > >>>>>>> As far as I > know/can > > > remember, > > > >> longint and atomics should all work > > > >>>>>>> now on NT386. > > > >>>>>>> > > > >>>>>>> Atomics only > currently for > > > 32bit > > > >> types. > > > >>>>>>> There are still a > few small > > > >> inefficiencies to maybe deal with. > > > >>>>>>> I'll add 64bit > shortly and > > > maybe > > > >> 8 and 16. > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> We should probably > add *a lot* > > > more > > > >> test coverage in p226 and p227. > > > >>>>>>> > > > >>>>>>> e.g. longint > > > >> multiply/add/sub/divide, not just > insert/extract > > > like I > > > >>>>>>> did a bunch of. > > > >>>>>> > > > >>>>>> Any volunteers to > increase the > > > test > > > >> coverage? > > > >>>>>> > > > >>>>>>> Still to fix the > Win32 > > > m3core/libm3 > > > >> to not always truncate file sizes. > > > >>>>>>> > > > >>>>>>> Still maybe to do > something > > > about > > > >> rd/wr...? > > > >>>>>>> > > > >>>>>>> Still to wonder > about > > > NT386/longint > > > >> support in the release branch? > > > >>>>>> > > > >>>>>> Should we / will you > merge this > > > stuff to > > > >> the release branch? > > > >>>>>> Or should we release > without it? > > > How > > > >> local are the changes? > > > >>>>>> > > > >>>>>> Olaf > > > >>>> -- > > > >>>> Olaf Wagner -- elego Software > Solutions > > > GmbH > > > >>>> Gustav-Meyer-Allee 25 / Geb?ude > 12, > > > 13355 > > > >> Berlin, Germany > > > >>>> phone: +49 30 23 45 86 96 > mobile: +49 177 > > > 2345 > > > >> 869 fax: +49 30 23 45 86 95 > > > >>>> > > > >> http://www.elegosoft.com | > > > >> > > > >>>> Gesch?ftsf?hrer: Olaf Wagner | > Sitz: > > > Berlin > > > >>>> Handelregister: Amtsgericht > Charlottenburg > > > HRB > > > >> 77719 | USt-IdNr: DE163214194 > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> Olaf Wagner -- elego Software > Solutions GmbH > > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, > 13355 > > > Berlin, > > > >> Germany > > > >>> phone: +49 30 23 45 86 96 mobile: > +49 177 2345 > > > 869 > > > >> fax: +49 30 23 45 86 95 > > > >>> http://www.elegosoft.com | > > > Gesch?ftsf?hrer: Olaf > > > >> Wagner | Sitz: Berlin > > > >>> Handelregister: Amtsgericht > Charlottenburg HRB > > > 77719 | > > > >> USt-IdNr: DE163214194 > > > >>> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From jay.krell at cornell.edu Fri Feb 19 22:08:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 19 Feb 2010 21:08:47 +0000 Subject: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics In-Reply-To: <168033.59265.qm@web23601.mail.ird.yahoo.com> References: , <168033.59265.qm@web23601.mail.ird.yahoo.com> Message-ID: Either head or release_branch_cm3_5_8. Something like cm3 -DNO-PTHREADS should work, yes. My scripts/python doesn't accept extra switches though. You could edit that into them, or use the *.sh files. Or edit m3-libs\m3core\src\thread.quake as I said. Thanks, - Jay > Date: Fri, 19 Feb 2010 15:08:04 +0000 > From: dabenavidesd at yahoo.es > To: wagner at elegosoft.com; m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Hi: > Thanks for your answer. Yes, I tried it in late 2008 as in the web page resulted. Then on mid 2009 with cm3's tree cvsup. > I was thinking in a command line switch like to cm3 -DNO_PTHREADS (or cm3 -DUSER_THREADS). Does something like that exist? > Yes, I will try it building again to see where it gets with current (cvs release ranch). Do you know which branch I should use cvs like > cvs tag release_branch_cm3_5_8 -d :pserver:anonymous at modula3.elegosoft.com:/usr/cvs checkout cm3 ? > > > Thanks in advance, > > --- El vie, 19/2/10, Jay K escribi?: > > > De: Jay K > > Asunto: RE: [M3devel] More testing needed for m3back, was: RE: m3back/longint/atomics > > Para: "Daniel (M3)" , "Olaf" , "m3devel" > > Fecha: viernes, 19 de febrero, 2010 05:43 > > > > > > > > > > > > Daniel, if you really last tried this in 2008, please > > try again. > > > > I'm not sure we had cvsup in our tree in 2008 though. > > > > Even if you tried it in 2009, try again? > > > > http://aivwiki.alma.cl/index.php/Installing_CVSup > > points to a particular non-current Modula-3 and a particular > > cvsup. > > > > We have cvsup in our tree now. Which did you use? Please > > try ours. > > > > > > > > -Jay > > > > > > > Date: Fri, 19 Feb 2010 06:20:10 +0000 > > > From: dabenavidesd at yahoo.es > > > To: wagner at elegosoft.com; m3devel at elegosoft.com; > > jay.krell at cornell.edu > > > Subject: Re: [M3devel] More testing needed for m3back, > > was: RE: m3back/longint/atomics > > > > > > HI: > > > thanks for answering so fast! > > > Well, more or less I tried to understand what was > > happening on cvsup LINUXLIBC6 on late 2008 quickly and half > > a year ago more carefully. > > > First I tried with system level threads and the first > > connection worked to retrieve files as I remember in this > > example case: > > http://aivwiki.alma.cl/index.php/Installing_CVSup > > > > > > more or less it makes you to do > > > cvsupd -b /diska/cvsup/base/ > > > which works for first client login as is written in > > the web page (that happened in my late 2008 try seeing the > > above url case as pointed by the person who tried and > > reported this at that time) > > > Then you had to use background command to cvsupd > > (where I think the problem appears but not in the first > > process, but in the forked, if forked or in both) > > copying/pasting the two commands from the url of case above > > mentioned > > > cvsupd -b /diska/cvsup/base/ -C 5 -l /diska/cvsup/log > > > This doesn't work (for me in both tries) and the > > reason is the problem is when the process forks so there > > might somehow a "small" error because process > > forked won't work as expectedly (I don't even if it > > dies on system) or if and runtime error is given. I just > > grabbed this output from terminal: > > > > > > (First command and executing after it the client with > > .sup file given there in the web page) > > > % telnet 192.168.0.3 5999 > > > Trying 192.168.0.3... > > > Connected to 192.168.0.3. > > > Escape character is '^]'. > > > OK 17 0 2009-07-20 14:06:34 CVSup server ready > > > Connection closed by foreign host. > > > > > > (After, second command it doesn't wait anything or > > if some client request, it just finish like this) > > > % telnet 192.168.0.3 5999 > > > Trying 192.168.0.3... > > > Connected to 192.168.0.3. > > > Escape character is '^]'. > > > > > > > > > Connection closed by foreign host. > > > % pwd > > > > > > > > > seeing docs from and now not found > > http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC29 > > > > > > > > > (m3gdb) cd code/cm3-cvs/m3-tools/cvsup/server > > > Directorio de trabajo > > /home/test/code/cm3-cvs/m3-tools/cvsup/server. > > > (m3gdb) file LINUXLIBC6/cvsupd > > > Reading symbols from > > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd...done. > > > Using host libthread_db library > > "/lib/tls/i686/cmov/libthread_db.so.1". > > > > > > (m3gdb) break src/Main.m3:BecomeDaemon > > > No source file named src/Main.m3. > > > Make breakpoint pending on future shared library load? > > (y or [n]) y > > > > > > Punto de rotura 1 (src/Main.m3:BecomeDaemon) > > pendiente. > > > (m3gdb) set args -b /home/test/code/cvsup/base/ -C 5 > > -l /home/test/code/cvsup/log > > > (m3gdb) set follow-fork-mode child > > > (m3gdb) run > > > Starting program: > > /home/test/code/cm3-cvs/m3-tools/cvsup/server/LINUXLIBC6/cvsupd > > -b /home/test/code/cvsup/base/ -C 5 -l > > /home/test/code/cvsup/log > > > Signal Stop Print Pass to program Description > > > SIG64 No No Yes Real-time event 64 > > > [Thread debugging using libthread_db enabled] > > > [Nuevo LWP 5074] > > > [Nuevo Thread -1221278032 (LWP 5074)] > > > > > > > > > In the above m3gdb session I did last year a session > > on it; I didn't find quite easy to follow track of > > forked process to see the stacks of the forked process, I > > didn't tried too hard. But I know gdb has a feature to > > allow you doing that, but I merely looked into gdb docs > > quickly, and thinking it now I should retry to see if m3gdb > > could get these days into that. Hints here or some advise > > would be appreciated, perhaps Rodney has a better idea of > > status of this feature on current m3gdb. > > > I don't know how to build with user-level threads, > > first I think I must recompile from bootstrap switched to > > user-level threads, right? I would appreciate any help on > > how to do that. > > > > > > About the case of NT386GNU and alternatives, I expect > > this tools gets optimized over the time more and more, which > > is the case for other platforms systems, current multi-core > > machines shows the speed up as you might have compared in > > over all compile time with older systems (wouldn't be a > > bad idea to grab those statistics from m3quake) to compare > > results in M3 terms and probably in over-all process if > > possible. There could be a similar performance or at least a > > constant reduction in number of seconds each time it gets a > > better platform. > > > > > > Thanks in advance, > > > > > > --- El jue, 18/2/10, Jay K > > escribi?: > > > > > > > De: Jay K > > > > Asunto: RE: [M3devel] More testing needed for > > m3back, was: RE: m3back/longint/atomics > > > > Para: "Daniel (M3)" > > , "Olaf" > > , "m3devel" > > > > > > Fecha: jueves, 18 de febrero, 2010 23:54 > > > > > > > > https://projects.elego.de/cm3/ticket/1080 > > > > can you provide the cvsup configuration file? > > Thanks. > > > > Can you try building with user threads and see if > > it > > > > occurs? > > > > Or on another platform? > > > > > > > > > > > > This is definitely something we want to look > > into. > > > > > > > > > > > > NT386GNU is there and worked for me, but it is > > slow. > > > > It had 64bit longint way ahead of NT386, but > > NT386 is there > > > > now. > > > > There is also NT386MINGNU. > > > > > > > > > > > > More testing definitely appreciated. > > > > > > > > > > > > Thanks, > > > > - Jay > > > > > > > > > > > > ---------------------------------------- > > > > > Date: Fri, 19 Feb 2010 03:07:36 +0000 > > > > > From: dabenavidesd at yahoo.es > > > > > Subject: Re: [M3devel] More testing needed > > for m3back, > > > > was: RE: m3back/longint/atomics > > > > > To: wagner at elegosoft.com; > > > > m3devel at elegosoft.com; > > > > jay.krell at cornell.edu > > > > > > > > > > Hi all: > > > > > great news to hear about a release coming > > soon, but > > > > how about testing NT386GNU or derivatives of it, > > would be > > > > hard to set up (I might try a friend's > > machine). > > > > > As I understood that was a great port to new > > Modula-3 > > > > programmers coming into the M3 world from win > > world. This > > > > doesn't have the all packages but is this a > > must to give > > > > have a check to release this port? > > > > > Any news from cvsup ticket #1080 > > https://projects.elego.de/cm3/ticket/1080 > > > > ? > > > > > Is there any chance to bring those platforms > > in final > > > > release? > > > > > Any difficulties to start trying that? > > > > > Thanks in advance > > > > > > > > > > --- El jue, 18/2/10, Jay K escribi?: > > > > > > > > > >> De: Jay K > > > > >> Asunto: Re: [M3devel] More testing > > needed for > > > > m3back, was: RE: m3back/longint/atomics > > > > >> Para: "Olaf" , > > "m3devel" > > > > >> Fecha: jueves, 18 de febrero, 2010 > > 16:26 > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> I added some testing, found/fixed bugs > > in the gcc > > > > >> backend (initializing constants, > > division). > > > > >> > > > > >> They should be in the automated tests > > already. > > > > >> > > > > >> However don't let this stop you from > > doing > > > > >> everything/anything you can think of. > > > > >> > > > > >> I didn't do all that much and you > > can save time > > > > and get > > > > >> more done by not worrying > > > > >> > > > > >> about the duplication. > > > > >> > > > > >> Pickles I didn't do anything with at > > all, so if > > > > you > > > > >> really want to avoid/delay duplication, > > > > >> > > > > >> start with them. > > > > >> > > > > >> > > > > >> > > > > >> - Jay > > > > >> > > > > >> > > > > >>> Date: Thu, 18 Feb 2010 17:20:56 > > +0100 > > > > >>> From: wagner at elegosoft.com > > > > >>> To: m3devel at elegosoft.com > > > > >>> Subject: Re: [M3devel] More testing > > needed for > > > > m3back, > > > > >> was: RE: m3back/longint/atomics > > > > >>> > > > > >>> Quoting "Coleburn, Randy" > > > > >> : > > > > >>> > > > > >>>> I can certainly run some tests > > on > > > > Windows. > > > > >>>> > > > > >>>> I don't have any code that > > uses longint, > > > > so > > > > >> either someone needs to > > > > >>>> identify which existing programs > > I can > > > > build and > > > > >> run to do the > > > > >>>> tests, OR I suppose I can write > > something > > > > if you > > > > >> can give me an idea > > > > >>>> of how extensive the tests you > > want. > > > > >>> > > > > >>> This sounds good! > > > > >>> > > > > >>> Some things that come to mind for > > LONGINT > > > > >> immeditately: > > > > >>> > > > > >>> o standard integer arithmetic (+, -, > > *, DIV, > > > > MOD) at > > > > >> runtime, > > > > >>> with and without overflows etc. > > > > >>> o constant declarations > > > > >>> o constant expressions > > > > >>> o assignability (should be rather > > strict; I'd > > > > have > > > > >> to check the mail > > > > >>> archive for the details) > > > > >>> o pickles > > > > >>> > > > > >>> It would be great if you could add > > some tests > > > > to > > > > >> m3tests that are > > > > >>> valid on all platforms. I expect > > that some > > > > should > > > > >> already be in place, > > > > >>> but haven't checked yet... > > > > >>> > > > > >>> Hm, a quick search for longint in > > > > >>> > > > > >>> > > > > >> > > http://hudson.modula3.com:8080/job/cm3-test-m3tests-FreeBSD4/ > > > > >>> > > > > >>> for example doesn't find > > anything. Has nobody > > > > >> added any LONGINT > > > > >>> test yet? Probably I'm looking > > for the wrong > > > > >> string... > > > > >>> > > > > >>> A complete regression with cm3 and > > other > > > > programs you > > > > >> may have available > > > > >>> would be great, too, just to make > > sure that > > > > the > > > > >> backend changes > > > > >>> don't break any old > > functionality. > > > > >>> > > > > >>> Olaf > > > > >>> > > > > >>>> > > > > >>>> I've been trying to keep my > > system updated > > > > to > > > > >> the latest sources on > > > > >>>> the main trunk, but I've > > been swamped > > > > lately > > > > >> and I'm afraid I'm a > > > > >>>> few weeks stale right now. > > I'll remedy > > > > that > > > > >> shortly. > > > > >>>> > > > > >>>> Regards, > > > > >>>> Randy > > > > >>>> > > > > >>>> > > ________________________________ > > > > >>>> From: Olaf Wagner > > [wagner at elegosoft.com] > > > > >>>> Sent: Thursday, February 18, > > 2010 6:57 AM > > > > >>>> To: Jay K > > > > >>>> Cc: m3devel > > > > >>>> Subject: [M3devel] More testing > > needed > > > > for > > > > >> m3back, was: RE: > > > > >>>> m3back/longint/atomics > > > > >>>> > > > > >>>> If I understand Jay correctly, > > it wouldn't > > > > be > > > > >> too difficult to bring > > > > >>>> the m3ack LONGINT changes for > > Windows into > > > > the > > > > >> release branch, but > > > > >>>> more testing would be needed. > > > > >>>> > > > > >>>> Randy, you're the only one I > > remember > > > > offhand > > > > >> who actively uses M3 > > > > >>>> on Windows except for Jay. Could > > you have > > > > a > > > > >> closer look at it? > > > > >>>> (Changes are only on the trunk > > right > > > > now.) > > > > >>>> > > > > >>>> Or is anybody else here lurking > > and eager > > > > to do > > > > >> some Windows-based tests? > > > > >>>> > > > > >>>> If nobody volunteers, I'm > > afraid we will > > > > have > > > > >> to release without 64bit > > > > >>>> LONGINT on Windows. > > > > >>>> > > > > >>>> Olaf > > > > >>>> > > > > >>>> Quoting Jay K : > > > > >>>> > > > > >>>>> NT386/longint changes are > > almost > > > > entirely in > > > > >> the m3back package. > > > > >>>>> > > > > >>>>> There is also some small > > easy stuff > > > > in > > > > >>>>> > > > > m3-libs/m3core/src/Csupport/common/hand.c. > > > > >>>>> > > > > >>>>> It'd be really great if > > anyone could > > > > test > > > > >> any of this and if > > > > >>>>> anyone could review the diff > > between > > > > release > > > > >> and head. > > > > >>>>> > > > > >>>>> Not just me. > > > > >>>>> > > > > >>>>> The changes for longint are > > quite > > > > large, even > > > > >> if local. > > > > >>>>> > > > > >>>>> I can port them, in the case > > of > > > > m3back, just > > > > >> copy, and make sure > > > > >>>>> the atomics stuff > > doesn't cause > > > > problems > > > > >> (it should be unused). > > > > >>>>> > > > > >>>>> There is also a small change > > in > > > > m3front so > > > > >> that longint can be initialized. > > > > >>>>> That affects all platforms. > > > > >>>>> > > > > >>>>> And a small change in > > m3cc/parse.c > > > > for > > > > >> div/mod of longint on non-NT386. > > > > >>>>> I have to test mod yet but > > my fix > > > > probably > > > > >> helps it. > > > > >>>>> > > > > >>>>> It'd be really great if > > anyone could > > > > do > > > > >> anything with this stuff. > > > > >>>>> ie. for now in head, then > > could easily > > > > port > > > > >> to release. > > > > >>>>> > > > > >>>>> We can of course release > > either way, > > > > >> depending on how satisfied people > > > > >>>>> are with 32bit longint on > > NT386. i.e. > > > > longint > > > > >> isn't useful portably, but it > > > > >>>>> is useful on non-NT386 > > platforms. > > > > >>>>> > > > > >>>>> - Jay > > > > >>>>> > > > > >>>>>> Date: Tue, 16 Feb 2010 > > 16:12:52 > > > > +0100 > > > > >>>>>> From: > > wagner at elegosoft.com > > > > >>>>>> To: > > m3devel at elegosoft.com > > > > >>>>>> Subject: Re: [M3devel] > > > > >> m3back/longint/atomics > > > > >>>>>> > > > > >>>>>> Quoting Jay K > > > > >> : > > > > >>>>>> > > > > >>>>>>> > > > > >>>>>>> As far as I > > know/can > > > > remember, > > > > >> longint and atomics should all work > > > > >>>>>>> now on NT386. > > > > >>>>>>> > > > > >>>>>>> Atomics only > > currently for > > > > 32bit > > > > >> types. > > > > >>>>>>> There are still a > > few small > > > > >> inefficiencies to maybe deal with. > > > > >>>>>>> I'll add 64bit > > shortly and > > > > maybe > > > > >> 8 and 16. > > > > >>>>>>> > > > > >>>>>>> > > > > >>>>>>> We should probably > > add *a lot* > > > > more > > > > >> test coverage in p226 and p227. > > > > >>>>>>> > > > > >>>>>>> e.g. longint > > > > >> multiply/add/sub/divide, not just > > insert/extract > > > > like I > > > > >>>>>>> did a bunch of. > > > > >>>>>> > > > > >>>>>> Any volunteers to > > increase the > > > > test > > > > >> coverage? > > > > >>>>>> > > > > >>>>>>> Still to fix the > > Win32 > > > > m3core/libm3 > > > > >> to not always truncate file sizes. > > > > >>>>>>> > > > > >>>>>>> Still maybe to do > > something > > > > about > > > > >> rd/wr...? > > > > >>>>>>> > > > > >>>>>>> Still to wonder > > about > > > > NT386/longint > > > > >> support in the release branch? > > > > >>>>>> > > > > >>>>>> Should we / will you > > merge this > > > > stuff to > > > > >> the release branch? > > > > >>>>>> Or should we release > > without it? > > > > How > > > > >> local are the changes? > > > > >>>>>> > > > > >>>>>> Olaf > > > > >>>> -- > > > > >>>> Olaf Wagner -- elego Software > > Solutions > > > > GmbH > > > > >>>> Gustav-Meyer-Allee 25 / Geb?ude > > 12, > > > > 13355 > > > > >> Berlin, Germany > > > > >>>> phone: +49 30 23 45 86 96 > > mobile: +49 177 > > > > 2345 > > > > >> 869 fax: +49 30 23 45 86 95 > > > > >>>> > > > > >> http://www.elegosoft.com | > > > > >> > > > > >>>> Gesch?ftsf?hrer: Olaf Wagner | > > Sitz: > > > > Berlin > > > > >>>> Handelregister: Amtsgericht > > Charlottenburg > > > > HRB > > > > >> 77719 | USt-IdNr: DE163214194 > > > > >>>> > > > > >>>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> -- > > > > >>> Olaf Wagner -- elego Software > > Solutions GmbH > > > > >>> Gustav-Meyer-Allee 25 / Geb?ude 12, > > 13355 > > > > Berlin, > > > > >> Germany > > > > >>> phone: +49 30 23 45 86 96 mobile: > > +49 177 2345 > > > > 869 > > > > >> fax: +49 30 23 45 86 95 > > > > >>> http://www.elegosoft.com | > > > > Gesch?ftsf?hrer: Olaf > > > > >> Wagner | Sitz: Berlin > > > > >>> Handelregister: Amtsgericht > > Charlottenburg HRB > > > > 77719 | > > > > >> USt-IdNr: DE163214194 > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 11:31:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 10:31:06 +0000 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int Message-ID: 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. Or TInt/TWord/.i3/.m3, since they know deeply about it. Having m3back know about them seems a bit off. Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. This is a minor dilemna though. 2) Are you sure having a fixed precision of 8 bytes is correct here? More generally are you sure TInt has the right interface? How does one check for overflow within the precision one cares about? I think I know. I think Chop should return a boolean, as to if the value fits. For that matter, have SignedChop and UnsignedChop. Or TInt.Chop and TWord.Chop. TInt.Chop is already SignedChop. Do the math in 64bits, if that overflows, then overflow. And then truncate to whatever, and that can overflow too. This is related to "you all have convinced me that overflow isn't all that important really, but range checking is". So you in sense defer the overflow. You don't do the complete overflow check at Add or whatever, but then you do a range check converting to a small size. But hm. This will skip "intermediate overflow". Does that matter? 1 billion * 8 / 8 Should that overflow in 32bits? Well, easy enough, do the chop after each operation. I said "defer", but it is brief. 1B * 8 / 8 isn't written as 1* 8 / 8 convert to 32bits but rather 1B * 8 convert to 32bits => failure here / 8 convert to 32bits ? 3) Related to #2. Where should RightShift insert zeros? I guess you chop first, and then it works. Proposed something like: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = CONST extension = 0; VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; But I have to back to your version of m3back and try these out. Very speculative at the moment. Could also leave the data alone upon failure, trivially related to previous: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); BEGIN FOR i := n TO LAST(Int) DO IF r[i] # extension THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := extension; END; RETURN TRUE; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO IF r[i] # 0 THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := 0; END; return TRUE; END Chop; I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. I'd prefer TInt.UnsignedChop and TInt.SignedChop. Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 11:39:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 10:39:13 +0000 Subject: [M3devel] diff -c vs. diff -u Message-ID: For the record, I don't like diff -c. In particular the use of "!" to show a changed line, without showing what was there before. diff -u and plain diff seem better. (Sometimes plain diff is superior, like if there is an unordered list of things, context doesn't matter.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 12:28:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 11:28:18 +0000 Subject: [M3devel] diffs in checkin comments Message-ID: I know I started this, and I'm still undecided, but, right now, the diffs in comments makes it hard to scroll through history, too much distance between versions. e.g. http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3 It would be super duper nice if the m3commit mail automatically included the (unified) diffs though. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 12:52:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 11:52:21 +0000 Subject: [M3devel] calling conventions (small proposal) Message-ID: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 21 13:34:51 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Feb 2010 13:34:51 +0100 Subject: [M3devel] LONGCARD, release branch... Message-ID: <1266755691.5451.1.camel@faramir.m3w.org> I would like to build release branch from sources.... Where can I get cm3-bin-min which knows about LONGCARD? -- Dragi?a Duri? From jay.krell at cornell.edu Sun Feb 21 13:57:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 12:57:57 +0000 Subject: [M3devel] LONGCARD, release branch... In-Reply-To: <1266755691.5451.1.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> Message-ID: You shouldn't need it. Really. Again. do this: Get almost any old release. I recently used 5.4 on LINUXLIBC6. Maybe that was with head instead of release. cd scripts/python ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py buildship skipgcc - Jay > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 21 Feb 2010 13:34:51 +0100 > Subject: [M3devel] LONGCARD, release branch... > > I would like to build release branch from sources.... Where can I get > cm3-bin-min which knows about LONGCARD? > -- > Dragi?a Duri? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 14:33:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 13:33:40 +0000 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int Message-ID: I *suspect* the "real" "big" problem is that left and right shift and "plain" shift should take a size. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu; m3devel at elegosoft.com Subject: opacity of Target.Int, overflow of Target.Int Date: Sun, 21 Feb 2010 10:31:06 +0000 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. Or TInt/TWord/.i3/.m3, since they know deeply about it. Having m3back know about them seems a bit off. Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. This is a minor dilemna though. 2) Are you sure having a fixed precision of 8 bytes is correct here? More generally are you sure TInt has the right interface? How does one check for overflow within the precision one cares about? I think I know. I think Chop should return a boolean, as to if the value fits. For that matter, have SignedChop and UnsignedChop. Or TInt.Chop and TWord.Chop. TInt.Chop is already SignedChop. Do the math in 64bits, if that overflows, then overflow. And then truncate to whatever, and that can overflow too. This is related to "you all have convinced me that overflow isn't all that important really, but range checking is". So you in sense defer the overflow. You don't do the complete overflow check at Add or whatever, but then you do a range check converting to a small size. But hm. This will skip "intermediate overflow". Does that matter? 1 billion * 8 / 8 Should that overflow in 32bits? Well, easy enough, do the chop after each operation. I said "defer", but it is brief. 1B * 8 / 8 isn't written as 1* 8 / 8 convert to 32bits but rather 1B * 8 convert to 32bits => failure here / 8 convert to 32bits ? 3) Related to #2. Where should RightShift insert zeros? I guess you chop first, and then it works. Proposed something like: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = CONST extension = 0; VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO result := (result AND (r[i] # extension)); r[i] := extension; END; return result; END Chop; But I have to back to your version of m3back and try these out. Very speculative at the moment. Could also leave the data alone upon failure, trivially related to previous: TInt: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); BEGIN FOR i := n TO LAST(Int) DO IF r[i] # extension THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := extension; END; RETURN TRUE; END Chop; TWord: PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = VAR result := TRUE; BEGIN FOR i := n TO LAST(Int) DO IF r[i] # 0 THEN RETURN FALSE; END; END; FOR i := n TO LAST(Int) DO r[i] := 0; END; return TRUE; END Chop; I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. I'd prefer TInt.UnsignedChop and TInt.SignedChop. Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Sun Feb 21 16:17:05 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 21 Feb 2010 16:17:05 +0100 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: References: <1266755691.5451.1.camel@faramir.m3w.org> Message-ID: <1266765425.5451.9.camel@faramir.m3w.org> Can you PLEASE enable other people to use this system, TOO. As we once used it, before all this moving-target-****?????? PLEASE, I just need minimal compiler runtime so I can use STANDARD scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT and RECODE every single time you found it INTERESTING and FUNNY to CHANGE ALL OVER????!!! And I thought I am INSIDE of this development process. Do we really think other people will not be bored by our change-it-all-again-and-again games??? Do I have to spend some fixed weekly time on this list so I won't miss LATEST and GREATEST IDEAS and PRACTICES? Sorry for all this "screaming" but I am really dissapointed to see all this changed AGAIN! What do you people think potentital users of this systems are?? And what measure of torturing people are ready to endure along the way? On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: > ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py > buildship skipgcc -- Dragi?a Duri? From hosking at cs.purdue.edu Sun Feb 21 20:23:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:23:20 -0500 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int In-Reply-To: References: Message-ID: <5637ACC9-D874-48B4-8071-2B1D3375DE7C@cs.purdue.edu> On 21 Feb 2010, at 05:31, Jay K wrote: > 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. > Or TInt/TWord/.i3/.m3, since they know deeply about it. > Having m3back know about them seems a bit off. > Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. > This is a minor dilemna though. Yeah, but it doesn't need to be totally opaque does it? An array of sign-extended bytes in little-endian order seems pretty general. You don't even need to specify the length of the array. I actually contemplated having TInt take open arrays of arbitrary length, with the result array length indicating the precision desired, but didn't do that just to maintain a simple implementation. > 2) Are you sure having a fixed precision of 8 bytes is correct here? There is nothing to stop it having more precision. In fact, increasing the size shouldn't affect any client code (so long as it uses appropriate array constructors to fill the sign in to the end, and performs bounds-checking to results to the desired precision, as well as checking the return values for potential overflow in whatever precision is implemented by TInt). > More generally are you sure TInt has the right interface? > How does one check for overflow within the precision one cares about? Bounds check. > I think I know. > I think Chop should return a boolean, as to if the value fits. No, because you may choose to ignore the high bits yet still want to sign-extend from the precision desired. That is exactly what I do for word operations in the front-end. > For that matter, have SignedChop and UnsignedChop. You should not need these. > Or TInt.Chop and TWord.Chop. What do you need TWord.Chop for. For example, TWord.And(val, Target.Word.max) gives me just the bits I need for a Word.Size full value. Take a look at the (relatively small number of) changes I made to the front-end to do the appropriate checks and conversions. > TInt.Chop is already SignedChop. > > Do the math in 64bits, if that overflows, then overflow. > And then truncate to whatever, and that can overflow too. > This is related to "you all have convinced me that overflow isn't > all that important really, but range checking is". > So you in sense defer the overflow. You don't do the complete > overflow check at Add or whatever, but then you do a range > check converting to a small size. > > But hm. This will skip "intermediate overflow". Does that matter? > 1 billion * 8 / 8 > > > Should that overflow in 32bits? > > > Well, easy enough, do the chop after each operation. > I said "defer", but it is brief. > 1B * 8 / 8 > isn't written as > 1* 8 / 8 > convert to 32bits > > but rather > 1B * 8 > convert to 32bits > => failure here > / 8 > convert to 32bits > > ? > > > 3) Related to #2. > Where should RightShift insert zeros? > I guess you chop first, and then it works. > > > Proposed something like: > > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > CONST extension = 0; > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > > > But I have to back to your version of m3back and try these out. > Very speculative at the moment. > > Could also leave the data alone upon failure, trivially related to previous: > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # extension THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := extension; > END; > RETURN TRUE; > END Chop; > > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # 0 THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := 0; > END; > return TRUE; > END Chop; > > > I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. > I'd prefer TInt.UnsignedChop and TInt.SignedChop. > Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. > > > Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". > (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 20:24:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:24:12 -0500 Subject: [M3devel] opacity of Target.Int, overflow of Target.Int In-Reply-To: References: Message-ID: <3F542805-0277-4334-BBD2-11D33231D22F@cs.purdue.edu> On 21 Feb 2010, at 08:33, Jay K wrote: > I *suspect* the "real" "big" problem is that left and right shift and "plain" shift should take a size. No! Simply mask the bits you want and perform the shift right, or shift left and mask the result. Easy! > > - Jay > > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: opacity of Target.Int, overflow of Target.Int > Date: Sun, 21 Feb 2010 10:31:06 +0000 > > 1) Tony, I claim that if Target.Int is really opaque, then values of it should only be formed in Target.i3/Target.m3. > Or TInt/TWord/.i3/.m3, since they know deeply about it. > Having m3back know about them seems a bit off. > Granted, pushing constants that only m3back uses into Target/TInt/TWord isn't great either, pollutes them some. > This is a minor dilemna though. > > > 2) Are you sure having a fixed precision of 8 bytes is correct here? > More generally are you sure TInt has the right interface? > How does one check for overflow within the precision one cares about? > I think I know. > I think Chop should return a boolean, as to if the value fits. > For that matter, have SignedChop and UnsignedChop. > Or TInt.Chop and TWord.Chop. > TInt.Chop is already SignedChop. > > Do the math in 64bits, if that overflows, then overflow. > And then truncate to whatever, and that can overflow too. > This is related to "you all have convinced me that overflow isn't > all that important really, but range checking is". > So you in sense defer the overflow. You don't do the complete > overflow check at Add or whatever, but then you do a range > check converting to a small size. > > But hm. This will skip "intermediate overflow". Does that matter? > 1 billion * 8 / 8 > > > Should that overflow in 32bits? > > > Well, easy enough, do the chop after each operation. > I said "defer", but it is brief. > 1B * 8 / 8 > isn't written as > 1* 8 / 8 > convert to 32bits > > but rather > 1B * 8 > convert to 32bits > => failure here > / 8 > convert to 32bits > > ? > > > 3) Related to #2. > Where should RightShift insert zeros? > I guess you chop first, and then it works. > > > Proposed something like: > > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > CONST extension = 0; > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > result := (result AND (r[i] # extension)); > r[i] := extension; > END; > return result; > END Chop; > > > > But I have to back to your version of m3back and try these out. > Very speculative at the moment. > > Could also leave the data alone upon failure, trivially related to previous: > > TInt: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR extension := Mask * ORD(And (r [n-1], SignMask) = 0); > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # extension THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := extension; > END; > RETURN TRUE; > END Chop; > > > TWord: > PROCEDURE Chop (VAR r: Int; n: CARDINAL): BOOLEAN = > VAR result := TRUE; > BEGIN > FOR i := n TO LAST(Int) DO > IF r[i] # 0 THEN > RETURN FALSE; > END; > END; > FOR i := n TO LAST(Int) DO > r[i] := 0; > END; > return TRUE; > END Chop; > > > I'm not sure I like the subtlety of TInt.Chop vs. TWord.Chop. > I'd prefer TInt.UnsignedChop and TInt.SignedChop. > Granted, "Un" doesn't exactly stand out, but at least "signed" does and makes you wonder about and discover the existance of signed vs. unsigned. > > > Alternatively Chop and UChop. More subtle, but I think plenty programmars are used to the names "uchar", "ushort", "uint", "ulong". "u" is pretty widely recognized as meaning "unsigned". More so I believe than "Word". > (I still don't like the name "interface Long"!, it doesn't imply unsigned at all!) > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 20:30:50 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 14:30:50 -0500 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <1266765425.5451.9.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> <1266765425.5451.9.camel@faramir.m3w.org> Message-ID: <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> Hi Dragisa, I too am a luddite and have never used any of Jay's scripts. I even still have essentially the same *old* monolithic config files on my system. Here is the general strategy. Take an old release. Compile and ship the following in order... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *old* libraries (m3core, libm3, sysutils). Now, compile and ship new libraries using the new compiler... m3core libm3 sysutils And build a new compiler against the new libraries... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *new* libraries. You should now be able to rebuild everything using the new compiler. Hope this helps! -- Tony (PS Let me know if you have any problems with this. I have a feeling there are some tweaks I have made to the m3makefiles to make this go through smoothly.) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 21 Feb 2010, at 10:17, Dragi?a Duri? wrote: > Can you PLEASE enable other people to use this system, TOO. As we once > used it, before all this moving-target-****?????? > > PLEASE, I just need minimal compiler runtime so I can use STANDARD > scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT > and RECODE every single time you found it INTERESTING and FUNNY to > CHANGE ALL OVER????!!! > > And I thought I am INSIDE of this development process. Do we really > think other people will not be bored by our > change-it-all-again-and-again games??? Do I have to spend some fixed > weekly time on this list so I won't miss LATEST and GREATEST IDEAS and > PRACTICES? > > Sorry for all this "screaming" but I am really dissapointed to see all > this changed AGAIN! What do you people think potentital users of this > systems are?? And what measure of torturing people are ready to endure > along the way? > > > On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: >> ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py >> buildship skipgcc > -- > Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 21 21:09:28 2010 From: darko at darko.org (Darko) Date: Mon, 22 Feb 2010 07:09:28 +1100 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:09:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:09:28 +0000 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> References: <1266755691.5451.1.camel@faramir.m3w.org>, , <1266765425.5451.9.camel@faramir.m3w.org>, <76E36BEB-FA86-475B-846B-49B0E041A8E8@cs.purdue.edu> Message-ID: Dragisa, I didn't change or break anything here. You can use the older upgrade.sh, or you can do what Tony said. None of the options seem to be well known, neither mine nor the old ways. I find Tony's steps long and tedious, so much so that he made some mistakes below (sysutils isn't in old releases, so needs to be in the first pass (and the second pass), m3cc is needed at some point). Obviously others did too, as they where automated first in the *.sh files. Who can remember that order? I just made it all easier, automated, portable, maintainable. And I did it years ago. For some definition of easier/automated/portable/maintable. To me .sh is not maintainable, and .py is more portable -- I'd rather depend on Python than Cygwin. Writing .sh that works across Linux, *BSD, Solaris, seems to be quite a battle. I can't remember all the rules for "how to write portable .sh" (see the Autoconf documentation), and I witness Olaf struggle with that too, I can hardly grasp the .sh language in the first place, and I suspect it is "overly string based", in the genre of severely flawed languages like cmd and Tcl. (Look at what '{' and '}' mean in Tcl. They aren't lexically scoping, as they appear to be, they are actually a string escape mechanism.) However I still don't have OpenBSD/mips64 Python, and I use *.sh there (haven't been there in a while, small probably with libffi). The automated builds use mostly *.sh, though making the .msis and .debs use Python. Given a system - not written in C - with necessary circular dependencies - that doesn't use make/autoconf Not necessarily bad things any of them (circular dependencies are just unavoidable), it's never going to be among the easiest to build. Since I do occasionally go back to old releases, and find running cminstall annoying, I've made the current config files compatible with older releases. The .py scripts do upgrade them first. Where .sh probably doesn't. We do provide prebuilt binaries, just that I don't always know where to get them esp. up to date ones. - Jay From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 14:30:50 -0500 To: dragisha at m3w.org CC: m3devel at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3devel] LONGCARD, release branch... A R G H Hi Dragisa, I too am a luddite and have never used any of Jay's scripts. I even still have essentially the same *old* monolithic config files on my system. Here is the general strategy. Take an old release. Compile and ship the following in order... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *old* libraries (m3core, libm3, sysutils). Now, compile and ship new libraries using the new compiler... m3core libm3 sysutils And build a new compiler against the new libraries... m3middle m3objfile m3linker m3back m3front m3quake cm3 You now have a *new* compiler in cm3/TARGET/cm3 linked against the *new* libraries. You should now be able to rebuild everything using the new compiler. Hope this helps! -- Tony (PS Let me know if you have any problems with this. I have a feeling there are some tweaks I have made to the m3makefiles to make this go through smoothly.) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 21 Feb 2010, at 10:17, Dragi?a Duri? wrote: Can you PLEASE enable other people to use this system, TOO. As we once used it, before all this moving-target-****?????? PLEASE, I just need minimal compiler runtime so I can use STANDARD scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT and RECODE every single time you found it INTERESTING and FUNNY to CHANGE ALL OVER????!!! And I thought I am INSIDE of this development process. Do we really think other people will not be bored by our change-it-all-again-and-again games??? Do I have to spend some fixed weekly time on this list so I won't miss LATEST and GREATEST IDEAS and PRACTICES? Sorry for all this "screaming" but I am really dissapointed to see all this changed AGAIN! What do you people think potentital users of this systems are?? And what measure of torturing people are ready to endure along the way? On Sun, 2010-02-21 at 12:57 +0000, Jay K wrote: ./upgrade.py && ./do-cm3-std.py realclean skipgcc && ./do-cm3-std.py buildship skipgcc -- Dragi?a Duri? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:16:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:16:38 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Message-ID: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 21:54:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 15:54:13 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> Message-ID: <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Sun Feb 21 21:51:07 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Sun, 21 Feb 2010 15:51:07 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org> Message-ID: <20100221205107.GD17113@topoi.pooq.com> On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the > NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl The first time I read this, I think I misunderstood. Presumably you don't mean that *all* platforms should ignore. You mean that NT386/I386_CYGWIN/etc. should still interpret them? -- hendrik From hosking at cs.purdue.edu Sun Feb 21 22:42:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 16:42:06 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> Message-ID: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:47:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:47:31 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <20100221205107.GD17113@topoi.pooq.com> References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <20100221205107.GD17113@topoi.pooq.com> Message-ID: Right, of course. - Jay > Date: Sun, 21 Feb 2010 15:51:07 -0500 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] calling conventions (small proposal) > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > > > 1) All platforms should accept, but silently ignore, the > > NT386/I386_CYGWIN/etc. calling conventions: > > at least __stdcall, and __cdecl > > The first time I read this, I think I misunderstood. Presumably you > don't mean that *all* platforms should ignore. You mean that > NT386/I386_CYGWIN/etc. should still interpret them? > > -- hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 21 22:48:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 21 Feb 2010 21:48:31 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Message-ID: Its meaning varies per platform. On platforms it changes the calling convention. On other platforms it means do nothing. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:42:06 -0500 CC: darko at darko.org; m3devel at elegosoft.com To: jay.krell at cornell.edu Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Feb 21 22:52:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 21 Feb 2010 16:52:20 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> Message-ID: The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage some. >> >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. Besides, as long as no platform uses >> the same name to mean multiple things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Sun Feb 21 22:47:58 2010 From: darko at darko.org (Darko) Date: Mon, 22 Feb 2010 08:47:58 +1100 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> Message-ID: <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 10:52:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 09:52:21 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Feb 22 15:39:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Feb 2010 15:39:11 +0100 Subject: [M3devel] LONGCARD, release branch... A R G H In-Reply-To: <1266765425.5451.9.camel@faramir.m3w.org> References: <1266755691.5451.1.camel@faramir.m3w.org> <1266765425.5451.9.camel@faramir.m3w.org> Message-ID: <20100222153911.chn7guy1w4gs00s0@mail.elegosoft.com> Quoting Dragi?a Duri? : > Can you PLEASE enable other people to use this system, TOO. As we once > used it, before all this moving-target-****?????? > > PLEASE, I just need minimal compiler runtime so I can use STANDARD > scripts and PROCEDURES so I can use my RPM packaging I HAD TO REINVENT > and RECODE every single time you found it INTERESTING and FUNNY to > CHANGE ALL OVER????!!! > > And I thought I am INSIDE of this development process. Do we really > think other people will not be bored by our > change-it-all-again-and-again games??? Do I have to spend some fixed > weekly time on this list so I won't miss LATEST and GREATEST IDEAS and > PRACTICES? > > Sorry for all this "screaming" but I am really dissapointed to see all > this changed AGAIN! What do you people think potentital users of this > systems are?? And what measure of torturing people are ready to endure > along the way? Hi Dragisha, I don't think that anything has changed or become broken recently regarding the cm3 build, too. If you want to avoid the tedious upgrade path, you can always find some recent executables in the Hudson jobs' workspaces. They only follow the release branch currently though. For example, look at http://hudson.modula3.com:8080/job/cm3-build-LINUXLIBC6/ws/cm3/m3-sys/cm3/LINUXLIBC6/ for the Linux 32 bit platform. If the build isn't in progress right when you look, you should find the last built cm3 there. Of course you can do that for other target platforms, too, as long as the servers are up. I haven't started building RC5 yet, as more testing is going on for the 64 bit LONGINT changes in the integrated Windows backend. So there is no `official' package giving you the latest state as you seem to require. Hope this helps, Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From wagner at elegosoft.com Mon Feb 22 15:43:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 22 Feb 2010 15:43:50 +0100 Subject: [M3devel] diffs in checkin comments In-Reply-To: References: Message-ID: <20100222154350.npvj1ypb4kokcows@mail.elegosoft.com> Quoting Jay K : > I know I started this, and I'm still undecided, but, right now, the > diffs in comments makes it hard to scroll through history, too much > distance between versions. e.g. > http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3back/src/Stackx86.m3 Well, yes, actually diffs are derivable information and shouldn't be stored in the change log. > It would be super duper nice if the m3commit mail automatically > included the (unified) diffs though. Jay, I haven't got the time, but we would need to adapt one of the Perl scripts in the CVSROOT of cm3 to do that. I don't know how difficult it would be (and won't try as I'm not really good in Perl and haven't got the time right now), but a decent Perl hacker should be able to do the job quickly ;-) Any volunteers? Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Mon Feb 22 17:01:57 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 11:01:57 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu> <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu> <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 22:10:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 21:10:08 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Message-ID: >> But why would you have platform-dependent pragmas in code that is not platform-dependent? example of mostly portable + pragma: ? hand.c: ? #if !defined(_MSC_VER) && !defined(__stdcall) #define __stdcall /* nothing */ #endif ? void __stdcall set_singleton ANSI(( ulong a, ulong* s)) KR((a, s) ulong a; ulong* s;) { ulong a_word = a / SET_GRAIN; ulong a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } ? (gcc on Windows #defines __stdcall to __attribute__(something)) ? Not the best example -- this function doesn't seem well motivated. We probably need a CG.i3 function to do div and mod in one go, since the processors usually expose that. Though this case is with a constant power of two, so.. And m3front would be a little pressed to notice the opportunity? - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 11:01:57 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ignore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gratuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 22:31:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 21:31:04 +0000 Subject: [M3devel] "pragmas being ignorable" In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: > I thought that was the point of pragmas, that the compiler could freely ignore them and that they > did not involve the correctness of the program. This confuses me. I'm not sure I see the line between having important meaning and having ignorable meaning. Is it like, they affect only codegen and diagnostics but not front end type/semantic analysis? Like "inline" and "nowarn"? <* asserts *> definitely change the behavior of a program. But I guess "behavior" and "correctness" are different? A "correct" program will never fail an assert, therefore removing them from a "correct" program makes no difference? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 22 23:45:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 17:45:12 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu> Message-ID: This is C code... On 22 Feb 2010, at 16:10, Jay K wrote: > >> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a constant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different than "ign! ore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd probably gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage some. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. Besides, ! as long as no platform uses > the same name to mean multiple things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Feb 22 23:46:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 17:46:14 -0500 Subject: [M3devel] "pragmas being ignorable" In-Reply-To: References: , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, Message-ID: <69ACB693-C6BA-4165-B901-F82F3FCBAD4E@cs.purdue.edu> On 22 Feb 2010, at 16:31, Jay K wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they > > did not involve the correctness of the program. > > This confuses me. I'm not sure I see the line between having > important meaning and having ignorable meaning. > Is it like, they affect only codegen and diagnostics but not > front end type/semantic analysis? Like "inline" and "nowarn"? Yes. > <* asserts *> definitely change the behavior of a program. > But I guess "behavior" and "correctness" are different? Asserts are benign so long as the program never violates the assertion. > A "correct" program will never fail an assert, therefore > removing them from a "correct" program makes no difference? Correct! And there is a compiler flag that lets you compile with assertions turned off... > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Feb 22 23:59:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 22 Feb 2010 22:59:36 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , Message-ID: There is an analog to Modula-3. Setting the calling convention on platforms that have them. "Doing nothing" on others. - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 17:45:12 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) This is C code... On 22 Feb 2010, at 16:10, Jay K wrote: >> But why would you have platform-dependent pragmas in code that is not platform-dependent? example of mostly portable + pragma: ? hand.c: ? #if !defined(_MSC_VER) && !defined(__stdcall) #define __stdcall /* nothing */ #endif ? void __stdcall set_singleton ANSI(( ulong a, ulong* s)) KR((a, s) ulong a; ulong* s;) { ulong a_word = a / SET_GRAIN; ulong a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } ? (gcc on Windows #defines __stdcall to __attribute__(something)) ? Not the best example -- this function doesn't seem well motivated. We probably need a CG.i3 function to do div and mod in one go, since the processors usually expose that. Though this case is with a constant power of two, so.. And m3front would be a little pressed to notice the opportunity? - Jay From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 11:01:57 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; darko at darko.org Subject: Re: [M3devel] calling conventions (small proposal) Pragmas should never give errors. If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 04:52, Jay K wrote: I wouldn't mind - an error - or a way to mark a pragma as needing an error vs. being ok with a warning Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. In fact, maybe this stuff doesn't belong in <* *>. I don't care much what the syntax is, but there is a legitimate need to note calling conventions, a syntax is already in use. I'd rather not invent a new syntax. The word "ignore" isn't relevant. Sorry if I was confusing. The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. but that most platforms interpret them as doing nothing. The pragmas already exist. "Recognize and do nothing" is much different than "ign! ore stuff that isn't recognized". - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 16:52:20 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org The compiler does continue to compile having warned that the pragma has no meaning. So, yes, they are ignored, but I want a warning. I even want a warning if I write <**>. On 21 Feb 2010, at 16:47, Darko wrote: I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. On 22/02/2010, at 8:42 AM, Tony Hosking wrote: Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. On 21 Feb 2010, at 16:16, Jay K wrote: To be clear, I don't propose ignoring all unrecognized pragmas. Just calling conventions. You could interpret it as: The pragmas *are* recognized, on all targets, but they have no meaning on most. The meaning is "do nothing". Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility with I386_NT source. And they all mean nothing. This lets people maintain one portable code base, and they *don't* even need to do so much as: #ifndef _X86_ #define __stdcall /* nothing */ #define __cdecl /* nothing */ #define __fastcall /* nothing */ #endif I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. The rest are a pointless proliferation of synonyms. Though that'd probably gr! atuitously break stuff (of course I can fix the entire cm3 tree in a few minutes, that's not the issue). Separate file would work, but I'd really rather stuff be all together. Once you separate things, one version goes stale. - Jay Subject: Re: [M3devel] calling conventions (small proposal) From: hosking at cs.purdue.edu Date: Sun, 21 Feb 2010 15:54:13 -0500 CC: jay.krell at cornell.edu; m3devel at elegosoft.com To: darko at darko.org Accepting and silently ignoring sounds very dangerous! I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. Silence is deadly! On 21 Feb 2010, at 15:09, Darko wrote: This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. On 21/02/2010, at 10:52 PM, Jay K wrote: 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: at least __stdcall, and __cdecl Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, This is a very small change. This is will allow: a) possibly merging the two nearly identical OpenGL.i3 files b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf I intend to that for hand.c's replacement, soon. Maybe experiment as to the perf. __stdcall is supposed to be faster, because the code is smaller. But __cdecl might be able to compete by using stores to the stack instead of pushes? I'd have to see how that compares in size, and it does increase stack usage some. ! Probably not worth large scale experimenting/changing, but maybe nice to mark new functions/interfaces as __stdcall (see next point). I was actually thinking of trying flat out changing the default, but I think that is too difficult, what with all the C<=>Modula-3 transitions. And not worth it given other more valuable work to do. 2) The calling convention pragmas should be allowed on an interface, to set the default for an interface. 2b) and I guess as well on a module, for unexported functions I assert that other than __stdcall and __cdecl on NT386, nothing else is particularly interesting here. There is __fastcall, maybe interesting. It has different meanings to different compilers. I'd rather keep this all fairly constrained. No other platform has more than one calling convention, so this doesn't have be to further generalized. Besides, ! as long as no platform uses the same name to mean multiple things, ok. Mac68K Classic? Mac68K CFM? Win16? MS-DOS? (I did recently acquire a working Mac68K, as well it is easily run on a modern PPC Mac; far down the list, but...) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Feb 23 02:05:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 20:05:46 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , Message-ID: <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? Again, I am very wary of platform-dependent pragmas in supposedly portable code! Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 17:59, Jay K wrote: > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > > >> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Feb 23 02:20:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 01:20:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> References: , ,,<8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , ,,<79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, ,,, ,,<477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, ,,<6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , ,,, ,,, , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> Message-ID: Two parts (sort of). 1) We do have what you describe -- __stdcall C code that Modula-3 calls. And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. I hope to get rid of that duplication. Later rather than earlier. 2) I want to write Modula-3 code that is __stdcall. We already have this, in platform specific code, e.g. the parameter to CreateThread. However I want to write code that is "otherwise" portable. In particular the replacements for hand.c Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:05:46 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > > > So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? > Again, I am very wary of platform-dependent pragmas in supposedly portable code! > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 17:59, Jay K wrote: > > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > >>> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > > From hosking at cs.purdue.edu Tue Feb 23 03:11:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 22 Feb 2010 21:11:27 -0500 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , , , <8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , , , <79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, , , , , , <477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, , , <6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , , , , , , , , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> Message-ID: Why would Modula-3 coded versions of hand.c need calling conventions? They are Modula-3 code which will use the standard Modula-3 calling convention to call from Modula-3! On 22 Feb 2010, at 20:20, Jay K wrote: > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> From jay.krell at cornell.edu Tue Feb 23 03:27:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 02:27:40 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: , ,,<8ADE1301-477C-47A5-B2E8-731E41052E9C@darko.org>, , ,,<79BF0B00-D4AA-40C8-AB83-99B10DA939C3@cs.purdue.edu>, ,,, ,,<477534A4-C56E-4945-B1DB-A7022A50F262@cs.purdue.edu>, ,,<6646AEEB-7854-4D82-B163-C8901F6372CB@darko.org>, , ,,, ,,, , , <1CB579D0-5B42-4D34-8923-0CEBC138DD70@cs.purdue.edu>, , , , , , <5C419424-6C5C-4708-A3A2-9BA23409B03E@cs.purdue.edu> , Message-ID: > the standard Modula-3 calling convention I'm not sure I'm happy with the standard Modula-3 calling convention. It isn't the smaller one. - Jay ---------------------------------------- > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 21:11:27 -0500 > CC: m3devel at elegosoft.com; darko at darko.org > To: jay.krell at cornell.edu > > Why would Modula-3 coded versions of hand.c need calling conventions? They are Modula-3 code which will use the standard Modula-3 calling convention to call from Modula-3! > > > On 22 Feb 2010, at 20:20, Jay K wrote: > >> >> Two parts (sort of). >> >> >> 1) >> We do have what you describe -- __stdcall C code that Modula-3 calls. >> And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. >> I hope to get rid of that duplication. Later rather than earlier. >> >> >> >> 2) >> I want to write Modula-3 code that is __stdcall. >> We already have this, in platform specific code, e.g. the parameter to CreateThread. >> However I want to write code that is "otherwise" portable. >> In particular the replacements for hand.c >> >> >> Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. >> >> >> >> 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). >> >> >> 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. >> >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 20:05:46 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> >>> >>> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >>> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 22 Feb 2010, at 17:59, Jay K wrote: >>> >>> There is an analog to Modula-3. >>> Setting the calling convention on platforms that have them. >>> "Doing nothing" on others. >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 17:45:12 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> This is C code... >>> >>> On 22 Feb 2010, at 16:10, Jay K wrote: >>> >>>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> >>> example of mostly portable + pragma: >>> >>> ? >>> hand.c: >>> ? >>> #if !defined(_MSC_VER) && !defined(__stdcall) >>> #define __stdcall /* nothing */ >>> #endif >>> ? >>> void __stdcall set_singleton >>> ANSI(( ulong a, ulong* s)) >>> KR((a, s) ulong a; ulong* s;) >>> { >>> ulong a_word = a / SET_GRAIN; >>> ulong a_bit = a % SET_GRAIN; >>> s[a_word] |= (1UL << a_bit); >>> } >>> ? >>> >>> (gcc on Windows #defines __stdcall to __attribute__(something)) >>> ? >>> >>> Not the best example -- this function doesn't seem well motivated. >>> We probably need a CG.i3 function to do div and mod in one go, since >>> the processors usually expose that. >>> Though this case is with a co! nstant power of two, so.. >>> And m3front would be a little pressed to notice the opportunity? >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 11:01:57 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> Pragmas should never give errors. >>> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 22 Feb 2010, at 04:52, Jay K wrote: >>> >>> I wouldn't mind >>> - an error >>> - or a way to mark a pragma as needing an error vs. being ok with a warning >>> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >>> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >>> the syntax is, but there is a legitimate need to note calling conventions, >>> a syntax is already in use. I'd rather not invent a new syntax. >>> >>> >>> The word "ignore" isn't relevant. >>> Sorry if I was confusing. >>> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >>> but that most platforms interpret them as doing nothing. >>> The pragmas already exist. >>> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 16:52:20 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> The compiler does continue to compile having warned that the pragma has no meaning. >>> >>> So, yes, they are ignored, but I want a warning. >>> >>> I even want a warning if I write <**>. >>> >>> >>> On 21 Feb 2010, at 16:47, Darko wrote: >>> >>> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >>> >>> >>> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >>> >>> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >>> >>> On 21 Feb 2010, at 16:16, Jay K wrote: >>> >>> To be clear, I don't propose ignoring all unrecognized pragmas. >>> Just calling conventions. >>> You could interpret it as: >>> The pragmas *are* recognized, on all targets, but they have no meaning on most. >>> The meaning is "do nothing". >>> >>> >>> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >>> with I386_NT source. And they all mean nothing. This lets people maintain >>> one portable code base, and they *don't* even need to do so much as: >>> #ifndef _X86_ >>> #define __stdcall /* nothing */ >>> #define __cdecl /* nothing */ >>> #define __fastcall /* nothing */ >>> #endif >>> >>> >>> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >>> The rest are a pointless proliferation of synonyms. >>> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >>> a few minutes, that's not the issue). >>> >>> >>> Separate file would work, but I'd really rather stuff be all together. >>> Once you separate things, one version goes stale. >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 15:54:13 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> Accepting and silently ignoring sounds very dangerous! >>> >>> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >>> >>> Silence is deadly! >>> >>> On 21 Feb 2010, at 15:09, Darko wrote: >>> >>> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >>> >>> >>> >>> On 21/02/2010, at 10:52 PM, Jay K wrote: >>> >>> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >>> at least __stdcall, and __cdecl >>> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >>> >>> This is a very small change. >>> >>> >>> This is will allow: >>> a) possibly merging the two nearly identical OpenGL.i3 files >>> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >>> I intend to that for hand.c's replacement, soon. >>> >>> >>> Maybe experiment as to the perf. >>> __stdcall is supposed to be faster, because the code is smaller. >>> But __cdecl might be able to compete by using stores to the stack instead of pushes? >>> I'd have to see how that compares in size, and it does increase stack usage som! e. >>> ! >>> >>> Probably not worth large scale experimenting/changing, but maybe nice to mark >>> new functions/interfaces as __stdcall (see next point). >>> >>> >>> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >>> what with all the C<=>Modula-3 transitions. And not worth it given other >>> more valuable work to do. >>> >>> >>> 2) The calling convention pragmas should be allowed on an interface, to set >>> the default for an interface. >>> >>> 2b) and I guess as well on a module, for unexported functions >>> >>> I assert that other than __stdcall and __cdecl on NT386, nothing else is >>> particularly interesting here. There is __fastcall, maybe interesting. >>> It has different meanings to different compilers. >>> I'd rather keep this all fairly constrained. >>> >>> No other platform has more than one calling convention, so this doesn't >>> have be to further generalized. B! esides, ! as long as no platform uses >>> the same name to mean multipl e things, ok. >>> Mac68K Classic? >>> Mac68K CFM? >>> Win16? >>> MS-DOS? >>> >>> >>> (I did recently acquire a working Mac68K, as well it is easily >>> run on a modern PPC Mac; far down the list, but...) >>> >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > From darko at darko.org Tue Feb 23 05:03:55 2010 From: darko at darko.org (Darko) Date: Tue, 23 Feb 2010 15:03:55 +1100 Subject: [M3devel] calling conventions (small proposal) Message-ID: Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? -original message- Subject: RE: [M3devel] calling conventions (small proposal) From: Jay K Date: 23/02/2010 12:20 pm Two parts (sort of). 1) We do have what you describe -- __stdcall C code that Modula-3 calls. And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. I hope to get rid of that duplication. Later rather than earlier. 2) I want to write Modula-3 code that is __stdcall. We already have this, in platform specific code, e.g. the parameter to CreateThread. However I want to write code that is "otherwise" portable. In particular the replacements for hand.c Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. - Jay ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:05:46 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > > > So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? > Again, I am very wary of platform-dependent pragmas in supposedly portable code! > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 17:59, Jay K wrote: > > There is an analog to Modula-3. > Setting the calling convention on platforms that have them. > "Doing nothing" on others. > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 17:45:12 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > This is C code... > > On 22 Feb 2010, at 16:10, Jay K wrote: > >>> But why would you have platform-dependent pragmas in code that is not platform-dependent? > > > example of mostly portable + pragma: > > ? > hand.c: > ? > #if !defined(_MSC_VER) && !defined(__stdcall) > #define __stdcall /* nothing */ > #endif > ? > void __stdcall set_singleton > ANSI(( ulong a, ulong* s)) > KR((a, s) ulong a; ulong* s;) > { > ulong a_word = a / SET_GRAIN; > ulong a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > ? > > (gcc on Windows #defines __stdcall to __attribute__(something)) > ? > > Not the best example -- this function doesn't seem well motivated. > We probably need a CG.i3 function to do div and mod in one go, since > the processors usually expose that. > Though this case is with a co! nstant power of two, so.. > And m3front would be a little pressed to notice the opportunity? > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 11:01:57 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] calling conventions (small proposal) > > Pragmas should never give errors. > If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 22 Feb 2010, at 04:52, Jay K wrote: > > I wouldn't mind > - an error > - or a way to mark a pragma as needing an error vs. being ok with a warning > Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. > In fact, maybe this stuff doesn't belong in <* *>. I don't care much what > the syntax is, but there is a legitimate need to note calling conventions, > a syntax is already in use. I'd rather not invent a new syntax. > > > The word "ignore" isn't relevant. > Sorry if I was confusing. > The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. > but that most platforms interpret them as doing nothing. > The pragmas already exist. > "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 16:52:20 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > The compiler does continue to compile having warned that the pragma has no meaning. > > So, yes, they are ignored, but I want a warning. > > I even want a warning if I write <**>. > > > On 21 Feb 2010, at 16:47, Darko wrote: > > I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. > > > On 22/02/2010, at 8:42 AM, Tony Hosking wrote: > > Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. > > On 21 Feb 2010, at 16:16, Jay K wrote: > > To be clear, I don't propose ignoring all unrecognized pragmas. > Just calling conventions. > You could interpret it as: > The pragmas *are* recognized, on all targets, but they have no meaning on most. > The meaning is "do nothing". > > > Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility > with I386_NT source. And they all mean nothing. This lets people maintain > one portable code base, and they *don't* even need to do so much as: > #ifndef _X86_ > #define __stdcall /* nothing */ > #define __cdecl /* nothing */ > #define __fastcall /* nothing */ > #endif > > > I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. > The rest are a pointless proliferation of synonyms. > Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in > a few minutes, that's not the issue). > > > Separate file would work, but I'd really rather stuff be all together. > Once you separate things, one version goes stale. > > > - Jay > > ________________________________ > Subject: Re: [M3devel] calling conventions (small proposal) > From: hosking at cs.purdue.edu > Date: Sun, 21 Feb 2010 15:54:13 -0500 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: darko at darko.org > > Accepting and silently ignoring sounds very dangerous! > > I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. > > Silence is deadly! > > On 21 Feb 2010, at 15:09, Darko wrote: > > This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. > > > > On 21/02/2010, at 10:52 PM, Jay K wrote: > > 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: > at least __stdcall, and __cdecl > Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, > > This is a very small change. > > > This is will allow: > a) possibly merging the two nearly identical OpenGL.i3 files > b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf > I intend to that for hand.c's replacement, soon. > > > Maybe experiment as to the perf. > __stdcall is supposed to be faster, because the code is smaller. > But __cdecl might be able to compete by using stores to the stack instead of pushes? > I'd have to see how that compares in size, and it does increase stack usage som! e. > ! > > Probably not worth large scale experimenting/changing, but maybe nice to mark > new functions/interfaces as __stdcall (see next point). > > > I was actually thinking of trying flat out changing the default, but I think that is too difficult, > what with all the C<=>Modula-3 transitions. And not worth it given other > more valuable work to do. > > > 2) The calling convention pragmas should be allowed on an interface, to set > the default for an interface. > > 2b) and I guess as well on a module, for unexported functions > > I assert that other than __stdcall and __cdecl on NT386, nothing else is > particularly interesting here. There is __fastcall, maybe interesting. > It has different meanings to different compilers. > I'd rather keep this all fairly constrained. > > No other platform has more than one calling convention, so this doesn't > have be to further generalized. B! esides, ! as long as no platform uses > the same name to mean multipl e things, ok. > Mac68K Classic? > Mac68K CFM? > Win16? > MS-DOS? > > > (I did recently acquire a working Mac68K, as well it is easily > run on a modern PPC Mac; far down the list, but...) > > > - Jay > > > > > > > > > > > > From jay.krell at cornell.edu Tue Feb 23 05:37:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 04:37:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: You mean like: module("foo") module_calling_convention("foo", "__stdcall") % default calling convention for module foo or calling_convention("foocall", "__stdcall") calling_convention("barcall", "__cdecl") foo.m3: <*foocall*> PROCEDURE Foo()... <*barcall*> PROCEDURE Bar()... Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. The integration of quake and Modula-3..like.. "confuses" me. That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. If I look for analogies however..in C and C++ you can do something like easily enough Makefile: !if WIN32 CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl !else CFLAGS=-DFOOCALL= -DBARCALL= !endif so maybe not a bad idea? To repeat myself, we already have the following valid working syntax, on NT386: foo.i3 <*__stdcall*> PROCEDURE Foo()... foo.m3 <*__stdcall*> PROCEDURE Foo()... They have to match I believe. Of course the procedure doesn't necessarily occur in the .i3 file. My proposal is two part. 1) Accept the existing syntax on all platforms. The interpretion is "do nothing" on most platforms. 2) Allow the existing pragmas on interface/module also: <*__stdcall*> INTERFACE Foo... <*__stdcall*> MODULE Foo... #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. #2 allows for less repetition. This will let me use the possibly more efficient non-default calling convention for hand.c replacement. And possibly avoid having two nearly identical OpenGL.i3 files. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 15:03:55 +1100 > > Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 12:20 pm > > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> > From darko at darko.org Tue Feb 23 07:44:01 2010 From: darko at darko.org (Darko) Date: Tue, 23 Feb 2010 17:44:01 +1100 Subject: [M3devel] calling conventions (small proposal) Message-ID: Calling convention is almost a linking issue it seems pretty good idea to move it to the makefile somehow since it reduces portability otherwise -original message- Subject: RE: [M3devel] calling conventions (small proposal) From: Jay K Date: 23/02/2010 3:37 pm You mean like: module("foo") module_calling_convention("foo", "__stdcall") % default calling convention for module foo or calling_convention("foocall", "__stdcall") calling_convention("barcall", "__cdecl") foo.m3: <*foocall*> PROCEDURE Foo()... <*barcall*> PROCEDURE Bar()... Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. The integration of quake and Modula-3..like.. "confuses" me. That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. If I look for analogies however..in C and C++ you can do something like easily enough Makefile: !if WIN32 CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl !else CFLAGS=-DFOOCALL= -DBARCALL= !endif so maybe not a bad idea? To repeat myself, we already have the following valid working syntax, on NT386: foo.i3 <*__stdcall*> PROCEDURE Foo()... foo.m3 <*__stdcall*> PROCEDURE Foo()... They have to match I believe. Of course the procedure doesn't necessarily occur in the .i3 file. My proposal is two part. 1) Accept the existing syntax on all platforms. The interpretion is "do nothing" on most platforms. 2) Allow the existing pragmas on interface/module also: <*__stdcall*> INTERFACE Foo... <*__stdcall*> MODULE Foo... #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. #2 allows for less repetition. This will let me use the possibly more efficient non-default calling convention for hand.c replacement. And possibly avoid having two nearly identical OpenGL.i3 files. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 15:03:55 +1100 > > Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 12:20 pm > > > Two parts (sort of). > > > 1) > We do have what you describe -- __stdcall C code that Modula-3 calls. > And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. > I hope to get rid of that duplication. Later rather than earlier. > > > > 2) > I want to write Modula-3 code that is __stdcall. > We already have this, in platform specific code, e.g. the parameter to CreateThread. > However I want to write code that is "otherwise" portable. > In particular the replacements for hand.c > > > Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. > > > > 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). > > > 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. > > > > - Jay > > > ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 20:05:46 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> >> >> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> >> >> On 22 Feb 2010, at 17:59, Jay K wrote: >> >> There is an analog to Modula-3. >> Setting the calling convention on platforms that have them. >> "Doing nothing" on others. >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 17:45:12 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> This is C code... >> >> On 22 Feb 2010, at 16:10, Jay K wrote: >> >>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> >> example of mostly portable + pragma: >> >> ? >> hand.c: >> ? >> #if !defined(_MSC_VER) && !defined(__stdcall) >> #define __stdcall /* nothing */ >> #endif >> ? >> void __stdcall set_singleton >> ANSI(( ulong a, ulong* s)) >> KR((a, s) ulong a; ulong* s;) >> { >> ulong a_word = a / SET_GRAIN; >> ulong a_bit = a % SET_GRAIN; >> s[a_word] |= (1UL << a_bit); >> } >> ? >> >> (gcc on Windows #defines __stdcall to __attribute__(something)) >> ? >> >> Not the best example -- this function doesn't seem well motivated. >> We probably need a CG.i3 function to do div and mod in one go, since >> the processors usually expose that. >> Though this case is with a co! nstant power of two, so.. >> And m3front would be a little pressed to notice the opportunity? >> >> >> - Jay >> >> >> ________________________________ >> From: hosking at cs.purdue.edu >> Date: Mon, 22 Feb 2010 11:01:57 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com; darko at darko.org >> Subject: Re: [M3devel] calling conventions (small proposal) >> >> Pragmas should never give errors. >> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Office +1 765 494 6001 | Mobile +1 765 427 5484 >> >> >> >> >> On 22 Feb 2010, at 04:52, Jay K wrote: >> >> I wouldn't mind >> - an error >> - or a way to mark a pragma as needing an error vs. being ok with a warning >> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >> the syntax is, but there is a legitimate need to note calling conventions, >> a syntax is already in use. I'd rather not invent a new syntax. >> >> >> The word "ignore" isn't relevant. >> Sorry if I was confusing. >> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >> but that most platforms interpret them as doing nothing. >> The pragmas already exist. >> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 16:52:20 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> The compiler does continue to compile having warned that the pragma has no meaning. >> >> So, yes, they are ignored, but I want a warning. >> >> I even want a warning if I write <**>. >> >> >> On 21 Feb 2010, at 16:47, Darko wrote: >> >> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >> >> >> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >> >> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >> >> On 21 Feb 2010, at 16:16, Jay K wrote: >> >> To be clear, I don't propose ignoring all unrecognized pragmas. >> Just calling conventions. >> You could interpret it as: >> The pragmas *are* recognized, on all targets, but they have no meaning on most. >> The meaning is "do nothing". >> >> >> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >> with I386_NT source. And they all mean nothing. This lets people maintain >> one portable code base, and they *don't* even need to do so much as: >> #ifndef _X86_ >> #define __stdcall /* nothing */ >> #define __cdecl /* nothing */ >> #define __fastcall /* nothing */ >> #endif >> >> >> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >> The rest are a pointless proliferation of synonyms. >> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >> a few minutes, that's not the issue). >> >> >> Separate file would work, but I'd really rather stuff be all together. >> Once you separate things, one version goes stale. >> >> >> - Jay >> >> ________________________________ >> Subject: Re: [M3devel] calling conventions (small proposal) >> From: hosking at cs.purdue.edu >> Date: Sun, 21 Feb 2010 15:54:13 -0500 >> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >> To: darko at darko.org >> >> Accepting and silently ignoring sounds very dangerous! >> >> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >> >> Silence is deadly! >> >> On 21 Feb 2010, at 15:09, Darko wrote: >> >> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >> >> >> >> On 21/02/2010, at 10:52 PM, Jay K wrote: >> >> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >> at least __stdcall, and __cdecl >> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >> >> This is a very small change. >> >> >> This is will allow: >> a) possibly merging the two nearly identical OpenGL.i3 files >> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >> I intend to that for hand.c's replacement, soon. >> >> >> Maybe experiment as to the perf. >> __stdcall is supposed to be faster, because the code is smaller. >> But __cdecl might be able to compete by using stores to the stack instead of pushes? >> I'd have to see how that compares in size, and it does increase stack usage som! e. >> ! >> >> Probably not worth large scale experimenting/changing, but maybe nice to mark >> new functions/interfaces as __stdcall (see next point). >> >> >> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >> what with all the C<=>Modula-3 transitions. And not worth it given other >> more valuable work to do. >> >> >> 2) The calling convention pragmas should be allowed on an interface, to set >> the default for an interface. >> >> 2b) and I guess as well on a module, for unexported functions >> >> I assert that other than __stdcall and __cdecl on NT386, nothing else is >> particularly interesting here. There is __fastcall, maybe interesting. >> It has different meanings to different compilers. >> I'd rather keep this all fairly constrained. >> >> No other platform has more than one calling convention, so this doesn't >> have be to further generalized. B! esides, ! as long as no platform uses >> the same name to mean multipl e things, ok. >> Mac68K Classic? >> Mac68K CFM? >> Win16? >> MS-DOS? >> >> >> (I did recently acquire a working Mac68K, as well it is easily >> run on a modern PPC Mac; far down the list, but...) >> >> >> - Jay >> >> >> >> >> >> >> >> >> >> >> >> > From jay.krell at cornell.edu Tue Feb 23 08:33:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 07:33:10 +0000 Subject: [M3devel] calling conventions (small proposal) In-Reply-To: References: Message-ID: I don't understand. Assuming there are precious few calling conventions in the world, beyond 1 per platform, it seems fine as I propose. Oh, I think I see what you mean though. If you imagine multiple platforms with multiple calling conventions, then you'd want to intercede one portable name that is then redefined on a per-platform basis? My proposal either assumes there is one (set of) platform with any calling conventions (the same ones) OR, at least, that the names don't overlap across platforms with different meaning. That is, NT386 has __stcall, __cdecl. I write: INTERFACE Foo; <*__stdcall*>PROCEDURE Bar(); then future platform WIERD comes along and it has a calling convention "wierdcall". In this unlikely hypothetical world, I'd propose you write: <*wierdcall*><*__stdcall*>PROCEDURE Bar(); All platforms would be taught to recognize the pragma wierdcall, and the interpretation would be to do nothing except for target WIERD. The problem becomes if target WIERD has conventions, say, wierdcall and __stdcall, and you want __stcall on NT386 but wierdcall on WIERD. Then the above is ambiguous. But you could repair the unlikely problem after the fact, by using longer/diferent names when clashes come along. We'd stomp on __stdcall today for NT386, because it has been around a long time and is likely to remain unique. If WIERD comes along later with __stdcall, ok, we'd just call it weird__stdcall, and you'd write: <*wierd__stdcall*><*__stdcall*>PROCEDURE Foo(); ? If you wrote <*wierdcall__stdcall*><*wierdcall*>PROCEDURE Foo(); that would be an error, at least when targeting target WIERD. Just as, today, I hope, <*__stdcall*><*__cdecl*>PROCEDURE Foo() is an error. This is *slightly* complicated -- the long term hypothetical proposal is that multiple calling convension pragmas be allowed, depending on what exactly they are. Again remember that it is highly unusual for any platform to have multiple calling conventions, so this "problem" is not likely to grow. Does ARM have serious issues here? I know they have all kinds of execution modes. But I think Debian, for example, has two ARM platforms, and one calling convention each. ? Again, minimal is 1) allow existing NT386 syntax on all targets 2) possibly allow existing NT386 procedure pragma on modules/interfaces Is your desire to annotate something with "FOOCALL" and then experiment in m3makefile with mapping FOOCALL to one convention or another? And it would be multiple files, so the terseness of an interface/module pragma is not terse enough, it'd be too much to copy/paste? I can see that scenario. Can we at least agree on my #1, maybe my #2, and extend it after that? #1 is about two lines of change. I'll do it pretty soon. I just haven't gotten to it yet. - Jay ---------------------------------------- > From: darko at darko.org > To: jay.krell at cornell.edu > CC: hosking at cs.purdue.edu; m3devel at elegosoft.com > Subject: RE: [M3devel] calling conventions (small proposal) > Date: Tue, 23 Feb 2010 17:44:01 +1100 > > Calling convention is almost a linking issue it seems pretty good idea to move it to the makefile somehow since it reduces portability otherwise > > -original message- > Subject: RE: [M3devel] calling conventions (small proposal) > From: Jay K > Date: 23/02/2010 3:37 pm > > > You mean like: > > > module("foo") > module_calling_convention("foo", "__stdcall") > % default calling convention for module foo > > > or > calling_convention("foocall", "__stdcall") > calling_convention("barcall", "__cdecl") > > > foo.m3: > <*foocall*> PROCEDURE Foo()... > <*barcall*> PROCEDURE Bar()... > > > Almost anything is possible -- what with the quake implementation and Modula-3 front end being the same program, but I'd rather not. > > > The integration of quake and Modula-3..like.. "confuses" me. > That is, it blurs the line as to what /should/ be done vs. what /can/ be done, because it makes so many things easy. > > If I look for analogies however..in C and C++ you can do something like easily enough > Makefile: > !if WIN32 > CFLAGS=-DFOOCALL=__stdcall -DBARCALL=__cdecl > !else > CFLAGS=-DFOOCALL= -DBARCALL= > !endif > > > so maybe not a bad idea? > > > > > To repeat myself, we already have the following valid working syntax, on NT386: > > > foo.i3 > <*__stdcall*> PROCEDURE Foo()... > > foo.m3 > <*__stdcall*> PROCEDURE Foo()... > > They have to match I believe. > Of course the procedure doesn't necessarily occur in the .i3 file. > > > My proposal is two part. > > 1) Accept the existing syntax on all platforms. > The interpretion is "do nothing" on most platforms. > > > 2) Allow the existing pragmas on interface/module also: > > <*__stdcall*> INTERFACE Foo... > > <*__stdcall*> MODULE Foo... > > > #1 is sufficient and a very small change and introduces no new syntax, merely allows existing NT386-specific syntax to be used on all platforms. > > > #2 allows for less repetition. > > > This will let me use the possibly more efficient non-default calling convention for hand.c replacement. > > > And possibly avoid having two nearly identical OpenGL.i3 files. > > > - Jay > > > ---------------------------------------- >> From: darko at darko.org >> To: jay.krell at cornell.edu >> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com >> Subject: RE: [M3devel] calling conventions (small proposal) >> Date: Tue, 23 Feb 2010 15:03:55 +1100 >> >> Can we have the pragma refer to a symbol defined in the makefile which nominates the actual calling convention? >> >> -original message- >> Subject: RE: [M3devel] calling conventions (small proposal) >> From: Jay K >> Date: 23/02/2010 12:20 pm >> >> >> Two parts (sort of). >> >> >> 1) >> We do have what you describe -- __stdcall C code that Modula-3 calls. >> And then, for example, we have OpenGL.i3 for Win32 and non-Win32 that are nearly identical, except that Win32 has calling conventions. >> I hope to get rid of that duplication. Later rather than earlier. >> >> >> >> 2) >> I want to write Modula-3 code that is __stdcall. >> We already have this, in platform specific code, e.g. the parameter to CreateThread. >> However I want to write code that is "otherwise" portable. >> In particular the replacements for hand.c >> >> >> Declaring a calling convention should render the whole thing non-portable, should not cause one to copy/paste everything and just add/remove one identifier. We historically have had far too much duplication of nearly identical code in Modula-3. >> >> >> >> 2b) More generally I'm interested in trying __stdcall because it leads to smaller code (for certain code gen strategies. There might be a way in which __cdecl is smaller -- where you allocate room for all your calls up front and store to the stack, instead of push/pop -- currently every call costs the call and an add esp. Whereas with __stdcall the "add" is in the callee instead of the caller, same number of instructions executed, but fewer contributing to code size). >> >> >> 2c) More generally even if it isn't a significant win, I definitely believe it should be possible. A lot of "otherwise" portable C and C++ code is written this way -- to have explicit calling conventions on systems that have any, and "just the normal" on others. Only one platform in heavy use today has this messed up notion of varying calling convention. >> >> >> >> - Jay >> >> >> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 20:05:46 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> >>> >>> So, do you mean you want to have C code to which Modula-3 interfaces are defined that has the calling convention? >>> Again, I am very wary of platform-dependent pragmas in supposedly portable code! >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> >>> >>> On 22 Feb 2010, at 17:59, Jay K wrote: >>> >>> There is an analog to Modula-3. >>> Setting the calling convention on platforms that have them. >>> "Doing nothing" on others. >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 17:45:12 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> This is C code... >>> >>> On 22 Feb 2010, at 16:10, Jay K wrote: >>> >>>>> But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> >>> example of mostly portable + pragma: >>> >>> ? >>> hand.c: >>> ? >>> #if !defined(_MSC_VER) && !defined(__stdcall) >>> #define __stdcall /* nothing */ >>> #endif >>> ? >>> void __stdcall set_singleton >>> ANSI(( ulong a, ulong* s)) >>> KR((a, s) ulong a; ulong* s;) >>> { >>> ulong a_word = a / SET_GRAIN; >>> ulong a_bit = a % SET_GRAIN; >>> s[a_word] |= (1UL << a_bit); >>> } >>> ? >>> >>> (gcc on Windows #defines __stdcall to __attribute__(something)) >>> ? >>> >>> Not the best example -- this function doesn't seem well motivated. >>> We probably need a CG.i3 function to do div and mod in one go, since >>> the processors usually expose that. >>> Though this case is with a co! nstant power of two, so.. >>> And m3front would be a little pressed to notice the opportunity? >>> >>> >>> - Jay >>> >>> >>> ________________________________ >>> From: hosking at cs.purdue.edu >>> Date: Mon, 22 Feb 2010 11:01:57 -0500 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com; darko at darko.org >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> >>> Pragmas should never give errors. >>> If you are proposing that all platforms recognise the pragmas, but most do nothing with them, then I guess OK. But why would you have platform-dependent pragmas in code that is not platform-dependent? >>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue University >>> 305 N. University Street | West Lafayette | IN 47907 | USA >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 >>> >>> >>> >>> >>> On 22 Feb 2010, at 04:52, Jay K wrote: >>> >>> I wouldn't mind >>> - an error >>> - or a way to mark a pragma as needing an error vs. being ok with a warning >>> Though perhaps that shouldn't be a pragma but some other syntax not in <* *>. >>> In fact, maybe this stuff doesn't belong in <* *>. I don't care much what >>> the syntax is, but there is a legitimate need to note calling conventions, >>> a syntax is already in use. I'd rather not invent a new syntax. >>> >>> >>> The word "ignore" isn't relevant. >>> Sorry if I was confusing. >>> The proposal is that all targets recognize the pragmas __stdcall, __cdecl, etc. >>> but that most platforms interpret them as doing nothing. >>> The pragmas already exist. >>> "Recognize and do nothing" is much different ! than "ign! ore stuff that isn't recognized". >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 16:52:20 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> The compiler does continue to compile having warned that the pragma has no meaning. >>> >>> So, yes, they are ignored, but I want a warning. >>> >>> I even want a warning if I write <**>. >>> >>> >>> On 21 Feb 2010, at 16:47, Darko wrote: >>> >>> I thought that was the point of pragmas, that the compiler could freely ignore them and that they did not involve the correctness of the program. >>> >>> >>> On 22/02/2010, at 8:42 AM, Tony Hosking wrote: >>> >>> Yes, but my point is that a pragma that has no meaning *should* give a warning. Otherwise, why did I write it. >>> >>> On 21 Feb 2010, at 16:16, Jay K wrote: >>> >>> To be clear, I don't propose ignoring all unrecognized pragmas. >>> Just calling conventions. >>> You could interpret it as: >>> The pragmas *are* recognized, on all targets, but they have no meaning on most. >>> The meaning is "do nothing". >>> >>> >>> Look at the situation in C for AMD64_NT. Calling conventions are accepted for compatibility >>> with I386_NT source. And they all mean nothing. This lets people maintain >>> one portable code base, and they *don't* even need to do so much as: >>> #ifndef _X86_ >>> #define __stdcall /* nothing */ >>> #define __cdecl /* nothing */ >>> #define __fastcall /* nothing */ >>> #endif >>> >>> >>> I'd be willing to prune the "big" list of calling conventions down to just two: __stdcall, __cdecl. >>> The rest are a pointless proliferation of synonyms. >>> Though that'd proba! bly gr! atuitously break stuff (of course I can fix the entire cm3 tree in >>> a few minutes, that's not the issue). >>> >>> >>> Separate file would work, but I'd really rather stuff be all together. >>> Once you separate things, one version goes stale. >>> >>> >>> - Jay >>> >>> ________________________________ >>> Subject: Re: [M3devel] calling conventions (small proposal) >>> From: hosking at cs.purdue.edu >>> Date: Sun, 21 Feb 2010 15:54:13 -0500 >>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com >>> To: darko at darko.org >>> >>> Accepting and silently ignoring sounds very dangerous! >>> >>> I want my compiler to warn me when I use a pragma that is unrecognised for my particular target. >>> >>> Silence is deadly! >>> >>> On 21 Feb 2010, at 15:09, Darko wrote: >>> >>> This is a good idea. An alternate proposal would be to put the calling conventions in an external file, but this change would seem to be the simplest and in line with the stated definition of pragamas. >>> >>> >>> >>> On 21/02/2010, at 10:52 PM, Jay K wrote: >>> >>> 1) All platforms should accept, but silently ignore, the NT386/I386_CYGWIN/etc. calling conventions: >>> at least __stdcall, and __cdecl >>> Probably all the synonyms: C, WINAPI, CALLBACK, WINAPIV, APIENTRY, APIPRIVATE, PASCAL, >>> >>> This is a very small change. >>> >>> >>> This is will allow: >>> a) possibly merging the two nearly identical OpenGL.i3 files >>> b) implementing functions in Modula-3 that are portable, but use __stdcall, possibly for perf >>> I intend to that for hand.c's replacement, soon. >>> >>> >>> Maybe experiment as to the perf. >>> __stdcall is supposed to be faster, because the code is smaller. >>> But __cdecl might be able to compete by using stores to the stack instead of pushes? >>> I'd have to see how that compares in size, and it does increase stack usage som! e. >>> ! >>> >>> Probably not worth large scale experimenting/changing, but maybe nice to mark >>> new functions/interfaces as __stdcall (see next point). >>> >>> >>> I was actually thinking of trying flat out changing the default, but I think that is too difficult, >>> what with all the C<=>Modula-3 transitions. And not worth it given other >>> more valuable work to do. >>> >>> >>> 2) The calling convention pragmas should be allowed on an interface, to set >>> the default for an interface. >>> >>> 2b) and I guess as well on a module, for unexported functions >>> >>> I assert that other than __stdcall and __cdecl on NT386, nothing else is >>> particularly interesting here. There is __fastcall, maybe interesting. >>> It has different meanings to different compilers. >>> I'd rather keep this all fairly constrained. >>> >>> No other platform has more than one calling convention, so this doesn't >>> have be to further generalized. B! esides, ! as long as no platform uses >>> the same name to mean multipl e things, ok. >>> Mac68K Classic? >>> Mac68K CFM? >>> Win16? >>> MS-DOS? >>> >>> >>> (I did recently acquire a working Mac68K, as well it is easily >>> run on a modern PPC Mac; far down the list, but...) >>> >>> >>> - Jay >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > From hendrik at topoi.pooq.com Tue Feb 23 19:19:38 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 23 Feb 2010 13:19:38 -0500 Subject: [M3devel] Style question about error messages Message-ID: <20100223181937.GA22300@topoi.pooq.com> Somewhere in my program after it has trued and failed to read the input file, I have the code Wr.PutText(Stdio.stderr, "No input file.\n"); Now presumably this message could be more detailed, but that's not waht I'm asking. What happens to me when I compile this code is the warning: "../src/Main.m3", line 63: warning: potentially unhandled exceptions: Thread.Alerted, Wr.Failure Now presumably this is an indication that I ought to wrap the whole thing in a TRY clause. But what am I supposed to do if the attempt to produce an error message fails? Write an error message? What have other people done in this situation? --hendrik From hosking at cs.purdue.edu Tue Feb 23 20:15:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Feb 2010 14:15:32 -0500 Subject: [M3devel] Style question about error messages In-Reply-To: <20100223181937.GA22300@topoi.pooq.com> References: <20100223181937.GA22300@topoi.pooq.com> Message-ID: You can just record that exception as fatal in that code block with the <*FATAL Thread.Alerted*> pragma. On 23 Feb 2010, at 13:19, hendrik at topoi.pooq.com wrote: > Somewhere in my program after it has trued and failed to read the > input file, I have the code > > Wr.PutText(Stdio.stderr, "No input file.\n"); > > Now presumably this message could be more detailed, but that's not waht > I'm asking. What happens to me when I compile this code is the warning: > > "../src/Main.m3", line 63: warning: potentially unhandled exceptions: > Thread.Alerted, Wr.Failure > > Now presumably this is an indication that I ought to wrap the whole > thing in a TRY clause. But what am I supposed to do if the attempt to > produce an error message fails? Write an error message? > > What have other people done in this situation? > > --hendrik From rcolebur at SCIRES.COM Tue Feb 23 22:05:57 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 23 Feb 2010 16:05:57 -0500 Subject: [M3devel] Style question about error messages In-Reply-To: References: <20100223181937.GA22300@topoi.pooq.com> Message-ID: Hendrik: I have run into this situation also. If you have code that runs on multiple platforms, you have to think through the best way to handle. For example, code might work differently say between Unix and Windows. Indeed, if you have a Windows GUI mode program and try to write to stdout there is some magic that is used to allocate a console writer on the fly. Also, if you know you aren't using Alerts, you might be ok using the FATAL pragma as Tony suggests, but then for Wr.Failure you may want to take a different course. Also, depending on your program, you may want to trap both of these so you can clean up any other resource use before terminating the program. If you want more specifics, I can dig into some of my code for examples. Regards, Randy -----Original Message----- From: Tony Hosking [mailto:hosking at cs.purdue.edu] Sent: Tuesday, February 23, 2010 2:16 PM To: hendrik at topoi.pooq.com Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Style question about error messages You can just record that exception as fatal in that code block with the <*FATAL Thread.Alerted*> pragma. On 23 Feb 2010, at 13:19, hendrik at topoi.pooq.com wrote: > Somewhere in my program after it has trued and failed to read the > input file, I have the code > > Wr.PutText(Stdio.stderr, "No input file.\n"); > > Now presumably this message could be more detailed, but that's not waht > I'm asking. What happens to me when I compile this code is the warning: > > "../src/Main.m3", line 63: warning: potentially unhandled exceptions: > Thread.Alerted, Wr.Failure > > Now presumably this is an indication that I ought to wrap the whole > thing in a TRY clause. But what am I supposed to do if the attempt to > produce an error message fails? Write an error message? > > What have other people done in this situation? > > --hendrik CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements. From jay.krell at cornell.edu Wed Feb 24 00:14:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 23:14:51 +0000 Subject: [M3devel] hand.c/set_singleton? Message-ID: I think hand.c is worth shrinking. And converting where easy to Modula-3. Agreed? It is "exercise" at least -- learn and get comfortable making changes, as long as they don't make anything worse. With that in mind, any hints on this: void set_singleton(size_t a, size_t* s) { size_t a_word = a / SET_GRAIN; size_t a_bit = a % SET_GRAIN; s[a_word] |= (1UL << a_bit); } Leave it alone? It works, not worth changing? Deal with it in m3front? In parse.c? I changed m3back to generate a bts instruction, which achieves "all four" operations in one instruction -- div (shift), mod (and), shift, or. The semantic mapping seems to be 100%. If set_singleton were a common operation, which I doubt, it seems like a major gain. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 00:33:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 23 Feb 2010 23:33:29 +0000 Subject: [M3devel] AMD64_LINUX/Tinderbox Message-ID: AMD64_LINUX seems stuck in m3core's use of LONGCARD. Presumably a problem in Tinderbox, not the actual cm3 code. Maybe because there is only one job instead of two? Please fix? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 24 04:33:54 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 23 Feb 2010 22:33:54 -0500 Subject: [M3devel] hand.c/set_singleton? In-Reply-To: References: Message-ID: We don't want this in m3front. On 23 Feb 2010, at 18:14, Jay K wrote: > I think hand.c is worth shrinking. > And converting where easy to Modula-3. > Agreed? > It is "exercise" at least -- learn and get comfortable making changes, as long as they don't make anything worse. > > > With that in mind, any hints on this: > > > void set_singleton(size_t a, size_t* s) > { > size_t a_word = a / SET_GRAIN; > size_t a_bit = a % SET_GRAIN; > s[a_word] |= (1UL << a_bit); > } > > > Leave it alone? It works, not worth changing? > Deal with it in m3front? > In parse.c? > > > I changed m3back to generate a bts instruction, which achieves "all four" operations in one instruction -- div (shift), mod (and), shift, or. The semantic mapping seems to be 100%. If set_singleton were a common operation, which I doubt, it seems like a major gain. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Feb 24 11:01:30 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 24 Feb 2010 11:01:30 +0100 Subject: [M3devel] AMD64_LINUX/Tinderbox In-Reply-To: References: Message-ID: <20100224110130.a810t555sgccoksg@mail.elegosoft.com> Quoting Jay K : > AMD64_LINUX seems stuck in m3core's use of LONGCARD. Sorry, I didn't notice this; I'm rather focused on Hudson and the release branch. > Presumably a problem in Tinderbox, not the actual cm3 code. > > Maybe because there is only one job instead of two? Well, yes. There is no old release for platform AMD64_LINUX, so the release-build job cannot run :-/ We should probably change the lastok-build job script to perform an upgrade in case of a failure. We wouldn't notice the incompatible change any more then though. > Please fix? I'll have a look at the scripts, perhaps tonight. I'd rather complete the release, use Hudson for the trunk then and disable the tinderbox job on birch. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Feb 24 13:41:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 12:41:12 +0000 Subject: [M3devel] portable/less portable test variations Message-ID: I'd like to write tests that, given different command line parameters, will either output totally portable results, or only somewhat portable, where "somewhat" probably means either portable to particular wordsize or portable to wordsize+endian. Worst case, completely platform specific. We'd have 1, 3, or 5 checked in expected results. Or possibly 1+n (portable + n platforms). This case is less useful, because it takes away the ability to compare, e.g. LINUXLIBC6 to NT386. The test would run twice, with and without the command line option. I guess it is about as much work to implement as to describe, but I've let it drag out. I have tests that would benefit from this. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 14:15:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 13:15:06 +0000 Subject: [M3devel] RTHook.Set* or RTSet.*? Message-ID: Again, I think hand.c's should largely be moved to Modula-3 code. e.g. all the "set_*" functions. (rough uncompiled unfinished) proposal #1 aka "RTHooks". premise: If the compiler generates calls to it, it ought to be in RTHooks. RTHooks.i3 TYPE Set = UNTRACED REF Word.T TYPE SetBoolean = Word.T; (* a full 32 or 64 bits; C would have returned at least 32 *) TYPE SetSize = CARDINAL; (* probably too much layering *) TYPE SetIndex = CARDINAL; (* probably too much layering *) CONST SetTRUE = 1; CONST SetFALSE = 0; PROCEDURE SetMember(set: Set; element: SetIndex): SetBoolean; (* SetTRUE IFF element IN set, else SetFALSE *) PROCEDURE SetUnion(inA, inB, out: Set; setSize: SetSize); (* out := inA + inB *) PROCEDURE SetIntersection(inA, inB, out: Set; setSize: SetSize); (* out := inA * inB *) PROCEDURE SetDifference(inA, inB, out: Set; setSize: SetSize); (* out := inA - inB *) PROCEDURE SetSymmetricDifference(inA, inB, out: Set; setSize: SetSize); (* out := inA xor inB *) PROCEDURE SetGE(inA, inB: Set; setSize: SetSize): SetBoolean; (* ... *) or longer SetGreaterOrEqual? etc. MODULE RTSet (m3-libs/m3core/src/runtime/common/RTSet.m3) EXPORTS RTHooks; ... You might also say: PROCEDURE SetMember(VAR set: Word.T; element: SetIndex): SetBoolean; esp. e.g. on the outputs. and to capture the invalidity of NULL? (rough uncompiled unfinished) proposal #2 aka "RTSet" premise: It seems right. RTSet.i3: (m3-libs/m3ore/src/runtime/common/RTSet.i3, or m3-libs/m3core/src/set?) It seems prudent to keep the "RT" prefix for global namespace reasons. It seems "RT" implies "runtime" directory though. I'd worry that calling it just Set.i3 could clash with other code. Notice that the existing names in hand.c cannot clash with any Modula-3 code, due to the single underscore. Perhaps perhaps perhaps this is a great reason to leave this all alone, because using C enables chosing identifiers in a separate namespace?? TYPE T = UNTRACED REF Word.T TYPE Boolean = Word.T; (* a full 32 or 64 bits; C would have returned at least 32 *) TYPE Size = CARDINAL; (* probably too much layering *) TYPE Index = CARDINAL; (* probably too much layering *) CONST True = 1; CONST False = 0; PROCEDURE Member aka In(set: T; element: Index): Boolean; (* True IFF element IN set, else False *) PROCEDURE Union aka Plus(inA, inB, out: T; size: Size); (* out := inA + inB *) PROCEDURE Intersect aka Intersection aka Times(inA, inB, out: T; size: Size); (* out := inA * inB *) PROCEDURE Difference aka Sub aka Subtract(inA, inB, out: T; size: Size); (* out := inA - inB *) PROCEDURE SymmetricDifference aka Xor(inA, inB, out: T; size: Size); (* out := inA xor inB *) PROCEDURE GE(inA, inB: T; size: Size): Boolean; (* ... *) etc. I'm undecided on the names. But I think I prefer: Union, Intersect, Difference, SymmetricDifference, Member, GE, EQ, NE, LT, LE, GT. It definitely looks nicer to put things in RTSet. (Assuming people believe "name scoping" is a good idea. There are counter arguments -- one flat global namespace is more conducive to search...) But the precedent of putting "everthing" in RTHooks seem clear. Though it is violated by hand.c..because it doesn't matter. You could declare them as extern in RTHooks.i3 and it wouldn't make any difference. The names are "never" referenced by Modula-3 code. Well, ok, m3back.m3 has the strings. I guess I'll do whittle at it a little more before doing this -- remove the tables, at least the NT386 exported ones. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Feb 24 14:41:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 24 Feb 2010 13:41:15 +0000 Subject: [M3devel] TInt.ToInt overflow In-Reply-To: References: <20100222225722.056AE2474001@birch.elegosoft.com>, ,,,,<48085E62-6C4C-4ECD-B1CB-F94CE7C5B10E@cs.purdue.edu>, , , , , , , , , , , , , <6A1F915C-A970-4485-8293-9E523DB278BA@cs.purdue.edu>, , , , <72B5DA75-B33A-4414-9E14-6625FA5816FB@cs.purdue.edu>, , <09B1E13B-15E0-452B-83E7-1F976049793C@cs.purdue.edu>, , Message-ID: Tony, it looks like basically all/many negative values are representeded as large positive values. Something is chopping the sign maybe? Here are the errors I get compiling m3core if I don't "ignore" overflow from TInt.ToInt. (for values that are under Integer.Word32.max). It isn't always clear how the source traffics in these numbers. I could get callstacks if it really helps. "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTAllocStats.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 452: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 463: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 464: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 471: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 549: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 550: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 555: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 558: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 561: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 566: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 569: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 574: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 577: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 592: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 593: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 801: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 952: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 964: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 970: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1016: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1071: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1077: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1089: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1090: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1092: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1094: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1186: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1208: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1209: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1242: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immdiate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1702: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 1724: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2056: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2257: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2259: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2365: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2386: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2398: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2418: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2420: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2425: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2442: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2482: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2498: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2520: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2525: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2541: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2543: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 "..\src\runtime\common\RTCollector.m3", line 2697: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 78: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 79: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 86: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 87: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 "..\src\float\IEEE\RealFloat.m3", line 99: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 81: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 82: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 89: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 96: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 101: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 103: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 108: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 "..\src\float\IEEE\LongFloat.m3", line 119: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 "..\src\convert\Convert.m3", line 496: pushOp: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 "..\src\convert\Convert.m3", line 503: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: RE: [M3commit] CVS Update: cm3 Date: Tue, 23 Feb 2010 23:08:32 +0000 I'll have to show you where the values are coming from. I don't know offhand. Could be from m3back, or m3front, I don't know. This stuff largely is runnable/testable from arbitrary hosts. cd scripts/python ./do-cm3-std.py realclean NT386 ./do-cm3-std.py buildship NT386 to get the data we are interested in, would want to change this code e.g.: C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386): IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN Note that most of the uses of ToInt in m3back don't do that, e.g.: IF shiftCount.loc = OLoc.imm THEN IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm)); END; ins.imsize := 1; And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday. But some are not, I didn't go here randomly. bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value. - Jay From: hosking at cs.purdue.edu Date: Tue, 23 Feb 2010 14:00:07 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 I guess I am uncertain what it is you are trying to achieve. The Modula-3 frontend never generates unsigned integers. Everything is signed. If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes. On 23 Feb 2010, at 13:15, Jay K wrote: So we need TWord.ToBytes? - Jay From: hosking at cs.purdue.edu Date: Tue, 23 Feb 2010 12:39:49 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com; jay.krell at cornell.edu Subject: Re: [M3commit] CVS Update: cm3 Actually, on second thought, of course it cannot be fixed. The signed value 128 *does* require 2 bytes to represent. (char)128 == -128. (short)128 == 128. These TInt functions should be interpreted as having C arithmetic semantics. On 23 Feb 2010, at 08:35, Tony Hosking wrote: That can be fixed... On 22 Feb 2010, at 21:30, Jay K wrote: ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte? I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad. - Jay ---------------------------------------- From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 21:10:10 -0500 To: jay.krell at cornell.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 On 22 Feb 2010, at 20:30, Jay K wrote: I'm still a bit leary of Chop and ToBytes. Chop is just the same as a C cast. i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1. ToBytes simply returns the significant bytes. I *suspect* we need a bit more in TWord to make this all hold together. I don't see the need. I think this speaks to confusion on your part... Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.) I don't entirely ignore ToInt's boolean. I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error. I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise. Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such. (I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.) What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it. And then rewriting hand.c in Modula-3. And then other stuff. ..Jay ________________________________ From: hosking at cs.purdue.edu Date: Mon, 22 Feb 2010 20:03:03 -0500 To: hosking at cs.purdue.edu CC: m3commit at elegosoft.com Subject: Re: [M3commit] CVS Update: cm3 P.S. The assumption is that results from operations that overflow should be discarded. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 22 Feb 2010, at 20:01, Tony Hosking wrote: Jay, If you want that behavior, just do: TInt.Chop(x, BYTESIZE(INTEGER), x); TInt.ToInt(x, i) On 22 Feb 2010, at 23:57, Jay Krell wrote: CVSROOT: /usr/cvs Changes by: jkrell at birch. 10/02/22 23:57:21 Modified files: cm3/m3-sys/m3back/src/: M3BackInt.m3 Log message: remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Feb 24 15:43:18 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 24 Feb 2010 09:43:18 -0500 Subject: [M3devel] TInt.ToInt overflow In-Reply-To: References: <20100222225722.056AE2474001@birch.elegosoft.com>, , , , , <48085E62-6C4C-4ECD-B1CB-F94CE7C5B10E@cs.purdue.edu>, , , , , , , , , , , , , <6A1F915C-A970-4485-8293-9E523DB278BA@cs.purdue.edu>, , , , <72B5DA75-B33A-4414-9E14-6625FA5816FB@cs.purdue.edu>, , <09B1E13B-15E0-452B-83E7-1F976049793C@cs.purdue.edu>, , Message-ID: <9635E921-3B9F-4A95-B4BC-0ACBCCE36D3A@cs.purdue.edu> I suspect that your backend code is not obeying the type conversions in the CG code. Here is line 202 from RTAllocator -- it has a lot of conversions (with implied sign extension). Does this give any clues? -----LINE 202 ----- declare_temp 4 4 Struct T v.159 load_integer Int.32 0 load v.159 0 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 0 1 store v.159 0 Int.32 Word.8 load v.67 0 Addr Addr load_indirect 0 Int.32 Int.32 check_range Int.32 0 1048575 1 load v.159 0 Word.32 Int.32 swap Int.32 Int.32 insert_mn Int.32 1 20 store v.159 0 Int.32 Word.32 load_integer Int.32 1 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 5 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 6 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 2 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 7 1 store v.159 2 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 0 1 store v.159 3 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 1 1 store v.159 3 Int.32 Word.8 load_integer Int.32 0 load v.159 3 Word.8 Int.32 swap Int.32 Int.32 insert_mn Int.32 2 6 store v.159 3 Int.32 Word.8 load v.65 0 Addr Addr load_integer Int.32 4 index_address Int.32 -1 load_address v.159 0 copy 1 Int.32 F On 24 Feb 2010, at 08:41, Jay K wrote: > Tony, it looks like basically all/many negative values are representeded as large positive values. > Something is chopping the sign maybe? > Here are the errors I get compiling m3core if I don't "ignore" overflow from TInt.ToInt. > (for values that are under Integer.Word32.max). > It isn't always clear how the source traffics in these numbers. I could get callstacks if it really helps. > > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 202: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 224: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 263: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:1,0,e0,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocator.m3", line 294: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTAllocStats.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:3,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 452: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 463: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 464: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 471: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 549: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 550: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 555: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 556: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 558: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 559: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 561: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 562: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 566: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 567: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 569: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 570: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 574: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 575: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 577: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 578: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 592: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 593: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 801: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 952: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 964: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 970: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1016: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1071: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1077: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1089: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1090: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1092: immOp1: unable to convert immediate to INTEGER:n:8,x:bf,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1094: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1186: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1208: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1209: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1242: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fb,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:f7,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:8f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immediate to INTEGER:n:8,x:fd,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1455: immOp1: unable to convert immdiate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1702: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 1724: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2056: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2257: immOp1: unable to convert immediate to INTEGER:n:8,x:df,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2259: immOp1: unable to convert immediate to INTEGER:n:8,x:fe,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2365: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2386: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2398: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2418: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2420: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2425: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2442: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2446: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2482: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2498: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2520: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2525: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2541: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2543: immOp1: unable to convert immediate to INTEGER:n:8,x:ff,3,0,fc,0,0,0,0 > "..\src\runtime\common\RTCollector.m3", line 2697: immOp1: unable to convert immediate to INTEGER:n:8,x:fc,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 72: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 78: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 79: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 86: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 87: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,80,ff,0,0,0,0 > "..\src\float\IEEE\RealFloat.m3", line 99: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 81: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 82: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 83: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 89: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 91: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 96: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 101: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 103: immOp1: unable to convert immediate to INTEGER:n:8,x:f,80,ff,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 108: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,f0,ff,0,0,0,0 > "..\src\float\IEEE\LongFloat.m3", line 119: immOp1: unable to convert immediate to INTEGER:n:8,x:7f,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 117: immOp1: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 > "..\src\convert\Convert.m3", line 496: pushOp: unable to convert immediate to INTEGER:n:8,x:0,0,0,80,0,0,0,0 > "..\src\convert\Convert.m3", line 503: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > "..\src\convert\Convert.m3", line 551: pushOp: unable to convert immediate to INTEGER:n:8,x:ff,ff,ff,ff,0,0,0,0 > > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: RE: [M3commit] CVS Update: cm3 > Date: Tue, 23 Feb 2010 23:08:32 +0000 > > I'll have to show you where the values are coming from. I don't know offhand. > Could be from m3back, or m3front, I don't know. > > This stuff largely is runnable/testable from arbitrary hosts. > cd scripts/python > ./do-cm3-std.py realclean NT386 > ./do-cm3-std.py buildship NT386 > > > to get the data we are interested in, would want to change this code e.g.: > > > C:\dev2\cm3.2\m3-sys\m3back\src\Codex86.m3(386): IF (NOT M3BackInt.ToInt(imm, ins.imm)) AND (NOT M3BackWord.LE(imm, M3BackInt.Word32.max)) THEN > > > Note that most of the uses of ToInt in m3back don't do that, e.g.: > > > IF shiftCount.loc = OLoc.imm THEN > IF NOT M3BackInt.ToInt(shiftCount.imm, ins.imm) THEN > t.Err("binOp: unable to convert immediate to INTEGER:" & M3BackInt.ToDiagnosticText(shiftCount.imm)); > END; > ins.imsize := 1; > > > And at least one of these examples is so far unreachable -- the one in bitTestAndSet that I added yesterday. > But some are not, I didn't go here randomly. > bitTestAndSet seems unusual but ok in that many x86 instructions can take a one byte signed immediate value, but bitTestAndSet seems to take a one byte unsigned immediate value. > > > - Jay > > From: hosking at cs.purdue.edu > Date: Tue, 23 Feb 2010 14:00:07 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I guess I am uncertain what it is you are trying to achieve. The Modula-3 frontend never generates unsigned integers. Everything is signed. If you want to represent (unsigned) then, yes, I guess you want TWord.TBytes. > > > On 23 Feb 2010, at 13:15, Jay K wrote: > > So we need TWord.ToBytes? > > - Jay > > From: hosking at cs.purdue.edu > Date: Tue, 23 Feb 2010 12:39:49 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3commit] CVS Update: cm3 > > Actually, on second thought, of course it cannot be fixed. The signed value 128 *does* require 2 bytes to represent. (char)128 == -128. (short)128 == 128. > These TInt functions should be interpreted as having C arithmetic semantics. > > On 23 Feb 2010, at 08:35, Tony Hosking wrote: > > That can be fixed... > > On 22 Feb 2010, at 21:30, Jay K wrote: > > > ToBytes claims the value 128 requires 2 bytes. Which is reasonable. But not always expected. There should be an unsigned version that claims 1 byte? > I can look into Chop and ToBytes more, but I am at least currently reusing add/subtract/multiple/div/mod/shift/rotate/toint/fromint/tochars, not bad. > > > - Jay > > > ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 21:10:10 -0500 > To: jay.krell at cornell.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > On 22 Feb 2010, at 20:30, Jay K wrote: > > I'm still a bit leary of Chop and ToBytes. > > Chop is just the same as a C cast. > i.e., (char)0xFFFFFFFF and (char)0x000000FF return the same value (char)-1. > > ToBytes simply returns the significant bytes. > > I *suspect* we need a bit more in TWord to make this all hold together. > > I don't see the need. I think this speaks to confusion on your part... > > Look at my current M3BackInt.m3. It is almost entirely now delegating to TInt/TWord, except it has its own conversions back and forth. It applies Widen before every operation, chop after every one. They are different for unsigned vs. signed. (Hm, unsigned narrow should probably check that the value fits, and the caller can ignore that or not.) > > > I don't entirely ignore ToInt's boolean. > I then check if the value fits in Word32. If it does, I ignore the overflow, knowing the value converted "reasonably". If it doesn't, I error. > > > I think TWord.ToWord, which doesn't exist, would do what I want -- allow for 0-2^n and fail otherwise. > > > Further, I should chose TWord.ToWord vs. TInt.ToInt based on the types I have. And then the frontend shouldn't claim 255 is an Int8. And such. > (I'm not sure how I'm getting away with this currently, maybe something odd in my ToBytes.) > > > What is there now is in pretty good shape, and M3BackInt/Word reinvent exceedingly little code now. I'd be plenty ok moving to other stuff now, such as atomic8/16/64 (and more testing of atomic32, which I think are done and working). I wasn't too keen spending the time adapting to the TInt/TWord changes, but I also didn't want the two nearly identical copies, esp. since I haven't read through DivMod to understand it. > > > And then rewriting hand.c in Modula-3. > > > And then other stuff. > > > ..Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Mon, 22 Feb 2010 20:03:03 -0500 > To: hosking at cs.purdue.edu > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > > > P.S. The assumption is that results from operations that overflow should be discarded. > > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > > > On 22 Feb 2010, at 20:01, Tony Hosking wrote: > > Jay, If you want that behavior, just do: > > TInt.Chop(x, BYTESIZE(INTEGER), x); > TInt.ToInt(x, i) > > On 22 Feb 2010, at 23:57, Jay Krell wrote: > > CVSROOT: /usr/cvs > Changes by: jkrell at birch. 10/02/22 23:57:21 > > Modified files: > cm3/m3-sys/m3back/src/: M3BackInt.m3 > > Log message: > remove local versions of ToInt and FromInt now that TInt.ToInt packs the bytes even if there is overflow (the right solution I suspect it TWord.ToWord) > > > > > > > > From jay.krell at cornell.edu Thu Feb 25 14:24:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Feb 2010 13:24:14 +0000 Subject: [M3devel] TInt/TWord/m3back Message-ID: Tony, it should now be much closer to your intent. I grant maybe the constants are misplaced, and I should try again to use ToBytes. I'm worried though. It used to be I could do: TInt.Add(Int{4,FF,FF,FF,7}, One) and be told it overflowed, in 4 bytes of precision. Now it'll just do it in 8 and no overflow. And chop always succeeds. Maybe: PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = BEGIN IF And (r [n-1], SignMask) = 0 THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; END; RETURN TRUE; END CheckChop; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Thu Feb 25 18:20:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 12:20:49 -0500 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: References: Message-ID: <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. On 25 Feb 2010, at 08:24, Jay K wrote: > Tony, it should now be much closer to your intent. > I grant maybe the constants are misplaced, and I should try again to use ToBytes. > > > I'm worried though. > It used to be I could do: > > > TInt.Add(Int{4,FF,FF,FF,7}, One) > and be told it overflowed, in 4 bytes of precision. You must check explicitly that there is no overflow. This is easy enough. TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) > Now it'll just do it in 8 and no overflow. > > > And chop always succeeds. > > Maybe: > > > PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = > BEGIN > IF And (r [n-1], SignMask) = 0 > THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; > ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; > END; > RETURN TRUE; > END CheckChop; > > ? > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 00:18:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 25 Feb 2010 23:18:38 +0000 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> References: , <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> Message-ID: Ok, I think maybe I should go back to the version where the type carries precision and each function is a small wrapper over TInt where I extend, call TInt, and then checked truncate. Or at least call TInt and checked truncate, maybe no need for extend. Something like that. That will still leave the hard work in TInt. I had hoped TInt could do "everything" for me. It is a little disappointing -- it was for doing "target math", which is what I want, but now it is just for doing 64bit math on any host. Probably should be called Int64.. On the other hand, m3back historically just did host INTEGER math, no overflow checks. So maybe ok asis. Adding the overflow checks found overflow in user source though, so I think a good thing. I'll probably just go back a day or so, as described, where each function in M3BackInt/M3BackWord is about one line. No need for th TInt/TWord changes then, even though they were acceptable. - Jay From: hosking at cs.purdue.edu Date: Thu, 25 Feb 2010 12:20:49 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] TInt/TWord/m3back This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. On 25 Feb 2010, at 08:24, Jay K wrote: Tony, it should now be much closer to your intent. I grant maybe the constants are misplaced, and I should try again to use ToBytes. I'm worried though. It used to be I could do: TInt.Add(Int{4,FF,FF,FF,7}, One) and be told it overflowed, in 4 bytes of precision. You must check explicitly that there is no overflow. This is easy enough. TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) Now it'll just do it in 8 and no overflow. And chop always succeeds. Maybe: PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = BEGIN IF And (r [n-1], SignMask) = 0 THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; END; RETURN TRUE; END CheckChop; ? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 01:06:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 00:06:28 +0000 Subject: [M3devel] TInt/TWord/specified precision Message-ID: Tony, the TInt/TWord cleanup cost me a lot of time, and still more to do. They used to provide target math to a specified precision. Now always to a fixed large precision. Historically M3back did host math, no overflow checking. It "had" to change, at least to split Target.Int into two host integers, in order to accomodate 64bit integers, but preferably to sometimes keep them together to do constant folding. (Arguably 64bit integer support initially only from 64bit host, then have working LONGINT, then use LONGINT, but no.) Adding overflow checking at the same time caught actual borderline bugs in user code -- code that depended on silent overflow. m3front won't catch those I guess because it never? folds constants? Maybe it should be willing to do so as long as there is no overflow, and then if it is hits overflow, back off and generate code to do the work? But also warn? I'm left very much desiring the functionaly that TInt did have. I have a few options. M3BackInt as it recently was, a thin layer over TInt. The constants could remain in TInt. Introducing TIntN, which is TInt but with n=specified precision, at runtime (Not TInt8, TInt32, just one TIntN that adapts at runtime, just like TInt used to do). The only difference between TIntN and M3BackInt is the name and location. It would be in m3middle. Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, and SignExtend and ZeroExtend that give a source precision. These functions would exist either way, just in TIntN, TWordN, or TInt. But I think still useful to wrap the type in a type that carries the precision. Now, also, I wonder if TInt, with its lost functionality, should be renamed, say to TInt64 or Int64? TInt used to do more and it was a little more complicated but useful. Are you sure it shouldn't go back to how it was? If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, if it keeps the individual layers thinner, simpler, easier to get correct. Doesn't analogy to TFloat suggest it was better before? TFloat doesn't support just one large precision type, it supports parameterizing itself in order to simulate various floating types. Granted, I haven't looked at what all it provides and I don't believe m3back folds constant float math at compile time, but it could. At least stuff not dependent on various "modes". 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. I'd have to think a bit, but it's probably something like floating constants with the same exponent and a mantissa that holds the full value can be folded. Bunch of examples is that if I convert a bunch of 32bit integers to double and do only add and subtract, it can all be folded at compile time. Multiplication and division cannot in general be done, though sometimes. Comparison to the same set can be done. Anyway, my current best idea is to introduce TIntN, TWordN, but I have a while to think about it before I do anything. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 26 03:44:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 21:44:40 -0500 Subject: [M3devel] TInt/TWord/m3back In-Reply-To: References: , <7548A380-E9E4-4AE8-84BB-BF61E21ED7B3@cs.purdue.edu> Message-ID: <8CAB3AD8-444C-4BB0-956A-73D24C6C237C@cs.purdue.edu> But TInt will do what you want. You just need to check bounds. TInt does mean "target INTEGER": is the way one does arithmetic on a host that doesn't support the range of the target. You cannot do constant folding safely without checking for overflow otherwise you violate the intent of the language (i.e., that some targets might check for overflow...) Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 25 Feb 2010, at 18:18, Jay K wrote: > Ok, I think maybe I should go back to the version where the type carries precision and each function is a small wrapper over TInt where I extend, call TInt, and then checked truncate. > Or at least call TInt and checked truncate, maybe no need for extend. > Something like that. > > > That will still leave the hard work in TInt. > > > I had hoped TInt could do "everything" for me. > It is a little disappointing -- it was for doing "target math", which is what I want, but now it is just for doing 64bit math on any host. Probably should be called Int64.. > > > On the other hand, m3back historically just did host INTEGER math, no overflow checks. So maybe ok asis. > Adding the overflow checks found overflow in user source though, so I think a good thing. > I'll probably just go back a day or so, as described, where each function in M3BackInt/M3BackWord is about one line. No need for th TInt/TWord changes then, even though they were acceptable. > > - Jay > > > From: hosking at cs.purdue.edu > Date: Thu, 25 Feb 2010 12:20:49 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/m3back > > This all speaks to your trying to use TInt for purposes it was never intended. It is there in support of the compiler front-end not compiler back-ends. > > On 25 Feb 2010, at 08:24, Jay K wrote: > > Tony, it should now be much closer to your intent. > I grant maybe the constants are misplaced, and I should try again to use ToBytes. > > > I'm worried though. > It used to be I could do: > > > TInt.Add(Int{4,FF,FF,FF,7}, One) > and be told it overflowed, in 4 bytes of precision. > > You must check explicitly that there is no overflow. This is easy enough. > > TInt.LT(result, Target.Int32.min) OR TInt.LT(Target.Int32.max, result) > > Now it'll just do it in 8 and no overflow. > > > And chop always succeeds. > > Maybe: > > > PROCEDURE CheckChop (VAR r: Int; n: CARDINAL) = > BEGIN > IF And (r [n-1], SignMask) = 0 > THEN FOR i := n TO LAST(Int) DO IF r [i] # 0 THEN RETURN FALSE END; END; > ELSE FOR i := n TO LAST(Int) DO IF r [i] # Mask THEN RETURN FALSE END; END; > END; > RETURN TRUE; > END CheckChop; > > ? > > - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Fri Feb 26 03:48:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 25 Feb 2010 21:48:11 -0500 Subject: [M3devel] TInt/TWord/specified precision In-Reply-To: References: Message-ID: The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed, m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold. I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard. I do not want to complicate TInt any more than it is now. On 25 Feb 2010, at 19:06, Jay K wrote: > Tony, the TInt/TWord cleanup cost me a lot of time, and > still more to do. > > > They used to provide target math to a specified precision. > > > Now always to a fixed large precision. > > > Historically M3back did host math, no overflow checking. > It "had" to change, at least to split Target.Int into > two host integers, in order to accomodate 64bit integers, > but preferably to sometimes keep them together to do constant folding. > (Arguably 64bit integer support initially only from 64bit host, > then have working LONGINT, then use LONGINT, but no.) > > > Adding overflow checking at the same time caught actual > borderline bugs in user code -- code that depended on silent overflow. > > > m3front won't catch those I guess because it never? folds constants? > Maybe it should be willing to do so as long as there is no overflow, > and then if it is hits overflow, back off and generate code to do the work? > But also warn? > > > I'm left very much desiring the functionaly that TInt did have. > > > I have a few options. > M3BackInt as it recently was, a thin layer over TInt. > The constants could remain in TInt. > > > Introducing TIntN, which is TInt but with n=specified precision, > at runtime (Not TInt8, TInt32, just one TIntN that adapts > at runtime, just like TInt used to do). > > > The only difference between TIntN and M3BackInt is the name and location. > It would be in m3middle. > > > Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, > and SignExtend and ZeroExtend that give a source precision. > These functions would exist either way, just in TIntN, TWordN, or TInt. > > > But I think still useful to wrap the type in a type that carries the precision. > > > Now, also, I wonder if TInt, with its lost functionality, should > be renamed, say to TInt64 or Int64? > > > TInt used to do more and it was a little more complicated but useful. > Are you sure it shouldn't go back to how it was? > If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, > if it keeps the individual layers thinner, simpler, easier to get correct. > > > Doesn't analogy to TFloat suggest it was better before? > > TFloat doesn't support just one large precision type, it supports > parameterizing itself in order to simulate various floating types. > Granted, I haven't looked at what all it provides and I don't believe > m3back folds constant float math at compile time, but it could. > At least stuff not dependent on various "modes". > 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. > I'd have to think a bit, but it's probably something like floating > constants with the same exponent and a mantissa that holds > the full value can be folded. Bunch of examples is that if I > convert a bunch of 32bit integers to double and do only > add and subtract, it can all be folded at compile time. > Multiplication and division cannot in general be done, though sometimes. > Comparison to the same set can be done. > > > Anyway, my current best idea is to introduce TIntN, TWordN, but I have > a while to think about it before I do anything. > > - Jay > From jay.krell at cornell.edu Fri Feb 26 11:41:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 10:41:05 +0000 Subject: [M3devel] TInt/TWord/specified precision In-Reply-To: References: , Message-ID: If I have to a range check after basically every single operation, if I can never just call Add, but always Add and then Something, that merits a better type/interface/implementation that does that for me. I was thinking maybe the check is at "chop time", but that would allow things like LAST(INTEGER) + 1 - 1 to work, and they probably should not, even if arguably they should. I think currently I let this through. I think the previous M3BackInt.m3 shall be TIntN.m3. I'll proceed that way. - Jay > From: hosking at cs.purdue.edu > Date: Thu, 25 Feb 2010 21:48:11 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/specified precision > > The precision (as you have noted) will possibly change. The problems arise because we now have two ranges of integer. We need to support both ranges. Explicit range checks are needed, > > m3front *does* fold constants. It has to for constant initialisers. If there is overflow (or results out of range) it refuses to constant fold. > > I really don't see the difficulty. You perform the arithmetic using TInt. If it doesn't overflow (at whatever arbitrary precision) then you still need to check that the result is in range for your desired precision. This is not hard. > > I do not want to complicate TInt any more than it is now. > > On 25 Feb 2010, at 19:06, Jay K wrote: > > > Tony, the TInt/TWord cleanup cost me a lot of time, and > > still more to do. > > > > > > They used to provide target math to a specified precision. > > > > > > Now always to a fixed large precision. > > > > > > Historically M3back did host math, no overflow checking. > > It "had" to change, at least to split Target.Int into > > two host integers, in order to accomodate 64bit integers, > > but preferably to sometimes keep them together to do constant folding. > > (Arguably 64bit integer support initially only from 64bit host, > > then have working LONGINT, then use LONGINT, but no.) > > > > > > Adding overflow checking at the same time caught actual > > borderline bugs in user code -- code that depended on silent overflow. > > > > > > m3front won't catch those I guess because it never? folds constants? > > Maybe it should be willing to do so as long as there is no overflow, > > and then if it is hits overflow, back off and generate code to do the work? > > But also warn? > > > > > > I'm left very much desiring the functionaly that TInt did have. > > > > > > I have a few options. > > M3BackInt as it recently was, a thin layer over TInt. > > The constants could remain in TInt. > > > > > > Introducing TIntN, which is TInt but with n=specified precision, > > at runtime (Not TInt8, TInt32, just one TIntN that adapts > > at runtime, just like TInt used to do). > > > > > > The only difference between TIntN and M3BackInt is the name and location. > > It would be in m3middle. > > > > > > Maybe adding just a few functions to TInt, like having Chop return a BOOLEAN, > > and SignExtend and ZeroExtend that give a source precision. > > These functions would exist either way, just in TIntN, TWordN, or TInt. > > > > > > But I think still useful to wrap the type in a type that carries the precision. > > > > > > Now, also, I wonder if TInt, with its lost functionality, should > > be renamed, say to TInt64 or Int64? > > > > > > TInt used to do more and it was a little more complicated but useful. > > Are you sure it shouldn't go back to how it was? > > If not, I'll layer over it. Multiple layers aren't necessarily a bad thing, > > if it keeps the individual layers thinner, simpler, easier to get correct. > > > > > > Doesn't analogy to TFloat suggest it was better before? > > > > TFloat doesn't support just one large precision type, it supports > > parameterizing itself in order to simulate various floating types. > > Granted, I haven't looked at what all it provides and I don't believe > > m3back folds constant float math at compile time, but it could. > > At least stuff not dependent on various "modes". > > 1.0 + 2.0 is always 3.0, no matter the rounding/precision mode. > > I'd have to think a bit, but it's probably something like floating > > constants with the same exponent and a mantissa that holds > > the full value can be folded. Bunch of examples is that if I > > convert a bunch of 32bit integers to double and do only > > add and subtract, it can all be folded at compile time. > > Multiplication and division cannot in general be done, though sometimes. > > Comparison to the same set can be done. > > > > > > Anyway, my current best idea is to introduce TIntN, TWordN, but I have > > a while to think about it before I do anything. > > > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Feb 26 13:59:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 26 Feb 2010 12:59:54 +0000 Subject: [M3devel] examples Message-ID: I think the release branch is missing the change to move examples. Update it? (I say this based on differences in the scripts.) - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 05:48:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 04:48:36 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> Message-ID: Tony, I just don't understand what is wrong with TIntN, TWordN. They are what TInt/TWord did for a long time after all. ? Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Fri, 26 Feb 2010 19:51:15 -0500 > To: jkrell at elego.de > CC: m3commit at elegosoft.com > Subject: Re: [M3commit] CVS Update: cm3 > > I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > On 26 Feb 2010, at 13:48, Jay Krell wrote: > >> CVSROOT: /usr/cvs >> Changes by: jkrell at birch. 10/02/26 13:48:34 >> >> Modified files: >> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >> Wrx86.i3 Wrx86.m3 m3makefile >> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >> TWordN.i3 TWordN.m3 Target.i3 >> Target.m3 m3makefile >> Removed files: >> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >> M3BackWord.m3 >> >> Log message: >> introduce type Target.IntN which is Int plus a precision >> just like the old Target.Int >> (previously M3BackInt.Int) >> >> make TIntN and TWordN support it >> they are just thin wrappers over TInt, TWord >> previously named M3BackInt, M3BackWord >> >> add small amount of support to TInt: >> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >> These could, if desired, go into their only users: TIntN, TWordN. >> (with the understanding that that Target.Int is "revealed" to them.) >> >> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >> >> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >> This is "just" additions. >> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >> (A little unsatisfactory that N is bytes instead of bits.) >> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >> >> While at it, in TIntN, rename things slightly: >> FromInt => FromHostInteger >> ToInt => ToHostInteger >> >> "Int" is "Target.Int" >> "HostInteger" is "INTEGER" >> >> again, TInt/TWord/m3front/m3middle not much affected. >> >> One fishy/uncertain thing in all of this, something to test out, is cross builds >> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >> really need INTEGER to be 4 bytes throughout m3back? >> (I know that mklib has little endian dependency.) > From hosking at cs.purdue.edu Sat Feb 27 07:16:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 01:16:32 -0500 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu> Message-ID: <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> The solution is not to push upstream into m3middle. I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. -- T On 26 Feb 2010, at 23:48, Jay K wrote: > > Tony, I just don't understand what is wrong with TIntN, TWordN. > They are what TInt/TWord did for a long time after all. ? > Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Fri, 26 Feb 2010 19:51:15 -0500 >> To: jkrell at elego.de >> CC: m3commit at elegosoft.com >> Subject: Re: [M3commit] CVS Update: cm3 >> >> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >> >> On 26 Feb 2010, at 13:48, Jay Krell wrote: >> >>> CVSROOT: /usr/cvs >>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>> >>> Modified files: >>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>> Wrx86.i3 Wrx86.m3 m3makefile >>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>> TWordN.i3 TWordN.m3 Target.i3 >>> Target.m3 m3makefile >>> Removed files: >>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>> M3BackWord.m3 >>> >>> Log message: >>> introduce type Target.IntN which is Int plus a precision >>> just like the old Target.Int >>> (previously M3BackInt.Int) >>> >>> make TIntN and TWordN support it >>> they are just thin wrappers over TInt, TWord >>> previously named M3BackInt, M3BackWord >>> >>> add small amount of support to TInt: >>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>> These could, if desired, go into their only users: TIntN, TWordN. >>> (with the understanding that that Target.Int is "revealed" to them.) >>> >>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>> >>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>> This is "just" additions. >>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>> (A little unsatisfactory that N is bytes instead of bits.) >>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>> >>> While at it, in TIntN, rename things slightly: >>> FromInt => FromHostInteger >>> ToInt => ToHostInteger >>> >>> "Int" is "Target.Int" >>> "HostInteger" is "INTEGER" >>> >>> again, TInt/TWord/m3front/m3middle not much affected. >>> >>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>> really need INTEGER to be 4 bytes throughout m3back? >>> (I know that mklib has little endian dependency.) >> From jay.krell at cornell.edu Sat Feb 27 08:34:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 07:34:52 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> Message-ID: > As I understand it your stuff in m3back is mostly working. > I took a look at the code there and I see a number of issues Tony, I don't know of anything that isn't working. Please let me know. All 64bit operations should work. atomic32 should work. Not yet atomic8/16/64, soon. Oh there is an alignment issue once atomic64 is there. It's present on other platforms too, for different reasons (incorrect max_align). Thanks, - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 01:16:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > The solution is not to push upstream into m3middle. > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > -- T > > On 26 Feb 2010, at 23:48, Jay K wrote: > >> >> Tony, I just don't understand what is wrong with TIntN, TWordN. >> They are what TInt/TWord did for a long time after all. ? >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. >> >> >> - Jay >> >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Fri, 26 Feb 2010 19:51:15 -0500 >>> To: jkrell at elego.de >>> CC: m3commit at elegosoft.com >>> Subject: Re: [M3commit] CVS Update: cm3 >>> >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >>> >>> On 26 Feb 2010, at 13:48, Jay Krell wrote: >>> >>>> CVSROOT: /usr/cvs >>>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>>> >>>> Modified files: >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>>> Wrx86.i3 Wrx86.m3 m3makefile >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>>> TWordN.i3 TWordN.m3 Target.i3 >>>> Target.m3 m3makefile >>>> Removed files: >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>>> M3BackWord.m3 >>>> >>>> Log message: >>>> introduce type Target.IntN which is Int plus a precision >>>> just like the old Target.Int >>>> (previously M3BackInt.Int) >>>> >>>> make TIntN and TWordN support it >>>> they are just thin wrappers over TInt, TWord >>>> previously named M3BackInt, M3BackWord >>>> >>>> add small amount of support to TInt: >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>>> These could, if desired, go into their only users: TIntN, TWordN. >>>> (with the understanding that that Target.Int is "revealed" to them.) >>>> >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>>> >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>>> This is "just" additions. >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>>> (A little unsatisfactory that N is bytes instead of bits.) >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>>> >>>> While at it, in TIntN, rename things slightly: >>>> FromInt => FromHostInteger >>>> ToInt => ToHostInteger >>>> >>>> "Int" is "Target.Int" >>>> "HostInteger" is "INTEGER" >>>> >>>> again, TInt/TWord/m3front/m3middle not much affected. >>>> >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>>> really need INTEGER to be 4 bytes throughout m3back? >>>> (I know that mklib has little endian dependency.) >>> > From jay.krell at cornell.edu Sat Feb 27 13:24:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 12:24:30 +0000 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, Message-ID: And now again it doesn't work. new source -> compiling RTIO.i3 new source -> compiling RTTypeMap.i3 new source -> compiling RTMapOp.i3 new source -> compiling RTModule.i3 new source -> compiling RTHeapMap.m3 *** *** runtime error: *** <*ASSERT*> failed. *** file "..\src\Codex86.m3", line 430 *** Stack trace: FP PC Procedure --------- --------- ------------------------------- 0x12f310 0x466a46 immOp1 + 0x475 in ..\src\Codex86.m3 0x12f400 0x467108 immOp + 0x662 in ..\src\Codex86.m3 0x12f444 0x47d5c7 doimm + 0x255 in ..\src\Stackx86.m3 0x12f470 0x43ff5e if_false + 0x222 in ..\src\M3x86.m3 0x12f49c 0x64138b if_false + 0x101 in ..\src\M3CG_Check.m3 0x12f4c8 0x501a8f If_false + 0xa8 in ..\src\misc\CG.m3 0x12f4e8 0x5c2466 PrepNoBranch + 0x66 in ..\src\exprs\Expr.m3 0x12f510 0x5c1e3e PrepBranch + 0xcc in ..\src\exprs\Expr.m3 0x12f564 0x5e4392 Compile + 0x104 in ..\src\stmts\IfStmt.m3 0x12f594 0x536610 Compile + 0x63 in ..\src\stmts\Stmt.m3 ......... ......... ... more frames ... *** execution of [, ] failed *** I'm going to move m3back to how it was, but leave m3middle alone. With TIntN still in m3back. I skimmed through most of your changes and they seemed ok, but I'll have to apply them slowly/piecemeal and see which work. - Jay > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 07:34:52 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > > > As I understand it your stuff in m3back is mostly working. > > I took a look at the code there and I see a number of issues > > > Tony, I don't know of anything that isn't working. > Please let me know. > All 64bit operations should work. atomic32 should work. > Not yet atomic8/16/64, soon. > Oh there is an alignment issue once atomic64 is there. > It's present on other platforms too, for different reasons (incorrect max_align). > > > Thanks, > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 01:16:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > The solution is not to push upstream into m3middle. > > I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > > > -- T > > > > On 26 Feb 2010, at 23:48, Jay K wrote: > > > >> > >> Tony, I just don't understand what is wrong with TIntN, TWordN. > >> They are what TInt/TWord did for a long time after all. ? > >> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>> To: jkrell at elego.de > >>> CC: m3commit at elegosoft.com > >>> Subject: Re: [M3commit] CVS Update: cm3 > >>> > >>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>> > >>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>> > >>>> CVSROOT: /usr/cvs > >>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>> > >>>> Modified files: > >>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>> TWordN.i3 TWordN.m3 Target.i3 > >>>> Target.m3 m3makefile > >>>> Removed files: > >>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>> M3BackWord.m3 > >>>> > >>>> Log message: > >>>> introduce type Target.IntN which is Int plus a precision > >>>> just like the old Target.Int > >>>> (previously M3BackInt.Int) > >>>> > >>>> make TIntN and TWordN support it > >>>> they are just thin wrappers over TInt, TWord > >>>> previously named M3BackInt, M3BackWord > >>>> > >>>> add small amount of support to TInt: > >>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>> > >>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>> > >>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>> This is "just" additions. > >>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>> > >>>> While at it, in TIntN, rename things slightly: > >>>> FromInt => FromHostInteger > >>>> ToInt => ToHostInteger > >>>> > >>>> "Int" is "Target.Int" > >>>> "HostInteger" is "INTEGER" > >>>> > >>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>> > >>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>> really need INTEGER to be 4 bytes throughout m3back? > >>>> (I know that mklib has little endian dependency.) > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 17:10:32 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 11:10:32 -0500 Subject: [M3devel] TInt/TWord/N In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu> Message-ID: Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. On 27 Feb 2010, at 02:34, Jay K wrote: > >> As I understand it your stuff in m3back is mostly working. >> I took a look at the code there and I see a number of issues > > > Tony, I don't know of anything that isn't working. > Please let me know. > All 64bit operations should work. atomic32 should work. > Not yet atomic8/16/64, soon. > Oh there is an alignment issue once atomic64 is there. > It's present on other platforms too, for different reasons (incorrect max_align). > > > Thanks, > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 27 Feb 2010 01:16:32 -0500 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] TInt/TWord/N >> >> The solution is not to push upstream into m3middle. >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. >> >> -- T >> >> On 26 Feb 2010, at 23:48, Jay K wrote: >> >>> >>> Tony, I just don't understand what is wrong with TIntN, TWordN. >>> They are what TInt/TWord did for a long time after all. ? >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. >>> >>> >>> - Jay >>> >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 >>>> To: jkrell at elego.de >>>> CC: m3commit at elegosoft.com >>>> Subject: Re: [M3commit] CVS Update: cm3 >>>> >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. >>>> >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: >>>> >>>>> CVSROOT: /usr/cvs >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 >>>>> >>>>> Modified files: >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 >>>>> Wrx86.i3 Wrx86.m3 m3makefile >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 >>>>> TWordN.i3 TWordN.m3 Target.i3 >>>>> Target.m3 m3makefile >>>>> Removed files: >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 >>>>> M3BackWord.m3 >>>>> >>>>> Log message: >>>>> introduce type Target.IntN which is Int plus a precision >>>>> just like the old Target.Int >>>>> (previously M3BackInt.Int) >>>>> >>>>> make TIntN and TWordN support it >>>>> they are just thin wrappers over TInt, TWord >>>>> previously named M3BackInt, M3BackWord >>>>> >>>>> add small amount of support to TInt: >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate >>>>> These could, if desired, go into their only users: TIntN, TWordN. >>>>> (with the understanding that that Target.Int is "revealed" to them.) >>>>> >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision >>>>> >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged >>>>> This is "just" additions. >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) >>>>> (A little unsatisfactory that N is bytes instead of bits.) >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) >>>>> >>>>> While at it, in TIntN, rename things slightly: >>>>> FromInt => FromHostInteger >>>>> ToInt => ToHostInteger >>>>> >>>>> "Int" is "Target.Int" >>>>> "HostInteger" is "INTEGER" >>>>> >>>>> again, TInt/TWord/m3front/m3middle not much affected. >>>>> >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we >>>>> really need INTEGER to be 4 bytes throughout m3back? >>>>> (I know that mklib has little endian dependency.) >>>> >> From jay.krell at cornell.edu Sat Feb 27 20:11:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 19:11:18 +0000 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , Message-ID: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 20:54:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 14:54:40 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , Message-ID: P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 21:50:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 20:50:40 +0000 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , ,,<7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, ,,, , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , Message-ID: > Target.Int values would always be interpreted based on their associated type They kind of mostly are? Except..I mean..you know..I bury a size in them, which is a step. But the signnedness is not buried in them and I might get that wrong sometimes. It is often, you know, the operation and not the type. "Shift is always unsigned." But Add isn't. But with "half range cardinals", I'm not sure it matters. 16_40000000 * 2 overflows the same for INTEGER and CARDINAL LAST(INTEGER) + 1 ditto. Some operations do vary and they are handled correctly I think: abs, mul, div. Actually this is somewhat wrong: signed and unsigned multiplication I don't think needs to vary the way it does. They are the same in the lower bits. The compiler doesn't need to be so picky I believe. In particular, in the following C: int F1(int a, int b) { return a * b; } unsigned F2(unsigned a, unsigned b) { return a * b; } __int64 F3(int a, int b) { return a * (__int64)b; } unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } only one of them does unsigned multiplication, the last. (and notice that it does it inline with one instruction; something our compiler will be harder pressed to do given the lack of mixed operations! but you could leave it to a smart optimizer) > Is64, IsWord, IsInt, Target.FloatType In familiar territory (C and C++), I like switches because they "evaluate simultaneously", at least however the compiler can figure it. That is: if foo == 1 else if foo == 2 else if foo == 3 else if foo == 4 else if foo == 5 unless the compiler is very smart is always go to penalize 5 comparisons for "5", plus the compiler might assume I'm meaning to optimize the earlier cases as being more common, but then I have to worry about the ordering to get the common cases earlier whereas if I write switch (foo) case 1: ... case 2: ... case 3: ... case 4: ... case 5: ... I'll let the compiler chose between table lookup, linear search, binary search. "table lookup" being "simultaneous evaluation", binary search being nice I also don't like "if ladders" because if I'm stepping through unoptimized code line by line, it is tedious. [mostly omitted aside: I go out of my way when writing command line parsers in C to have a switch statement instead of an if/elseif/elseif ladder] However In Modula-3, I've gotten warnings when I miss cases, so there is overhead of always writing "else". Partly this because I don't know Modula-3 well. The use of FloatType[type] was already there, and it is good to have equivalence classes to reduce the number of cases listed and allow for more to be added later, "silently". I also don't like "data based interfaces", I prefer function calls, that's why Is64 instead of is foo IN Types64. (but FloatType[type] was already there) Granted, I lament the lack of inlining in m3back. I'm worried about nomenclature if/when this is extended to 64bit architectures. I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. I think I just drifted away from using TInt.Min/Max{8,16,32,64}. I'll see if any uses remain. Eh maybe just: C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); Some places were in extract/insert, and looked wrong. Yes definitely more eyes on m3back appreciated. Heck more eyes on cm3 appreciated! We have way too few. :( There were many style changes along with making things not work. I didn't want to sift through it all so I put it all back. Now to ponder sifting through it more slowly from a working baseline. Also I often favor mvar.mvar_type over mvar.type, so I can plain text search for mvar_type, and not just "type". I realize that you can't throw out all contexta all the time, but, there is something to be said for flatter namespaces. Nothing scales like plain text search. No language aware search work adequately. Let alone the matter of existance of languages x tools. I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. I would certainly be ok with TypeIsFloat to make it more consistently function call based, thoug I know I put in some cases too -- for the "simultaneous evaluation" property. - Jay From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 14:54:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] max_align P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sat Feb 27 22:24:41 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 16:24:41 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , Message-ID: <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> On 27 Feb 2010, at 15:50, Jay K wrote: > > Target.Int values would always be interpreted based on their associated type > > > They kind of mostly are? > Except..I mean..you know..I bury a size in them, which is a step. No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: add Int.32 the semantics are: take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. e.g., in C, (int)a + (int)b So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! > But the signnedness is not buried in them and I might get that wrong sometimes. > It is often, you know, the operation and not the type. > "Shift is always unsigned." > But Add isn't. > But with "half range cardinals", I'm not sure it matters. > 16_40000000 * 2 overflows the same for INTEGER and CARDINAL > LAST(INTEGER) + 1 ditto. > > > Some operations do vary and they are handled correctly I think: abs, mul, div. > Actually this is somewhat wrong: signed and unsigned multiplication I don't think > needs to vary the way it does. They are the same in the lower bits. > The compiler doesn't need to be so picky I believe. In particular, in the following C: > int F1(int a, int b) { return a * b; } > unsigned F2(unsigned a, unsigned b) { return a * b; } > __int64 F3(int a, int b) { return a * (__int64)b; } > unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } > > > only one of them does unsigned multiplication, the last. > (and notice that it does it inline with one instruction; something > our compiler will be harder pressed to do given the lack of mixed operations! > but you could leave it to a smart optimizer) > > > > Is64, IsWord, IsInt, Target.FloatType > > > In familiar territory (C and C++), > I like switches because they "evaluate simultaneously", at least however the compiler can figure it. > > > That is: > > > if foo == 1 > else if foo == 2 > else if foo == 3 > else if foo == 4 > else if foo == 5 > > unless the compiler is very smart is always go to penalize 5 comparisons for "5", > plus the compiler might assume I'm meaning to optimize the earlier cases > as being more common, but then I have to worry about the ordering > to get the common cases earlier whereas > if I write > switch (foo) > case 1: ... > case 2: ... > case 3: ... > case 4: ... > case 5: ... > > > I'll let the compiler chose between table lookup, linear search, binary search. > "table lookup" being "simultaneous evaluation", binary search being nice > > > I also don't like "if ladders" because if I'm stepping through unoptimized > code line by line, it is tedious. > [mostly omitted aside: I go out of my way when writing command line > parsers in C to have a switch statement instead of an if/elseif/elseif ladder] > > > However > In Modula-3, I've gotten warnings when I miss cases, so there is overhead > of always writing "else". > Partly this because I don't know Modula-3 well. You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. > The use of FloatType[type] was already there, and it is good > to have equivalence classes to reduce the number of cases listed > and allow for more to be added later, "silently". Again, with CASE you can still select for those, without having a cascade of IF. > > I also don't like "data based interfaces", I prefer function calls, > that's why Is64 instead of is foo IN Types64. > (but FloatType[type] was already there) > Granted, I lament the lack of inlining in m3back. Function call is overkill. Use the types! > I'm worried about nomenclature if/when this is extended to 64bit architectures. > I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. > I think I just drifted away from using TInt.Min/Max{8,16,32,64}. The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. > I'll see if any uses remain. > Eh maybe just: > C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); > > > Some places were in extract/insert, and looked wrong. > > > Yes definitely more eyes on m3back appreciated. > Heck more eyes on cm3 appreciated! We have way too few. :( > There were many style changes along with making things not work. > I didn't want to sift through it all so I put it all back. > Now to ponder sifting through it more slowly from a working baseline. > > > Also I often favor mvar.mvar_type over mvar.type, so I can plain text > search for mvar_type, and not just "type". I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). > I realize that you can't throw out all contexta all the time, but, > there is something to be said for flatter namespaces. > Nothing scales like plain text search. > No language aware search work adequately. > Let alone the matter of existance of languages x tools. > > > I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. > I would certainly be ok with TypeIsFloat to make it more consistently function call based, > thoug I know I put in some cases too -- for the "simultaneous evaluation" property. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 14:54:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] max_align > > P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 27 Feb 2010, at 14:11, Jay K wrote: > > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Feb 27 23:12:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 27 Feb 2010 22:12:21 +0000 Subject: [M3devel] max_align In-Reply-To: <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , ,,<7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, ,,, , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , , <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> Message-ID: ok..I'll maybe reply more later. But what does it mean to load_int(type1, value1) load_int(type2, value2) add(type3) It seems like both the values and the operations have types. I do try to consider all types, with "ELSE <* ASSERT FALSE *>", be it an if ladder or a switch. Perhaps that is too little thought? I admit, ZType, IType, AType, etc., I can't keep them straight. I "know" that floats are handled specially by m3back and so I can ignore them in most code and that the backend traffics only rarely in 8 or 16 bit types, so the four most interesting types are Int32, Int64, Word32, Word64. As well, since my agenda is currently 64bit longint, I just need to add word64/int64 to the existing paths. (m3back is so geared against int8/word8/int16/word16 that it takes special pain to widen all function results, lest they be generated by a C compiler, and the historical command indict the C compiler's behavior, I edited out the subjectivity; and the 8 bits produced by setccop are always immediately widened; I have to revisit that soon, I think the code can be much better. That is part of the evidence to what it traffics in.) - Jay Subject: Re: [M3devel] max_align From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 16:24:41 -0500 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu On 27 Feb 2010, at 15:50, Jay K wrote: > Target.Int values would always be interpreted based on their associated type They kind of mostly are? Except..I mean..you know..I bury a size in them, which is a step. No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: add Int.32 the semantics are: take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. e.g., in C, (int)a + (int)b So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! But the signnedness is not buried in them and I might get that wrong sometimes. It is often, you know, the operation and not the type. "Shift is always unsigned." But Add isn't. But with "half range cardinals", I'm not sure it matters. 16_40000000 * 2 overflows the same for INTEGER and CARDINAL LAST(INTEGER) + 1 ditto. Some operations do vary and they are handled correctly I think: abs, mul, div. Actually this is somewhat wrong: signed and unsigned multiplication I don't think needs to vary the way it does. They are the same in the lower bits. The compiler doesn't need to be so picky I believe. In particular, in the following C: int F1(int a, int b) { return a * b; } unsigned F2(unsigned a, unsigned b) { return a * b; } __int64 F3(int a, int b) { return a * (__int64)b; } unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } only one of them does unsigned multiplication, the last. (and notice that it does it inline with one instruction; something our compiler will be harder pressed to do given the lack of mixed operations! but you could leave it to a smart optimizer) > Is64, IsWord, IsInt, Target.FloatType In familiar territory (C and C++), I like switches because they "evaluate simultaneously", at least however the compiler can figure it. That is: if foo == 1 else if foo == 2 else if foo == 3 else if foo == 4 else if foo == 5 unless the compiler is very smart is always go to penalize 5 comparisons for "5", plus the compiler might assume I'm meaning to optimize the earlier cases as being more common, but then I have to worry about the ordering to get the common cases earlier whereas if I write switch (foo) case 1: ... case 2: ... case 3: ... case 4: ... case 5: ... I'll let the compiler chose between table lookup, linear search, binary search. "table lookup" being "simultaneous evaluation", binary search being nice I also don't like "if ladders" because if I'm stepping through unoptimized code line by line, it is tedious. [mostly omitted aside: I go out of my way when writing command line parsers in C to have a switch statement instead of an if/elseif/elseif ladder] However In Modula-3, I've gotten warnings when I miss cases, so there is overhead of always writing "else". Partly this because I don't know Modula-3 well. You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. The use of FloatType[type] was already there, and it is good to have equivalence classes to reduce the number of cases listed and allow for more to be added later, "silently". Again, with CASE you can still select for those, without having a cascade of IF. I also don't like "data based interfaces", I prefer function calls, that's why Is64 instead of is foo IN Types64. (but FloatType[type] was already there) Granted, I lament the lack of inlining in m3back. Function call is overkill. Use the types! I'm worried about nomenclature if/when this is extended to 64bit architectures. I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. I think I just drifted away from using TInt.Min/Max{8,16,32,64}. The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. I'll see if any uses remain. Eh maybe just: C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); Some places were in extract/insert, and looked wrong. Yes definitely more eyes on m3back appreciated. Heck more eyes on cm3 appreciated! We have way too few. :( There were many style changes along with making things not work. I didn't want to sift through it all so I put it all back. Now to ponder sifting through it more slowly from a working baseline. Also I often favor mvar.mvar_type over mvar.type, so I can plain text search for mvar_type, and not just "type". I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). I realize that you can't throw out all contexta all the time, but, there is something to be said for flatter namespaces. Nothing scales like plain text search. No language aware search work adequately. Let alone the matter of existance of languages x tools. I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. I would certainly be ok with TypeIsFloat to make it more consistently function call based, thoug I know I put in some cases too -- for the "simultaneous evaluation" property. - Jay From: hosking at cs.purdue.edu Date: Sat, 27 Feb 2010 14:54:40 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] max_align P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On 27 Feb 2010, at 14:11, Jay K wrote: The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. We probably don't generate atomic operations against them. I already changed it to 64 for the front/middle ends But right, max_align is wrong for a few targets. I believe max_align ends up being basically target-independent. It is always 64. Types are always aligned on their size. The only exceptions are 68K platforms where max_align is possibly 2 bytes. 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems like a language hole to me. I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. - Jay > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 11:10:32 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] TInt/TWord/N > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > >> As I understand it your stuff in m3back is mostly working. > >> I took a look at the code there and I see a number of issues > > > > > > Tony, I don't know of anything that isn't working. > > Please let me know. > > All 64bit operations should work. atomic32 should work. > > Not yet atomic8/16/64, soon. > > Oh there is an alignment issue once atomic64 is there. > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > Thanks, > > - Jay > > > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] TInt/TWord/N > >> > >> The solution is not to push upstream into m3middle. > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > >> > >> -- T > >> > >> On 26 Feb 2010, at 23:48, Jay K wrote: > >> > >>> > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > >>> They are what TInt/TWord did for a long time after all. ? > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > >>> > >>> > >>> - Jay > >>> > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > >>>> To: jkrell at elego.de > >>>> CC: m3commit at elegosoft.com > >>>> Subject: Re: [M3commit] CVS Update: cm3 > >>>> > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > >>>> > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > >>>> > >>>>> CVSROOT: /usr/cvs > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > >>>>> > >>>>> Modified files: > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > >>>>> TWordN.i3 TWordN.m3 Target.i3 > >>>>> Target.m3 m3makefile > >>>>> Removed files: > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > >>>>> M3BackWord.m3 > >>>>> > >>>>> Log message: > >>>>> introduce type Target.IntN which is Int plus a precision > >>>>> just like the old Target.Int > >>>>> (previously M3BackInt.Int) > >>>>> > >>>>> make TIntN and TWordN support it > >>>>> they are just thin wrappers over TInt, TWord > >>>>> previously named M3BackInt, M3BackWord > >>>>> > >>>>> add small amount of support to TInt: > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > >>>>> > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > >>>>> > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > >>>>> This is "just" additions. > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > >>>>> > >>>>> While at it, in TIntN, rename things slightly: > >>>>> FromInt => FromHostInteger > >>>>> ToInt => ToHostInteger > >>>>> > >>>>> "Int" is "Target.Int" > >>>>> "HostInteger" is "INTEGER" > >>>>> > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > >>>>> > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > >>>>> really need INTEGER to be 4 bytes throughout m3back? > >>>>> (I know that mklib has little endian dependency.) > >>>> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sat Feb 27 23:52:50 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sat, 27 Feb 2010 23:52:50 +0100 Subject: [M3devel] examples In-Reply-To: References: Message-ID: <20100227235250.mbm07ehhwsokskg4@mail.elegosoft.com> Quoting Jay K : > > I think the release branch is missing the change to move examples. > > Update it? Yes, please do. Olaf > (I say this based on differences in the scripts.) -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From hosking at cs.purdue.edu Sun Feb 28 00:08:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 27 Feb 2010 18:08:07 -0500 Subject: [M3devel] max_align In-Reply-To: References: <20100226124834.9AB1D2474001@birch.elegosoft.com>, , , , <7E4207F1-C6FD-4421-8A4A-6C08DF566E35@cs.purdue.edu>, , , , , , <92FEE72C-2BAC-48F6-8267-3084F5AA9E1A@cs.purdue.edu>, , , , , , , <00F1848D-7888-4629-B292-0488E3FE0CB6@cs.purdue.edu> Message-ID: <21DE2D25-A591-4E8E-AF8C-0E050CE471D4@cs.purdue.edu> On 27 Feb 2010, at 17:12, Jay K wrote: > ok..I'll maybe reply more later. > > > But what does it mean to > > > load_int(type1, value1) Take value, cast to type1 (may involve sign extend from low bits/truncation of high bits), push on stack. > load_int(type2, value2) Take value, cast to type2 (may involve sign extend from low bits/truncation of high bits), push on stack. > add(type3) Add values on stack, interpreted as type3 (perhaps sign extended/truncated), with result of type3. > It seems like both the values and the operations have types. The types say how the bits of the operands are to be interpreted. > I do try to consider all types, with "ELSE <* ASSERT FALSE *>", be it an if ladder or a switch. > Perhaps that is too little thought? > I admit, ZType, IType, AType, etc., I can't keep them straight. > I "know" that floats are handled specially by m3back and so I can ignore them in most code > and that the backend traffics only rarely in 8 or 16 bit types, so the four most interesting > types are Int32, Int64, Word32, Word64. Correct. > As well, since my agenda is currently 64bit longint, I just need to add word64/int64 to > the existing paths. Right. > (m3back is so geared against int8/word8/int16/word16 that it takes special pain > to widen all function results, lest they be generated by a C compiler, and the > historical command indict the C compiler's behavior, I edited out the subjectivity; > and the 8 bits produced by setccop are always > immediately widened; I have to revisit that soon, I think the code can be much better. > That is part of the evidence to what it traffics in.) Yes, the front-end never usually generates stack values of 8/16 bits. All integer operations are in the 32/64-bit types. > > > - Jay > > > Subject: Re: [M3devel] max_align > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 16:24:41 -0500 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > > On 27 Feb 2010, at 15:50, Jay K wrote: > > > Target.Int values would always be interpreted based on their associated type > > > They kind of mostly are? > Except..I mean..you know..I bury a size in them, which is a step. > > No, my point was that the front-end generates properly typed operations. The specs for m3middle state that all Target.Int values are to be used for only their low bits as defined by the associated type of the operation. Consider what would happen if we had a C-generating backend. All the integer values would be expressed as emitted by TInt.ToBytes (i.e., just the significant bytes of the value). Then, the operations are defined as implicitly casting those values using the given type. Thus, for: > > add Int.32 > > the semantics are: > > take the two operands from the stack, sign-extend their low 32 bits, and perform the addition, with the result interpreted as Int.32. > > e.g., in C, (int)a + (int)b > > So, for your backend code, you don't need the TIntN/TWordN length encoded in the value. The operations define how a Target.Int is to be interpreted. Target.Int is just a bunch of bits that are interpreted according to the type on the operation! You need to choose the proper operation from TInt/TWord to get signed/unsigned, and in some cases (Rotate) to define the bits to be rotated. Then, to get the appropriate result from the Target.Int operations you need to mask/extend the bits of the result correctly to match the sign. > > I hope this is starting to make more sense to you, and help to motivate why I've been so pedantic about the TInt/TWord support! > > But the signnedness is not buried in them and I might get that wrong sometimes. > It is often, you know, the operation and not the type. > "Shift is always unsigned." > But Add isn't. > But with "half range cardinals", I'm not sure it matters. > 16_40000000 * 2 overflows the same for INTEGER and CARDINAL > LAST(INTEGER) + 1 ditto. > > > Some operations do vary and they are handled correctly I think: abs, mul, div. > Actually this is somewhat wrong: signed and unsigned multiplication I don't think > needs to vary the way it does. They are the same in the lower bits. > The compiler doesn't need to be so picky I believe. In particular, in the following C: > int F1(int a, int b) { return a * b; } > unsigned F2(unsigned a, unsigned b) { return a * b; } > __int64 F3(int a, int b) { return a * (__int64)b; } > unsigned __int64 F3(unsigned a, unsigned b) { return a * (unsigned __int64)b; } > > > only one of them does unsigned multiplication, the last. > (and notice that it does it inline with one instruction; something > our compiler will be harder pressed to do given the lack of mixed operations! > but you could leave it to a smart optimizer) > > > > Is64, IsWord, IsInt, Target.FloatType > > > In familiar territory (C and C++), > I like switches because they "evaluate simultaneously", at least however the compiler can figure it. > > > That is: > > > if foo == 1 > else if foo == 2 > else if foo == 3 > else if foo == 4 > else if foo == 5 > > unless the compiler is very smart is always go to penalize 5 comparisons for "5", > plus the compiler might assume I'm meaning to optimize the earlier cases > as being more common, but then I have to worry about the ordering > to get the common cases earlier whereas > if I write > switch (foo) > case 1: ... > case 2: ... > case 3: ... > case 4: ... > case 5: ... > > > I'll let the compiler chose between table lookup, linear search, binary search. > "table lookup" being "simultaneous evaluation", binary search being nice > > > I also don't like "if ladders" because if I'm stepping through unoptimized > code line by line, it is tedious. > [mostly omitted aside: I go out of my way when writing command line > parsers in C to have a switch statement instead of an if/elseif/elseif ladder] > > > However > In Modula-3, I've gotten warnings when I miss cases, so there is overhead > of always writing "else". > Partly this because I don't know Modula-3 well. > > You should try to avoid else so that you are forced to handle every case. This is exactly my point. The m3back code has a lot of places that must handle a range of types (e.g., IType, AType, etc.) and using cases forces you to think about all in the range. > > The use of FloatType[type] was already there, and it is good > to have equivalence classes to reduce the number of cases listed > and allow for more to be added later, "silently". > > Again, with CASE you can still select for those, without having a cascade of IF. > > > I also don't like "data based interfaces", I prefer function calls, > that's why Is64 instead of is foo IN Types64. > (but FloatType[type] was already there) > Granted, I lament the lack of inlining in m3back. > > Function call is overkill. Use the types! > > I'm worried about nomenclature if/when this is extended to 64bit architectures. > I wonder if "Is64" should be "IsLong" or RegisterCount > 1 or something. > > No, because the front-end generates explicit types of the form Int64, Int32, Word64, Word32 for all of the code generated through m3middle. You can rely on those types as being correct. > > I think I just drifted away from using TInt.Min/Max{8,16,32,64}. > > The whole point here was for you to be explicit about types and ranges. If you know you are performing Int32 addition then you can check that the result is in range for TInt.Min32..TInt.Max32. That's exactly how you should be using TInt and getting away from the TIntN/TWordN kludge. > > I'll see if any uses remain. > Eh maybe just: > C:\dev2\cm3.2\m3-sys\m3back\src\M3x86.m3(3846): TWordN.And(imm, TWordN.Max32, immA[0]); > > > Some places were in extract/insert, and looked wrong. > > > Yes definitely more eyes on m3back appreciated. > Heck more eyes on cm3 appreciated! We have way too few. :( > There were many style changes along with making things not work. > I didn't want to sift through it all so I put it all back. > Now to ponder sifting through it more slowly from a working baseline. > > > Also I often favor mvar.mvar_type over mvar.type, so I can plain text > search for mvar_type, and not just "type". > > I do find that to be overly verbose. WIth a decent IDE it can resolve those definitions (Eclipse M3 plugin anyone?). > > I realize that you can't throw out all contexta all the time, but, > there is something to be said for flatter namespaces. > Nothing scales like plain text search. > No language aware search work adequately. > Let alone the matter of existance of languages x tools. > > > I don't think that's a mismash in the first 3, but yes FloatType makes it inconsistent. > I would certainly be ok with TypeIsFloat to make it more consistently function call based, > thoug I know I put in some cases too -- for the "simultaneous evaluation" property. > > > - Jay > > > > > > > > From: hosking at cs.purdue.edu > Date: Sat, 27 Feb 2010 14:54:40 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] max_align > > P.S. Sorry for all the push-back from me in m3middle/m3back. I'm feeling like the module police lately. I really do need to take some time to look over your m3back code and see how it can be tidied. Ideally, the Target.Int values would always be interpreted based on their associated type (which from the looks of things gets passed around just about all the places it is needed). That means checking bounds whenever performing operations using TInt (that's why I added TInt.Min/Max{8,16,32,64} and TWord.Max{8,16,32,64}). I did adopt your version of the signed TInt.Extend (which was much the same as my old Chop) and added the equivalent unsigned TWord.Truncate. One quick observation on some of the m3back code: There were a lot of places where I thought you should use CASE on the type instead of conditionals (currently involving a mishmash of Is64, IsWord, IsInt, Target.FloatType, etc. Using CASE has the advantage of warning when you don't handle every case value, and moreover makes the code more readable (uniformly handling each of the type combinations). > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On 27 Feb 2010, at 14:11, Jay K wrote: > > The issue on NT386 I was thinking of is the alignment of temporaries. That probably doesn't matter. > We probably don't generate atomic operations against them. > I already changed it to 64 for the front/middle ends > > But right, max_align is wrong for a few targets. > > I believe max_align ends up being basically target-independent. It is always 64. > Types are always aligned on their size. > The only exceptions are 68K platforms where max_align is possibly 2 bytes. > 68K targets aren't likely to rematerialize ever, though it is on my hypothetical long list. > > > PPC_something prefers a 128 bit aligned jmpbuf, but lower is ok, and max_align isn't applied to the jmpbufs > that the compiler generates, and 128 bit alignment can't be specified in Csetjmp.i3 -- seems > like a language hole to me. > > > I'd like to "just" do this, but I haven't fired up the relevant targets in a while: FreeBSD/NetBSD/x86. > > > - Jay > > > > From: hosking at cs.purdue.edu > > Date: Sat, 27 Feb 2010 11:10:32 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] TInt/TWord/N > > > > Yes, we do need to fix max_align for 64-bit atomics. I don't know what issues it will shake out though. > > On 27 Feb 2010, at 02:34, Jay K wrote: > > > > > > > >> As I understand it your stuff in m3back is mostly working. > > >> I took a look at the code there and I see a number of issues > > > > > > > > > Tony, I don't know of anything that isn't working. > > > Please let me know. > > > All 64bit operations should work. atomic32 should work. > > > Not yet atomic8/16/64, soon. > > > Oh there is an alignment issue once atomic64 is there. > > > It's present on other platforms too, for different reasons (incorrect max_align). > > > > > > > > > Thanks, > > > - Jay > > > > > > > > > ---------------------------------------- > > >> From: hosking at cs.purdue.edu > > >> Date: Sat, 27 Feb 2010 01:16:32 -0500 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] TInt/TWord/N > > >> > > >> The solution is not to push upstream into m3middle. > > >> I'll try to find some time to push through what is needed in m3back. I can't promise anything soon. Let's leave things lie for a while. As I understand it your stuff in m3back is mostly working. I took a look at the code there and I see a number of issues. Hopefully I can get a look sometime. > > >> > > >> -- T > > >> > > >> On 26 Feb 2010, at 23:48, Jay K wrote: > > >> > > >>> > > >>> Tony, I just don't understand what is wrong with TIntN, TWordN. > > >>> They are what TInt/TWord did for a long time after all. ? > > >>> Sometimes we have 4 byte integers, sometimes 8. When 4, we want overflow checking in 4, for every single operation, not just a chop when they end up in a register or such. Right? It seems natural to bundle that up conveniently. And putting them in m3middle didn't seem so contaminating to me, since they layer thinly over Target.Int. Nor do I know what the fix is, short of inlining the repitious conversions and checks. > > >>> > > >>> > > >>> - Jay > > >>> > > >>> > > >>> ---------------------------------------- > > >>>> From: hosking at cs.purdue.edu > > >>>> Date: Fri, 26 Feb 2010 19:51:15 -0500 > > >>>> To: jkrell at elego.de > > >>>> CC: m3commit at elegosoft.com > > >>>> Subject: Re: [M3commit] CVS Update: cm3 > > >>>> > > >>>> I've just spent most of the day decontaminating m3middle and putting TIntN and TWordN back into m3back as deprecated modules. m3back needs to be fixed to get rid of these. I don't have time to mess with this stuff and I am peeved that I wasted a whole day on this. > > >>>> > > >>>> On 26 Feb 2010, at 13:48, Jay Krell wrote: > > >>>> > > >>>>> CVSROOT: /usr/cvs > > >>>>> Changes by: jkrell at birch. 10/02/26 13:48:34 > > >>>>> > > >>>>> Modified files: > > >>>>> cm3/m3-sys/m3back/src/: Codex86.i3 Codex86.m3 M3x86.m3 > > >>>>> M3x86Rep.i3 Stackx86.i3 Stackx86.m3 > > >>>>> Wrx86.i3 Wrx86.m3 m3makefile > > >>>>> cm3/m3-sys/m3middle/src/: TInt.i3 TInt.m3 TIntN.i3 TIntN.m3 > > >>>>> TWordN.i3 TWordN.m3 Target.i3 > > >>>>> Target.m3 m3makefile > > >>>>> Removed files: > > >>>>> cm3/m3-sys/m3back/src/: M3BackInt.i3 M3BackInt.m3 M3BackWord.i3 > > >>>>> M3BackWord.m3 > > >>>>> > > >>>>> Log message: > > >>>>> introduce type Target.IntN which is Int plus a precision > > >>>>> just like the old Target.Int > > >>>>> (previously M3BackInt.Int) > > >>>>> > > >>>>> make TIntN and TWordN support it > > >>>>> they are just thin wrappers over TInt, TWord > > >>>>> previously named M3BackInt, M3BackWord > > >>>>> > > >>>>> add small amount of support to TInt: > > >>>>> SignExtend, SignedTruncate, ZeroExtend, UnsignedTruncate > > >>>>> These could, if desired, go into their only users: TIntN, TWordN. > > >>>>> (with the understanding that that Target.Int is "revealed" to them.) > > >>>>> > > >>>>> add maxN, minN fields to Target.Int_type, that are equal to max and min but have a precision > > >>>>> > > >>>>> NOTE: Don't worry Tony, the vast majority of m3middle, m3front, TInt, Tword are unchanged > > >>>>> This is "just" additions. > > >>>>> (Moving maintenance cost from m3back to m3middle, if that isn't a no-op.) > > >>>>> (Coming up with alternate names for M3BackInt, M3BackWord => TIntN, TWordN) > > >>>>> (A little unsatisfactory that N is bytes instead of bits.) > > >>>>> (What a fun little exercise that might be, changing Int to be array [0..63] of [0..1] :) ) > > >>>>> > > >>>>> While at it, in TIntN, rename things slightly: > > >>>>> FromInt => FromHostInteger > > >>>>> ToInt => ToHostInteger > > >>>>> > > >>>>> "Int" is "Target.Int" > > >>>>> "HostInteger" is "INTEGER" > > >>>>> > > >>>>> again, TInt/TWord/m3front/m3middle not much affected. > > >>>>> > > >>>>> One fishy/uncertain thing in all of this, something to test out, is cross builds > > >>>>> that target NT386 from 64bit host. Is TIntN.ToHostInteger correct? Or do we > > >>>>> really need INTEGER to be 4 bytes throughout m3back? > > >>>>> (I know that mklib has little endian dependency.) > > >>>> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 28 09:56:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 28 Feb 2010 08:56:08 +0000 Subject: [M3devel] r_test, pr_test, pb_test Message-ID: Olaf, I think pr_test and pb_test are cryptic, and there is no explanation what "pr" and "pb" stand for (as opposed to p_test, e_test, c_test, which have comment). I propose run_flags_test build_flags_test or program_with_run_flags program_with_build_flags program_with_compiler_flags or somesuch. I'm guessing "r" means "run flags", "b" means "build flags. I'll probably do something here very soon, since I'm adding another type of test. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Feb 28 10:54:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 28 Feb 2010 09:54:44 +0000 Subject: [M3devel] portable/less portable test variations Message-ID: I commited something here. The function in m3tests/m3makefile is "mixed_portability_test". p227 uses it. The test can be run with no parameters, in which case the output is "fully portable" (the same on all targets) and the output is compared with the "unadorned" stdout.pgm, etc. And it can be run with the flag -include-less-portable-output, in which case we probe for, e.g.: stdout.pgm32 stdout.pgm-little_endian32 stdout.pgm-little_endian (or "64" or "big") The automated tests will run both variations. As well, the preexisting recent default was to probe, as we had a few cases that needed "stdout.pgm64". We should clean this up so those are called out specifically. This way, e.g. PPC can be compared to SPARC, I386_* can be compared amongst each other, with more coverage than might be had if just all platforms compared against all platforms and the coverage constrained. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: portable/less portable test variations Date: Wed, 24 Feb 2010 12:41:12 +0000 I'd like to write tests that, given different command line parameters, will either output totally portable results, or only somewhat portable, where "somewhat" probably means either portable to particular wordsize or portable to wordsize+endian. Worst case, completely platform specific. We'd have 1, 3, or 5 checked in expected results. Or possibly 1+n (portable + n platforms). This case is less useful, because it takes away the ability to compare, e.g. LINUXLIBC6 to NT386. The test would run twice, with and without the command line option. I guess it is about as much work to implement as to describe, but I've let it drag out. I have tests that would benefit from this. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Feb 28 12:55:38 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 28 Feb 2010 12:55:38 +0100 Subject: [M3devel] r_test, pr_test, pb_test In-Reply-To: References: Message-ID: <20100228125538.29yb34mrs4wsoo4o@mail.elegosoft.com> Quoting Jay K : > Olaf, I think pr_test and pb_test are cryptic, and there is > no explanation what "pr" and "pb" stand for (as opposed > to p_test, e_test, c_test, which have comment). > > I propose > > run_flags_test > build_flags_test > > or > > program_with_run_flags > program_with_build_flags > program_with_compiler_flags > > or somesuch. > > I'm guessing "r" means "run flags", "b" means "build flags. > > I'll probably do something here very soon, since I'm adding another > type of test. Yes. I must have forgotten to document it better. They are there to run a program or its build with additional flags or options. You can easily see their use at the test instances though: pr_test ("p2", "p213", "runtime arguments: @M3paranoidgc", "@M3paranoidgc") pr_test ("p2", "p214", "runtime arguments: @M3noincremental", "@M3noincremental") pr_test ("p2", "p215", "runtime arguments: @M3nogenerational", "@M3nogenerational") pr_test ("p2", "p216", "runtime arguments: @M3nogc", "@M3nogc") pb_test ("p2", "p217", ".M3SHIP program", "-no-m3ship-resolution") pb_test ("p2", "p218", ".M3SHIP Program", "-no-m3ship-resolution") pb_test ("p2", "p219", ".M3SHIP Program group-writable", "-no-m3ship-resolution -group-writable") pb_test ("p2", "p220", ".M3SHIP library", "-no-m3ship-resolution") pb_test ("p2", "p221", ".M3SHIP Library", "-no-m3ship-resolution") pb_test ("p2", "p222", ".M3SHIP Library", "-no-m3ship-resolution -group-writable") % The following test won't run until FSUtils.RmRec() is fixed %pb_test ("p2", "p223", ".M3SHIP Library", "-no-m3ship-resolution -group-writable") Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194