From jay.krell at cornell.edu Wed Sep 1 01:09:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:09:56 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , Message-ID: I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. Yucky. I'm also going to try giving temporaries types. ?Another m3cg change like pop_struct. ?Given the latest internal error I saw. ?Maybe review m3cg for more missing type information. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > t1 must still be passed in registers. The ABI can't be changed by that. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 09:15:32 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > What happens if you take the address of t inside ActionLookup? > > What happens if you take the address of t1 inside main? > > > > On 31 Aug 2010, at 07:25, Jay K wrote: > > > > > > > > Given something like this: > > > > > > jbook2:p247 jay$ more 1.c > > > #include > > > > > > typedef struct { long code; long value; } T1; > > > > > > void ActionLookup(T1 t, long code, long value); > > > > > > void ActionLookup(T1 t, long code, long value) > > > { > > > assert(t.code == code); > > > assert(t.value == value); > > > } > > > > > > int main() > > > { > > > T1 t1 = {2,2}; > > > ActionLookup(t1, 2, 2); > > > return 0; > > > } > > > j > > > > > > > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > > > > > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > > Darn. > > > > > > > > > If m3cg were higher level this could be better. > > > > > > > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > > > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > > > > > > > Maybe we should have M3CG include field references? > > > > > > > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > > > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > > > > > > > - Jay > > > > > > From jay.krell at cornell.edu Wed Sep 1 01:05:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:05:08 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , Message-ID: t1 must still be passed in registers. The ABI can't be changed by that. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 09:15:32 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > What happens if you take the address of t inside ActionLookup? > What happens if you take the address of t1 inside main? > > On 31 Aug 2010, at 07:25, Jay K wrote: > > > > > Given something like this: > > > > jbook2:p247 jay$ more 1.c > > #include > > > > typedef struct { long code; long value; } T1; > > > > void ActionLookup(T1 t, long code, long value); > > > > void ActionLookup(T1 t, long code, long value) > > { > > assert(t.code == code); > > assert(t.value == value); > > } > > > > int main() > > { > > T1 t1 = {2,2}; > > ActionLookup(t1, 2, 2); > > return 0; > > } > > j > > > > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > Darn. > > > > > > If m3cg were higher level this could be better. > > > > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > > > > Maybe we should have M3CG include field references? > > > > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > > > > - Jay > > > From jay.krell at cornell.edu Wed Sep 1 01:13:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:13:04 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , Message-ID: Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. It might also be good to have the backend feed its computed sizes/alignments back to the front end. It'd be via more files. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 23:09:56 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > Yucky. > > I'm also going to try giving temporaries types. > Another m3cg change like pop_struct. > Given the latest internal error I saw. > Maybe review m3cg for more missing type information. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] a trouble with passing records by value.. > > Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > > > > t1 must still be passed in registers. The ABI can't be changed by that. > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Tue, 31 Aug 2010 09:15:32 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > What happens if you take the address of t inside ActionLookup? > > > What happens if you take the address of t1 inside main? > > > > > > On 31 Aug 2010, at 07:25, Jay K wrote: > > > > > > > > > > > Given something like this: > > > > > > > > jbook2:p247 jay$ more 1.c > > > > #include > > > > > > > > typedef struct { long code; long value; } T1; > > > > > > > > void ActionLookup(T1 t, long code, long value); > > > > > > > > void ActionLookup(T1 t, long code, long value) > > > > { > > > > assert(t.code == code); > > > > assert(t.value == value); > > > > } > > > > > > > > int main() > > > > { > > > > T1 t1 = {2,2}; > > > > ActionLookup(t1, 2, 2); > > > > return 0; > > > > } > > > > j > > > > > > > > > > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > > > > > > > > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > > > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > > > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > > > Darn. > > > > > > > > > > > > If m3cg were higher level this could be better. > > > > > > > > > > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > > > > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > > > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > > > > > > > > > > Maybe we should have M3CG include field references? > > > > > > > > > > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > > > > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > > > > > > > > > > - Jay > > > > > > > > > > From jay.krell at cornell.edu Wed Sep 1 01:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:19:48 +0000 Subject: [M3devel] break in cvsup Message-ID: "../src/FileAttr.m3", line 792: undefined (Utime.struct_timeval) "../src/FileAttr.m3", line 794: unknown qualification '.' (gettimeofday) "../src/FileAttr.m3", line 797: unknown qualification '.' (utimes) 3 errors encountered presumably my fault; can't look for a bit though, sorry ?- Jay From jay.krell at cornell.edu Wed Sep 1 01:53:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:53:26 +0000 Subject: [M3devel] break in cvsup In-Reply-To: References: Message-ID: oh probably just something dumb locally ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 31 Aug 2010 23:19:48 +0000 > Subject: [M3devel] break in cvsup > > > "../src/FileAttr.m3", line 792: undefined (Utime.struct_timeval) > "../src/FileAttr.m3", line 794: unknown qualification '.' (gettimeofday) > "../src/FileAttr.m3", line 797: unknown qualification '.' (utimes) > 3 errors encountered > > > presumably my fault; can't look for a bit though, sorry > > > - Jay > > > > > From jay.krell at cornell.edu Wed Sep 1 02:03:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 00:03:48 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 29 Aug 2010 13:15:44 +0200 > From: wagner at elegosoft.com > > BTW, CI is working quite well now, and produces nightly snapshots > that can be downloaded for almost all supported platforms, so this > is better than ever before. See > > http://hudson.modula3.com:8080/view/cm3-current/ > > for details. => http://www.opencm3.net/snaps/snapshot-index.html Nice! Even NT386 is working well enough (though with odd archive names :) ) ?- Jay From jay.krell at cornell.edu Wed Sep 1 02:13:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 00:13:03 +0000 Subject: [M3devel] break in cvsup In-Reply-To: References: , Message-ID: a backup in /Users/jay/dev2/cm3/m3-tools/cvsup.1/ can do that.. ?- Jay ---------------------------------------- > oh probably just something dumb locally > > - Jay > > ---------------------------------------- > > > > "../src/FileAttr.m3", line 792: undefined (Utime.struct_timeval) > > "../src/FileAttr.m3", line 794: unknown qualification '.' (gettimeofday) > > "../src/FileAttr.m3", line 797: unknown qualification '.' (utimes) > > 3 errors encountered > > > > presumably my fault; can't look for a bit though, sorry From hosking at cs.purdue.edu Wed Sep 1 02:58:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 20:58:07 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , Message-ID: <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> On 31 Aug 2010, at 19:09, Jay K wrote: > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > Yucky. I strongly advise against that hack. > I'm also going to try giving temporaries types. > Another m3cg change like pop_struct. > Given the latest internal error I saw. > Maybe review m3cg for more missing type information. This would be better... > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] a trouble with passing records by value.. >> Date: Tue, 31 Aug 2010 23:05:08 +0000 >> >> >> t1 must still be passed in registers. The ABI can't be changed by that. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] a trouble with passing records by value.. >>> >>> What happens if you take the address of t inside ActionLookup? >>> What happens if you take the address of t1 inside main? >>> >>> On 31 Aug 2010, at 07:25, Jay K wrote: >>> >>>> >>>> Given something like this: >>>> >>>> jbook2:p247 jay$ more 1.c >>>> #include >>>> >>>> typedef struct { long code; long value; } T1; >>>> >>>> void ActionLookup(T1 t, long code, long value); >>>> >>>> void ActionLookup(T1 t, long code, long value) >>>> { >>>> assert(t.code == code); >>>> assert(t.value == value); >>>> } >>>> >>>> int main() >>>> { >>>> T1 t1 = {2,2}; >>>> ActionLookup(t1, 2, 2); >>>> return 0; >>>> } >>>> j >>>> >>>> >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. >>>> >>>> >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. >>>> Darn. >>>> >>>> >>>> If m3cg were higher level this could be better. >>>> >>>> >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? >>>> >>>> >>>> Maybe we should have M3CG include field references? >>>> >>>> >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. >>>> >>>> >>>> - Jay >>>> >>> >> > From hosking at cs.purdue.edu Wed Sep 1 02:59:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 20:59:09 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , Message-ID: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> On 31 Aug 2010, at 19:13, Jay K wrote: > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. Why would it not? We specify alignment... > It might also be good to have the backend feed its computed sizes/alignments back to the front end. > It'd be via more files. YUCK!!!!!!!!! Not a good plan... > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Tue, 31 Aug 2010 23:09:56 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> >> >> I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. >> Yucky. >> >> I'm also going to try giving temporaries types. >> Another m3cg change like pop_struct. >> Given the latest internal error I saw. >> Maybe review m3cg for more missing type information. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] a trouble with passing records by value.. >>> Date: Tue, 31 Aug 2010 23:05:08 +0000 >>> >>> >>> t1 must still be passed in registers. The ABI can't be changed by that. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>> >>>> What happens if you take the address of t inside ActionLookup? >>>> What happens if you take the address of t1 inside main? >>>> >>>> On 31 Aug 2010, at 07:25, Jay K wrote: >>>> >>>>> >>>>> Given something like this: >>>>> >>>>> jbook2:p247 jay$ more 1.c >>>>> #include >>>>> >>>>> typedef struct { long code; long value; } T1; >>>>> >>>>> void ActionLookup(T1 t, long code, long value); >>>>> >>>>> void ActionLookup(T1 t, long code, long value) >>>>> { >>>>> assert(t.code == code); >>>>> assert(t.value == value); >>>>> } >>>>> >>>>> int main() >>>>> { >>>>> T1 t1 = {2,2}; >>>>> ActionLookup(t1, 2, 2); >>>>> return 0; >>>>> } >>>>> j >>>>> >>>>> >>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. >>>>> >>>>> >>>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, >>>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, >>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. >>>>> Darn. >>>>> >>>>> >>>>> If m3cg were higher level this could be better. >>>>> >>>>> >>>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" >>>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. >>>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? >>>>> >>>>> >>>>> Maybe we should have M3CG include field references? >>>>> >>>>> >>>>> There is this basic problem that the interface between m3front and m3cc isn't really at the >>>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Wed Sep 1 03:45:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 01:45:44 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> References: , ,,, , , , , , , <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> Message-ID: Both the frontend and backend seem to layout types. This is bad. I know we pass sizes/alignments to the backend, but to what extent does it have its own notions and make its own decisions? I don't fully know. It is ok if they agree, but they absolutely must agree. I suppose it is much less bad, and maybe they can disagree, because we never access fields, from the backend's point of view -- so it doesn't matter much if it thinks they are elsewhere. But what about e.g. the overall size of a record? We don't specify the layout of stack frames I believe. Perhaps we should? Perhaps every function should have one "big" local record that contains its locals? This will lead to increase correctness by decreased mismatch between backend and frontend, but it would also tie the optimizer's hand a bunch, e.g. no "stack packing" (placing locals in the same location if their lifetimes don't overlap), no removal of unused locals. There is I believe a real mismatch between the frontend and backend. I'm wondering if my feeding any type information to the backend is such a good idea afterall. It provides wonderful improvements to debugging, but feeds into this "conflict". If we only tell the backend we just have blocks of sizes/alignments, and we add offsets to those blocks, cast, deref, we will continue to avoid, e.g. backend record layout mattering. Just then a matter of dealing with records by value in a way that works. - Jay > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 20:59:09 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > On 31 Aug 2010, at 19:13, Jay K wrote: > > > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. > > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. > > Why would it not? We specify alignment... > > > It might also be good to have the backend feed its computed sizes/alignments back to the front end. > > It'd be via more files. > > YUCK!!!!!!!!! Not a good plan... > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> Date: Tue, 31 Aug 2010 23:09:56 +0000 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] a trouble with passing records by value.. > >> > >> > >> I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > >> Yucky. > >> > >> I'm also going to try giving temporaries types. > >> Another m3cg change like pop_struct. > >> Given the latest internal error I saw. > >> Maybe review m3cg for more missing type information. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] a trouble with passing records by value.. > >>> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >>> > >>> > >>> t1 must still be passed in registers. The ABI can't be changed by that. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] a trouble with passing records by value.. > >>>> > >>>> What happens if you take the address of t inside ActionLookup? > >>>> What happens if you take the address of t1 inside main? > >>>> > >>>> On 31 Aug 2010, at 07:25, Jay K wrote: > >>>> > >>>>> > >>>>> Given something like this: > >>>>> > >>>>> jbook2:p247 jay$ more 1.c > >>>>> #include > >>>>> > >>>>> typedef struct { long code; long value; } T1; > >>>>> > >>>>> void ActionLookup(T1 t, long code, long value); > >>>>> > >>>>> void ActionLookup(T1 t, long code, long value) > >>>>> { > >>>>> assert(t.code == code); > >>>>> assert(t.value == value); > >>>>> } > >>>>> > >>>>> int main() > >>>>> { > >>>>> T1 t1 = {2,2}; > >>>>> ActionLookup(t1, 2, 2); > >>>>> return 0; > >>>>> } > >>>>> j > >>>>> > >>>>> > >>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > >>>>> > >>>>> > >>>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > >>>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > >>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > >>>>> Darn. > >>>>> > >>>>> > >>>>> If m3cg were higher level this could be better. > >>>>> > >>>>> > >>>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > >>>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > >>>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > >>>>> > >>>>> > >>>>> Maybe we should have M3CG include field references? > >>>>> > >>>>> > >>>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > >>>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 1 04:00:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 02:00:58 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> References: , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> Message-ID: > I strongly advise against that hack. It's not my favorite, but I'm possibly in a jam here between providing type information for debugging with stock gdb, and I suspect an overall poor story regarding type information and backend/frontend interface. One option is to give up on type information. i.e. go back to the historical way i.e. before August 2010. That worked ok as far as most people observed (except for stock gdb..) However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. I suspect we never historically passed records in registers, and that we must continue not to. Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if it notices their address taken. It might suffice, besides giving up on type information, to mark all records as "addressable". Or, again, to slightly hack the backend. Maybe only for SPARC64. The bigger controversial question is if we should change m3cg (the interface) to know about "field references". And then, again, should layout be done by the frontend, backend, or both? There are arguments for all three options. I think the current *design* is frontend only. But I think the current *implementation* is both (except for NT386). And probably the right way is backend only. This would also generally fix the pesky "load/store use bitfields" thing. Debuggability with stock gdb does seem like a nice idea. But I see now it might conflict tremendously with our odd structuring. I'll keep poking at it. e.g.: good type information, including for temporaries, and mark all record types/values as addressable. We should still consider the notion of "field references" in the m3cg interface. Right? I'm not crazy in the "mismatch" I seem to "detect"? Probably besides given the field "name", we should pass what the frontend thinks is the offset, type, alignment. This will serve two purposes. For NT386, it will let it continue to be fairly typeless, at least for now. For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. I still have to understand how bitfields fit here also. Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! - Jay > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 20:58:07 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > Yucky. > > I strongly advise against that hack. > > > I'm also going to try giving temporaries types. > > Another m3cg change like pop_struct. > > Given the latest internal error I saw. > > Maybe review m3cg for more missing type information. > > This would be better... > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: RE: [M3devel] a trouble with passing records by value.. > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed by that. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > >>> > >>> What happens if you take the address of t inside ActionLookup? > >>> What happens if you take the address of t1 inside main? > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > >>> > >>>> > >>>> Given something like this: > >>>> > >>>> jbook2:p247 jay$ more 1.c > >>>> #include > >>>> > >>>> typedef struct { long code; long value; } T1; > >>>> > >>>> void ActionLookup(T1 t, long code, long value); > >>>> > >>>> void ActionLookup(T1 t, long code, long value) > >>>> { > >>>> assert(t.code == code); > >>>> assert(t.value == value); > >>>> } > >>>> > >>>> int main() > >>>> { > >>>> T1 t1 = {2,2}; > >>>> ActionLookup(t1, 2, 2); > >>>> return 0; > >>>> } > >>>> j > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > >>>> Darn. > >>>> > >>>> > >>>> If m3cg were higher level this could be better. > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? > >>>> > >>>> > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > >>>> > >>>> > >>>> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Sep 1 04:24:07 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 31 Aug 2010 21:24:07 -0500 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , Message-ID: <4C7DB947.5030707@lcwb.coop> If the writers of an ABI actually *required* that small structs/records be passed in registers, then they have made a big blunder. In C, formal parameters are l-values, and in Modula-3, they are designators, regardless of the parameter mode. Thus taking their address must always be possible, to comply with language semantics, which means they must be in memory. The only possible resolutions are 1) Declare that language semantics trump ABI requirements and defy the ABI. 2) Pass them in registers at the time of control transfer, but store them in memory in the prologue, then access them from memory thereafter. As for 1), any usable ABI will have to have an alternate, in-memory method of passing things by value (if for no other reason, because they can be too big for registers), so it is hard to imagine how just using this mechanism in more cases could cause any trouble that didn't already exist anyway. I guess the one case that would preclude doing 1) would be if you wanted to allow calls and prologues generated by different compilers to work, and you couldn't rely on getting all compilers to do 1). As for 2), in some stack runtime models, passing in registers is probably less efficient than just letting the call-site code store parameters directly into the being-constructed activation record. Of course, if the compiler can ascertain that the address is never taken, then it could avoid storing them, but this doesn't absolve an ABI from providing an adequate mechanism for those cases when this can't be done. And of course, making formals be l-values/designators applies to most/all other types besides structs/records. Jay K wrote: > t1 must still be passed in registers. The ABI can't be changed by that. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Tue, 31 Aug 2010 09:15:32 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> >> What happens if you take the address of t inside ActionLookup? >> What happens if you take the address of t1 inside main? >> >> On 31 Aug 2010, at 07:25, Jay K wrote: >> >>> Given something like this: >>> >>> jbook2:p247 jay$ more 1.c >>> #include >>> >>> typedef struct { long code; long value; } T1; >>> >>> void ActionLookup(T1 t, long code, long value); >>> >>> void ActionLookup(T1 t, long code, long value) >>> { >>> assert(t.code == code); >>> assert(t.value == value); >>> } >>> >>> int main() >>> { >>> T1 t1 = {2,2}; >>> ActionLookup(t1, 2, 2); >>> return 0; >>> } >>> j >>> >>> >>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. >>> >>> >>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, >>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, >>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. >>> Darn. >>> >>> >>> If m3cg were higher level this could be better. >>> >>> >>> There should be a viable compromise where the parameter is passed in registers, and only "homed" >>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. >>> But given the inefficiency of field accesses, I'm not sure it is worth trying? >>> >>> >>> Maybe we should have M3CG include field references? >>> >>> >>> There is this basic problem that the interface between m3front and m3cc isn't really at the >>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. >>> >>> >>> - Jay >>> > From hosking at cs.purdue.edu Wed Sep 1 04:22:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 22:22:16 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> Message-ID: <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> I believe there is one way out here. Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. We can even rely on Modula-3 run-time support to interpret the UIDs. I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? On 31 Aug 2010, at 22:00, Jay K wrote: > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 1 06:13:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 04:13:08 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7DB947.5030707@lcwb.coop> References: , , , , <4C7DB947.5030707@lcwb.coop> Message-ID: > Date: Tue, 31 Aug 2010 21:24:07 -0500 > From: rodney_bates@ > > If the writers of an ABI actually *required* that small structs/records be > passed in registers Yes, they have. The rules are hard for me to understand. It isn't just based on size. > then they have made a big blunder. No they have not. They know what they are doing. > Thus taking their address must always be possible, If they have to be in memory, then they will be put in memory, at or before the address is taken. That doesn't mean the parameters have to be passed in memory. > 1) Declare that language semantics trump ABI requirements and defy the ABI. Not necessary. Granted, we don't have to follow the ABI. The ABI is for interoperability with C. I'm plenty willing to say you can't pass records by value between C and Modula-3. > 2) Pass them in registers at the time of control transfer, but store them > in memory in the prologue, then access them from memory thereafter. The backend does that as needed for C already. Data can live in multiple places. Just that there can be only be one mutable location at a time. Look at the code generated Tony asked about, add like printr("%p\n", &t); you'll see the registers get written to the stack. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 1 06:26:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 04:26:48 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> References: , ,,, , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> Message-ID: > I don't particularly understand the SPARC64_SOLARIS issue When a record is passed by value SPARC64_SOLARIS backend goes to figure out the ABI for it and it hits an assertion failure. Historically no type was associated with parameters and locals in the backend. At least not for records. Maybe they had a size and an alignment. But certainly no fields. You know -- imagine a record with non-zero size but zero fields. Wierd eh? The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. (gcc can cope with some such cases the comments say, but still..) If you start but don't finish fixing this problem, by giving types to parameters, you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. I don't fully understand/remember the problem, but it is easy to uncover. Part of the problem was plain missing type information -- I fixed that in m3front. If you both imported and defined a type, you wouldn't get the information. m3front was deliberately skipping imported types, even if they coincided with locally defined types. If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, if the supertype matches. That's still not the extent of the problem on AMD64_DARWIN though. Test case p247 covers much of this. It just passes a record with a pointer and integer by value. Two integers (in record) have same problem. To try to summarize: There has been a historical lack of use of type information in the backend. Mostly the backend does get good type information from frontend, but it didn't associate it with locals/parameters. And it is better now. (globals are worse still I believe) I'm not 100% sure, but it appears to me that both the frontend and backend layout records. That is, determine the offset of each field, such as by adding up the sizes of preceding fields. (It is more involved than that, due to alignment.) I am concerned that these two layouts might not agree, and the result would be terrible. - Jay From: hosking at cs.purdue.edu Date: Tue, 31 Aug 2010 22:22:16 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] a trouble with passing records by value.. I believe there is one way out here. Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. We can even rely on Modula-3 run-time support to interpret the UIDs. I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? On 31 Aug 2010, at 22:00, Jay K wrote: > I strongly advise against that hack. It's not my favorite, but I'm possibly in a jam here between providing type information for debugging with stock gdb, and I suspect an overall poor story regarding type information and backend/frontend interface. One option is to give up on type information. i.e. go back to the historical way i.e. before August 2010. That worked ok as far as most people observed (except for stock gdb..) However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. I suspect we never historically passed records in registers, and that we must continue not to. Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if it notices their address taken. It might suffice, besides giving up on type information, to mark all records as "addressable". Or, again, to slightly hack the backend. Maybe only for SPARC64. The bigger controversial question is if we should change m3cg (the interface) to know about "field references". And then, again, should layout be done by the frontend, backend, or both? There are arguments for all three options. I think the current *design* is frontend only. But I think the current *implementation* is both (except for NT386). And probably the right way is backend only. This would also generally fix the pesky "load/store use bitfields" thing. Debuggability with stock gdb does seem like a nice idea. But I see now it might conflict tremendously with our odd structuring. I'll keep poking at it. e.g.: good type information, including for temporaries, and mark all record types/values as addressable. We should still consider the notion of "field references" in the m3cg interface. Right? I'm not crazy in the "mismatch" I seem to "detect"? Probably besides given the field "name", we should pass what the frontend thinks is the offset, type, alignment. This will serve two purposes. For NT386, it will let it continue to be fairly typeless, at least for now. For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. I still have to understand how bitfields fit here also. Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! - Jay > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 20:58:07 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > Yucky. > > I strongly advise against that hack. > > > I'm also going to try giving temporaries types. > > Another m3cg change like pop_struct. > > Given the latest internal error I saw. > > Maybe review m3cg for more missing type information. > > This would be better... > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: RE: [M3devel] a trouble with passing records by value.. > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed by that. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > >>> > >>> What happens if you take the address of t inside ActionLookup? > >>> What happens if you take the address of t1 inside main? > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > >>> > >>>> > >>>> Given something like this: > >>>> > >>>> jbook2:p247 jay$ more 1.c > >>>> #include > >>>> > >>>> typedef struct { long code; long value; } T1; > >>>> > >>>> void ActionLookup(T1 t, long code, long value); > >>>> > >>>> void ActionLookup(T1 t, long code, long value) > >>>> { > >>>> assert(t.code == code); > >>>> assert(t.value == value); > >>>> } > >>>> > >>>> int main() > >>>> { > >>>> T1 t1 = {2,2}; > >>>> ActionLookup(t1, 2, 2); > >>>> return 0; > >>>> } > >>>> j > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > >>>> Darn. > >>>> > >>>> > >>>> If m3cg were higher level this could be better. > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? > >>>> > >>>> > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > >>>> > >>>> > >>>> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 1 08:15:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Sep 2010 08:15:05 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> Quoting Jay K : > ---------------------------------------- >> Date: Sun, 29 Aug 2010 13:15:44 +0200 >> From: wagner at elegosoft.com >> >> BTW, CI is working quite well now, and produces nightly snapshots >> that can be downloaded for almost all supported platforms, so this >> is better than ever before. See >> >> http://hudson.modula3.com:8080/view/cm3-current/ >> >> for details. > > => http://www.opencm3.net/snaps/snapshot-index.html > > Nice! > > Even NT386 is working well enough (though with odd archive names :) ) Sorry for that. I'm really in favour of using the new canonical ones, but haven't got round to change them where I can. I think FreeBSD4 should be my first candidate, as this keeps to confuse people... 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 Sep 1 08:43:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 06:43:46 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> Message-ID: That's not what I meant. I've complained enough about that. :) The NT386 archive has "cygwin" in its name. I'd also like to drop "vendor"/"hardware", at least pc/unknown. Unless anyone thinks this is "programmable": run config.guess locally and then download matching archive. - Jay > Date: Wed, 1 Sep 2010 08:15:05 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Jay K : > > > ---------------------------------------- > >> Date: Sun, 29 Aug 2010 13:15:44 +0200 > >> From: wagner at elegosoft.com > >> > >> BTW, CI is working quite well now, and produces nightly snapshots > >> that can be downloaded for almost all supported platforms, so this > >> is better than ever before. See > >> > >> http://hudson.modula3.com:8080/view/cm3-current/ > >> > >> for details. > > > > => http://www.opencm3.net/snaps/snapshot-index.html > > > > Nice! > > > > Even NT386 is working well enough (though with odd archive names :) ) > > Sorry for that. I'm really in favour of using the new canonical ones, > but haven't got round to change them where I can. > > I think FreeBSD4 should be my first candidate, as this keeps to confuse > people... > > 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 Sep 1 09:57:33 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Sep 2010 09:57:33 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> Message-ID: <20100901095733.d2ml7w8xi8koo4gs@mail.elegosoft.com> Quoting Jay K : > That's not what I meant. I've complained enough about that. :) > The NT386 archive has "cygwin" in its name. Ah, that, sorry, the sleep still in my eyes led me to misread odd as old. Please add something appropriate for Windows in http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/sysinfo.sh?annotate=1.104 line 112 in function build_platform. Probably some environment variable extract? > I'd also like to drop "vendor"/"hardware", at least pc/unknown. > Unless anyone thinks this is "programmable": run config.guess > locally and then download matching archive. I think we should have a common format there. I agree that the -unknown- is unfortunate, but i386-apple- actually adds a bit of information (for those wondering about Darwin). If it looks better and doesn't break any scripts I won't object to any changes though. Olaf > - Jay > >> Date: Wed, 1 Sep 2010 08:15:05 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] CM3 services and Elego support, was: Re: >> conversion to another version control system >> >> Quoting Jay K : >> >> > ---------------------------------------- >> >> Date: Sun, 29 Aug 2010 13:15:44 +0200 >> >> From: wagner at elegosoft.com >> >> >> >> BTW, CI is working quite well now, and produces nightly snapshots >> >> that can be downloaded for almost all supported platforms, so this >> >> is better than ever before. See >> >> >> >> http://hudson.modula3.com:8080/view/cm3-current/ >> >> >> >> for details. >> > >> > => http://www.opencm3.net/snaps/snapshot-index.html >> > >> > Nice! >> > >> > Even NT386 is working well enough (though with odd archive names :) ) >> >> Sorry for that. I'm really in favour of using the new canonical ones, >> but haven't got round to change them where I can. >> >> I think FreeBSD4 should be my first candidate, as this keeps to confuse >> people... >> >> 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 Sep 1 11:05:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 09:05:57 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, Message-ID: oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type information adequately.. the backend thought all the records were one word/register/integer, and was reasonably well passing that first word/integer in a register. I needed to call layout_type. Testing another fix currently, but it works with both p247 and netobj, previously of which had conflicting requirements -- marking all records as addressable would break netobj, an assertion failure in tree-nested.c, and not fixable I believe with type information on temporaries (though I never tried that.. not sure we even ever have any temporary records..) ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Wed, 1 Sep 2010 04:26:48 +0000 > > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the > backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > > > If you start but don't finish fixing this problem, by giving types to > parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably > all AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that > in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they > coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque > error in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the > backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and > backend layout records. > That is, determine the offset of each field, such as by adding up > the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the > result would be terrible. > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in > which we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that > we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the > records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for > temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg > interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for > the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes > are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system > is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of > "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is > passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass > unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is > worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front > and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front > wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > From jay.krell at cornell.edu Wed Sep 1 13:41:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 11:41:20 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , Message-ID: Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. They don't. I think we should probably ? - not call layout_type ? - be sure to pass size/align to backend, and have it just set the values, if the rest of the ??? backend is ok with that. e.g.? m3cg_declare_field and m3cg_declare_record don't take an alignment. Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size and records are aligned on the highest alignment among their members. I have to poke around more. I'm going to disable this code again. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Wed, 1 Sep 2010 09:05:57 +0000 > > > oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type > information adequately.. the backend thought all the records were one word/register/integer, > and was reasonably well passing that first word/integer in a register. > > > I needed to call layout_type. > > > Testing another fix currently, but it works with both p247 and netobj, previously > of which had conflicting requirements -- marking all records as addressable > would break netobj, an assertion failure in tree-nested.c, and not fixable > I believe with type information on temporaries (though I never tried that.. > not sure we even ever have any temporary records..) > > - Jay > > > ________________________________ > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] a trouble with passing records by value.. > > Date: Wed, 1 Sep 2010 04:26:48 +0000 > > > > > I don't particularly understand the SPARC64_SOLARIS issue > > > > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > > out the ABI for it and it hits an assertion failure. > > > > > > Historically no type was associated with parameters and locals in the > > backend. > > At least not for records. > > Maybe they had a size and an alignment. > > But certainly no fields. > > > > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > > (gcc can cope with some such cases the comments say, but still..) > > > > > > If you start but don't finish fixing this problem, by giving types to > > parameters, > > you can then quickly run into problems in AMD64_DARWIN, and probably > > all AMD64 targets. > > I don't fully understand/remember the problem, but it is easy to uncover. > > > > > > Part of the problem was plain missing type information -- I fixed that > > in m3front. > > If you both imported and defined a type, you wouldn't get the information. > > m3front was deliberately skipping imported types, even if they > > coincided with locally defined types. > > If you fix that by defining "everything", you get duplicate opaque > > error in m3linker. I allow that now, > > if the supertype matches. > > > > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > > > > Test case p247 covers much of this. > > It just passes a record with a pointer and integer by value. > > Two integers (in record) have same problem. > > > > > > To try to summarize: > > There has been a historical lack of use of type information in the > > backend. > > Mostly the backend does get good type information from frontend, but > > it didn't associate it with locals/parameters. And it is better now. > > (globals are worse still I believe) > > > > > > I'm not 100% sure, but it appears to me that both the frontend and > > backend layout records. > > That is, determine the offset of each field, such as by adding up > > the sizes of preceding fields. > > (It is more involved than that, due to alignment.) > > I am concerned that these two layouts might not agree, and the > > result would be terrible. > > > > > > - Jay > > > > > > ________________________________ > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 22:22:16 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > I believe there is one way out here. > > Modula-3's dynamic types (UID-based) give a story for debugging in > > which we interpret the layout dynamically based on the Modula-3 type. > > We can even rely on Modula-3 run-time support to interpret the UIDs. > > > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > > elaborate? > > > > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > > > I strongly advise against that hack. > > > > > > It's not my favorite, but I'm possibly in > > a jam here between providing type information > > for debugging with stock gdb, and I suspect an > > overall poor story regarding type information > > and backend/frontend interface. > > > > > > One option is to give up on type information. > > i.e. go back to the historical way i.e. before August 2010. > > That worked ok as far as most people observed (except for stock gdb..) > > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > > > > I suspect we never historically passed records in registers, and that > > we must continue not to. > > Because of how fields are referenced. Unless maybe gcc "homes" the > > records as needed, if > > it notices their address taken. > > > > > > It might suffice, besides giving up on type information, to > > mark all records as "addressable". Or, again, to slightly > > hack the backend. Maybe only for SPARC64. > > > > > > The bigger controversial question is if we should change > > m3cg (the interface) to know about "field references". > > > > > > And then, again, should layout be done by the frontend, backend, > > or both? There are arguments for all three options. > > I think the current *design* is frontend only. > > But I think the current *implementation* is both (except for NT386). > > And probably the right way is backend only. > > > > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > > > > Debuggability with stock gdb does seem like a nice idea. > > But I see now it might conflict tremendously with our odd structuring. > > > > > > I'll keep poking at it. e.g.: good type information, including for > > temporaries, > > and mark all record types/values as addressable. > > > > > > We should still consider the notion of "field references" in the m3cg > > interface. > > Right? I'm not crazy in the "mismatch" I seem to "detect"? > > Probably besides given the field "name", we should pass what the frontend > > thinks is the offset, type, alignment. This will serve two purposes. > > For NT386, it will let it continue to be fairly typeless, at least for now. > > For m3cc, it can maybe assert that the layouts agree -- at least for > > the fields that are accessed. > > > > > > I still have to understand how bitfields fit here also. > > Though I checked -- it is quite nice afterall that offsets and sizes > > are given in bits instead of bytes! > > > > > > - Jay > > > > > > > > > From: hosking at cs.purdue.edu > > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > > to never pass structs in registers. > > > > Yucky. > > > > > > I strongly advise against that hack. > > > > > > > I'm also going to try giving temporaries types. > > > > Another m3cg change like pop_struct. > > > > Given the latest internal error I saw. > > > > Maybe review m3cg for more missing type information. > > > > > > This would be better... > > > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: jay.krell at cornell.edu > > > >> To: hosking at cs.purdue.edu > > > >> CC: m3devel at elegosoft.com > > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > >> > > > >> > > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > > >> > > > >> - Jay > > > >> > > > >> ---------------------------------------- > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > > >>> To: jay.krell at cornell.edu > > > >>> CC: m3devel at elegosoft.com > > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > > >>> > > > >>> What happens if you take the address of t inside ActionLookup? > > > >>> What happens if you take the address of t1 inside main? > > > >>> > > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > > >>> > > > >>>> > > > >>>> Given something like this: > > > >>>> > > > >>>> jbook2:p247 jay$ more 1.c > > > >>>> #include > > > >>>> > > > >>>> typedef struct { long code; long value; } T1; > > > >>>> > > > >>>> void ActionLookup(T1 t, long code, long value); > > > >>>> > > > >>>> void ActionLookup(T1 t, long code, long value) > > > >>>> { > > > >>>> assert(t.code == code); > > > >>>> assert(t.value == value); > > > >>>> } > > > >>>> > > > >>>> int main() > > > >>>> { > > > >>>> T1 t1 = {2,2}; > > > >>>> ActionLookup(t1, 2, 2); > > > >>>> return 0; > > > >>>> } > > > >>>> j > > > >>>> > > > >>>> > > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > > registers. Good. > > > >>>> > > > >>>> > > > >>>> However, one of the unfortunate aspects of our Modula-3 system > > is that when you reference e.g. t1.value, > > > >>>> the backend isn't told you are accessing the "value" "field" of > > "t1", and it figures out where that is, > > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > > have an address. Therefore it can't be in registers. > > > >>>> Darn. > > > >>>> > > > >>>> > > > >>>> If m3cg were higher level this could be better. > > > >>>> > > > >>>> > > > >>>> There should be a viable compromise where the parameter is > > passed in registers, and only "homed" > > > >>>> to some stack location if its address is used -- e.g. to pass > > unused parameters in registers. > > > >>>> But given the inefficiency of field accesses, I'm not sure it is > > worth trying? > > > >>>> > > > >>>> > > > >>>> Maybe we should have M3CG include field references? > > > >>>> > > > >>>> > > > >>>> There is this basic problem that the interface between m3front > > and m3cc isn't really at the > > > >>>> right level for m3cc. But it is probably for m3front. m3front > > wants a lower level code generator. > > > >>>> > > > >>>> > > > >>>> - Jay > > > From jay.krell at cornell.edu Wed Sep 1 13:50:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 11:50:11 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , , Message-ID: I should point out that the there is still missing type information -- typeids that are referenced but never defined, and typeids used before they are defined. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Wed, 1 Sep 2010 11:41:20 +0000 > > > Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. > They don't. > > I think we should probably > - not call layout_type > - be sure to pass size/align to backend, and have it just set the values, if the rest of the > backend is ok with that. > > e.g. m3cg_declare_field and m3cg_declare_record don't take an alignment. > > Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size > and records are aligned on the highest alignment among their members. > > I have to poke around more. I'm going to disable this code again. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] a trouble with passing records by value.. > > Date: Wed, 1 Sep 2010 09:05:57 +0000 > > > > > > oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type > > information adequately.. the backend thought all the records were one word/register/integer, > > and was reasonably well passing that first word/integer in a register. > > > > > > I needed to call layout_type. > > > > > > Testing another fix currently, but it works with both p247 and netobj, previously > > of which had conflicting requirements -- marking all records as addressable > > would break netobj, an assertion failure in tree-nested.c, and not fixable > > I believe with type information on temporaries (though I never tried that.. > > not sure we even ever have any temporary records..) > > > > - Jay > > > > > > ________________________________ > > > From: jay.krell at cornell.edu > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: RE: [M3devel] a trouble with passing records by value.. > > > Date: Wed, 1 Sep 2010 04:26:48 +0000 > > > > > > > I don't particularly understand the SPARC64_SOLARIS issue > > > > > > > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > > > out the ABI for it and it hits an assertion failure. > > > > > > > > > Historically no type was associated with parameters and locals in the > > > backend. > > > At least not for records. > > > Maybe they had a size and an alignment. > > > But certainly no fields. > > > > > > > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > > > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > > > (gcc can cope with some such cases the comments say, but still..) > > > > > > > > > If you start but don't finish fixing this problem, by giving types to > > > parameters, > > > you can then quickly run into problems in AMD64_DARWIN, and probably > > > all AMD64 targets. > > > I don't fully understand/remember the problem, but it is easy to uncover. > > > > > > > > > Part of the problem was plain missing type information -- I fixed that > > > in m3front. > > > If you both imported and defined a type, you wouldn't get the information. > > > m3front was deliberately skipping imported types, even if they > > > coincided with locally defined types. > > > If you fix that by defining "everything", you get duplicate opaque > > > error in m3linker. I allow that now, > > > if the supertype matches. > > > > > > > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > > > > > > > Test case p247 covers much of this. > > > It just passes a record with a pointer and integer by value. > > > Two integers (in record) have same problem. > > > > > > > > > To try to summarize: > > > There has been a historical lack of use of type information in the > > > backend. > > > Mostly the backend does get good type information from frontend, but > > > it didn't associate it with locals/parameters. And it is better now. > > > (globals are worse still I believe) > > > > > > > > > I'm not 100% sure, but it appears to me that both the frontend and > > > backend layout records. > > > That is, determine the offset of each field, such as by adding up > > > the sizes of preceding fields. > > > (It is more involved than that, due to alignment.) > > > I am concerned that these two layouts might not agree, and the > > > result would be terrible. > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > > From: hosking at cs.purdue.edu > > > Date: Tue, 31 Aug 2010 22:22:16 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > I believe there is one way out here. > > > Modula-3's dynamic types (UID-based) give a story for debugging in > > > which we interpret the layout dynamically based on the Modula-3 type. > > > We can even rely on Modula-3 run-time support to interpret the UIDs. > > > > > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > > > elaborate? > > > > > > > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > > > > > I strongly advise against that hack. > > > > > > > > > It's not my favorite, but I'm possibly in > > > a jam here between providing type information > > > for debugging with stock gdb, and I suspect an > > > overall poor story regarding type information > > > and backend/frontend interface. > > > > > > > > > One option is to give up on type information. > > > i.e. go back to the historical way i.e. before August 2010. > > > That worked ok as far as most people observed (except for stock gdb..) > > > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > > > > > > > I suspect we never historically passed records in registers, and that > > > we must continue not to. > > > Because of how fields are referenced. Unless maybe gcc "homes" the > > > records as needed, if > > > it notices their address taken. > > > > > > > > > It might suffice, besides giving up on type information, to > > > mark all records as "addressable". Or, again, to slightly > > > hack the backend. Maybe only for SPARC64. > > > > > > > > > The bigger controversial question is if we should change > > > m3cg (the interface) to know about "field references". > > > > > > > > > And then, again, should layout be done by the frontend, backend, > > > or both? There are arguments for all three options. > > > I think the current *design* is frontend only. > > > But I think the current *implementation* is both (except for NT386). > > > And probably the right way is backend only. > > > > > > > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > > > > > > > Debuggability with stock gdb does seem like a nice idea. > > > But I see now it might conflict tremendously with our odd structuring. > > > > > > > > > I'll keep poking at it. e.g.: good type information, including for > > > temporaries, > > > and mark all record types/values as addressable. > > > > > > > > > We should still consider the notion of "field references" in the m3cg > > > interface. > > > Right? I'm not crazy in the "mismatch" I seem to "detect"? > > > Probably besides given the field "name", we should pass what the frontend > > > thinks is the offset, type, alignment. This will serve two purposes. > > > For NT386, it will let it continue to be fairly typeless, at least for now. > > > For m3cc, it can maybe assert that the layouts agree -- at least for > > > the fields that are accessed. > > > > > > > > > I still have to understand how bitfields fit here also. > > > Though I checked -- it is quite nice afterall that offsets and sizes > > > are given in bits instead of bytes! > > > > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > > > to never pass structs in registers. > > > > > Yucky. > > > > > > > > I strongly advise against that hack. > > > > > > > > > I'm also going to try giving temporaries types. > > > > > Another m3cg change like pop_struct. > > > > > Given the latest internal error I saw. > > > > > Maybe review m3cg for more missing type information. > > > > > > > > This would be better... > > > > > > > > > > > > > > - Jay > > > > > > > > > > ---------------------------------------- > > > > >> From: jay.krell at cornell.edu > > > > >> To: hosking at cs.purdue.edu > > > > >> CC: m3devel at elegosoft.com > > > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > > >> > > > > >> > > > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > > > >> > > > > >> - Jay > > > > >> > > > > >> ---------------------------------------- > > > > >>> From: hosking at cs.purdue.edu > > > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > > > >>> To: jay.krell at cornell.edu > > > > >>> CC: m3devel at elegosoft.com > > > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > > > >>> > > > > >>> What happens if you take the address of t inside ActionLookup? > > > > >>> What happens if you take the address of t1 inside main? > > > > >>> > > > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > > > >>> > > > > >>>> > > > > >>>> Given something like this: > > > > >>>> > > > > >>>> jbook2:p247 jay$ more 1.c > > > > >>>> #include > > > > >>>> > > > > >>>> typedef struct { long code; long value; } T1; > > > > >>>> > > > > >>>> void ActionLookup(T1 t, long code, long value); > > > > >>>> > > > > >>>> void ActionLookup(T1 t, long code, long value) > > > > >>>> { > > > > >>>> assert(t.code == code); > > > > >>>> assert(t.value == value); > > > > >>>> } > > > > >>>> > > > > >>>> int main() > > > > >>>> { > > > > >>>> T1 t1 = {2,2}; > > > > >>>> ActionLookup(t1, 2, 2); > > > > >>>> return 0; > > > > >>>> } > > > > >>>> j > > > > >>>> > > > > >>>> > > > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > > > registers. Good. > > > > >>>> > > > > >>>> > > > > >>>> However, one of the unfortunate aspects of our Modula-3 system > > > is that when you reference e.g. t1.value, > > > > >>>> the backend isn't told you are accessing the "value" "field" of > > > "t1", and it figures out where that is, > > > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > > > have an address. Therefore it can't be in registers. > > > > >>>> Darn. > > > > >>>> > > > > >>>> > > > > >>>> If m3cg were higher level this could be better. > > > > >>>> > > > > >>>> > > > > >>>> There should be a viable compromise where the parameter is > > > passed in registers, and only "homed" > > > > >>>> to some stack location if its address is used -- e.g. to pass > > > unused parameters in registers. > > > > >>>> But given the inefficiency of field accesses, I'm not sure it is > > > worth trying? > > > > >>>> > > > > >>>> > > > > >>>> Maybe we should have M3CG include field references? > > > > >>>> > > > > >>>> > > > > >>>> There is this basic problem that the interface between m3front > > > and m3cc isn't really at the > > > > >>>> right level for m3cc. But it is probably for m3front. m3front > > > wants a lower level code generator. > > > > >>>> > > > > >>>> > > > > >>>> - Jay > > > > > > From hosking at cs.purdue.edu Wed Sep 1 15:51:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 09:51:42 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> Message-ID: <74ADF74D-BEB2-4694-A04D-FD3BC403B8AB@cs.purdue.edu> Surely we can give the backend enough opaque information about record types (size, alignment, etc.) without revealing their complete structure... So, layout is still computed by the front-end and the back-end just sees a bag of bits. Or is that the exact problem you are facing... On 1 Sep 2010, at 00:26, Jay K wrote: > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > > > If you start but don't finish fixing this problem, by giving types to parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and backend layout records. > That is, determine the offset of each field, such as by adding up the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the result would be terrible. > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 1 15:52:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 09:52:55 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , , Message-ID: <32B40A2C-E4B8-41B3-A2F8-74BE670382C0@cs.purdue.edu> Type ids can always be looked up via the Modula-3 run-time. On 1 Sep 2010, at 07:50, Jay K wrote: > > I should point out that the there is still missing type information -- typeids that are > referenced but never defined, and typeids used before they are defined. > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] a trouble with passing records by value.. >> Date: Wed, 1 Sep 2010 11:41:20 +0000 >> >> >> Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. >> They don't. >> >> I think we should probably >> - not call layout_type >> - be sure to pass size/align to backend, and have it just set the values, if the rest of the >> backend is ok with that. >> >> e.g. m3cg_declare_field and m3cg_declare_record don't take an alignment. >> >> Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size >> and records are aligned on the highest alignment among their members. >> >> I have to poke around more. I'm going to disable this code again. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] a trouble with passing records by value.. >>> Date: Wed, 1 Sep 2010 09:05:57 +0000 >>> >>> >>> oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type >>> information adequately.. the backend thought all the records were one word/register/integer, >>> and was reasonably well passing that first word/integer in a register. >>> >>> >>> I needed to call layout_type. >>> >>> >>> Testing another fix currently, but it works with both p247 and netobj, previously >>> of which had conflicting requirements -- marking all records as addressable >>> would break netobj, an assertion failure in tree-nested.c, and not fixable >>> I believe with type information on temporaries (though I never tried that.. >>> not sure we even ever have any temporary records..) >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] a trouble with passing records by value.. >>>> Date: Wed, 1 Sep 2010 04:26:48 +0000 >>>> >>>>> I don't particularly understand the SPARC64_SOLARIS issue >>>> >>>> >>>> When a record is passed by value SPARC64_SOLARIS backend goes to figure >>>> out the ABI for it and it hits an assertion failure. >>>> >>>> >>>> Historically no type was associated with parameters and locals in the >>>> backend. >>>> At least not for records. >>>> Maybe they had a size and an alignment. >>>> But certainly no fields. >>>> >>>> >>>> You know -- imagine a record with non-zero size but zero fields. Wierd eh? >>>> The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. >>>> (gcc can cope with some such cases the comments say, but still..) >>>> >>>> >>>> If you start but don't finish fixing this problem, by giving types to >>>> parameters, >>>> you can then quickly run into problems in AMD64_DARWIN, and probably >>>> all AMD64 targets. >>>> I don't fully understand/remember the problem, but it is easy to uncover. >>>> >>>> >>>> Part of the problem was plain missing type information -- I fixed that >>>> in m3front. >>>> If you both imported and defined a type, you wouldn't get the information. >>>> m3front was deliberately skipping imported types, even if they >>>> coincided with locally defined types. >>>> If you fix that by defining "everything", you get duplicate opaque >>>> error in m3linker. I allow that now, >>>> if the supertype matches. >>>> >>>> >>>> That's still not the extent of the problem on AMD64_DARWIN though. >>>> >>>> >>>> Test case p247 covers much of this. >>>> It just passes a record with a pointer and integer by value. >>>> Two integers (in record) have same problem. >>>> >>>> >>>> To try to summarize: >>>> There has been a historical lack of use of type information in the >>>> backend. >>>> Mostly the backend does get good type information from frontend, but >>>> it didn't associate it with locals/parameters. And it is better now. >>>> (globals are worse still I believe) >>>> >>>> >>>> I'm not 100% sure, but it appears to me that both the frontend and >>>> backend layout records. >>>> That is, determine the offset of each field, such as by adding up >>>> the sizes of preceding fields. >>>> (It is more involved than that, due to alignment.) >>>> I am concerned that these two layouts might not agree, and the >>>> result would be terrible. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> Date: Tue, 31 Aug 2010 22:22:16 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>> >>>> I believe there is one way out here. >>>> Modula-3's dynamic types (UID-based) give a story for debugging in >>>> which we interpret the layout dynamically based on the Modula-3 type. >>>> We can even rely on Modula-3 run-time support to interpret the UIDs. >>>> >>>> I don't particularly understand the SPARC64_SOLARIS issue. Can you >>>> elaborate? >>>> >>>> >>>> On 31 Aug 2010, at 22:00, Jay K wrote: >>>> >>>>> I strongly advise against that hack. >>>> >>>> >>>> It's not my favorite, but I'm possibly in >>>> a jam here between providing type information >>>> for debugging with stock gdb, and I suspect an >>>> overall poor story regarding type information >>>> and backend/frontend interface. >>>> >>>> >>>> One option is to give up on type information. >>>> i.e. go back to the historical way i.e. before August 2010. >>>> That worked ok as far as most people observed (except for stock gdb..) >>>> However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. >>>> >>>> >>>> I suspect we never historically passed records in registers, and that >>>> we must continue not to. >>>> Because of how fields are referenced. Unless maybe gcc "homes" the >>>> records as needed, if >>>> it notices their address taken. >>>> >>>> >>>> It might suffice, besides giving up on type information, to >>>> mark all records as "addressable". Or, again, to slightly >>>> hack the backend. Maybe only for SPARC64. >>>> >>>> >>>> The bigger controversial question is if we should change >>>> m3cg (the interface) to know about "field references". >>>> >>>> >>>> And then, again, should layout be done by the frontend, backend, >>>> or both? There are arguments for all three options. >>>> I think the current *design* is frontend only. >>>> But I think the current *implementation* is both (except for NT386). >>>> And probably the right way is backend only. >>>> >>>> >>>> This would also generally fix the pesky "load/store use bitfields" thing. >>>> >>>> >>>> Debuggability with stock gdb does seem like a nice idea. >>>> But I see now it might conflict tremendously with our odd structuring. >>>> >>>> >>>> I'll keep poking at it. e.g.: good type information, including for >>>> temporaries, >>>> and mark all record types/values as addressable. >>>> >>>> >>>> We should still consider the notion of "field references" in the m3cg >>>> interface. >>>> Right? I'm not crazy in the "mismatch" I seem to "detect"? >>>> Probably besides given the field "name", we should pass what the frontend >>>> thinks is the offset, type, alignment. This will serve two purposes. >>>> For NT386, it will let it continue to be fairly typeless, at least for now. >>>> For m3cc, it can maybe assert that the layouts agree -- at least for >>>> the fields that are accessed. >>>> >>>> >>>> I still have to understand how bitfields fit here also. >>>> Though I checked -- it is quite nice afterall that offsets and sizes >>>> are given in bits instead of bytes! >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>>> From: hosking at cs.purdue.edu >>>>> Date: Tue, 31 Aug 2010 20:58:07 -0400 >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>>> >>>>> >>>>> >>>>> On 31 Aug 2010, at 19:09, Jay K wrote: >>>>> >>>>>> >>>>>> I'm possibly going to try changing the target-specific code in gcc >>>> to never pass structs in registers. >>>>>> Yucky. >>>>> >>>>> I strongly advise against that hack. >>>>> >>>>>> I'm also going to try giving temporaries types. >>>>>> Another m3cg change like pop_struct. >>>>>> Given the latest internal error I saw. >>>>>> Maybe review m3cg for more missing type information. >>>>> >>>>> This would be better... >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] a trouble with passing records by value.. >>>>>>> Date: Tue, 31 Aug 2010 23:05:08 +0000 >>>>>>> >>>>>>> >>>>>>> t1 must still be passed in registers. The ABI can't be changed by that. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >>>>>>>> To: jay.krell at cornell.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>>>>>> >>>>>>>> What happens if you take the address of t inside ActionLookup? >>>>>>>> What happens if you take the address of t1 inside main? >>>>>>>> >>>>>>>> On 31 Aug 2010, at 07:25, Jay K wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Given something like this: >>>>>>>>> >>>>>>>>> jbook2:p247 jay$ more 1.c >>>>>>>>> #include >>>>>>>>> >>>>>>>>> typedef struct { long code; long value; } T1; >>>>>>>>> >>>>>>>>> void ActionLookup(T1 t, long code, long value); >>>>>>>>> >>>>>>>>> void ActionLookup(T1 t, long code, long value) >>>>>>>>> { >>>>>>>>> assert(t.code == code); >>>>>>>>> assert(t.value == value); >>>>>>>>> } >>>>>>>>> >>>>>>>>> int main() >>>>>>>>> { >>>>>>>>> T1 t1 = {2,2}; >>>>>>>>> ActionLookup(t1, 2, 2); >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in >>>> registers. Good. >>>>>>>>> >>>>>>>>> >>>>>>>>> However, one of the unfortunate aspects of our Modula-3 system >>>> is that when you reference e.g. t1.value, >>>>>>>>> the backend isn't told you are accessing the "value" "field" of >>>> "t1", and it figures out where that is, >>>>>>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must >>>> have an address. Therefore it can't be in registers. >>>>>>>>> Darn. >>>>>>>>> >>>>>>>>> >>>>>>>>> If m3cg were higher level this could be better. >>>>>>>>> >>>>>>>>> >>>>>>>>> There should be a viable compromise where the parameter is >>>> passed in registers, and only "homed" >>>>>>>>> to some stack location if its address is used -- e.g. to pass >>>> unused parameters in registers. >>>>>>>>> But given the inefficiency of field accesses, I'm not sure it is >>>> worth trying? >>>>>>>>> >>>>>>>>> >>>>>>>>> Maybe we should have M3CG include field references? >>>>>>>>> >>>>>>>>> >>>>>>>>> There is this basic problem that the interface between m3front >>>> and m3cc isn't really at the >>>>>>>>> right level for m3cc. But it is probably for m3front. m3front >>>> wants a lower level code generator. >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>> >>> >> > From rodney_bates at lcwb.coop Wed Sep 1 16:41:13 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 01 Sep 2010 09:41:13 -0500 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> Message-ID: <4C7E6609.4000107@lcwb.coop> Jay K wrote: > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the > backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > Is it possible the assertion is just overzealous and can be removed? Or, if the assertion is really needed, can gcc be changed so it no longer needs it? Would this approach be a simpler way? I sounds like it might at least be a more local change, instead of the pervasive problems that have emerged from putting type info in at the front of gcc. Or, are you trying to avoid internal changes to gcc at all cost? > > If you start but don't finish fixing this problem, by giving types to > parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably all > AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that > in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they > coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque error > in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the > backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and > backend layout records. > That is, determine the offset of each field, such as by adding up > the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the result > would be terrible. > > > - Jay > > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in which > we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and > that we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the > records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" > thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for > temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the > m3cg interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the > frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least > for now. > For m3cc, it can maybe assert that the layouts agree -- at least for > the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes > are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in > gcc to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed > by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 > system is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" > of "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is > passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass > unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it > is worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between > m3front and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front > wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > > From hosking at cs.purdue.edu Wed Sep 1 16:54:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 10:54:43 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7E6609.4000107@lcwb.coop> References: , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> <4C7E6609.4000107@lcwb.coop> Message-ID: <29E75898-3FBC-4C65-8200-78F448B18183@cs.purdue.edu> I would very much hesitate to remove these internal assertions in GCC since they tend to be needed to catch invariants that the rest of the compiler relies upon. Especially, internal changes to the backend of gcc is something to be strongly avoided. My inclination would be to type the record in a way that forces gcc to assume the worst and not pass the record in a register. I don't know what the sparc64 ABI says about passing structs, but surely we can type it in such as way as to get the behaviour the CM3 front-end expects. On 1 Sep 2010, at 10:41, Rodney M. Bates wrote: > > > Jay K wrote: >> > I don't particularly understand the SPARC64_SOLARIS issue >> When a record is passed by value SPARC64_SOLARIS backend goes to figure >> out the ABI for it and it hits an assertion failure. >> Historically no type was associated with parameters and locals in the backend. >> At least not for records. >> Maybe they had a size and an alignment. >> But certainly no fields. >> You know -- imagine a record with non-zero size but zero fields. Wierd eh? >> The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. >> (gcc can cope with some such cases the comments say, but still..) >> > > Is it possible the assertion is just overzealous and can be removed? > Or, if the assertion is really needed, can gcc be changed so it no > longer needs it? Would this approach be a simpler way? I sounds like > it might at least be a more local change, instead of the pervasive > problems that have emerged from putting type info in at the front of > gcc. > > Or, are you trying to avoid internal changes to gcc at all cost? > > >> If you start but don't finish fixing this problem, by giving types to parameters, >> you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. >> I don't fully understand/remember the problem, but it is easy to uncover. >> Part of the problem was plain missing type information -- I fixed that in m3front. >> If you both imported and defined a type, you wouldn't get the information. >> m3front was deliberately skipping imported types, even if they coincided with locally defined types. >> If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, >> if the supertype matches. >> That's still not the extent of the problem on AMD64_DARWIN though. >> Test case p247 covers much of this. >> It just passes a record with a pointer and integer by value. >> Two integers (in record) have same problem. >> To try to summarize: >> There has been a historical lack of use of type information in the backend. >> Mostly the backend does get good type information from frontend, but >> it didn't associate it with locals/parameters. And it is better now. >> (globals are worse still I believe) >> I'm not 100% sure, but it appears to me that both the frontend and backend layout records. >> That is, determine the offset of each field, such as by adding up the sizes of preceding fields. >> (It is more involved than that, due to alignment.) >> I am concerned that these two layouts might not agree, and the result would be terrible. >> - Jay >> ------------------------------------------------------------------------ >> From: hosking at cs.purdue.edu >> Date: Tue, 31 Aug 2010 22:22:16 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> I believe there is one way out here. >> Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. >> We can even rely on Modula-3 run-time support to interpret the UIDs. >> I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? >> On 31 Aug 2010, at 22:00, Jay K wrote: >> > I strongly advise against that hack. >> It's not my favorite, but I'm possibly in >> a jam here between providing type information >> for debugging with stock gdb, and I suspect an >> overall poor story regarding type information >> and backend/frontend interface. >> One option is to give up on type information. >> i.e. go back to the historical way i.e. before August 2010. >> That worked ok as far as most people observed (except for stock gdb..) >> However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. >> I suspect we never historically passed records in registers, and >> that we must continue not to. >> Because of how fields are referenced. Unless maybe gcc "homes" the >> records as needed, if >> it notices their address taken. >> It might suffice, besides giving up on type information, to >> mark all records as "addressable". Or, again, to slightly >> hack the backend. Maybe only for SPARC64. >> The bigger controversial question is if we should change >> m3cg (the interface) to know about "field references". >> And then, again, should layout be done by the frontend, backend, >> or both? There are arguments for all three options. >> I think the current *design* is frontend only. >> But I think the current *implementation* is both (except for NT386). >> And probably the right way is backend only. >> This would also generally fix the pesky "load/store use bitfields" >> thing. >> Debuggability with stock gdb does seem like a nice idea. >> But I see now it might conflict tremendously with our odd structuring. >> I'll keep poking at it. e.g.: good type information, including for >> temporaries, >> and mark all record types/values as addressable. >> We should still consider the notion of "field references" in the >> m3cg interface. >> Right? I'm not crazy in the "mismatch" I seem to "detect"? >> Probably besides given the field "name", we should pass what the >> frontend >> thinks is the offset, type, alignment. This will serve two purposes. >> For NT386, it will let it continue to be fairly typeless, at least >> for now. >> For m3cc, it can maybe assert that the layouts agree -- at least for >> the fields that are accessed. >> I still have to understand how bitfields fit here also. >> Though I checked -- it is quite nice afterall that offsets and sizes >> are given in bits instead of bytes! >> - Jay >> > From: hosking at cs.purdue.edu >> > Date: Tue, 31 Aug 2010 20:58:07 -0400 >> > To: jay.krell at cornell.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] a trouble with passing records by value.. >> > > > > On 31 Aug 2010, at 19:09, Jay K wrote: >> > > > > > I'm possibly going to try changing the target-specific code in >> gcc to never pass structs in registers. >> > > Yucky. >> > > I strongly advise against that hack. >> > > > I'm also going to try giving temporaries types. >> > > Another m3cg change like pop_struct. >> > > Given the latest internal error I saw. >> > > Maybe review m3cg for more missing type information. >> > > This would be better... >> > > > > > - Jay >> > > > > ---------------------------------------- >> > >> From: jay.krell at cornell.edu >> > >> To: hosking at cs.purdue.edu >> > >> CC: m3devel at elegosoft.com >> > >> Subject: RE: [M3devel] a trouble with passing records by value.. >> > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 >> > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed >> by that. >> > >> > >> - Jay >> > >> > >> ---------------------------------------- >> > >>> From: hosking at cs.purdue.edu >> > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >> > >>> To: jay.krell at cornell.edu >> > >>> CC: m3devel at elegosoft.com >> > >>> Subject: Re: [M3devel] a trouble with passing records by value.. >> > >>> > >>> What happens if you take the address of t inside ActionLookup? >> > >>> What happens if you take the address of t1 inside main? >> > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: >> > >>> > >>>> > >>>> Given something like this: >> > >>>> > >>>> jbook2:p247 jay$ more 1.c >> > >>>> #include >> > >>>> > >>>> typedef struct { long code; long value; } T1; >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value); >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value) >> > >>>> { >> > >>>> assert(t.code == code); >> > >>>> assert(t.value == value); >> > >>>> } >> > >>>> > >>>> int main() >> > >>>> { >> > >>>> T1 t1 = {2,2}; >> > >>>> ActionLookup(t1, 2, 2); >> > >>>> return 0; >> > >>>> } >> > >>>> j >> > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in >> registers. Good. >> > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 >> system is that when you reference e.g. t1.value, >> > >>>> the backend isn't told you are accessing the "value" "field" >> of "t1", and it figures out where that is, >> > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must >> have an address. Therefore it can't be in registers. >> > >>>> Darn. >> > >>>> > >>>> > >>>> If m3cg were higher level this could be better. >> > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is >> passed in registers, and only "homed" >> > >>>> to some stack location if its address is used -- e.g. to pass >> unused parameters in registers. >> > >>>> But given the inefficiency of field accesses, I'm not sure it >> is worth trying? >> > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? >> > >>>> > >>>> > >>>> There is this basic problem that the interface between >> m3front and m3cc isn't really at the >> > >>>> right level for m3cc. But it is probably for m3front. m3front >> wants a lower level code generator. >> > >>>> > >>>> > >>>> - Jay From jay.krell at cornell.edu Wed Sep 1 16:58:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 14:58:24 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <29E75898-3FBC-4C65-8200-78F448B18183@cs.purdue.edu> References: , , ,,, , ,,, ,,, , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , , , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , <4C7E6609.4000107@lcwb.coop>, <29E75898-3FBC-4C65-8200-78F448B18183@cs.purdue.edu> Message-ID: 1) I'm not sure there is a type that lets SPARC64_SOLARIS just work and be correct. 2) I want the type to be correct so that debugging with stock gdb works. Currently I'm fighting with getting unaligned bitfields.. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 1 Sep 2010 10:54:43 -0400 > To: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I would very much hesitate to remove these internal assertions in GCC since they tend to be needed to catch invariants that the rest of the compiler relies upon. Especially, internal changes to the backend of gcc is something to be strongly avoided. My inclination would be to type the record in a way that forces gcc to assume the worst and not pass the record in a register. I don't know what the sparc64 ABI says about passing structs, but surely we can type it in such as way as to get the behaviour the CM3 front-end expects. > > On 1 Sep 2010, at 10:41, Rodney M. Bates wrote: > > > > > > > Jay K wrote: > >> > I don't particularly understand the SPARC64_SOLARIS issue > >> When a record is passed by value SPARC64_SOLARIS backend goes to figure > >> out the ABI for it and it hits an assertion failure. > >> Historically no type was associated with parameters and locals in the backend. > >> At least not for records. > >> Maybe they had a size and an alignment. > >> But certainly no fields. > >> You know -- imagine a record with non-zero size but zero fields. Wierd eh? > >> The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > >> (gcc can cope with some such cases the comments say, but still..) > >> > > > > Is it possible the assertion is just overzealous and can be removed? > > Or, if the assertion is really needed, can gcc be changed so it no > > longer needs it? Would this approach be a simpler way? I sounds like > > it might at least be a more local change, instead of the pervasive > > problems that have emerged from putting type info in at the front of > > gcc. > > > > Or, are you trying to avoid internal changes to gcc at all cost? > > > > > >> If you start but don't finish fixing this problem, by giving types to parameters, > >> you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. > >> I don't fully understand/remember the problem, but it is easy to uncover. > >> Part of the problem was plain missing type information -- I fixed that in m3front. > >> If you both imported and defined a type, you wouldn't get the information. > >> m3front was deliberately skipping imported types, even if they coincided with locally defined types. > >> If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, > >> if the supertype matches. > >> That's still not the extent of the problem on AMD64_DARWIN though. > >> Test case p247 covers much of this. > >> It just passes a record with a pointer and integer by value. > >> Two integers (in record) have same problem. > >> To try to summarize: > >> There has been a historical lack of use of type information in the backend. > >> Mostly the backend does get good type information from frontend, but > >> it didn't associate it with locals/parameters. And it is better now. > >> (globals are worse still I believe) > >> I'm not 100% sure, but it appears to me that both the frontend and backend layout records. > >> That is, determine the offset of each field, such as by adding up the sizes of preceding fields. > >> (It is more involved than that, due to alignment.) > >> I am concerned that these two layouts might not agree, and the result would be terrible. > >> - Jay > >> ------------------------------------------------------------------------ > >> From: hosking at cs.purdue.edu > >> Date: Tue, 31 Aug 2010 22:22:16 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] a trouble with passing records by value.. > >> I believe there is one way out here. > >> Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. > >> We can even rely on Modula-3 run-time support to interpret the UIDs. > >> I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? > >> On 31 Aug 2010, at 22:00, Jay K wrote: > >> > I strongly advise against that hack. > >> It's not my favorite, but I'm possibly in > >> a jam here between providing type information > >> for debugging with stock gdb, and I suspect an > >> overall poor story regarding type information > >> and backend/frontend interface. > >> One option is to give up on type information. > >> i.e. go back to the historical way i.e. before August 2010. > >> That worked ok as far as most people observed (except for stock gdb..) > >> However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > >> I suspect we never historically passed records in registers, and > >> that we must continue not to. > >> Because of how fields are referenced. Unless maybe gcc "homes" the > >> records as needed, if > >> it notices their address taken. > >> It might suffice, besides giving up on type information, to > >> mark all records as "addressable". Or, again, to slightly > >> hack the backend. Maybe only for SPARC64. > >> The bigger controversial question is if we should change > >> m3cg (the interface) to know about "field references". > >> And then, again, should layout be done by the frontend, backend, > >> or both? There are arguments for all three options. > >> I think the current *design* is frontend only. > >> But I think the current *implementation* is both (except for NT386). > >> And probably the right way is backend only. > >> This would also generally fix the pesky "load/store use bitfields" > >> thing. > >> Debuggability with stock gdb does seem like a nice idea. > >> But I see now it might conflict tremendously with our odd structuring. > >> I'll keep poking at it. e.g.: good type information, including for > >> temporaries, > >> and mark all record types/values as addressable. > >> We should still consider the notion of "field references" in the > >> m3cg interface. > >> Right? I'm not crazy in the "mismatch" I seem to "detect"? > >> Probably besides given the field "name", we should pass what the > >> frontend > >> thinks is the offset, type, alignment. This will serve two purposes. > >> For NT386, it will let it continue to be fairly typeless, at least > >> for now. > >> For m3cc, it can maybe assert that the layouts agree -- at least for > >> the fields that are accessed. > >> I still have to understand how bitfields fit here also. > >> Though I checked -- it is quite nice afterall that offsets and sizes > >> are given in bits instead of bytes! > >> - Jay > >> > From: hosking at cs.purdue.edu > >> > Date: Tue, 31 Aug 2010 20:58:07 -0400 > >> > To: jay.krell at cornell.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] a trouble with passing records by value.. > >> > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > >> > > > > > I'm possibly going to try changing the target-specific code in > >> gcc to never pass structs in registers. > >> > > Yucky. > >> > > I strongly advise against that hack. > >> > > > I'm also going to try giving temporaries types. > >> > > Another m3cg change like pop_struct. > >> > > Given the latest internal error I saw. > >> > > Maybe review m3cg for more missing type information. > >> > > This would be better... > >> > > > > > - Jay > >> > > > > ---------------------------------------- > >> > >> From: jay.krell at cornell.edu > >> > >> To: hosking at cs.purdue.edu > >> > >> CC: m3devel at elegosoft.com > >> > >> Subject: RE: [M3devel] a trouble with passing records by value.. > >> > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >> > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed > >> by that. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >> > >>> From: hosking at cs.purdue.edu > >> > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >> > >>> To: jay.krell at cornell.edu > >> > >>> CC: m3devel at elegosoft.com > >> > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > >> > >>> > >>> What happens if you take the address of t inside ActionLookup? > >> > >>> What happens if you take the address of t1 inside main? > >> > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > >> > >>> > >>>> > >>>> Given something like this: > >> > >>>> > >>>> jbook2:p247 jay$ more 1.c > >> > >>>> #include > >> > >>>> > >>>> typedef struct { long code; long value; } T1; > >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value); > >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value) > >> > >>>> { > >> > >>>> assert(t.code == code); > >> > >>>> assert(t.value == value); > >> > >>>> } > >> > >>>> > >>>> int main() > >> > >>>> { > >> > >>>> T1 t1 = {2,2}; > >> > >>>> ActionLookup(t1, 2, 2); > >> > >>>> return 0; > >> > >>>> } > >> > >>>> j > >> > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > >> registers. Good. > >> > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 > >> system is that when you reference e.g. t1.value, > >> > >>>> the backend isn't told you are accessing the "value" "field" > >> of "t1", and it figures out where that is, > >> > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > >> have an address. Therefore it can't be in registers. > >> > >>>> Darn. > >> > >>>> > >>>> > >>>> If m3cg were higher level this could be better. > >> > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is > >> passed in registers, and only "homed" > >> > >>>> to some stack location if its address is used -- e.g. to pass > >> unused parameters in registers. > >> > >>>> But given the inefficiency of field accesses, I'm not sure it > >> is worth trying? > >> > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? > >> > >>>> > >>>> > >>>> There is this basic problem that the interface between > >> m3front and m3cc isn't really at the > >> > >>>> right level for m3cc. But it is probably for m3front. m3front > >> wants a lower level code generator. > >> > >>>> > >>>> > >>>> - Jay > From jay.krell at cornell.edu Wed Sep 1 16:59:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 14:59:46 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <74ADF74D-BEB2-4694-A04D-FD3BC403B8AB@cs.purdue.edu> References: , ,,, , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> , <74ADF74D-BEB2-4694-A04D-FD3BC403B8AB@cs.purdue.edu> Message-ID: Yes and yes -- that isn't adequate, and I'd like stock gdb to work. ?- Jay ________________________________ > Subject: Re: [M3devel] a trouble with passing records by value.. > From: hosking at cs.purdue.edu > Date: Wed, 1 Sep 2010 09:51:42 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Surely we can give the backend enough opaque information about record > types (size, alignment, etc.) without revealing their complete > structure... So, layout is still computed by the front-end and the > back-end just sees a bag of bits. Or is that the exact problem you are > facing... > > On 1 Sep 2010, at 00:26, Jay K wrote: > > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the > backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > > > If you start but don't finish fixing this problem, by giving types to > parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably > all AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that > in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they > coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque > error in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the > backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and > backend layout records. > That is, determine the offset of each field, such as by adding up > the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the > result would be terrible. > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in > which we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that > we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the > records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for > temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg > interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for > the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes > are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system > is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of > "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is > passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass > unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is > worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front > and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front > wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > > > From hendrik at topoi.pooq.com Wed Sep 1 17:29:27 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Sep 2010 11:29:27 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: Message-ID: <20100901152927.GA28881@topoi.pooq.com> On Wed, Sep 01, 2010 at 11:41:20AM +0000, Jay K wrote: > > Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. > They don't. > > I think we should probably > ? - not call layout_type > ? - be sure to pass size/align to backend, and have it just set the values, if the rest of the > ??? backend is ok with that. > > e.g.? m3cg_declare_field and m3cg_declare_record don't take an alignment. > > Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size > and records are aligned on the highest alignment among their members. I seem to remember an exception on one of the old IBM "workstations". Its structires were 32-bit aligned (and its 64-bit floats were 32-bit aligned *except* that structures whose first actual field was a 64-bit float had to be 64-bit aligned. "First actual field" meancould mean the first field of the first field of the first field of ... of the first field. I've never figured out the reason for that crazy rule. long floats anywhere else in the structure didn't matter. Let's hope you don't have to be copatible with *that* C compiler! -- hendrik > > I have to poke around more. I'm going to disable this code again. > > ?- Jay > From hendrik at topoi.pooq.com Wed Sep 1 17:36:31 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Sep 2010 11:36:31 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> References: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> Message-ID: <20100901153631.GB28881@topoi.pooq.com> On Tue, Aug 31, 2010 at 08:59:09PM -0400, Tony Hosking wrote: > On 31 Aug 2010, at 19:13, Jay K wrote: > > > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. > > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. > > Why would it not? We specify alignment... > > > It might also be good to have the backend feed its computed sizes/alignments back to the front end. > > It'd be via more files. > > YUCK!!!!!!!!! Not a good plan... I've always thought back ends and front ends should communicate more, but not if they are separatee processes run at separate times; especially if the feedback would involve some kind of surrogate time travel. But failing that, it might be good to have a suite of sizes/alignment tests, where the front end explicitly reports sizes and aligmment and the back end does the same. It that's done by generating all these numbers into the executable and writing them out at run-time, that would be OK. -- hendrik From hendrik at topoi.pooq.com Wed Sep 1 17:47:14 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Sep 2010 11:47:14 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7DB947.5030707@lcwb.coop> References: <4C7DB947.5030707@lcwb.coop> Message-ID: <20100901154713.GC28881@topoi.pooq.com> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: > If the writers of an ABI actually *required* that small structs/records be > passed in registers, then they have made a big blunder. In C, formal > parameters are l-values, but they are copies of the corresponding actual parameters. > and in Modula-3, they are designators, regardless > of the parameter mode. Thus taking their address must always be possible, > to comply with language semantics, which means they must be in memory. > > The only possible resolutions are > > 1) Declare that language semantics trump ABI requirements and defy the ABI. On most platforms I ever had to be binary-compatible with in a C interpreter I dealt with long long ago, declaring the formal parameters as "..." (like printf) kept them in storage on the stack. -- hendrik > > 2) Pass them in registers at the time of control transfer, but store them > in memory in the prologue, then access them from memory thereafter. That's what the more optimizing compilers did, except they only ccopied them to memory if the called code actually needed them to be in memory. And they also watched out for functions whose addresses were taken, or were accessible by external linkage. But it mattered whether the function had a prototoype, and whether parameters were declared as "...". -- hendrik From jay.krell at cornell.edu Wed Sep 1 18:10:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 16:10:02 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <20100901154713.GC28881@topoi.pooq.com> References: , , <4C7DB947.5030707@lcwb.coop>, <20100901154713.GC28881@topoi.pooq.com> Message-ID: "..." won't let me see things gdb. Clever hack though. The backend below parse.c implements the ABI, and generation of debugging information, as long as you give it correctly typed trees. So yes, we would generally be compatible with the C compiler. Except, well, except that m3front does the same work. Not good. ?- Jay ---------------------------------------- > Date: Wed, 1 Sep 2010 11:47:14 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: > > If the writers of an ABI actually *required* that small structs/records be > > passed in registers, then they have made a big blunder. In C, formal > > parameters are l-values, > > but they are copies of the corresponding actual parameters. > > > and in Modula-3, they are designators, regardless > > of the parameter mode. Thus taking their address must always be possible, > > to comply with language semantics, which means they must be in memory. > > > > The only possible resolutions are > > > > 1) Declare that language semantics trump ABI requirements and defy the ABI. > > On most platforms I ever had to be binary-compatible with in a C > interpreter I dealt with long long ago, declaring the formal parameters > as "..." (like printf) kept them in storage on the stack. > > -- hendrik > > > > > 2) Pass them in registers at the time of control transfer, but store them > > in memory in the prologue, then access them from memory thereafter. > > That's what the more optimizing compilers did, except they only ccopied > them to memory if the called code actually needed them to be in memory. > And they also watched out for functions whose addresses were taken, or > were accessible by external linkage. > > But it mattered whether the function had a prototoype, and whether > parameters were declared as "...". > > -- hendrik From jay.krell at cornell.edu Wed Sep 1 18:30:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 16:30:35 +0000 Subject: [M3devel] debugging with stock gdb Message-ID: Here's a quick sample of what you can do now in gdb, so much better than before. Records used to have no types. This is on Darwin. jbook2:m3cc jay$ gdb /cm3/bin/Juno GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009) (gdb) break RTType__Expand (gdb) run Breakpoint 1, RTType__Expand (M3_DaARCY_m=0x1010cccd0) at ../src/runtime/common/RTType.m3:715 715??? ??? new : InfoMap; (gdb) n 716??? ??? pi, pt: SlotPtr; (gdb) n 719??? ??? IF m.map = NIL THEN (gdb) 721??? ????? m.cnt? := 0; (gdb) info locals M3_AcxOUs_key2 = 4312105936 M3_AcxOUs_key1 = 4321920593 M3_EM4UH1_pt = (struct {...} ***) 0x0 M3_EM4UH1_pi = (struct {...} ***) 0x0 M3_BQo8Jp_new = { ? name = 0x0, ? is_equal = 0x0, ? rehash = 0x0, ? initial_size = 0, ? full = 0, ? cnt = 0, ? max = 0, ? mask = 0, ? map = 0x0 } (gdb) p **M3_DaARCY_m $1 = { ? name = 0x1010e2ca0, ? is_equal = 0x8, ? rehash = 0x7364697565707974, ? initial_size = 0, ? full = 2, ? cnt = 4312673440, ? max = 6, ? mask = 126875185803874, ? map = 0x2 } ?- Jay From hosking at cs.purdue.edu Wed Sep 1 21:23:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 15:23:17 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , <4C7DB947.5030707@lcwb.coop>, <20100901154713.GC28881@topoi.pooq.com> Message-ID: <9D70491C-0B0A-4FC2-B4E9-A2E7EE35337F@cs.purdue.edu> Surely there are ways to type things such that the backend is forced to compute the same layout as the front-end. Can we type fields as bitfields to get what's needed? On 1 Sep 2010, at 12:10, Jay K wrote: > > "..." won't let me see things gdb. > Clever hack though. > > > The backend below parse.c implements the ABI, and generation of debugging information, > as long as you give it correctly typed trees. So yes, we would generally be compatible > with the C compiler. Except, well, except that m3front does the same work. Not good. > > > - Jay > > ---------------------------------------- >> Date: Wed, 1 Sep 2010 11:47:14 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> >> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: >>> If the writers of an ABI actually *required* that small structs/records be >>> passed in registers, then they have made a big blunder. In C, formal >>> parameters are l-values, >> >> but they are copies of the corresponding actual parameters. >> >>> and in Modula-3, they are designators, regardless >>> of the parameter mode. Thus taking their address must always be possible, >>> to comply with language semantics, which means they must be in memory. >>> >>> The only possible resolutions are >>> >>> 1) Declare that language semantics trump ABI requirements and defy the ABI. >> >> On most platforms I ever had to be binary-compatible with in a C >> interpreter I dealt with long long ago, declaring the formal parameters >> as "..." (like printf) kept them in storage on the stack. >> >> -- hendrik >> >>> >>> 2) Pass them in registers at the time of control transfer, but store them >>> in memory in the prologue, then access them from memory thereafter. >> >> That's what the more optimizing compilers did, except they only ccopied >> them to memory if the called code actually needed them to be in memory. >> And they also watched out for functions whose addresses were taken, or >> were accessible by external linkage. >> >> But it mattered whether the function had a prototoype, and whether >> parameters were declared as "...". >> >> -- hendrik > From dabenavidesd at yahoo.es Wed Sep 1 23:53:33 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 1 Sep 2010 21:53:33 +0000 (GMT) Subject: [M3devel] debugging with stock gdb Message-ID: <583899.90242.qm@web29704.mail.ird.yahoo.com> Hi all: Yes I think this might be useful specially debugging when no stock m3gdb available. I wanted to also consider this case you have great disassemblers, debuggers and plenty of useful tools for easier debugging. If you could do that would be great for all the developers planning transition to Modula-3 from other languages. But thinking in the core developers testers, users as you have seen probably the best resource at hand even in the case there are better ones is just to keep the new environment enhancing and porting. Most of code debuggers are written from runtime environments so the advantage would be cumbersome because we need also a lot of tools to keep track of all variety of this third party tools distributors. Also if in such an effort you can actually test changes in fewer platforms. In the other case would be newer things to ask and use on the new stock debugger. So keeping the changes in this way will get more of the same characteristics at some level less or more but in the end you will you would just have to keep an effort in the same way, not too many in a lot of different ways certainly. By the end of the day it will be just less output for the same work and as a contrast more output for same work, so a lot easier if not new things were added. A wanted feature might be a less harder work to port to new system, this was achieved using the native code generators but this was a lot of effort to put it to work still. I guess this efforts could be later enhanced for the good of the native platform and others also. In other projects efforts are working towards that end, like openwatcom. As being openned they have more customers, users and developers with different needs and they are working to adapt their system to that. Perhaps no with the same effort to put it to work in other systems but certainly to their system that's an useful advantage to host more users with same system Probably this kind of systems doesn't allow too much new tools if they want to maintain the user base, but they wanted and have to move forward with new ones. As a result the system is enhanced but the cost or effort could be less than the actual to get a new runtime environment to work in top of it. Main thing here was to try to save some time in getting user and easily adapted to your users, but you have spent more time in that case for that thing than keeping up to date of others. So you might wonder how this might happen. Well in such a case we need a little more of illustration we can take advantage of a useful paper to look for standing with the challenges that anyway come like this side effect of independent works of related efforts or works and so much of the forks and third party options and distributions. This might be a penalty for this customer base but how it would if they were not there for us? well it might interesting to have a read of https://168.176.86.16/~danielb/Taking_control.pdf (just accept security domain error and add security exception to download it) This resumes some techniques useful for this kind of tricky questions, downloaded from: http://ciozone.madisonlogic.com/black_duck_software/ You will need to fill a survey. Well that's all I have in mind well and a last long ago sentence from a paper "The Modula-3 compiler generates the intermediate code of the GNU compiler. Therefore, any system that can run GNU C can run Modula-3" p. 28 in http://www.liacs.nl/~llexx/APPARC/DELIVERABLES/PME4a.ps.gz I guess that is not the same case for the symbols of the new stock debugger, what do you think? Thanks in advance --- El mi?, 1/9/10, Jay K escribi?: > De: Jay K > Asunto: [M3devel] debugging with stock gdb > Para: "m3devel" > Fecha: mi?rcoles, 1 de septiembre, 2010 11:30 > > Here's a quick sample of what you can do now in gdb, so > much better than before. > Records used to have no types. > This is on Darwin. > > > jbook2:m3cc jay$ gdb /cm3/bin/Juno > GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 > 02:43:13 UTC 2009) > > (gdb) break RTType__Expand > (gdb) run > Breakpoint 1, RTType__Expand (M3_DaARCY_m=0x1010cccd0) at > ../src/runtime/common/RTType.m3:715 > 715 new : InfoMap; > (gdb) n > 716 pi, pt: SlotPtr; > (gdb) n > 719 IF m.map = NIL THEN > (gdb) > 721 m.cnt := 0; > (gdb) info locals > M3_AcxOUs_key2 = 4312105936 > M3_AcxOUs_key1 = 4321920593 > M3_EM4UH1_pt = (struct {...} ***) 0x0 > M3_EM4UH1_pi = (struct {...} ***) 0x0 > M3_BQo8Jp_new = { > name = 0x0, > is_equal = 0x0, > rehash = 0x0, > initial_size = 0, > full = 0, > cnt = 0, > max = 0, > mask = 0, > map = 0x0 > } > (gdb) p **M3_DaARCY_m > $1 = { > name = 0x1010e2ca0, > is_equal = 0x8, > rehash = 0x7364697565707974, > initial_size = 0, > full = 2, > cnt = 4312673440, > max = 6, > mask = 126875185803874, > map = 0x2 > } > > > - Jay > > > > From jay.krell at cornell.edu Thu Sep 2 06:31:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Sep 2010 04:31:47 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <9D70491C-0B0A-4FC2-B4E9-A2E7EE35337F@cs.purdue.edu> References: , , , , <4C7DB947.5030707@lcwb.coop>, , <20100901154713.GC28881@topoi.pooq.com>, , <9D70491C-0B0A-4FC2-B4E9-A2E7EE35337F@cs.purdue.edu> Message-ID: Well, I'd like to be able to dereference pointers in stock gdb and also see floats properly. But yes, I put in use of bitfields for things with offset or size not a multiple of 8 (or "unit", whatever). I put in asserts that record sizes match between frontend and backend. It seems to work, at least on AMD64_DARWIN. That still leaves room for fields to be placed wrong though. It's a start. I should be able to go back and assert those too. There's still a fair amount more to do here, including objects, enums, globals, constants, packed. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 1 Sep 2010 15:23:17 -0400 > To: jay.krell at cornell.edu > CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > Surely there are ways to type things such that the backend is forced to compute the same layout as the front-end. Can we type fields as bitfields to get what's needed? > > > On 1 Sep 2010, at 12:10, Jay K wrote: > > > > > "..." won't let me see things gdb. > > Clever hack though. > > > > > > The backend below parse.c implements the ABI, and generation of debugging information, > > as long as you give it correctly typed trees. So yes, we would generally be compatible > > with the C compiler. Except, well, except that m3front does the same work. Not good. > > > > > > - Jay > > > > ---------------------------------------- > >> Date: Wed, 1 Sep 2010 11:47:14 -0400 > >> From: hendrik at topoi.pooq.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] a trouble with passing records by value.. > >> > >> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: > >>> If the writers of an ABI actually *required* that small structs/records be > >>> passed in registers, then they have made a big blunder. In C, formal > >>> parameters are l-values, > >> > >> but they are copies of the corresponding actual parameters. > >> > >>> and in Modula-3, they are designators, regardless > >>> of the parameter mode. Thus taking their address must always be possible, > >>> to comply with language semantics, which means they must be in memory. > >>> > >>> The only possible resolutions are > >>> > >>> 1) Declare that language semantics trump ABI requirements and defy the ABI. > >> > >> On most platforms I ever had to be binary-compatible with in a C > >> interpreter I dealt with long long ago, declaring the formal parameters > >> as "..." (like printf) kept them in storage on the stack. > >> > >> -- hendrik > >> > >>> > >>> 2) Pass them in registers at the time of control transfer, but store them > >>> in memory in the prologue, then access them from memory thereafter. > >> > >> That's what the more optimizing compilers did, except they only ccopied > >> them to memory if the called code actually needed them to be in memory. > >> And they also watched out for functions whose addresses were taken, or > >> were accessible by external linkage. > >> > >> But it mattered whether the function had a prototoype, and whether > >> parameters were declared as "...". > >> > >> -- hendrik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Sep 2 16:39:12 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 02 Sep 2010 09:39:12 -0500 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , <4C7DB947.5030707@lcwb.coop> Message-ID: <4C7FB710.7000204@lcwb.coop> Jay K wrote: > > Date: Tue, 31 Aug 2010 21:24:07 -0500 > > From: rodney_bates@ > > > > If the writers of an ABI actually *required* that small > structs/records be > > passed in registers > > > Yes, they have. The rules are hard for me to understand. It isn't just > based on size. > > > > then they have made a big blunder. > > > No they have not. They know what they are doing. When the ABI requires a compiler to do it wrong for the language semantics, which it must then compensate for at a place that's outside the jurisdiction of the ABI, the ABI has a design bug. At least when the language in question is one of those the ABI designers considered, which has to be the case with C. > > > > Thus taking their address must always be possible, > > > If they have to be in memory, then they will be put in memory, at or before > the address is taken. That doesn't mean the parameters have to be passed > in memory. > > > > 1) Declare that language semantics trump ABI requirements and defy > the ABI. > > Not necessary. > Granted, we don't have to follow the ABI. The ABI is for > interoperability with C. > I'm plenty willing to say you can't pass records by value between C and > Modula-3. > > > > > 2) Pass them in registers at the time of control transfer, but store them > > in memory in the prologue, then access them from memory thereafter. > > > The backend does that as needed for C already. > > > Data can live in multiple places. > Just that there can be only be one mutable location at a time. > > > Look at the code generated Tony asked about, add like > printr("%p\n", &t); > > > you'll see the registers get written to the stack. > > > - Jay From jay.krell at cornell.edu Thu Sep 2 16:59:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Sep 2010 14:59:13 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7FB710.7000204@lcwb.coop> References: , , , , , , , <4C7DB947.5030707@lcwb.coop>, , <4C7FB710.7000204@lcwb.coop> Message-ID: Short answer: Consider: void F1(int a) { printf("%p\n", &a); } void F2(struct { int b,c;} d) { printf("%p\n", &d); } Longer anser: There is no ABI bug. Really. How parameters are passed does not imply where they must be at all times. C has the same feature set as Modula-3. In general and here specifically. You can pass structs by value in C and you can take the address of such a struct. The ABI is never perfectly efficient for all scenarios. If one could predict that all structed passed by value will have their address taken, then a different choice might be made. However the reality is that sometimes their address is taken, sometimes not. One ABI must be formulated (for interop) that strikes an efficiency balance, and always works. Consider that I can take the address of integers and floats and pointers passed by value! Yet they are very very often passed in registers. (see the "short answer"). A record is just a smaller or larger collection of integers/floats/pointers. The difference is mainly in the layout of the in-memory location, and the possibility of large size. - Jay > Date: Thu, 2 Sep 2010 09:39:12 -0500 > From: rodney_bates > To: m3devel > Subject: Re: [M3devel] a trouble with passing records by value.. > > Jay K wrote: > > > Date: Tue, 31 Aug 2010 21:24:07 -0500 > > > From: rodney_bates@ > > > > > > If the writers of an ABI actually *required* that small > > structs/records be > > > passed in registers > > > > > > Yes, they have. The rules are hard for me to understand. It isn't just > > based on size. > > > > > > > then they have made a big blunder. > > > > > > No they have not. They know what they are doing. > > When the ABI requires a compiler to do it wrong for the language semantics, > which it must then compensate for at a place that's outside the jurisdiction > of the ABI, the ABI has a design bug. At least when the language in question > is one of those the ABI designers considered, which has to be the case > with C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Sep 2 19:50:33 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 2 Sep 2010 13:50:33 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: <4C7FB710.7000204@lcwb.coop> Message-ID: <20100902175032.GA1879@topoi.pooq.com> On Thu, Sep 02, 2010 at 02:59:13PM +0000, Jay K wrote: > > Short answer: > > > Consider: > void F1(int a) { printf("%p\n", &a); } > void F2(struct { int b,c;} d) { printf("%p\n", &d); } > > > Longer anser: > > > There is no ABI bug. Really. > > > How parameters are passed does not imply where they must be at all times. > > > C has the same feature set as Modula-3. In general and here specifically. > You can pass structs by value in C and you can take the address of such a struct. > > > The ABI is never perfectly efficient for all scenarios. > If one could predict that all structed passed by value will have their > address taken, then a different choice might be made. > However the reality is that sometimes their address is taken, sometimes not. > One ABI must be formulated (for interop) that strikes an efficiency balance, and always works. > > > Consider that I can take the address of integers and floats and pointers passed by value! > Yet they are very very often passed in registers. (see the "short answer"). > > > A record is just a smaller or larger collection of integers/floats/pointers. > > > The difference is mainly in the layout of the in-memory location, and > the possibility of large size. > To avoid going into assembly langauge in my C interpreter, on many platforms I did the following hack: Pack the parameters into a large struct (like struct big{char space[1000];} ), calculating parameter positions myself. The type of the space array was completely irrelevant -- as long as it ws big enough. Then I pass the struct by value to the called program, ignoring the types the called program wanted -- you can do this with enough casts. This worked for a *lot* of systems. To avoid wasting too much stack space, I had a variety of struct types available, of different sizes, each with its own code. -- hendrik From mark at wickensonline.co.uk Thu Sep 2 20:29:32 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Thu, 02 Sep 2010 19:29:32 +0100 Subject: [M3devel] CM3 on Solaris 2.6/GNU Message-ID: <1283452172.6292.2.camel@x60.hecnet.eu> Hi guys, My conquest of Modula-3 on old hardware has started once again now that I have Solaris 2.6 running on the SPARCbook 3. What would be my options for getting it on there? The machine has 64 MB of RAM and a few hundred MB of disk space - is it going to have to be a cross-compile, if anything? Cheers, Mark. From jay.krell at cornell.edu Thu Sep 2 23:24:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Sep 2010 21:24:50 +0000 Subject: [M3devel] CM3 on Solaris 2.6/GNU In-Reply-To: <1283452172.6292.2.camel@x60.hecnet.eu> References: <1283452172.6292.2.camel@x60.hecnet.eu> Message-ID: You have a working C compiler on it? Does 2.6 have pthreads? Our userthreads won't work on 2.6 at least for a small reason, maybe for larger reasons. (makecontext in 2.8 and some versions of 2.9 have the stack direction wrong; we could easily enough make our code work on those I think) There's a problem in head on sparc. Been a while, sorry. I do need to look into it. Try the release branch? Go to any working machine -- any machine with cm3. Preferably a fast one. And it should have Python. cd scripts/python ./boot1.py SOLgnu wait a bit, it's not fast because the first thing it does is build a cross cm3cg. ls *.tar.gz *tgz make some guesses and attempts ok -- copy the *gz to the Solaris 2.6 machine extract it cd into it look at the top of Makefile, see if it is sane make ./cm3 If it says "can't find cm3.cfg", good, proceed... If it doesn't say that, bad, go back and debug... "proceed": I use python/boot2.sh, but with only 64MB.. the backend won't compile in 128MB.. Canadian cross might do. There is clearly an intent for it to work but I haven't used it much. You'd likely need to work out other cross issues -- get a working cross gcc in the usual way.. This machine is probably intolerably slow, to me. Even though I did use machines with much less memory. Get me ssh access, I might might might might might look. If 2.6 doesn't have pthreads, or adequate pthreads, you'd need to hack on it to use the Sun threads or userthreads, neither is particularly automatic. Both are probably possible. - Jay > From: mark at wickensonline.co.uk > To: m3devel at elegosoft.com > Date: Thu, 2 Sep 2010 19:29:32 +0100 > Subject: [M3devel] CM3 on Solaris 2.6/GNU > > Hi guys, > > My conquest of Modula-3 on old hardware has started once again now that > I have Solaris 2.6 running on the SPARCbook 3. What would be my options > for getting it on there? The machine has 64 MB of RAM and a few hundred > MB of disk space - is it going to have to be a cross-compile, if > anything? > > Cheers, Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 3 04:57:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 02:57:52 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <20100902175032.GA1879@topoi.pooq.com> References: <4C7FB710.7000204@lcwb.coop>, , <20100902175032.GA1879@topoi.pooq.com> Message-ID: > To avoid going into assembly langauge in my C interpreter, on many platforms I did the > following hack: > > Pack the parameters into a large struct (like struct big{char space[1000];} ), calculating > parameter positions myself. The type of the space array was completely irrelevant -- as > long as it ws big enough. > > Then I pass the struct by value to the called program, ignoring the types the called > program wanted -- you can do this with enough casts. > > This worked for a *lot* of systems. > > To avoid wasting too much stack space, I had a variety of struct types available, of > different sizes, each with its own code. > > -- hendrik Debugging would suffer like it did/does today. Code quality would suffer. Hey, I wanted to pass the static link in an extra parameter concocted by the frontend but Tony didn't want that loss of code quality. (Letting gcc do the work here has a few advantages: the optimizer can decide which locals even need to be in the struct, and 32bit x86 can use a register for the extra parameter, whereas it otherwise might not). ?- Jay From jay.krell at cornell.edu Fri Sep 3 12:24:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 10:24:54 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 29 Aug 2010 15:58:21 +0200 > From: wagner > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Jay K : > > > I think I would settle for SVN. > > Though SVN has completely broken branching last I checked, and they > > acknowledged it. > > SVN also has relatively large dependencies to build from source. > > Branching in SVN is OK, merging is still wanting in case of tree > conflicts. Last I knew, svn wouldn't keep track if particular changes were merged or not. You were supposed to note in the commit comment what you merged and then know in future to ignore them. Therefore, you can't merge. Therefore, branching is just copying. All systems support that. ?? Ok, so they might have copy-on-write cheaper branching. Not impressive. ?? Perforce does branching darn near perfectly. Also last I knew I think SVN only really supported like temporary single level branches off of trunk. Perforce allows arbitrary deep hiearchies and a model where developers stay in their branches indefinitely, with regular merging in both directions. Model where branches aren't meant to be temporary or experimental, but are meant for "staging" or "isolation", give places for work to stabilize before moving around, and do that as a matter of course for all changes. You do then have to build all the various branches and regularly merge (they call it "integrate"). It is great for large teams. SVN's model seems to be that branches are all temporary/experimental and expected to eventually merge to trunk and then go away. > > I would also like a system that doesn't drop files/directories all > > over the place. Just in the root of a checkout should > > suffice and be ideal. CVS is awful here and I believe SVN is too. > > The working copy overhaul expected to be included in SVN 1.7 will > keep all metadata at the root of the checkout in an SQL database. Excellent! Maybe wait for that? :) ?- Jay From jay.krell at cornell.edu Fri Sep 3 12:29:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 10:29:00 +0000 Subject: [M3devel] AMD64_FREEBSD to gcc 4.5? Message-ID: AMD64_FREEBSD to gcc 4.5? There are a few options for me to do this: ? - just make the "small" change and see what happens in Hudson ? ?? ? ("small" as in a small textual diff, but not small in meaning) ? - ssh as hudson to the hudson node and work/test in $HOME/jay or such ? - setup a VM and test it there; not difficult x86/AMD64 platforms have had a high rate of working here and there aren't many left, so option #1 doesn't seem too bad. "Philosophically" #1 is the worst, least responsible, option. But probably ok. I can at least do a quick cross build of cm3 only. ? (still todo: enable cross building the whole system, for our ?? unusual but useful definition of "cross build") ?- Jay From wagner at elegosoft.com Fri Sep 3 12:45:40 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 12:45:40 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: <20100903124540.qsd9e5bsgs4w0o8g@mail.elegosoft.com> Quoting Jay K : >> Date: Sun, 29 Aug 2010 15:58:21 +0200 >> From: wagner >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] CM3 services and Elego support, was: Re: >> conversion to another version control system >> >> Quoting Jay K : >> >> > I think I would settle for SVN. >> > Though SVN has completely broken branching last I checked, and they >> > acknowledged it. >> > SVN also has relatively large dependencies to build from source. >> >> Branching in SVN is OK, merging is still wanting in case of tree >> conflicts. > > Last I knew, svn wouldn't keep track if particular changes were > merged or not. > You were supposed to note in the commit comment what you merged > and then know in future to ignore them. It does that now. Merge tracking was a feature in 1.5 IIRC. > Therefore, you can't merge. > Therefore, branching is just copying. All systems support that. > ?? Ok, so they might have copy-on-write cheaper branching. Not impressive. > ?? Perforce does branching darn near perfectly. > Also last I knew I think SVN only really supported like temporary > single level > branches off of trunk. Perforce allows arbitrary deep hiearchies and a model > where developers stay in their branches indefinitely, with regular merging > in both directions. Model where branches aren't meant to be temporary > or experimental, but are meant for "staging" or "isolation", give places > for work to stabilize before moving around, and do that as a matter of > course for all changes. You do then have to build all the various branches > and regularly merge (they call it "integrate"). It is great for large teams. > > SVN's model seems to be that branches are all temporary/experimental > and expected to eventually merge to trunk and then go away. SVN does not enforce any branching/merging patterns. Our customers use it with very different branching setups. It supports arbitrary branching of development lines to any depth. >> > I would also like a system that doesn't drop files/directories all >> > over the place. Just in the root of a checkout should >> > suffice and be ideal. CVS is awful here and I believe SVN is too. >> >> The working copy overhaul expected to be included in SVN 1.7 will >> keep all metadata at the root of the checkout in an SQL database. > > Excellent! > Maybe wait for that? :) No problem from my side. I'm not in a hurry to replace the existing CVS setup. It would be cool if we could run CVS and GIT copies of the CM3 repo in parallel for some time (r/o but regularly sync'ed), so that people can try and see what works best for them. 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 Fri Sep 3 12:49:29 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 12:49:29 +0200 Subject: [M3devel] AMD64_FREEBSD to gcc 4.5? In-Reply-To: References: Message-ID: <20100903124929.q4ygisaf440kgwg0@mail.elegosoft.com> Quoting Jay K : > AMD64_FREEBSD to gcc 4.5? > > There are a few options for me to do this: > > ? - just make the "small" change and see what happens in Hudson > ? ?? ? ("small" as in a small textual diff, but not small in meaning) > ? - ssh as hudson to the hudson node and work/test in $HOME/jay or such > ? - setup a VM and test it there; not difficult > > x86/AMD64 platforms have had a high rate of working here and there > aren't many left, so option #1 doesn't seem too bad. > > "Philosophically" #1 is the worst, least responsible, option. > But probably ok. > > I can at least do a quick cross build of cm3 only. > ? (still todo: enable cross building the whole system, for our > ?? unusual but useful definition of "cross build") AMD64_FREEBSD is one of the platforms that does quick continuous builds, I'd go ahead and just make the small change if you can roll it back easily. If you want I can also give you an account on my home system for testing. 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 Fri Sep 3 12:53:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 10:53:51 +0000 Subject: [M3devel] symlink grief? Message-ID: ?+++ /cm3/bin/cm3? -ship -DROOT=/home/jay/dev2/cm3 +++ --- shipping from I386_LINUX --- "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/cm3": errno=17 --procedure--? -line-? -file--- make_dir?????????? --? ??????????????????? 1? /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP Fatal Error: package build failed ?*** execution of [, ????? RETURN FALSE; ??? END; ? END IsDirectory; Maybe the right thing is to mimic Posix and allow code like: PROCEDURE IsDirectory (path: TEXT): BOOLEAN = ? VAR s: File.Status; ? BEGIN ??? TRY ????? s := FS.LinkStatus (path); ????? RETURN (s.type = FS.SymblicLinkFileType); ??? EXCEPT OSError.E => ????? RETURN FALSE; ??? END; ? END IsDirectory; or such? Not sure it is needed. Or FS.StatusNoLinkResolve? Is that clearer? There are a few basic problems here: ? - The "Modula-3 code base" has been written I assume without symlinks in mind. ?? ? - I don't have symlinks in mind, much at all, since I'm usually not on a system with them. ? I don't have a mental model of how to program with them, etc. ? Maybe some short document I can read and memorize? ?- Jay From wagner at elegosoft.com Fri Sep 3 13:10:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 13:10:51 +0200 Subject: [M3devel] symlink grief? In-Reply-To: References: Message-ID: <20100903131051.nwppumquscgos08s@mail.elegosoft.com> Symbolic links usually `just work'. If you have changed stat to lstat for all use cases, that will of course cause problems. I thought your changes were local to the rmrec implementation for quake. Aren't they? If not, it will be better to revert them. Olaf PS: Windows NTFS does support symbolic links, too, though I've probably never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link Quoting Jay K : > ?+++ /cm3/bin/cm3? -ship -DROOT=/home/jay/dev2/cm3 +++ > --- shipping from I386_LINUX --- > > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: > quake runtime error: unable to create directory "/cm3": errno=17 > > --procedure--? -line-? -file--- > make_dir?????????? --? > ??????????????????? 1? /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP > > Fatal Error: package build failed > ?*** execution of [, > > > /cm3 is a symlink to /home/jay/cm3 > They both exist. > /home/jay/cm3 is a directory. > > I predict no good answers here. > ?- a code base that historically used stat, that I changed to lstat. > > I think maybe I should put it back to stat. > And maybe come up with new functions for fs_rmrec to use. > > Wild guess... we have code like: > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > ? VAR s: File.Status; > ? BEGIN > ??? TRY > ????? s := FS.Status (path); > ????? RETURN (s.type = FS.DirectoryFileType); > ??? EXCEPT OSError.E => > ????? RETURN FALSE; > ??? END; > ? END IsDirectory; > > > Maybe the right thing is to mimic Posix and allow code like: > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > ? VAR s: File.Status; > ? BEGIN > ??? TRY > ????? s := FS.LinkStatus (path); > ????? RETURN (s.type = FS.SymblicLinkFileType); > ??? EXCEPT OSError.E => > ????? RETURN FALSE; > ??? END; > ? END IsDirectory; > > or such? > > Not sure it is needed. > > Or FS.StatusNoLinkResolve? Is that clearer? > > There are a few basic problems here: > ? - The "Modula-3 code base" has been written I assume without > symlinks in mind. ?? > ? - I don't have symlinks in mind, much at all, since I'm usually > not on a system with them. > ? I don't have a mental model of how to program with them, etc. > ? Maybe some short document I can read and memorize? > > > ?- Jay > -- 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 Sep 3 13:17:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 11:17:09 +0000 Subject: [M3devel] symlink grief? In-Reply-To: <20100903131051.nwppumquscgos08s@mail.elegosoft.com> References: , <20100903131051.nwppumquscgos08s@mail.elegosoft.com> Message-ID: No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3. How about: PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER = ? VAR statBuf: Ustat.struct_stat; ? BEGIN ??? IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s, ADR(statBuf)) < 0 THEN ????? RETURN -1; ??? END; ??? status.type := FilePosix.FileTypeFromStatbuf(statBuf); ??? (* Could make following assignments conditional on type: *) ??? status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL); ??? status.size := statBuf.st_size; ??? IF status.size < 0L THEN RETURN -1 END; ??? RETURN 0 ? END CStatus; I can look again, *maybe* rmrec can avoid calling here. Though probably the best way to achieve that is by writing two independent versions in C. I think the Modula-3 file system libraries are just too keen on calling stat, which fails for dangling symlinks. ?- Jay ---------------------------------------- > Date: Fri, 3 Sep 2010 13:10:51 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] symlink grief? > > Symbolic links usually `just work'. > If you have changed stat to lstat for all use cases, that will of > course cause problems. I thought your changes were local to the > rmrec implementation for quake. Aren't they? > > If not, it will be better to revert them. > > Olaf > > PS: Windows NTFS does support symbolic links, too, though I've probably > never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link > > Quoting Jay K : > > > +++ /cm3/bin/cm3 -ship -DROOT=/home/jay/dev2/cm3 +++ > > --- shipping from I386_LINUX --- > > > > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: > > quake runtime error: unable to create directory "/cm3": errno=17 > > > > --procedure-- -line- -file--- > > make_dir -- > > 1 /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP > > > > Fatal Error: package build failed > > *** execution of [, > > > > > > > > /cm3 is a symlink to /home/jay/cm3 > > They both exist. > > /home/jay/cm3 is a directory. > > > > I predict no good answers here. > > - a code base that historically used stat, that I changed to lstat. > > > > I think maybe I should put it back to stat. > > And maybe come up with new functions for fs_rmrec to use. > > > > Wild guess... we have code like: > > > > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > > VAR s: File.Status; > > BEGIN > > TRY > > s := FS.Status (path); > > RETURN (s.type = FS.DirectoryFileType); > > EXCEPT OSError.E => > > RETURN FALSE; > > END; > > END IsDirectory; > > > > > > Maybe the right thing is to mimic Posix and allow code like: > > > > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > > VAR s: File.Status; > > BEGIN > > TRY > > s := FS.LinkStatus (path); > > RETURN (s.type = FS.SymblicLinkFileType); > > EXCEPT OSError.E => > > RETURN FALSE; > > END; > > END IsDirectory; > > > > or such? > > > > Not sure it is needed. > > > > Or FS.StatusNoLinkResolve? Is that clearer? > > > > There are a few basic problems here: > > - The "Modula-3 code base" has been written I assume without > > symlinks in mind. ?? > > - I don't have symlinks in mind, much at all, since I'm usually > > not on a system with them. > > I don't have a mental model of how to program with them, etc. > > Maybe some short document I can read and memorize? > > > > > > - Jay > > > > > > -- > 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 Sep 3 13:27:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 11:27:38 +0000 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? Message-ID: more type improvements in m3cc/parse.c? So, the initial goal of fixing SPARC64_SOLARIS without breaking anything seems to have worked. ?I have to check all the platforms still. And debugging of records is much much better in gdb. ? (again, needs testing..) Now I'd like to continue: ?enums ?packed ?objects ?function pointer types ?arrays ?open arrays ? ? This requires a fairly complete understanding of the "object model". Basically what Modula-3 looks like in C. ? Yes, this dovetails into generating C. Stuff like: ?Are enums always 32 bits? ?Or are they chosen among 8, 16, 32 bits, as needed to fit their values? ?Or are they always integer sized but we limit them to 2^32 values? ? ? What can/does packed do? The language spec was deliberately vague. It can add arbitrary padding to the end of records? It removes any possible padding at end of records? It can shrink enums and subranges to other than 8/16/32/64 bits? ?It can grow enums/subranges? ? ? ?What do objects look like? ?I assume they are something like C++ classes with single inheritance. ?A vtable pointer followed by the data. ? What do arrays look like? ?This was answered recently. Including it here for completeness. ?I should commit what was said. ? What are the ramifications of the ability to do type switching at runtime? Maybe another field in objects? What do exceptions look like? ?Just records? ? Just read m3front to learn all this? And look at generated code? I can, but I'm lazy. If anyone knows all this stuff off the top of their head, checking it into doc/notes/objectmodel.txt is roughly my preference. I will have to put together a bunch of small samples, that both RTIO.PrintWhatever their data, and step through in gdb and see if things match. How much, if any of this is subject to change? I suspect none of it. Sure, you are supposed to know it when you write Modula-3. But parse.c can/should, caveat about making the same decisions as m3front. Thanks, ?- Jay From jay.krell at cornell.edu Fri Sep 3 13:28:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 11:28:48 +0000 Subject: [M3devel] field accesses in m3cg? Message-ID: Thoughts on exposing higher level "field load/store" in m3cg? I'm wary of it currently. Would rather do other stuff for now. It'd let the bitfield refs be replaced by something "proper". But it opens up more danger in terms of frontend/backend layout disagreement. ?- Jay From jay.krell at cornell.edu Fri Sep 3 14:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 12:19:08 +0000 Subject: [M3devel] SPARC64_SOLARIS still not quite wokring Message-ID: Just a note that there are further problems. Later.. == package /home/jay/dev2/cm3/m3-obliq/obliqrt == ?+++ /cm3.sparc64/bin/cm3??? -build -DROOT=/home/jay/dev2/cm3 +++ --- building in SPARC64_SOLARIS --- ignoring ../src/m3overrides /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemVar?? -T.M3IMPTAB stubgen: Processing ObValue.RemVar /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemArray?? -T.M3IMPTAB stubgen: Processing ObValue.RemArray /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemObj?? -T.M3IMPTAB stubgen: Processing ObValue.RemObj /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemEngine?? -T.M3IMPTAB stubgen: Processing ObValue.RemEngine /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemFileSystem?? -T.M3IMPTAB stubgen: Processing ObValue.RemFileSystem /cm3.sparc64/bin/stubgen -v1 -sno ObValue.NonRemObjHook?? -T.M3IMPTAB stubgen: Processing ObValue.NonRemObjHook /cm3.sparc64/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB /cm3.sparc64/bin/shobjcodegen: Processing ObValue.ReplObjStd /cm3.sparc64/bin/shobjcodegen: method? listed in SHARED UPDATE METHODS pragma not declared /cm3.sparc64/bin/shobjcodegen: Method error -- no stubs produced. "/cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl", line 55: quake runtime error: exit 1: /cm3.sparc64/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB --procedure--? -line-? -file--- exec?????????????? --? _v_sharedobjv1????? 55? /cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl sharedobjv1??????? 62? /cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl sharedobj????????? 70? /cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl include_dir??????? 53? /home/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile ??????????????????? 5? /home/jay/dev2/cm3/m3-obliq/obliqrt/SPARC64_SOLARIS/m3make.args From jay.krell at cornell.edu Fri Sep 3 14:37:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 12:37:37 +0000 Subject: [M3devel] I386_LINUX -O3 Message-ID: It looks like I386_LINUX -O3 is broken now. Probably due to the types on trees in parse.c I gets just to the start of InitRuntime and accesses NULL. I don't remember if I tested unpotimized or -O2 or -O3 in the bulk of my testing here. Later.. ?- Jay From wagner at elegosoft.com Fri Sep 3 14:38:25 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 14:38:25 +0200 Subject: [M3devel] symlink grief? In-Reply-To: References: , <20100903131051.nwppumquscgos08s@mail.elegosoft.com> Message-ID: <20100903143825.t378qzdqsc0cgwc4@mail.elegosoft.com> Quoting Jay K : > No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3. > How about: > > PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER = > ? VAR statBuf: Ustat.struct_stat; > ? BEGIN > ??? IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s, > ADR(statBuf)) < 0 THEN > ????? RETURN -1; > ??? END; > ??? status.type := FilePosix.FileTypeFromStatbuf(statBuf); > ??? (* Could make following assignments conditional on type: *) > ??? status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL); > ??? status.size := statBuf.st_size; > ??? IF status.size < 0L THEN RETURN -1 END; > ??? RETURN 0 > ? END CStatus; Could be worth a try, Olaf > > I can look again, *maybe* rmrec can avoid calling here. > Though probably the best way to achieve that is by writing two > independent versions in C. > I think the Modula-3 file system libraries are just too keen on > calling stat, which fails > for dangling symlinks. > > ?- Jay > > ---------------------------------------- >> Date: Fri, 3 Sep 2010 13:10:51 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] symlink grief? >> >> Symbolic links usually `just work'. >> If you have changed stat to lstat for all use cases, that will of >> course cause problems. I thought your changes were local to the >> rmrec implementation for quake. Aren't they? >> >> If not, it will be better to revert them. >> >> Olaf >> >> PS: Windows NTFS does support symbolic links, too, though I've probably >> never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link >> >> Quoting Jay K : >> >> > +++ /cm3/bin/cm3 -ship -DROOT=/home/jay/dev2/cm3 +++ >> > --- shipping from I386_LINUX --- >> > >> > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: >> > quake runtime error: unable to create directory "/cm3": errno=17 >> > >> > --procedure-- -line- -file--- >> > make_dir -- >> > 1 >> /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP >> > >> > Fatal Error: package build failed >> > *** execution of [, >> > >> > >> > >> > /cm3 is a symlink to /home/jay/cm3 >> > They both exist. >> > /home/jay/cm3 is a directory. >> > >> > I predict no good answers here. >> > - a code base that historically used stat, that I changed to lstat. >> > >> > I think maybe I should put it back to stat. >> > And maybe come up with new functions for fs_rmrec to use. >> > >> > Wild guess... we have code like: >> > >> > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = >> > VAR s: File.Status; >> > BEGIN >> > TRY >> > s := FS.Status (path); >> > RETURN (s.type = FS.DirectoryFileType); >> > EXCEPT OSError.E => >> > RETURN FALSE; >> > END; >> > END IsDirectory; >> > >> > >> > Maybe the right thing is to mimic Posix and allow code like: >> > >> > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = >> > VAR s: File.Status; >> > BEGIN >> > TRY >> > s := FS.LinkStatus (path); >> > RETURN (s.type = FS.SymblicLinkFileType); >> > EXCEPT OSError.E => >> > RETURN FALSE; >> > END; >> > END IsDirectory; >> > >> > or such? >> > >> > Not sure it is needed. >> > >> > Or FS.StatusNoLinkResolve? Is that clearer? >> > >> > There are a few basic problems here: >> > - The "Modula-3 code base" has been written I assume without >> > symlinks in mind. ?? >> > - I don't have symlinks in mind, much at all, since I'm usually >> > not on a system with them. >> > I don't have a mental model of how to program with them, etc. >> > Maybe some short document I can read and memorize? >> > >> > >> > - Jay >> > >> >> >> >> -- >> 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 hosking at cs.purdue.edu Fri Sep 3 15:34:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 3 Sep 2010 09:34:29 -0400 Subject: [M3devel] field accesses in m3cg? In-Reply-To: References: Message-ID: <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu> On 3 Sep 2010, at 07:28, Jay K wrote: > > Thoughts on exposing higher level "field load/store" in m3cg? > I'm wary of it currently. > Would rather do other stuff for now. > > It'd let the bitfield refs be replaced by something "proper". > > But it opens up more danger in terms of frontend/backend layout disagreement. I worry about this. > > - Jay > > > > > From hendrik at topoi.pooq.com Fri Sep 3 16:02:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Sep 2010 10:02:37 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: <20100902175032.GA1879@topoi.pooq.com> Message-ID: <20100903140236.GA4701@topoi.pooq.com> On Fri, Sep 03, 2010 at 02:57:52AM +0000, Jay K wrote: > > > To avoid going into assembly langauge in my C interpreter, on many platforms I did the > > following hack: > > > > Pack the parameters into a large struct (like struct big{char space[1000];} ), calculating > > parameter positions myself. The type of the space array was completely irrelevant -- as > > long as it ws big enough. > > > > Then I pass the struct by value to the called program, ignoring the types the called > > program wanted -- you can do this with enough casts. > > > > This worked for a *lot* of systems. > > > > To avoid wasting too much stack space, I had a variety of struct types available, of > > different sizes, each with its own code. > > > > -- hendrik > > > Debugging would suffer like it did/does today. Well, it was an interpreter, and so gdb would be useless anyway. > Code quality would suffer. Yeah. Interpreters aren't known for optimising register allocation for the interpreted program anyway. > > > Hey, I wanted to pass the static link in an extra parameter concocted by the > frontend but Tony didn't want that loss of code quality. The extra parameter would be the way to do it if you had to generate standard C code, but it's not if you are able to rely on gcc extras. > (Letting gcc do the work here has a few advantages: the optimizer > can decide which locals even need to be in the struct, and 32bit x86 > can use a register for the extra parameter, whereas it otherwise might not). > > > ?- Jay > From jay.krell at cornell.edu Fri Sep 3 16:31:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 14:31:59 +0000 Subject: [M3devel] I386_LINUX -O3 In-Reply-To: References: Message-ID: -O2 crashes also. Non-optimized works. I can't look more till next week, might try setting up Hudson job for this. Jay/phone > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 3 Sep 2010 12:37:37 +0000 > Subject: [M3devel] I386_LINUX -O3 > > > It looks like I386_LINUX -O3 is broken now. > Probably due to the types on trees in parse.c > I gets just to the start of InitRuntime and accesses NULL. > > I don't remember if I tested unpotimized or -O2 or -O3 in the bulk of my testing here. > > Later.. > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Sep 3 17:34:48 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 03 Sep 2010 08:34:48 -0700 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? In-Reply-To: References: Message-ID: <20100903153448.952911A20A7@async.async.caltech.edu> Jay can you please not use the term "object model" for what you're describing here? I think "object model" should be limited to what is in the Green Book and Cardelli's paper on the Modula-3 type system. What you're talking about is "object implementation", specific to CM3 and perhaps a few other compilers, not the Modula-3 programming language. It is very confusing to see the expression used to cover both concepts, which, though obviously related, are quite different. And no you don't have to know many of these things when programming in Modula-3. As you say, the book is sometimes deliberately vague. For some of the points you raise, the programmer should write the program so it can deal with any possible implementation; for some others it helps if he knows, but if he doesn't, the compiler may reject some perfectly legal Modula-3 programs ("implementation restrictions"). Just please don't mix that up with the language definition... Mika Jay K writes: > >more type improvements in m3cc/parse.c? > > >So=2C the initial goal of fixing SPARC64_SOLARIS >without breaking anything seems to have worked. >=A0I have to check all the platforms still. > > >And debugging of records is much much better in gdb. >=A0 (again=2C needs testing..) > > >Now I'd like to continue: >=A0enums >=A0packed >=A0objects >=A0function pointer types >=A0arrays >=A0open arrays >=A0 >=A0 >This requires a fairly complete understanding of the "object model". >Basically what Modula-3 looks like in C. >=A0 Yes=2C this dovetails into generating C. > > >Stuff like: >=A0Are enums always 32 bits? >=A0Or are they chosen among 8=2C 16=2C 32 bits=2C as needed to fit their va= >lues? >=A0Or are they always integer sized but we limit them to 2^32 values? >=A0 >=A0 >What can/does packed do? >The language spec was deliberately vague. >It can add arbitrary padding to the end of records? >It removes any possible padding at end of records? >It can shrink enums and subranges to other than 8/16/32/64 bits? >=A0It can grow enums/subranges? >=A0 >=A0 >=A0What do objects look like? >=A0I assume they are something like C++ classes with single inheritance. >=A0A vtable pointer followed by the data. >=A0 > >What do arrays look like? >=A0This was answered recently. Including it here for completeness. >=A0I should commit what was said. > >=A0 >What are the ramifications of the ability to do type switching at runtime? >Maybe another field in objects? > > >What do exceptions look like? >=A0Just records? >=A0 > >Just read m3front to learn all this? >And look at generated code? >I can=2C but I'm lazy. > > >If anyone knows all this stuff off the top of their head=2C >checking it into doc/notes/objectmodel.txt is roughly >my preference. > > >I will have to put together a bunch of small samples=2C that >both RTIO.PrintWhatever their data=2C and step through in gdb >and see if things match. > > >How much=2C if any of this is subject to change? >I suspect none of it. >Sure=2C you are supposed to know it when you write Modula-3. >But parse.c can/should=2C caveat about making the same decisions as m3front= >. > > >Thanks=2C >=A0- Jay = From jay.krell at cornell.edu Fri Sep 3 22:19:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 20:19:11 +0000 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? In-Reply-To: <20100903153448.952911A20A7@async.async.caltech.edu> References: , <20100903153448.952911A20A7@async.async.caltech.edu> Message-ID: Stan Lippmann's excellent book "The C Object Model".. but ok.. Looks like I missed "not" at important place: Modula-3 programmer does NOT need to know this stuff generally. But Modula-3 implementer does. Jay/phone > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? > Date: Fri, 3 Sep 2010 08:34:48 -0700 > From: mika at async.async.caltech.edu > > > Jay can you please not use the term "object model" for what you're > describing here? I think "object model" should be limited to what > is in the Green Book and Cardelli's paper on the Modula-3 type system. > What you're talking about is "object implementation", specific to CM3 and > perhaps a few other compilers, not the Modula-3 programming language. > It is very confusing to see the expression used to cover both concepts, > which, though obviously related, are quite different. > > And no you don't have to know many of these things when programming > in Modula-3. As you say, the book is sometimes deliberately vague. > For some of the points you raise, the programmer should write the program > so it can deal with any possible implementation; for some others it helps > if he knows, but if he doesn't, the compiler may reject some perfectly > legal Modula-3 programs ("implementation restrictions"). Just please > don't mix that up with the language definition... > > Mika > > Jay K writes: > > > >more type improvements in m3cc/parse.c? > > > > > >So=2C the initial goal of fixing SPARC64_SOLARIS > >without breaking anything seems to have worked. > >=A0I have to check all the platforms still. > > > > > >And debugging of records is much much better in gdb. > >=A0 (again=2C needs testing..) > > > > > >Now I'd like to continue: > >=A0enums > >=A0packed > >=A0objects > >=A0function pointer types > >=A0arrays > >=A0open arrays > >=A0 > >=A0 > >This requires a fairly complete understanding of the "object model". > >Basically what Modula-3 looks like in C. > >=A0 Yes=2C this dovetails into generating C. > > > > > >Stuff like: > >=A0Are enums always 32 bits? > >=A0Or are they chosen among 8=2C 16=2C 32 bits=2C as needed to fit their va= > >lues? > >=A0Or are they always integer sized but we limit them to 2^32 values? > >=A0 > >=A0 > >What can/does packed do? > >The language spec was deliberately vague. > >It can add arbitrary padding to the end of records? > >It removes any possible padding at end of records? > >It can shrink enums and subranges to other than 8/16/32/64 bits? > >=A0It can grow enums/subranges? > >=A0 > >=A0 > >=A0What do objects look like? > >=A0I assume they are something like C++ classes with single inheritance. > >=A0A vtable pointer followed by the data. > >=A0 > > > >What do arrays look like? > >=A0This was answered recently. Including it here for completeness. > >=A0I should commit what was said. > > > >=A0 > >What are the ramifications of the ability to do type switching at runtime? > >Maybe another field in objects? > > > > > >What do exceptions look like? > >=A0Just records? > >=A0 > > > >Just read m3front to learn all this? > >And look at generated code? > >I can=2C but I'm lazy. > > > > > >If anyone knows all this stuff off the top of their head=2C > >checking it into doc/notes/objectmodel.txt is roughly > >my preference. > > > > > >I will have to put together a bunch of small samples=2C that > >both RTIO.PrintWhatever their data=2C and step through in gdb > >and see if things match. > > > > > >How much=2C if any of this is subject to change? > >I suspect none of it. > >Sure=2C you are supposed to know it when you write Modula-3. > >But parse.c can/should=2C caveat about making the same decisions as m3front= > >. > > > > > >Thanks=2C > >=A0- Jay = -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 3 23:00:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 21:00:52 +0000 Subject: [M3devel] symlink grief? In-Reply-To: <20100903143825.t378qzdqsc0cgwc4@mail.elegosoft.com> References: , <20100903131051.nwppumquscgos08s@mail.elegosoft.com>, , <20100903143825.t378qzdqsc0cgwc4@mail.elegosoft.com> Message-ID: Clarification: There were changes at both levels. The toplevel ones maybe all unnecessary. I'll maybe look at this more but I also suspect it is ok now. Another approach would be to avoid stat altogether here, in rmrec. One can deduce the type by calling unlink and/or rmdir & checking the error. Or just rewrite rmrec in C.. - jay/phone > Date: Fri, 3 Sep 2010 14:38:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] symlink grief? > > Quoting Jay K : > > > No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3. > > How about: > > > > PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER = > > VAR statBuf: Ustat.struct_stat; > > BEGIN > > IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s, > > ADR(statBuf)) < 0 THEN > > RETURN -1; > > END; > > status.type := FilePosix.FileTypeFromStatbuf(statBuf); > > (* Could make following assignments conditional on type: *) > > status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL); > > status.size := statBuf.st_size; > > IF status.size < 0L THEN RETURN -1 END; > > RETURN 0 > > END CStatus; > > Could be worth a try, > > Olaf > > > > > I can look again, *maybe* rmrec can avoid calling here. > > Though probably the best way to achieve that is by writing two > > independent versions in C. > > I think the Modula-3 file system libraries are just too keen on > > calling stat, which fails > > for dangling symlinks. > > > > - Jay > > > > ---------------------------------------- > >> Date: Fri, 3 Sep 2010 13:10:51 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] symlink grief? > >> > >> Symbolic links usually `just work'. > >> If you have changed stat to lstat for all use cases, that will of > >> course cause problems. I thought your changes were local to the > >> rmrec implementation for quake. Aren't they? > >> > >> If not, it will be better to revert them. > >> > >> Olaf > >> > >> PS: Windows NTFS does support symbolic links, too, though I've probably > >> never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link > >> > >> Quoting Jay K : > >> > >> > +++ /cm3/bin/cm3 -ship -DROOT=/home/jay/dev2/cm3 +++ > >> > --- shipping from I386_LINUX --- > >> > > >> > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: > >> > quake runtime error: unable to create directory "/cm3": errno=17 > >> > > >> > --procedure-- -line- -file--- > >> > make_dir -- > >> > 1 > >> /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP > >> > > >> > Fatal Error: package build failed > >> > *** execution of [, > >> > > >> > > >> > > >> > /cm3 is a symlink to /home/jay/cm3 > >> > They both exist. > >> > /home/jay/cm3 is a directory. > >> > > >> > I predict no good answers here. > >> > - a code base that historically used stat, that I changed to lstat. > >> > > >> > I think maybe I should put it back to stat. > >> > And maybe come up with new functions for fs_rmrec to use. > >> > > >> > Wild guess... we have code like: > >> > > >> > > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > >> > VAR s: File.Status; > >> > BEGIN > >> > TRY > >> > s := FS.Status (path); > >> > RETURN (s.type = FS.DirectoryFileType); > >> > EXCEPT OSError.E => > >> > RETURN FALSE; > >> > END; > >> > END IsDirectory; > >> > > >> > > >> > Maybe the right thing is to mimic Posix and allow code like: > >> > > >> > > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > >> > VAR s: File.Status; > >> > BEGIN > >> > TRY > >> > s := FS.LinkStatus (path); > >> > RETURN (s.type = FS.SymblicLinkFileType); > >> > EXCEPT OSError.E => > >> > RETURN FALSE; > >> > END; > >> > END IsDirectory; > >> > > >> > or such? > >> > > >> > Not sure it is needed. > >> > > >> > Or FS.StatusNoLinkResolve? Is that clearer? > >> > > >> > There are a few basic problems here: > >> > - The "Modula-3 code base" has been written I assume without > >> > symlinks in mind. ?? > >> > - I don't have symlinks in mind, much at all, since I'm usually > >> > not on a system with them. > >> > I don't have a mental model of how to program with them, etc. > >> > Maybe some short document I can read and memorize? > >> > > >> > > >> > - Jay > >> > > >> > >> > >> > >> -- > >> 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 rodney_bates at lcwb.coop Sun Sep 5 21:03:50 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 05 Sep 2010 14:03:50 -0500 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? In-Reply-To: References: Message-ID: <4C83E996.2090609@lcwb.coop> Jay K wrote: > more type improvements in m3cc/parse.c? > > > So, the initial goal of fixing SPARC64_SOLARIS > without breaking anything seems to have worked. > I have to check all the platforms still. > > > And debugging of records is much much better in gdb. > (again, needs testing..) > > > Now I'd like to continue: > enums > packed > objects > function pointer types > arrays > open arrays > > > This requires a fairly complete understanding of the "object model". > Basically what Modula-3 looks like in C. > Yes, this dovetails into generating C. Because of the much stronger type system, much of the code written will not be dependent on this stuff, the exception being unsafe code. So, the language specifies very little of it. The below is what I understand about our compiler. There may be some target dependencies here. > > > Stuff like: > Are enums always 32 bits? > Or are they chosen among 8, 16, 32 bits, as needed to fit their values? ^Yes. Except when packed, see below. There is nothing in the language that requires this, but the binary values are equal to the ORD function. It is hard to imagine a perverse enough machine for which it would make sense for a compiler to do it any other way. But the type system of the language would allow some other encoding. ORD and VAL would then require runtime computation. > Or are they always integer sized but we limit them to 2^32 values? > > > What can/does packed do? > The language spec was deliberately vague. > a) It can add arbitrary padding to the end of records? > b) It removes any possible padding at end of records? > c) It can shrink enums and subranges to other than 8/16/32/64 bits? > d) It can grow enums/subranges? 1) BITS ... never changes the legal value set. An implication is that if the number of bits given is too small for the value set, as the compiler has chosen to represent it, the compiler must give an error. 2) Packed types have no effect on target layout at all, except when the packed type is used for an array element or field of a record or object. So a packed type in a VAR declaration, for example, accomplishes nothing. (Although it can make the static rules harder to satisfy.) 3) An element or field of packed type can have no padding added ahead of it. 4) An element or field of packed type must occupy exactly the given number of bits. The compiler can either satisfy 3) and 4), or it can refuse, with an error message. These are the only rules. So the implications for your questions above (I added letter designations to them) are: The language makes no statement about a) and b) The compiler can do what it likes at the end of a record, regardless of whether it contains packed fields. Packed types constrain padding only before a packed field. I suppose, if there were an inner record that was a packed field of an outer record, and the compiler had previously laid out the inner record type with trailing padding, and it considered that padding part of the inner record type, then it would then have to require the BITS count to be enough to hold the entire inner record, including its trailing padding. I don't think our compilers ever add trailing padding to anything. Only leading padding ahead of non-packed fields/elements, when needed for alignment or convenience. It can do both c) and d) in order to satisfy 3) and/or 4), in fact it must, or else emit an error message. > > > What do objects look like? > I assume they are something like C++ classes with single inheritance. > A vtable pointer followed by the data. > There are two redundant mechanisms for finding the code body of a dispatching method. Every traced heap object (M3 object or not) has a word at negative displacement that is used by the allocator/GC, for TYPECASEing, etc. You can see its layout in RT0.RefHeader. The biggest part of its contents is a subscript into a table of all the reference types. This is field typecode of RefHeader. This table is in the runtime system, initialized partly by compiled code, partly at program startup. It has one pointer for every reference type in the complete program, counting all the separate compilations. The subscripts to this table are the TYPECODEs. The pointers point to a record of runtime description of the type. These records are of type RT0.Typecell, extended by RT0.ObjectTypecell. The latter has field DefaultMethods, which points to the expected array of pointers to method code bodies for each method of the object, with subscripts laid out statically, in order of the method declarations. But this was apparently judged too slow somewhere along the way, so each object has, at displacement 0, a pointer leading directly to the table of method bodies. Beyond that, it's just the fields of the object, just like a record. BTW, reading this stuff in the RTS is a wonderful example of a seldom-mentioned advantage of static typing. It's all coded using unsafe techniques. No doubt this is necessary for bootstrapping. But the pointers are often of type ADDRESS, and figuring out what thing/things they can point to is much harder than if they were typed. Comments are called for. > > What do arrays look like? > This was answered recently. Including it here for completeness. > I should commit what was said. > > > What are the ramifications of the ability to do type switching at runtime? > Maybe another field in objects? > Not sure what you mean. Do your mean ISTYPE, NARROW, TYPECASE, etc., which all involve testing the allocated type of an object at runtime? These use the typecode/Typecell mechanism. > > What do exceptions look like? > Just records? > > > Just read m3front to learn all this? > And look at generated code? > I can, but I'm lazy. > > > If anyone knows all this stuff off the top of their head, > checking it into doc/notes/objectmodel.txt is roughly > my preference. > > > I will have to put together a bunch of small samples, that > both RTIO.PrintWhatever their data, and step through in gdb > and see if things match. > > > How much, if any of this is subject to change? > I suspect none of it. > Sure, you are supposed to know it when you write Modula-3. > But parse.c can/should, caveat about making the same decisions as m3front. > > > Thanks, > - Jay From wagner at elegosoft.com Mon Sep 6 09:57:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Sep 2010 09:57:42 +0200 Subject: [M3devel] Fwd: [CM3] #1149: cm3 compiler looping Message-ID: <20100906095742.927ik5z9ic4kk84k@mail.elegosoft.com> FYI ----- Forwarded message from bugs at elego.de ----- Date: Sat, 04 Sep 2010 12:22:52 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1149: cm3 compiler looping To: peter.mckinna at gmail.com, wagner at elego.de #1149: cm3 compiler looping ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: wagner Type: sw-bug | Status: new Priority: medium | Milestone: Component: sys | Version: 5.8.6 Severity: serious | Keywords: Relnote: | Org: Estimatedhours: 0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: copy the following files to a src directory and run cm3. A.i3 INTERFACE A; TYPE CBase <: CBasePublic; CBasePublic = BRANDED OBJECT METHODS area(parm: INTEGER): INTEGER; END; END A. A.m3 MODULE A; BEGIN END A. B.i3 INTERFACE B; IMPORT A; TYPE CSubobj1 <: CSubobj1Public; CSubobj1Public = A.CBase BRANDED OBJECT METHODS area1(parm: INTEGER); END; END B. B.m3 UNSAFE MODULE B; IMPORT BRaw; IMPORT IO; PROCEDURE A1(self : CSubobj1; parm : INTEGER) = BEGIN END A1; REVEAL CSubobj1 = CSubobj1Public BRANDED OBJECT OVERRIDES area1 := A1; END; BEGIN END B. BRaw.i3 INTERFACE BRaw; FROM A IMPORT CBase; REVEAL CSubobj1 = CBase; END BRaw. m3makefile import("libm3") module("A") interface("BRaw") module ("B") library("test") Fix: Env: ------------------------------------------+--------------------------------- the cm3 compiler loops on a reveal statement using 100% cpu. I was making changes to swig generator and inadvertently generated some degenerate code. I have distilled the problem to the sources. It is caused by the reveal stmt in BRaw,i3 -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Mon Sep 6 21:50:26 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 6 Sep 2010 15:50:26 -0400 Subject: [M3devel] cvsup crash Message-ID: <20100906195026.GA25815@topoi.pooq.com> Is this a known problem? From the mentions of cvsup on this list a few months ago I suspect it might be. But I'm mentioning it in case it's not known. I installed cm3 from the cm3-LINUXLIBC6-REL.deb I downloaded on Sept 5. I than ran cvsup to update my copy of the Modula 3 CVS that I acquired some months ago. This time I did specify the 'cvsroot' option I had forgotten that time. But this time, cvsup crashed: hendrik at lovesong:~/newcm3/trywholecvs$ cvsup cvsupfile-cm3 *** *** runtime error: *** An array subscript was out of range. *** file "../src/vbt/VBTRep.m3", line 644 *** Aborted hendrik at lovesong:~/newcm3/trywholecvs$ Just in case it's relevant, my cvsupfile-cm3 file: # # If not running X, or invoking cvsup from a non-interactive script, then # run it as follows: # # cvsup -g -L 2 cvsupfile.cm3 # # To use the GUI, omit the -g option # # Defaults that apply to all the collections # This host address is permanent: *default host=modula3.elegosoft.com # Please change the local destination as you like # *default base=/usr/tmp/cvs # *default prefix=/usr/tmp/cvs *default base=/farhome/hendrik/newcm3/trywholecvs/cvs *default prefix=/farhome/hendrik/newcm3/trywholecvs/cvs # Use release=cvs to get the full repository, . to checkout the latest # sources, or a cvs tag *default release=cvs *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress *default preserve # cm3 is the complete source file collection, including everything # I had access to from the CM3 4.1 and CM3 5.1 releases made by Critical # Mass, Inc., and all subsequent updates, fixes, and additions of the # open source CM3 distribution # cm3 includes all the cm3-xxx collections below cm3 # scanner and parser generators from the California Institute of Technology #cm3-caltech-parser # cm3 documentation in html and pdf format #cm3-doc # cm3 communication packages distribution (tcp, network objects, serial lines) #cm3-m3-comm # cm3 database related packages (odbc, smalldb, stablegen, postgres) #cm3-m3-db # miscellaneous cm3 demo programs (cube, calculator, fisheye, sharedboard, # mentor) #cm3-m3-demo # games (columns, badbricks, tetris, solitaire, maze) #cm3-m3-games # the lectern documentation tools packages #cm3-m3-lectern # cm3 standard libraries (m3core, libm3, lists, tables, tempfiles, digraphs, # slisp, parseparams, realgeometry, libsio) #cm3-m3-libs # mail packages (llscan, postcard, webcard) #cm3-m3-mail # packages related to the obliq language #cm3-m3-obliq # the SRC package tools #cm3-m3-pkgtools # m3 and quake comopiler, linker, interpreter, installation and support #cm3-m3-sys # miscellaneous tools from pretty printing to heap and thread monitors #cm3-m3-tools # graphical user interface packages (trestle, X11, motif, formsvbt, # videovbt, zeus etc.) #cm3-m3-ui # WWW related packages (http, proxy, web, webcat, webscape, deckscape) #cm3-m3-www # cm3 shell scripts #cm3-scripts # cm3 WWW pages #cm3-www # a CVSROOT directory cvsroot The cvsup I used identifies itself as: hendrik at lovesong:~$ cvsup -v CVSup client, GUI version Copyright 1996-2003 John D. Polstra Software version: release_branch_cm3_5_8 Protocol version: 17.0 Operating system: LINUXLIBC6 http://www.cvsup.org/ Report problems to cvsup-bugs at polstra.com CVSup is a registered trademark of John D. Polstra hendrik at lovesong:~$ -- hendrik From hendrik at topoi.pooq.com Mon Sep 6 22:36:08 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 6 Sep 2010 16:36:08 -0400 Subject: [M3devel] versioning of .deb Message-ID: <20100906203607.GA26003@topoi.pooq.com> I used cm3-LINUXLIBC6-REL.deb, and it installed cleanly. But as is, it won't pass muster as a submission to Debian. Not that I expected it to, and I'm happy with where it puts files, especially for a package that's still 'experimental' (but not in the Debian-technical sense of the 'experimental' distro, which is even freakier than sid). But one thing it should do, which it doesn't, is include a version number in its name. I'm not sure what the exact rules are in Debian for delimiting a version number, but I'm sure *you*'d find it useful to know which version of a package is involved when getting bug reports. -- hendrik From dabenavidesd at yahoo.es Tue Sep 7 00:36:26 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 6 Sep 2010 22:36:26 +0000 (GMT) Subject: [M3devel] cvsup crash In-Reply-To: <20100906195026.GA25815@topoi.pooq.com> Message-ID: <663789.72909.qm@web29704.mail.ird.yahoo.com> Hi all: perhaps this change was made in support of that days before: https://mail.elegosoft.com/pipermail/m3commit/2010-September/008793.html need to check it really what that means. This perhaps relates to the abstract visibility of memory of the M3CG machine? A similar setting could be written on the ldb debugger as it mentioned the Cedar Abstract machine setting as an example for using its Abstract Memory Interfaces, on which could had interactive debuggers interpreters. This all was based on the Mesa stack machine with some basic extension for Automatic Storage Management. There some types of docs related to it on: http://www.digibarn.com/friends/alanfreier/princops/00yTableOfContents.html Hope this helps a bit --- El lun, 6/9/10, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: [M3devel] cvsup crash > Para: m3devel at elegosoft.com > Fecha: lunes, 6 de septiembre, 2010 14:50 > Is this a known problem? From > the mentions of cvsup on this list a few > months ago I suspect it might be. But I'm mentioning > it in case it's > not known. > > I installed cm3 from the cm3-LINUXLIBC6-REL.deb I > downloaded on Sept 5. > I than ran cvsup to update my copy of the Modula 3 CVS that > I acquired > some months ago. This time I did specify the > 'cvsroot' option I had > forgotten that time. > > But this time, cvsup crashed: > > hendrik at lovesong:~/newcm3/trywholecvs$ cvsup cvsupfile-cm3 > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/vbt/VBTRep.m3", line 644 > *** > > Aborted > hendrik at lovesong:~/newcm3/trywholecvs$ > > > Just in case it's relevant, my cvsupfile-cm3 file: > > # > # If not running X, or invoking cvsup from a > non-interactive script, > then > # run it as follows: > # > # cvsup -g -L 2 cvsupfile.cm3 > # > # To use the GUI, omit the -g option > # > > # Defaults that apply to all the collections > > # This host address is permanent: > *default host=modula3.elegosoft.com > > # Please change the local destination as you like > # *default base=/usr/tmp/cvs > # *default prefix=/usr/tmp/cvs > *default base=/farhome/hendrik/newcm3/trywholecvs/cvs > *default prefix=/farhome/hendrik/newcm3/trywholecvs/cvs > > # Use release=cvs to get the full repository, . to checkout > the latest > # sources, or a cvs tag > *default release=cvs > *default delete use-rel-suffix > > # If your network link is a T1 or faster, comment out the > following > line. > *default compress > *default preserve > > # cm3 is the complete source file collection, including > everything > # I had access to from the CM3 4.1 and CM3 5.1 releases > made by Critical > # Mass, Inc., and all subsequent updates, fixes, and > additions of the > # open source CM3 distribution > # cm3 includes all the cm3-xxx collections below > cm3 > > # scanner and parser generators from the California > Institute of > Technology > #cm3-caltech-parser > > # cm3 documentation in html and pdf format > #cm3-doc > > # cm3 communication packages distribution (tcp, network > objects, serial > lines) > #cm3-m3-comm > > # cm3 database related packages (odbc, smalldb, stablegen, > postgres) > #cm3-m3-db > > # miscellaneous cm3 demo programs (cube, calculator, > fisheye, > sharedboard, > # mentor) > #cm3-m3-demo > > # games (columns, badbricks, tetris, solitaire, maze) > #cm3-m3-games > > # the lectern documentation tools packages > #cm3-m3-lectern > > # cm3 standard libraries (m3core, libm3, lists, tables, > tempfiles, > digraphs, > # slisp, parseparams, realgeometry, libsio) > #cm3-m3-libs > > # mail packages (llscan, postcard, webcard) > #cm3-m3-mail > > # packages related to the obliq language > #cm3-m3-obliq > > # the SRC package tools > #cm3-m3-pkgtools > > # m3 and quake comopiler, linker, interpreter, installation > and support > #cm3-m3-sys > > # miscellaneous tools from pretty printing to heap and > thread monitors > #cm3-m3-tools > # graphical user interface packages (trestle, X11, motif, > formsvbt, > # videovbt, zeus etc.) > #cm3-m3-ui > > # WWW related packages (http, proxy, web, webcat, webscape, > deckscape) > #cm3-m3-www > > # cm3 shell scripts > #cm3-scripts > > # cm3 WWW pages > #cm3-www > > # a CVSROOT directory > cvsroot > > > The cvsup I used identifies itself as: > > hendrik at lovesong:~$ cvsup -v > CVSup client, GUI version > Copyright 1996-2003 John D. Polstra > Software version: release_branch_cm3_5_8 > Protocol version: 17.0 > Operating system: LINUXLIBC6 > http://www.cvsup.org/ > Report problems to cvsup-bugs at polstra.com > CVSup is a registered trademark of John D. Polstra > hendrik at lovesong:~$ > > > -- hendrik > > From jay.krell at cornell.edu Tue Sep 7 02:23:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Sep 2010 00:23:15 +0000 Subject: [M3devel] cvsup crash In-Reply-To: <663789.72909.qm@web29704.mail.ird.yahoo.com> References: <20100906195026.GA25815@topoi.pooq.com>, <663789.72909.qm@web29704.mail.ird.yahoo.com> Message-ID: Sorry, no. Point there was considering forcing records into memory to help pass them as parameters but I abandoned that approach anyway. It caused other problems -- specifically an assertion failure in the backend related to records and nested functions. Current source passes on more type information than ever before to compiler, and is working in some ways more than ever before, but there are problems under optimization that need more investigation. We only pass on an "intermediate" level of type information, and the frontend does layout itself, so while "good", it is also dangerous. Anyway, to be looked into further. The unfortunate plain truth, it seems, is we have a fairly large code base, with little use, and little expertise. The original authors are all gone. I don't know cvsup. Given how poor cvs is in the first place, and how many promising alternatives there are now, it seems a waste to invest in learning to use cvsup, or spending much time debugging it and fixing it. But maybe we'll get it working. - Jay > Date: Mon, 6 Sep 2010 22:36:26 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; hendrik at topoi.pooq.com > Subject: Re: [M3devel] cvsup crash > > Hi all: > perhaps this change was made in support of that days before: > https://mail.elegosoft.com/pipermail/m3commit/2010-September/008793.html > need to check it really what that means. > This perhaps relates to the abstract visibility of memory of the M3CG machine? > A similar setting could be written on the ldb debugger as it mentioned the Cedar Abstract machine setting as an example for using its Abstract Memory Interfaces, on which could had interactive debuggers interpreters. > This all was based on the Mesa stack machine with some basic extension for Automatic Storage Management. There some types of docs related to it on: > http://www.digibarn.com/friends/alanfreier/princops/00yTableOfContents.html > Hope this helps a bit > > --- El lun, 6/9/10, hendrik at topoi.pooq.com escribi?: > > > De: hendrik at topoi.pooq.com > > Asunto: [M3devel] cvsup crash > > Para: m3devel at elegosoft.com > > Fecha: lunes, 6 de septiembre, 2010 14:50 > > Is this a known problem? From > > the mentions of cvsup on this list a few > > months ago I suspect it might be. But I'm mentioning > > it in case it's > > not known. > > > > I installed cm3 from the cm3-LINUXLIBC6-REL.deb I > > downloaded on Sept 5. > > I than ran cvsup to update my copy of the Modula 3 CVS that > > I acquired > > some months ago. This time I did specify the > > 'cvsroot' option I had > > forgotten that time. > > > > But this time, cvsup crashed: > > > > hendrik at lovesong:~/newcm3/trywholecvs$ cvsup cvsupfile-cm3 > > > > > > *** > > *** runtime error: > > *** An array subscript was out of range. > > *** file "../src/vbt/VBTRep.m3", line 644 > > *** > > > > Aborted > > hendrik at lovesong:~/newcm3/trywholecvs$ > > > > > > Just in case it's relevant, my cvsupfile-cm3 file: > > > > # > > # If not running X, or invoking cvsup from a > > non-interactive script, > > then > > # run it as follows: > > # > > # cvsup -g -L 2 cvsupfile.cm3 > > # > > # To use the GUI, omit the -g option > > # > > > > # Defaults that apply to all the collections > > > > # This host address is permanent: > > *default host=modula3.elegosoft.com > > > > # Please change the local destination as you like > > # *default base=/usr/tmp/cvs > > # *default prefix=/usr/tmp/cvs > > *default base=/farhome/hendrik/newcm3/trywholecvs/cvs > > *default prefix=/farhome/hendrik/newcm3/trywholecvs/cvs > > > > # Use release=cvs to get the full repository, . to checkout > > the latest > > # sources, or a cvs tag > > *default release=cvs > > *default delete use-rel-suffix > > > > # If your network link is a T1 or faster, comment out the > > following > > line. > > *default compress > > *default preserve > > > > # cm3 is the complete source file collection, including > > everything > > # I had access to from the CM3 4.1 and CM3 5.1 releases > > made by Critical > > # Mass, Inc., and all subsequent updates, fixes, and > > additions of the > > # open source CM3 distribution > > # cm3 includes all the cm3-xxx collections below > > cm3 > > > > # scanner and parser generators from the California > > Institute of > > Technology > > #cm3-caltech-parser > > > > # cm3 documentation in html and pdf format > > #cm3-doc > > > > # cm3 communication packages distribution (tcp, network > > objects, serial > > lines) > > #cm3-m3-comm > > > > # cm3 database related packages (odbc, smalldb, stablegen, > > postgres) > > #cm3-m3-db > > > > # miscellaneous cm3 demo programs (cube, calculator, > > fisheye, > > sharedboard, > > # mentor) > > #cm3-m3-demo > > > > # games (columns, badbricks, tetris, solitaire, maze) > > #cm3-m3-games > > > > # the lectern documentation tools packages > > #cm3-m3-lectern > > > > # cm3 standard libraries (m3core, libm3, lists, tables, > > tempfiles, > > digraphs, > > # slisp, parseparams, realgeometry, libsio) > > #cm3-m3-libs > > > > # mail packages (llscan, postcard, webcard) > > #cm3-m3-mail > > > > # packages related to the obliq language > > #cm3-m3-obliq > > > > # the SRC package tools > > #cm3-m3-pkgtools > > > > # m3 and quake comopiler, linker, interpreter, installation > > and support > > #cm3-m3-sys > > > > # miscellaneous tools from pretty printing to heap and > > thread monitors > > #cm3-m3-tools > > # graphical user interface packages (trestle, X11, motif, > > formsvbt, > > # videovbt, zeus etc.) > > #cm3-m3-ui > > > > # WWW related packages (http, proxy, web, webcat, webscape, > > deckscape) > > #cm3-m3-www > > > > # cm3 shell scripts > > #cm3-scripts > > > > # cm3 WWW pages > > #cm3-www > > > > # a CVSROOT directory > > cvsroot > > > > > > The cvsup I used identifies itself as: > > > > hendrik at lovesong:~$ cvsup -v > > CVSup client, GUI version > > Copyright 1996-2003 John D. Polstra > > Software version: release_branch_cm3_5_8 > > Protocol version: 17.0 > > Operating system: LINUXLIBC6 > > http://www.cvsup.org/ > > Report problems to cvsup-bugs at polstra.com > > CVSup is a registered trademark of John D. Polstra > > hendrik at lovesong:~$ > > > > > > -- hendrik > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 7 04:26:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 6 Sep 2010 22:26:45 -0400 Subject: [M3devel] cvsup crash In-Reply-To: References: <20100906195026.GA25815@topoi.pooq.com>, <663789.72909.qm@web29704.mail.ird.yahoo.com> Message-ID: It is certainly worth On 6 Sep 2010, at 20:23, Jay K wrote: > I don't know cvsup. > Given how poor cvs is in the first place, and how many promising alternatives there are now, > it seems a waste to invest in learning to use cvsup, or spending much time debugging it and fixing it. > But maybe we'll get it working. It is certainly worth fixing bugs exposed by cvsup. It used to run. Why does it not run now? Has there been regression in the CM3 implementation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 7 05:21:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Sep 2010 03:21:30 +0000 Subject: [M3devel] cvsup crash In-Reply-To: References: <20100906195026.GA25815@topoi.pooq.com>, , <663789.72909.qm@web29704.mail.ird.yahoo.com>, , Message-ID: > It is certainly worth fixing bugs exposed by cvsup. It used to run. Why does it not run now? Has there been regression in the CM3 implementation? Very little is known. I don't think we should be so quick to assume a regression in cm3. For example, cvsup only recently was ever made to work with non-userthreads. And this version has seen extremely little use. Perhaps it never actually worked with non-user threads. It previously depended on all threads surviving fork(). Bugs could easily be in cvsup itself. As well, don't we know that Trestle has forever had several race conditions? Having recently fixed a few? It's been my experience that the less something is used, the more bugs it has.. Modula-3 * cvsup + trestle... - Jay From: hosking at cs.purdue.edu Date: Mon, 6 Sep 2010 22:26:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; hendrik at topoi.pooq.com Subject: Re: [M3devel] cvsup crash It is certainly worth On 6 Sep 2010, at 20:23, Jay K wrote: I don't know cvsup. Given how poor cvs is in the first place, and how many promising alternatives there are now, it seems a waste to invest in learning to use cvsup, or spending much time debugging it and fixing it. But maybe we'll get it working. It is certainly worth fixing bugs exposed by cvsup. It used to run. Why does it not run now? Has there been regression in the CM3 implementation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 7 10:31:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Sep 2010 10:31:52 +0200 Subject: [M3devel] cvsup crash In-Reply-To: References: <20100906195026.GA25815@topoi.pooq.com>, , <663789.72909.qm@web29704.mail.ird.yahoo.com>, , Message-ID: <20100907103152.w5t3pt1zhwco0gwo@mail.elegosoft.com> Quoting Jay K : > > It is certainly worth fixing bugs exposed by cvsup. It used to > run. Why does it not run now? Has there been regression in the CM3 > implementation? > > Very little is known. I don't think we should be so quick to assume > a regression in cm3. > For example, cvsup only recently was ever made to work with non-userthreads. > And this version has seen extremely little use. Perhaps it never > actually worked with non-user threads. > It previously depended on all threads surviving fork(). The server uses fork. The client doesn't. The problem reported here is on the client side. > Bugs could easily be in cvsup itself. Well, it used to run without problems and is still replicating the CM3 repository regularly to several sites (in an older version). So I think it is likely that we introduced the bugs recently. > As well, don't we know that Trestle has forever had several race conditions? > Having recently fixed a few? > > It's been my experience that the less something is used, the more > bugs it has.. > Modula-3 * cvsup + trestle... The GUI may be disabled with the -g parameter, IIRC. Olaf > From: hosking at cs.purdue.edu > Date: Mon, 6 Sep 2010 22:26:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; hendrik at topoi.pooq.com > Subject: Re: [M3devel] cvsup crash > > > It is certainly worth > > > On 6 Sep 2010, at 20:23, Jay K wrote: > > I don't know cvsup. > Given how poor cvs is in the first place, and how many promising > alternatives there are now, > it seems a waste to invest in learning to use cvsup, or spending > much time debugging it and fixing it. > But maybe we'll get it working. > > It is certainly worth fixing bugs exposed by cvsup. It used to run. > Why does it not run now? Has there been regression in the CM3 > implementation? -- 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 Sep 7 10:52:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Sep 2010 10:52:13 +0200 Subject: [M3devel] versioning of .deb In-Reply-To: <20100906203607.GA26003@topoi.pooq.com> References: <20100906203607.GA26003@topoi.pooq.com> Message-ID: <20100907105213.yb1pvnz6sw8o4k4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > I used cm3-LINUXLIBC6-REL.deb, and it installed cleanly. But as is, it > won't pass muster as a submission to Debian. Not that I expected it to, > and I'm happy with where it puts files, especially for a package that's > still 'experimental' (but not in the Debian-technical sense of the > 'experimental' distro, which is even freakier than sid). > > But one thing it should do, which it doesn't, is include a version > number in its name. I'm not sure what the exact rules are in Debian for > delimiting a version number, but I'm sure *you*'d find it useful to know > which version of a package is involved when getting bug reports. Sure. Anybody cares to fix that? I've been uneasy with providing these unfinished types of platform-specific archives all the time. 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 Tue Sep 7 17:47:29 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Sep 2010 11:47:29 -0400 Subject: [M3devel] cvsup crash In-Reply-To: <20100907103152.w5t3pt1zhwco0gwo@mail.elegosoft.com> References: <20100907103152.w5t3pt1zhwco0gwo@mail.elegosoft.com> Message-ID: <20100907154729.GA29532@topoi.pooq.com> On Tue, Sep 07, 2010 at 10:31:52AM +0200, Olaf Wagner wrote: > Quoting Jay K : > >> > It is certainly worth fixing bugs exposed by cvsup. It used to >> run. Why does it not run now? Has there been regression in the CM3 >> implementation? >> >> Very little is known. I don't think we should be so quick to assume a >> regression in cm3. >> For example, cvsup only recently was ever made to work with non-userthreads. >> And this version has seen extremely little use. Perhaps it never >> actually worked with non-user threads. >> It previously depended on all threads surviving fork(). > > The server uses fork. The client doesn't. The problem reported here > is on the client side. > >> Bugs could easily be in cvsup itself. > > Well, it used to run without problems and is still replicating the > CM3 repository regularly to several sites (in an older version). > So I think it is likely that we introduced the bugs recently. > >> As well, don't we know that Trestle has forever had several race conditions? >> Having recently fixed a few? >> >> It's been my experience that the less something is used, the more >> bugs it has.. >> Modula-3 * cvsup + trestle... > > The GUI may be disabled with the -g parameter, IIRC. It may well be a new GUI bug. I could try and rerun with the -g parameter, but if it works it won't be conclusive, because the copied CVS tree probably doesn't start in the same state. -- hendrik From hendrik at topoi.pooq.com Tue Sep 7 17:48:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Sep 2010 11:48:37 -0400 Subject: [M3devel] versioning of .deb In-Reply-To: <20100907105213.yb1pvnz6sw8o4k4c@mail.elegosoft.com> References: <20100906203607.GA26003@topoi.pooq.com> <20100907105213.yb1pvnz6sw8o4k4c@mail.elegosoft.com> Message-ID: <20100907154837.GB29532@topoi.pooq.com> On Tue, Sep 07, 2010 at 10:52:13AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> I used cm3-LINUXLIBC6-REL.deb, and it installed cleanly. But as is, it >> won't pass muster as a submission to Debian. Not that I expected it to, >> and I'm happy with where it puts files, especially for a package that's >> still 'experimental' (but not in the Debian-technical sense of the >> 'experimental' distro, which is even freakier than sid). >> >> But one thing it should do, which it doesn't, is include a version >> number in its name. I'm not sure what the exact rules are in Debian for >> delimiting a version number, but I'm sure *you*'d find it useful to know >> which version of a package is involved when getting bug reports. > > Sure. Anybody cares to fix that? I've been uneasy with providing > these unfinished types of platform-specific archives all the time. I'll try to find out just what their version-numbering scheme is. Is seems to have changed in the past year. -- hendrik From wagner at elegosoft.com Tue Sep 7 17:44:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Sep 2010 17:44:02 +0200 Subject: [M3devel] CM3 CVS mirror for test Message-ID: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com> Hi, I've now converted the four cm3-current-*-LINUXLIBC6 jobs to use the CVS repository at :pserver:anonymous at cm3cvs.acme-works.com/usr/cvs, which should be synchronized with the repo on birch every half hour. A first build run has shown that either Hudson updates the CVS/Root files correctly or does a complete new checkout, so we don't need to update the workspaces manually. When more Hudson clients are available again, we should change two or three more to use the mirror. 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 Sep 8 09:49:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Sep 2010 09:49:11 +0200 Subject: [M3devel] CM3 CVS mirror for test In-Reply-To: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com> References: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com> Message-ID: <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> Quoting Olaf Wagner : > Hi, > > I've now converted the four cm3-current-*-LINUXLIBC6 jobs to use > the CVS repository at :pserver:anonymous at cm3cvs.acme-works.com/usr/cvs, > which should be synchronized with the repo on birch every half hour. > > A first build run has shown that either Hudson updates the CVS/Root > files correctly or does a complete new checkout, so we don't need to > update the workspaces manually. > > When more Hudson clients are available again, we should change two > or three more to use the mirror. I have also changed the NetBSD and OpenBSD jobs now. openbsd-jkrell seems to be too slow to be productive though (all jobs timed out). Anyway, I think we should perhaps redirect one more client and then watch how things work out for some time. Olaf PS: The ppc-linux setup seems still to be broken (mkdirs failed). -- 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 Sep 8 12:09:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 8 Sep 2010 10:09:44 +0000 Subject: [M3devel] CM3 CVS mirror for test In-Reply-To: <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> References: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com>, <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> Message-ID: > I have also changed the NetBSD and OpenBSD jobs now. openbsd-jkrell > seems to be too slow to be productive though (all jobs timed out). Something may be off here? It has worked well so long w/o much change? I notice: ? PID USERNAME PRI NICE? SIZE?? RES STATE???? WAIT????? TIME??? CPU COMMAND ... ?3970 jay??????? 2??? 0 4064K 4056K idle????? poll????? 0:00? 0.00% stubgen ? 609 jay??????? 2??? 0 3792K 4008K idle????? poll????? 0:00? 0.00% stubgen 24031 jay??????? 2??? 0 3924K 3984K idle????? poll????? 0:00? 0.00% stubgen ?suspicious considering I hadn't touched the machine in days. ?- Jay From jay.krell at cornell.edu Wed Sep 8 12:13:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 8 Sep 2010 10:13:04 +0000 Subject: [M3devel] CM3 CVS mirror for test In-Reply-To: <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> References: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com>, <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> Message-ID: PS: The ppc-linux setup seems still to be broken (mkdirs failed). I'll "recross" to make sure the stat/lstat latest is there. That is, I'll rebuild cm3 cross and copy it around. ?- Jay From wagner at elegosoft.com Thu Sep 9 15:49:10 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 09 Sep 2010 15:49:10 +0200 Subject: [M3devel] Out of office and connectivity Message-ID: <20100909154910.e7s1xqgbpcc8kw04@mail.elegosoft.com> I will be on holiday from September 10th till September 26th. There won't probably be many opportunities to read (and answer) my mail. In cases of emergency you may try to contact me via my mobile phone (voice/sms, no email access). Usually, someone at Elego should be able to provide backup. 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 Sat Sep 11 10:32:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 08:32:25 +0000 Subject: [M3devel] granular trace options in cm3cg? Message-ID: Does anyone (Tony?) ever use -ffvars_trace, -fsource_line_trace, etc.? I only ever use -y for trace all. Very useful. I'm considering a change, that'll make the tracing more systematic and more complete, and it'd be slightly easier if I only supported -y. You know -- something like, the serialization macros could do all the work. Each operation would probably be on just one line -- well, that I'm already going to try. ? - Jay From jay.krell at cornell.edu Sat Sep 11 11:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 09:35:32 +0000 Subject: [M3devel] another strike against the wierd use of bitfields Message-ID: configure -enable-checking reports ../src/text/TextConv.m3: In function 'TextConv__Explode': ../src/text/TextConv.m3:348: error: GIMPLE register modified with BIT_FIELD_REF BIT_FIELD_REF = 0B; ../src/text/TextConv.m3:348: error: GIMPLE register modified with BIT_FIELD_REF BIT_FIELD_REF = D.1977; ../src/text/TextConv.m3:348: internal compiler error: verify_stmts failed Please submit a full bug report, ?- Jay From jay.krell at cornell.edu Sun Sep 12 00:02:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 22:02:45 +0000 Subject: [M3devel] invalid trees, debugging Message-ID: So, when you configure -enable-checking, you get lots of errors. This should have been done all along and now we have dug a hole for ourselves to get out of. Some of them I've fixed, some of them I've hacked to warnings for now. They should all be fixed. The errors from -enable-checking have helped me, I believe, restore inlining. ?? I haven't finished testing these changes or commited them yet. ?? It looks like, in particular, we weren't forming RETURN_EXPR correctly. ?? It looks like they don't like merely the NOP_EXPR we wrap the store with. I was also running afoul of the gcc garbage collector. That might have been the bigger problem, recent, my fault. Anyway, some of the errors are related to the debugging information. I repeat, again, my belief, that the "normal" way of outputing debugging information, is to do nothing, except create well formed, well typed trees. That lets any debug format work. The way as I understand cm3cg works is by tunneling custom information on the side. ?At least for types. Granted, for line numbers it does the right thing -- good data. Here is an example where the debugging information is wierd: ../src/M3x86.m3: In function 'M3x86__start_int_proc': ../src/M3x86.m3:3291:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in compute_record_mode, at stor-layout.c:1559 Please submit a full bug report, I'm using I386_DARWIN currently and m3gdb doesn't build here. At least for that reason, I'm not likely to test m3gdb. In some cases I might migt might downgrade the experience with it, to fix these errors. I kind of suspect there is a way to tunnel the information without breaking configure -enable-checking. But I'm not sure. Hopefully this is ok. If people insist I can turn off the checking again on my machine and just proceed with the fixes I have. ?- Jay From jay.krell at cornell.edu Sun Sep 12 01:26:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 23:26:40 +0000 Subject: [M3devel] invalid trees, debugging In-Reply-To: References: Message-ID: This was placing the gcc GTY annotation at the wrong spot, sorry, nevermind. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sat, 11 Sep 2010 22:02:45 +0000 > Subject: [M3devel] invalid trees, debugging > > > So, when you configure -enable-checking, you get lots of errors. > This should have been done all along and now we have dug a hole for ourselves to get out of. > Some of them I've fixed, some of them I've hacked to warnings for now. > They should all be fixed. > The errors from -enable-checking have helped me, I believe, restore inlining. > I haven't finished testing these changes or commited them yet. > It looks like, in particular, we weren't forming RETURN_EXPR correctly. > It looks like they don't like merely the NOP_EXPR we wrap the store with. > > > I was also running afoul of the gcc garbage collector. > That might have been the bigger problem, recent, my fault. > > > Anyway, some of the errors are related to the debugging information. > I repeat, again, my belief, that the "normal" way of outputing debugging information, is > to do nothing, except create well formed, well typed trees. > That lets any debug format work. > The way as I understand cm3cg works is by tunneling custom information on the side. > At least for types. Granted, for line numbers it does the right thing -- good data. > > > Here is an example where the debugging information is wierd: > > ../src/M3x86.m3: In function 'M3x86__start_int_proc': > ../src/M3x86.m3:3291:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in compute_record_mode, at stor-layout.c:1559 > Please submit a full bug report, > > > I'm using I386_DARWIN currently and m3gdb doesn't build here. > At least for that reason, I'm not likely to test m3gdb. > In some cases I might migt might downgrade the experience with it, to fix these errors. > I kind of suspect there is a way to tunnel the information without breaking configure -enable-checking. > But I'm not sure. > > > Hopefully this is ok. > If people insist I can turn off the checking again on my machine and just proceed with the fixes I have. > > > - Jay > From jay.krell at cornell.edu Mon Sep 13 00:50:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Sep 2010 22:50:04 +0000 Subject: [M3devel] more combinations to test? Message-ID: I'd be super nice if we had some automation around: ? testing cm3cg -O, -O1, -O2, -O3 ?? m3cc/gcc/configure -enable-checking ?? m3cc/gcc/configure -enable-checking=all I'd settle for just -O3 and -enable-checking=all. I have a suspicion that if -enable-checking=all was done all along, we wouldn't have such problems with volatile and optimization. Currently cm3cg built with -enable-checking hits lots of problems, or at least many instances of a few problems. For now I change them warnings while I work through them. Having Hudson do this, and having then the record logged would be good. ? (It is a large log/record, as we hit many warnings per file, mostly ? converting integer types.) On the other hand, I'm not sure any of this is worth much. cm3cg -O3 is noticable slow to run. Possibly more time is spent in it than it saves. And -enable-checking maybe only fixes things that matter if optimizing -- based on what has historically worked. ?- Jay From hosking at cs.purdue.edu Mon Sep 13 00:52:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Sep 2010 18:52:14 -0400 Subject: [M3devel] more combinations to test? In-Reply-To: References: Message-ID: <76B77E55-97DD-4628-8446-46EB2ACA1A49@cs.purdue.edu> I think all of this is worthwhile. Probably enough to test -O and -O3. On 12 Sep 2010, at 18:50, Jay K wrote: > > I'd be super nice if we had some automation around: > testing cm3cg -O, -O1, -O2, -O3 > m3cc/gcc/configure -enable-checking > m3cc/gcc/configure -enable-checking=all > > I'd settle for just -O3 and -enable-checking=all. > > I have a suspicion that if -enable-checking=all was done all along, > we wouldn't have such problems with volatile and optimization. > > > Currently cm3cg built with -enable-checking hits lots of problems, > or at least many instances of a few problems. For now I change > them warnings while I work through them. > > > Having Hudson do this, and having then the record logged would be good. > (It is a large log/record, as we hit many warnings per file, mostly > converting integer types.) > > On the other hand, I'm not sure any of this is worth much. > cm3cg -O3 is noticable slow to run. > Possibly more time is spent in it than it saves. > And -enable-checking maybe only fixes things that matter if optimizing -- based > on what has historically worked. > > > - Jay > > > > From jay.krell at cornell.edu Mon Sep 13 01:53:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Sep 2010 23:53:18 +0000 Subject: [M3devel] field accesses in m3cg? In-Reply-To: <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu> References: , <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu> Message-ID: The more I look at this, the more I think we need to do it. If we want to stop hacking optimizations off, use -O3, use configure -enable-checking. The "failsafe" replacement for bitfields doesn't even work, though I'm trying to make it work. Inevitably, for now, we are trading one set of deoptimizations vs. another. For example, the heavy use of volatile was a big deoptimization that enabled ? "all" the rest to be done..at least from parse.c's point of view, though presumably ?? volatile stopped a lot of code below. Now I'm trying throwing around TREE_ADDRESSABLE, which I'm sure will ?also pessimize. We'll see. I'm not convinced that using ADDR_EXPR ?is equivalent to TREE_ADDRESSABLE. We'll see. It wasn't enough to throw in TREE_ADDRESSABLE on load/store with offset != 0. I'm trying it on all load/store now. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Fri, 3 Sep 2010 09:34:29 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] field accesses in m3cg? > > On 3 Sep 2010, at 07:28, Jay K wrote: > > > > > Thoughts on exposing higher level "field load/store" in m3cg? > > I'm wary of it currently. > > Would rather do other stuff for now. > > > > It'd let the bitfield refs be replaced by something "proper". > > > > But it opens up more danger in terms of frontend/backend layout disagreement. > > I worry about this. > > > > > - Jay > > > > > > > > > > > From jay.krell at cornell.edu Mon Sep 13 02:25:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 00:25:10 +0000 Subject: [M3devel] field accesses in m3cg? In-Reply-To: References: , , <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu>, Message-ID: No luck. In a jam between bitfields and configure -enable-checking: ?? ? error ("statement makes a memory store, but has no VDEFS"); ?? gimple_stmt (stderr, stmt, 0, TDF_VOPS); the "failsafe" form doesn't hit that error, but crashes somewhere. I'll probably have to debug said crash. I wonder..maybe we can prototype/synthesize field accesses? ie: without a frontend/m3cg change? In parse.c given an offset load/store, we could look at the base, and if it is a record just walk the fields linearly until the offset matches and then generate a component/field reference? Obviously it'd be better to do something without linear search. Similarly but easier for arrays. Heck, I have to imagine that arrays aren't a problem with the non-bitfield form. This still leaves some missing parts, mainly type information for other things, like packed and maybe opaque. I have to understand packed better. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 12 Sep 2010 23:53:18 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] field accesses in m3cg? > > > The more I look at this, the more I think we need to do it. > If we want to stop hacking optimizations off, use -O3, use configure -enable-checking. > The "failsafe" replacement for bitfields doesn't even work, though I'm trying to make it work. > > Inevitably, for now, we are trading one set of deoptimizations vs. another. > For example, the heavy use of volatile was a big deoptimization that enabled > "all" the rest to be done..at least from parse.c's point of view, though presumably > volatile stopped a lot of code below. > > Now I'm trying throwing around TREE_ADDRESSABLE, which I'm sure will > also pessimize. We'll see. I'm not convinced that using ADDR_EXPR > is equivalent to TREE_ADDRESSABLE. We'll see. > > It wasn't enough to throw in TREE_ADDRESSABLE on load/store with offset != 0. > I'm trying it on all load/store now. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Fri, 3 Sep 2010 09:34:29 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] field accesses in m3cg? > > > > On 3 Sep 2010, at 07:28, Jay K wrote: > > > > > > > > Thoughts on exposing higher level "field load/store" in m3cg? > > > I'm wary of it currently. > > > Would rather do other stuff for now. > > > > > > It'd let the bitfield refs be replaced by something "proper". > > > > > > But it opens up more danger in terms of frontend/backend layout disagreement. > > > > I worry about this. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > From jay.krell at cornell.edu Mon Sep 13 02:30:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 00:30:54 +0000 Subject: [M3devel] more packed questions Message-ID: T = BITS 2 FOR [0..3]; makes sense to me T = BITS 10 FOR [0..3]; What does that do? It is legal, and allocates 10 bits, and uses a certain 2 of them? Which 2? Probably, it depends on endian and read the code, and it is meant to mean the same thing in C, if embedded in a struct, as a 10 bit bitfield that only happens to contain values 0..3? TYPE T1 = RECORD a:INTEGER END; TYPE T2 = BITS 64 FOR T1; ?legal? ?Sticks 0 or 32 bits after T1/a? ? ? ?My goal is to generate accurate type information in parse.c. ?Debugging in stock gdb should work. ?And then furthermore try converting offset loads/stores ?to component/array_refs. ?And then furthermore, let all of -O3 work. ? ? ? - Jay From jay.krell at cornell.edu Mon Sep 13 02:33:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 00:33:34 +0000 Subject: [M3devel] representation of enums? Message-ID: How are enums represented? As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? An enum with 128 or 255 values -- 8 bits or 16? I assume 8. Packable into fewer bits, if they fit presumably. ?- Jay From hosking at cs.purdue.edu Mon Sep 13 02:44:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Sep 2010 20:44:49 -0400 Subject: [M3devel] representation of enums? In-Reply-To: References: Message-ID: <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> On 12 Sep 2010, at 20:33, Jay K wrote: > > How are enums represented? > > As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? Stored, yes. All operations on enum are as INTEGER. > An enum with 128 or 255 values -- 8 bits or 16? > I assume 8. 8 > Packable into fewer bits, if they fit presumably. BITS FOR, yes. > > - Jay > > > > > From jay.krell at cornell.edu Mon Sep 13 03:27:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 01:27:34 +0000 Subject: [M3devel] representation of enums? In-Reply-To: <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> References: , <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> Message-ID: Values are sign extended or zero extended? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 12 Sep 2010 20:44:49 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] representation of enums? > > On 12 Sep 2010, at 20:33, Jay K wrote: > > > > > How are enums represented? > > > > As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? > > Stored, yes. All operations on enum are as INTEGER. > > > An enum with 128 or 255 values -- 8 bits or 16? > > I assume 8. > > 8 > > > Packable into fewer bits, if they fit presumably. > > BITS FOR, yes. > > > > > - Jay > > > > > > > > > > > From rcolebur at SCIRES.COM Mon Sep 13 04:45:57 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 12 Sep 2010 22:45:57 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100913022909.0BAB52474033@birch.elegosoft.com> References: <20100913022909.0BAB52474033@birch.elegosoft.com> Message-ID: Sorry, the dependency should have read "...being present in C:\cm3\bin" --Randy -----Original Message----- From: Randy Coleburn [mailto:rcoleburn at elego.de] Sent: Monday, September 13, 2010 12:29 AM To: m3commit at elegosoft.com Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/09/13 04:29:08 Added files: cm3/scripts/install/windows/: CommandPromptHere.reg cm3CommandPromptHere.reg Log message: Use these 2 registry files to add context menu entries to Windows Explorer. Double-click to install. cm3CommandPromptHere.reg: Right click on a folder in explorer, choose "cm3 Command Prompt Here" and it brings up a new command prompt window ready for using cm3 in that directory. Depends on cm3CommandShell.cmd being present in C:\CM3. CommandPromptHere.reg: Right click on a folder in explorer, choose "Command Prompt Here" and it brings up a new command prompt window in that directory. From jay.krell at cornell.edu Mon Sep 13 09:18:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 07:18:12 +0000 Subject: [M3devel] tracing implementation minutae -- parity with automatic tracing of mangled names? Message-ID: wherever we have: static void m3cg_import_global (void) { ? NAME?????? (name, name_length); ... ? TYPEID???? (id); ... ? DECL_NAME (v) = fix_name (name, name_length, id); ? if (option_trace_all) ??? fprintf (stderr, " ...%s...", .. POINTER (DECL_NAME (v))); The "automatic tracing" can't achieve parity. I see three choices: ? - don't achieve parity -- don't print the m3 mangled name ? - leave in some manual tracing ? - move the TYPEID parameters to right after the NAME parameters, ?? and then introduce a new macro M3NAME that reads them in succession ?? and traces them with parity The last works, but touches, well, not necessarily the m3cg interface and all the implementations, etc., but at least the binary writer/reader. Seems a bit expensive..but maybe not. ?- Jay From jay.krell at cornell.edu Mon Sep 13 12:31:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 10:31:32 +0000 Subject: [M3devel] convert vs. cast in parse.c? Message-ID: Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"? Thanks, ?- Jay From jay.krell at cornell.edu Mon Sep 13 12:40:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 10:40:45 +0000 Subject: [M3devel] unnecessary temporaries Message-ID: parse.c seems to go crazy sometimes on the temporaries. Here, in min, max, and check_eq: Index: parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.314 diff -u -r1.314 parse.c --- parse.c??? 13 Sep 2010 09:59:25 -0000??? 1.314 +++ parse.c??? 13 Sep 2010 10:24:16 -0000 @@ -4791,11 +4791,8 @@ ?{ ?? MTYPE (t); ? -? tree t1 = declare_temp (t); -? tree t2 = declare_temp (t); - -? add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); -? add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); +? tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); +? tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); ? ?? EXPR_REF (-2) = m3_build3 (COND_EXPR, t, ????????????????????????????? m3_build2 (LE_EXPR, boolean_type_node, t2, t1), @@ -4808,11 +4805,8 @@ ?{ ?? MTYPE (t); ? -? tree t1 = declare_temp (t); -? tree t2 = declare_temp (t); - -? add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); -? add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); +? tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); +? tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); ? ?? EXPR_REF (-2) = m3_build3 (COND_EXPR, t, ????????????????????????????? m3_build2 (LE_EXPR, boolean_type_node, t1, t2), @@ -5679,11 +5673,10 @@ ?? MTYPE2? (t, T); ?? INTEGER (code); ? -? tree temp1 = declare_temp (t); -? tree temp2 = declare_temp (t); - -? m3_store (temp1, 0, t, T, t, T); -? m3_store (temp2, 0, t, T, t, T); +? tree temp1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); +? tree temp2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); +? EXPR_POP (); +? EXPR_POP (); ?? add_stmt (build3 (COND_EXPR, t_void, ???????????????????? m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2), ???????????????????? generate_fault (code), and in the unoptimized m3core/src/text/TextCat PROCEDURE MyGetChars (t: T;? VAR a: ARRAY OF CHAR;? start: CARDINAL) = ? VAR u: TEXT;? a_offset, t_offset, u_offset: CARDINAL := 0; ? BEGIN ??? u := t.a; ??? IF (t_offset + t.a_len > start) THEN ????? u_offset := MAX (start - t_offset, 0); ????? u.get_chars (SUBARRAY (a, a_offset, NUMBER (a) - a_offset), u_offset); 7 instructions go down to 3, 4 memory operations saved, and 16 bytes of stack are saved (presumably 12, rounded) --- I386_DARWIN.3/TextCat.ms??? 2010-09-13 03:18:45.000000000 -0700 +++ I386_DARWIN.4/TextCat.ms??? 2010-09-13 03:19:40.000000000 -0700 @@ -835,7 +835,7 @@ ?LCFI41: ???? movl??? %esp, %ebp ?LCFI42: -??? subl??? $88, %esp +??? subl??? $72, %esp ?LCFI43: ???? movl??? -16(%ebp), %eax ???? andl??? $0, %eax @@ -879,18 +879,14 @@ ???? movl??? 16(%ebp), %eax ???? cmpl??? %eax, %edx ???? jle??? L54 -??? movl??? $0, -32(%ebp) ???? movl??? 16(%ebp), %edx ???? movl??? -20(%ebp), %eax ???? movl??? %edx, %ecx ???? subl??? %eax, %ecx ???? movl??? %ecx, %eax -??? movl??? %eax, -36(%ebp) -??? movl??? -36(%ebp), %edx -??? movl??? -32(%ebp), %eax -??? cmpl??? %edx, %eax -??? jge??? L49 -??? movl??? %edx, %eax +??? testl??? %eax, %eax +??? jns??? L49 +??? movl??? $0, %eax Reasonable, eh? Or should I be nervous? check_eq in particular -- if you get it wrong, such that it is underaggressive, correct programs will work the same. I guess I should make sure m3tests is full of failure cases for that. Ok, in m3front, it looks like all the uses of check_eq are related to runtime assignments of open arrays, to make sure their sizes match, or such, either for assignment or passing a parameter. ?- Jay From jay.krell at cornell.edu Mon Sep 13 12:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 10:54:03 +0000 Subject: [M3devel] unnecessary temporaries In-Reply-To: References: Message-ID: Hm, test r003 should show a difference, at least unoptimized, but it doesn't seem to. I think I'll just #if out my change here unless/until I/anyone can confirm the expected change. Between min and max, just checking one should suffice. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Mon, 13 Sep 2010 10:40:45 +0000 > Subject: [M3devel] unnecessary temporaries > > > parse.c seems to go crazy sometimes on the temporaries. > > Here, in min, max, and check_eq: > > Index: parse.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > retrieving revision 1.314 > diff -u -r1.314 parse.c > --- parse.c 13 Sep 2010 09:59:25 -0000 1.314 > +++ parse.c 13 Sep 2010 10:24:16 -0000 > @@ -4791,11 +4791,8 @@ > { > MTYPE (t); > > - tree t1 = declare_temp (t); > - tree t2 = declare_temp (t); > - > - add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); > - add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); > + tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); > + tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); > > EXPR_REF (-2) = m3_build3 (COND_EXPR, t, > m3_build2 (LE_EXPR, boolean_type_node, t2, t1), > @@ -4808,11 +4805,8 @@ > { > MTYPE (t); > > - tree t1 = declare_temp (t); > - tree t2 = declare_temp (t); > - > - add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); > - add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); > + tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); > + tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); > > EXPR_REF (-2) = m3_build3 (COND_EXPR, t, > m3_build2 (LE_EXPR, boolean_type_node, t1, t2), > @@ -5679,11 +5673,10 @@ > MTYPE2 (t, T); > INTEGER (code); > > - tree temp1 = declare_temp (t); > - tree temp2 = declare_temp (t); > - > - m3_store (temp1, 0, t, T, t, T); > - m3_store (temp2, 0, t, T, t, T); > + tree temp1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); > + tree temp2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); > + EXPR_POP (); > + EXPR_POP (); > add_stmt (build3 (COND_EXPR, t_void, > m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2), > generate_fault (code), > > > and in the unoptimized > > m3core/src/text/TextCat > > PROCEDURE MyGetChars (t: T; VAR a: ARRAY OF CHAR; start: CARDINAL) = > VAR u: TEXT; a_offset, t_offset, u_offset: CARDINAL := 0; > BEGIN > u := t.a; > IF (t_offset + t.a_len > start) THEN > u_offset := MAX (start - t_offset, 0); > u.get_chars (SUBARRAY (a, a_offset, NUMBER (a) - a_offset), u_offset); > > > > 7 instructions go down to 3, 4 memory operations saved, and 16 bytes of stack are saved (presumably 12, rounded) > > > > --- I386_DARWIN.3/TextCat.ms 2010-09-13 03:18:45.000000000 -0700 > +++ I386_DARWIN.4/TextCat.ms 2010-09-13 03:19:40.000000000 -0700 > @@ -835,7 +835,7 @@ > LCFI41: > movl %esp, %ebp > LCFI42: > - subl $88, %esp > + subl $72, %esp > LCFI43: > movl -16(%ebp), %eax > andl $0, %eax > @@ -879,18 +879,14 @@ > movl 16(%ebp), %eax > cmpl %eax, %edx > jle L54 > - movl $0, -32(%ebp) > movl 16(%ebp), %edx > movl -20(%ebp), %eax > movl %edx, %ecx > subl %eax, %ecx > movl %ecx, %eax > - movl %eax, -36(%ebp) > - movl -36(%ebp), %edx > - movl -32(%ebp), %eax > - cmpl %edx, %eax > - jge L49 > - movl %edx, %eax > + testl %eax, %eax > + jns L49 > + movl $0, %eax > > > Reasonable, eh? > Or should I be nervous? > > > check_eq in particular -- if you get it wrong, such that it is underaggressive, correct programs > will work the same. > > > I guess I should make sure m3tests is full of failure cases for that. > Ok, in m3front, it looks like all the uses of check_eq are related to runtime assignments > of open arrays, to make sure their sizes match, or such, either for assignment or passing a parameter. > > > - Jay > > From hosking at cs.purdue.edu Mon Sep 13 15:48:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 13 Sep 2010 09:48:46 -0400 Subject: [M3devel] representation of enums? In-Reply-To: References: , <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> Message-ID: Zeros. On 12 Sep 2010, at 21:27, Jay K wrote: > > Values are sign extended or zero extended? > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 12 Sep 2010 20:44:49 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] representation of enums? >> >> On 12 Sep 2010, at 20:33, Jay K wrote: >> >>> >>> How are enums represented? >>> >>> As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? >> >> Stored, yes. All operations on enum are as INTEGER. >> >>> An enum with 128 or 255 values -- 8 bits or 16? >>> I assume 8. >> >> 8 >> >>> Packable into fewer bits, if they fit presumably. >> >> BITS FOR, yes. >> >>> >>> - Jay >>> >>> >>> >>> >>> >> > From hosking at cs.purdue.edu Mon Sep 13 22:22:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 13 Sep 2010 16:22:11 -0400 Subject: [M3devel] convert vs. cast in parse.c? In-Reply-To: References: Message-ID: m3_cast uses a NOP_EXPR, which assumes no code needs generating to effect the type change (i.e., bits are compatible, no extension necessary, etc.). convert is provided to perform all reasonable conversions. It generates code as necessary (see comments below from c-convert.c). Looking at the comments for VIEW_CONVERT_EXPR, I wonder if we should be using that for LOOPHOLE on floats to avoid the need for the temporary? I'm not sure we should ever be using CONVERT_EXPR explicitly ? probably better to use convert and get the CONVERT_EXPR from that as necessary? /* Change of width--truncation and extension of integers or reals-- is represented with NOP_EXPR. Proper functioning of many things assumes that no other conversions can be NOP_EXPRs. Conversion between integer and pointer is represented with CONVERT_EXPR. Converting integer to real uses FLOAT_EXPR and real to integer uses FIX_TRUNC_EXPR. Here is a list of all the functions that assume that widening and narrowing is always done with a NOP_EXPR: In convert.c, convert_to_integer. In c-typeck.c, build_binary_op (boolean ops), and c_common_truthvalue_conversion. In expr.c: expand_expr, for operands of a MULT_EXPR. In fold-const.c: fold. In tree.c: get_narrower and get_unwidened. */ /* Subroutines of `convert'. */ /* Create an expression whose value is that of EXPR, converted to type TYPE. The TREE_TYPE of the value is always TYPE. This function implements all reasonable conversions; callers should filter out those that are not permitted by the language being compiled. */ tree convert (tree type, tree expr) Also: NOP_EXPR These nodes are used to represent conversions that do not require any code-generation. For example, conversion of a char* to an int* does not require any code be generated; such a conversion is represented by a NOP_EXPR. The single operand is the expression to be converted. The conversion from a pointer to a reference is also represented with a NOP_EXPR. CONVERT_EXPR These nodes are similar to NOP_EXPRs, but are used in those situations where code may need to be generated. For example, if an int* is converted to an intcode may need to be generated on some platforms. These nodes are never used for C++-specific conversions, like conversions between pointers to different classes in an inheritance hierarchy. Any adjustments that need to be made in such cases are always indicated explicitly. Similarly, a user-defined conversion is never represented by a CONVERT_EXPR; instead, the function calls are made explicit. FIXED_CONVERT_EXPR These nodes are used to represent conversions that involve fixed-point values. For example, from a fixed-point value to another fixed-point value, from an integer to a fixed-point value, from a fixed-point value to an integer, from a floating-point value to a fixed-point value, or from a fixed-point value to a floating-point value. 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 13 Sep 2010, at 06:31, Jay K wrote: > > Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"? > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Sep 13 22:56:15 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 13 Sep 2010 15:56:15 -0500 Subject: [M3devel] more packed questions In-Reply-To: References: Message-ID: <4C8E8FEF.1060801@lcwb.coop> Jay K wrote: > T = BITS 2 FOR [0..3]; makes sense to me > > > T = BITS 10 FOR [0..3]; > What does that do? > It is legal, and allocates 10 bits, and uses a certain 2 of them? Yes, but only for an array element or field of a record or object. > Which 2? The least significant 2. Actually, the value would be treated as occupying all 10, but the bounds rules of the language would ensure that only values in 0..3 are ever stored therein. Same as just [0..3], the compiler can allocate whatever number of bits it wants (but at least 2) but ensure stored values are in the range. > Probably, it depends on endian and read the code, and it is meant > to mean the same thing in C, if embedded in a struct, as > a 10 bit bitfield that only happens to contain values 0..3? > > > TYPE T1 = RECORD a:INTEGER END; > TYPE T2 = BITS 64 FOR T1; > legal? > Sticks 0 or 32 bits after T1/a? First, it doesn't do anything unless T2 is used as an array element or a field. If so, then that element/field occupies 64 bits itself. Where within those bits the compiler puts the T1 record is not specified by the language, and this case is not as obvious as INTEGER or [0..3]. I would expect a compiler would, on a 32-bit machine, put the T1 within the 64 bits of the T2 the same way it would allocate fields in a record, i.e., the lowest-numbered 4 bytes of the 8. This would effectively do what you speculated. > > > My goal is to generate accurate type information in parse.c. > Debugging in stock gdb should work. > And then furthermore try converting offset loads/stores > to component/array_refs. > And then furthermore, let all of -O3 work. > > > - Jay From jay.krell at cornell.edu Tue Sep 14 01:51:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 23:51:44 +0000 Subject: [M3devel] a likely way to force passing records by address Message-ID: tree.h /* For a PARM_DECL, records the data type used to pass the argument, ?? which may be different from the type seen in the program.? */ #define DECL_ARG_TYPE(NODE) (PARM_DECL_CHECK (NODE)->decl_common.initial) We could probably use this to easily/quickly solve the SPARC64 record problem. But forcing records to always be passed by address. And then dispense with any long tedious attempt to make the trees better-formed/typed. But the better formed/typed trees have the advantage of better debugging with gdb and probably able to allow more optimizations. Really the SPARC64 problems (assertion failures in backend compiling caltech-parser) triggered this, but are no longer the point). ? ?- Jay From jay.krell at cornell.edu Tue Sep 14 04:28:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 02:28:14 +0000 Subject: [M3devel] convert vs. cast in parse.c? In-Reply-To: References: , Message-ID: I don't know. I'm not too concerned with float/loophole at the moment. Granted, probably a good way is take address, cast to new pointer type, deref -- you know, the "safe" load/store pattern. "view convert" sounds like it might be equivalent but more efficient (ie: not introduce pessimization associated with address-taken). I agree though, now that you mention it, sounds useful. My more immediate concern is 1) the min/max change I made, though that seems clearly to preserve preexisting semantics 2) changes to let configure -enable-checking to work. Many of the errors around operations that mix integer types, in comparison, assignment, plus, multiply, etc. > (i.e., bits are compatible, no extension necessary, etc.). What would qualify there? I can think of only a few: signed to/from unsigned, of same size pointer to/from integer, of same size (loophole) possibly loophole, of same size (e.g. int32 <=> float, int64 <=> double, heck float or double <=> pointer) enum <=> integer, of same size and NOT anything involving a change in size possibly, like boolean <=> int8/uint8, if boolean is 8 bits - Jay Subject: Re: convert vs. cast in parse.c? From: hosking at cs.purdue.edu Date: Mon, 13 Sep 2010 16:22:11 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu m3_cast uses a NOP_EXPR, which assumes no code needs generating to effect the type change (i.e., bits are compatible, no extension necessary, etc.). convert is provided to perform all reasonable conversions. It generates code as necessary (see comments below from c-convert.c). Looking at the comments for VIEW_CONVERT_EXPR, I wonder if we should be using that for LOOPHOLE on floats to avoid the need for the temporary? I'm not sure we should ever be using CONVERT_EXPR explicitly ? probably better to use convert and get the CONVERT_EXPR from that as necessary? /* Change of width--truncation and extension of integers or reals-- is represented with NOP_EXPR. Proper functioning of many things assumes that no other conversions can be NOP_EXPRs. Conversion between integer and pointer is represented with CONVERT_EXPR. Converting integer to real uses FLOAT_EXPR and real to integer uses FIX_TRUNC_EXPR. Here is a list of all the functions that assume that widening and narrowing is always done with a NOP_EXPR: In convert.c, convert_to_integer. In c-typeck.c, build_binary_op (boolean ops), and c_common_truthvalue_conversion. In expr.c: expand_expr, for operands of a MULT_EXPR. In fold-const.c: fold. In tree.c: get_narrower and get_unwidened. */ /* Subroutines of `convert'. */ /* Create an expression whose value is that of EXPR, converted to type TYPE. The TREE_TYPE of the value is always TYPE. This function implements all reasonable conversions; callers should filter out those that are not permitted by the language being compiled. */ tree convert (tree type, tree expr) Also: NOP_EXPR These nodes are used to represent conversions that do not require any code-generation. For example, conversion of a char* to an int* does not require any code be generated; such a conversion is represented by a NOP_EXPR. The single operand is the expression to be converted. The conversion from a pointer to a reference is also represented with a NOP_EXPR. CONVERT_EXPR These nodes are similar to NOP_EXPRs, but are used in those situations where code may need to be generated. For example, if an int* is converted to an intcode may need to be generated on some platforms. These nodes are never used for C++-specific conversions, like conversions between pointers to different classes in an inheritance hierarchy. Any adjustments that need to be made in such cases are always indicated explicitly. Similarly, a user-defined conversion is never represented by a CONVERT_EXPR; instead, the function calls are made explicit. FIXED_CONVERT_EXPR These nodes are used to represent conversions that involve fixed-point values. For example, from a fixed-point value to another fixed-point value, from an integer to a fixed-point value, from a fixed-point value to an integer, from a floating-point value to a fixed-point value, or from a fixed-point value to a floating-point value. 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 13 Sep 2010, at 06:31, Jay K wrote: Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Sep 14 06:14:38 2010 From: darko at darko.org (Darko) Date: Mon, 13 Sep 2010 21:14:38 -0700 Subject: [M3devel] Per thread data Message-ID: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? Cheers, Darko. From mika at async.async.caltech.edu Tue Sep 14 06:55:04 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 13 Sep 2010 21:55:04 -0700 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <20100914045504.A62281A209C@async.async.caltech.edu> Darko writes: >I need to have certain data structures allocated on a per thread basis. = >Right now I'm thinking of using the thread id from ThreadF.MyId() to = >index a list. Is there a better, more portable way of allocating on a = >per-thread basis? > >Cheers, >Darko. In my experience what you suggest works just fine (remember to lock the doors, though!) But you can get disappointing performance on some thread implementations (ones that involve switching into supervisor mode more than necessary when accessing pthread structures). Generally speaking I avoid needing per-thread structures as much as possible and instead put what you need in the Closure and then pass pointers around. Of course you can mix the methods for a compromise between speed and cluttered code... I think what you want is also not a list but a Table. Mika From dragisha at m3w.org Tue Sep 14 06:57:33 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 14 Sep 2010 06:57:33 +0200 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <1284440253.2748.36.camel@boromir.m3w.org> Only "better" would be using same storage as for MyId... Access time would be same as for that value, and if you use MyId access time is access to TLS (thread local storage) plus your structure manipulation. IMO, some IntRefTbl is better idea than list. If you decide to use same storage, then it's pthread.getspecific and pthread.setspecific you are looking for. On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: > I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > Cheers, > Darko. > -- Dragi?a Duri? From darko at darko.org Tue Sep 14 07:08:14 2010 From: darko at darko.org (Darko) Date: Mon, 13 Sep 2010 22:08:14 -0700 Subject: [M3devel] Per thread data In-Reply-To: <20100914045504.A62281A209C@async.async.caltech.edu> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <20100914045504.A62281A209C@async.async.caltech.edu> Message-ID: <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > Darko writes: >> I need to have certain data structures allocated on a per thread basis. = >> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >> index a list. Is there a better, more portable way of allocating on a = >> per-thread basis? >> >> Cheers, >> Darko. > > In my experience what you suggest works just fine (remember to lock the > doors, though!) But you can get disappointing performance on some thread > implementations (ones that involve switching into supervisor mode more > than necessary when accessing pthread structures). > > Generally speaking I avoid needing per-thread structures as much as possible > and instead put what you need in the Closure and then pass pointers around. > Of course you can mix the methods for a compromise between speed and > cluttered code... > > I think what you want is also not a list but a Table. > > Mika From darko at darko.org Tue Sep 14 07:08:19 2010 From: darko at darko.org (Darko) Date: Mon, 13 Sep 2010 22:08:19 -0700 Subject: [M3devel] Per thread data In-Reply-To: <1284440253.2748.36.camel@boromir.m3w.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <1284440253.2748.36.camel@boromir.m3w.org> Message-ID: <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> I'm guessing that the pthread calls wouldn't be portable to Win32? Which is ok if there are similar calls for Win threads. On 13/09/2010, at 9:57 PM, Dragi?a Duri? wrote: > Only "better" would be using same storage as for MyId... Access time > would be same as for that value, and if you use MyId access time is > access to TLS (thread local storage) plus your structure manipulation. > IMO, some IntRefTbl is better idea than list. > > If you decide to use same storage, then it's pthread.getspecific and > pthread.setspecific you are looking for. > > On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? >> >> Cheers, >> Darko. >> > > -- > Dragi?a Duri? > From jay.krell at cornell.edu Tue Sep 14 07:36:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 05:36:38 +0000 Subject: [M3devel] Per thread data In-Reply-To: <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <1284440253.2748.36.camel@boromir.m3w.org>, <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> Message-ID: Best results imho would be use lightly #ifdefed C and ignore OpenBSD. Perhaps we should provide something for Modula-3, that is then portable to user threads. The Win32 equivalent is "thread local storage", or, if you are picky and care "fiber local storage". TlsAlloc TlsGetValue TlsSetValue TlsFree Search the web, you'll find the documentation right away. There are also Fls functions. They aren't in XP and fibers are exceedingly rarely used. Fiber local storage is thread local if fibers aren't in use. That is, using FLS is like a "superset" of TLS. You can't go wrong by using it, except you need to handle the LoadLibrary/GetProcAddress to see if the functions are available or not. For TLS (and FLS?), there is an array of 64 and an array of 1024, pointers. Each thread local is a pointer. You can heap allocate therein. Note that the heap allocation can fail. And Tls can be exhausted. The maximum number of thread locals is 1088. On older operating systems it is 64. TlsGet/SetValue just index into the appropriate array. If you are in an .exe, or a .dll that the .exe statically depends upon, or depend on Vista or newer, than __declspec(thread) is more convenient, faster, and I think has no limits. You just put that marker on your data and voila, the compiler, linker, and loader collaborate. (as well as the context switcher, which must be involved in both mechanisms). That is __declspec(thread) does not work in .dlls that are loaded via LoadLibrary, prior to Vista. This is a major downer, though decreasing in time now, as __declspec(thread) is so preferable. Non-Win32 systems often have "__thread" that is equivalent ot __declspec(thread), probably without an equivalent dlopen limitation, but of varying efficiency -- really, read the spec, it is confusing, there are so many "models" for the linker/loader to worry about. Current gcc emulates __thread in terms of "whatever" (tls or pthread) if there isn't anything better. I did some experiments though and __thread didn't seem all that much faster, at least once you go to the worst of the "models". "models" include like in the executable or a shared object, position-independent or not. m3core uses pthread_getspecific/setspecific -- like for every occurence of "TRY" -- but those experiments were around having it use __thread if it is available. Ultimately we just want to dramatically reduce the use of that specific data anyway -- by having a stack walker or using whatever the underlying native exception handling mechanism is.. There is surprisingly more to this subject. Imagine you have a few thread locals and you pack them together into a heap allocated struct/record. It is tempting to think DllMain(THREAD_ATTACH) is the place to do the allocation. It is, but threads can be created before your .dll is loaded, and you won't get notifications for them. So you are still left having to do the allocation on-demand. You are still left with "failure points" on every access. Thread locals are also "fragile", nearly as much so as globals. Like, written when you don't realize and their value "lost". What I mean, is, imagine this code: f = fopen(...) if (!f) return errno; errno is a thread local on all modern systems. Then imagine similar: f = fopen(...) if (!f) return errno; g = fopen(...) if (!g) { fclose(f); /* preferably in a destructor or finally! */ return errno; } See the bug? fclose might have clobbered errno. As well, accessing thread locals is always going to much slower than accessing a function local or parameter. You really should try to avoid them. - Jay > From: darko at darko.org > Date: Mon, 13 Sep 2010 22:08:19 -0700 > To: dragisha at m3w.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > I'm guessing that the pthread calls wouldn't be portable to Win32? Which is ok if there are similar calls for Win threads. > > > On 13/09/2010, at 9:57 PM, Dragi?a Duri? wrote: > > > Only "better" would be using same storage as for MyId... Access time > > would be same as for that value, and if you use MyId access time is > > access to TLS (thread local storage) plus your structure manipulation. > > IMO, some IntRefTbl is better idea than list. > > > > If you decide to use same storage, then it's pthread.getspecific and > > pthread.setspecific you are looking for. > > > > On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: > >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > >> > >> Cheers, > >> Darko. > >> > > > > -- > > Dragi?a Duri? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 14 14:07:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 08:07:39 -0400 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: Why not just allocate in the heap and hold a reference in the thread closure? On 14 Sep 2010, at 00:14, Darko wrote: > I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > Cheers, > Darko. > From hosking at cs.purdue.edu Tue Sep 14 14:08:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 08:08:39 -0400 Subject: [M3devel] Per thread data In-Reply-To: <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <20100914045504.A62281A209C@async.async.caltech.edu> <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> Message-ID: If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? On 14 Sep 2010, at 01:08, Darko wrote: > I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > > On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > >> Darko writes: >>> I need to have certain data structures allocated on a per thread basis. = >>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >>> index a list. Is there a better, more portable way of allocating on a = >>> per-thread basis? >>> >>> Cheers, >>> Darko. >> >> In my experience what you suggest works just fine (remember to lock the >> doors, though!) But you can get disappointing performance on some thread >> implementations (ones that involve switching into supervisor mode more >> than necessary when accessing pthread structures). >> >> Generally speaking I avoid needing per-thread structures as much as possible >> and instead put what you need in the Closure and then pass pointers around. >> Of course you can mix the methods for a compromise between speed and >> cluttered code... >> >> I think what you want is also not a list but a Table. >> >> Mika > From hosking at cs.purdue.edu Tue Sep 14 14:09:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 08:09:46 -0400 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <1284440253.2748.36.camel@boromir.m3w.org>, <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> Message-ID: I really don't understand any of this motivation for a language that has heap allocation. Where is the overhead to just holding a reference to heap-allocated state from each thread? On 14 Sep 2010, at 01:36, Jay K wrote: > Best results imho would be use lightly #ifdefed C and ignore OpenBSD. > Perhaps we should provide something for Modula-3, that is then portable to user threads. > > > The Win32 equivalent is "thread local storage", or, if you are picky and care "fiber local storage". > TlsAlloc > TlsGetValue > TlsSetValue > TlsFree > > > Search the web, you'll find the documentation right away. > > > There are also Fls functions. They aren't in XP and fibers are exceedingly rarely used. > Fiber local storage is thread local if fibers aren't in use. > That is, using FLS is like a "superset" of TLS. You can't go wrong by using it, except you need to handle the LoadLibrary/GetProcAddress to see if the functions are available or not. > > > For TLS (and FLS?), there is an array of 64 and an array of 1024, pointers. Each thread local is a pointer. You can heap allocate therein. Note that the heap allocation can fail. And Tls can be exhausted. > The maximum number of thread locals is 1088. > On older operating systems it is 64. > TlsGet/SetValue just index into the appropriate array. > > > If you are in an .exe, or a .dll that the .exe statically depends upon, or depend on Vista or newer, than __declspec(thread) is more convenient, faster, and I think has no limits. You just put that marker on your data and voila, the compiler, linker, and loader collaborate. (as well as the context switcher, which must be involved in both mechanisms). > > > That is __declspec(thread) does not work in .dlls that are loaded via LoadLibrary, prior to Vista. > This is a major downer, though decreasing in time now, as __declspec(thread) is so preferable. > > > Non-Win32 systems often have "__thread" that is equivalent ot __declspec(thread), probably without an equivalent dlopen limitation, but of varying efficiency -- really, read the spec, it is confusing, there are so many "models" for the linker/loader to worry about. > > > Current gcc emulates __thread in terms of "whatever" (tls or pthread) if there isn't anything better. > > > I did some experiments though and __thread didn't seem all that much faster, at least once you go to the worst of the "models". > "models" include like in the executable or a shared object, position-independent or not. > > > m3core uses pthread_getspecific/setspecific -- like for every occurence of "TRY" -- but those experiments were around having it use __thread if it is available. > Ultimately we just want to dramatically reduce the use of that specific data anyway -- by having a stack walker or using whatever the underlying native exception handling mechanism is.. > > > There is surprisingly more to this subject. Imagine you have a few thread locals and you pack them together into a heap allocated struct/record. > It is tempting to think DllMain(THREAD_ATTACH) is the place to do the allocation. It is, but threads can be created before your .dll is loaded, and you won't get notifications for them. So you are still left having to do the allocation on-demand. You are still left with "failure points" on every access. > > > Thread locals are also "fragile", nearly as much so as globals. > Like, written when you don't realize and their value "lost". > > > What I mean, is, imagine this code: > > > f = fopen(...) > if (!f) > return errno; > > errno is a thread local on all modern systems. > Then imagine similar: > > > f = fopen(...) > if (!f) > return errno; > g = fopen(...) > if (!g) > { > fclose(f); /* preferably in a destructor or finally! */ > return errno; > } > > > See the bug? fclose might have clobbered errno. > > > As well, accessing thread locals is always going to much slower than accessing a function local or parameter. > You really should try to avoid them. > > > - Jay > > > > > From: darko at darko.org > > Date: Mon, 13 Sep 2010 22:08:19 -0700 > > To: dragisha at m3w.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > I'm guessing that the pthread calls wouldn't be portable to Win32? Which is ok if there are similar calls for Win threads. > > > > > > On 13/09/2010, at 9:57 PM, Dragi?a Duri? wrote: > > > > > Only "better" would be using same storage as for MyId... Access time > > > would be same as for that value, and if you use MyId access time is > > > access to TLS (thread local storage) plus your structure manipulation. > > > IMO, some IntRefTbl is better idea than list. > > > > > > If you decide to use same storage, then it's pthread.getspecific and > > > pthread.setspecific you are looking for. > > > > > > On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: > > >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > >> > > >> Cheers, > > >> Darko. > > >> > > > > > > -- > > > Dragi?a Duri? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Sep 14 14:31:48 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 05:31:48 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <4D57FCA0-0636-4BE3-91FB-79D23FAFC209@darko.org> What I'm not clear about in that case is how I get back to the allocated references. Any particular object doesn't know what thread it's running in but needs access to the currently running thread's copy of the objects. If I could subclass Thread.T and have that allocated when creating new threads that would be perfect. I could store a reference in each object pointing to it's per-thread data but that seems wasteful. On 14/09/2010, at 5:07 AM, Tony Hosking wrote: > Why not just allocate in the heap and hold a reference in the thread closure? > > On 14 Sep 2010, at 00:14, Darko wrote: > >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? >> >> Cheers, >> Darko. >> > From darko at darko.org Tue Sep 14 14:34:59 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 05:34:59 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <20100914045504.A62281A209C@async.async.caltech.edu> <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> Message-ID: That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > On 14 Sep 2010, at 01:08, Darko wrote: > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. >> >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: >> >>> Darko writes: >>>> I need to have certain data structures allocated on a per thread basis. = >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >>>> index a list. Is there a better, more portable way of allocating on a = >>>> per-thread basis? >>>> >>>> Cheers, >>>> Darko. >>> >>> In my experience what you suggest works just fine (remember to lock the >>> doors, though!) But you can get disappointing performance on some thread >>> implementations (ones that involve switching into supervisor mode more >>> than necessary when accessing pthread structures). >>> >>> Generally speaking I avoid needing per-thread structures as much as possible >>> and instead put what you need in the Closure and then pass pointers around. >>> Of course you can mix the methods for a compromise between speed and >>> cluttered code... >>> >>> I think what you want is also not a list but a Table. >>> >>> Mika >> > From jay.krell at cornell.edu Tue Sep 14 14:59:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 12:59:18 +0000 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , Message-ID: Tony -- then why does pthread_get/setspecific and Win32 TLS exist? What language doesn't support heap allocation were they designed to support? It is because code often fails to pass all the parameters through all functions. Again the best current answer is: #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. As well, you'd get very very far with merely: #ifdef _WIN32 __declspec(thread) #else __thread #endif Those work adequately for many many purposes, are more efficient, much more convenient, and very portable. I believe there is even an "official" C++ proposal along these lines. We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well. Can anyone propose something? It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use. - Jay > From: darko at darko.org > Date: Tue, 14 Sep 2010 05:34:59 -0700 > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > >> > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > >> > >>> Darko writes: > >>>> I need to have certain data structures allocated on a per thread basis. = > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > >>>> index a list. Is there a better, more portable way of allocating on a = > >>>> per-thread basis? > >>>> > >>>> Cheers, > >>>> Darko. > >>> > >>> In my experience what you suggest works just fine (remember to lock the > >>> doors, though!) But you can get disappointing performance on some thread > >>> implementations (ones that involve switching into supervisor mode more > >>> than necessary when accessing pthread structures). > >>> > >>> Generally speaking I avoid needing per-thread structures as much as possible > >>> and instead put what you need in the Closure and then pass pointers around. > >>> Of course you can mix the methods for a compromise between speed and > >>> cluttered code... > >>> > >>> I think what you want is also not a list but a Table. > >>> > >>> Mika > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Sep 14 15:13:26 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 06:13:26 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , Message-ID: <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> I think a minimalist approach where you get to store and retrieve one traced reference per thread would do the trick. If people want more they can design their own abstraction on top of that. Maybe just add the following to the Thread interface: PROCEDURE GetPrivate(): REFANY; PROCEDURE SetPrivate(ref: REFANY); On 14/09/2010, at 5:59 AM, Jay K wrote: > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much as possible > > >>> and instead put what you need in the Closure and then pass pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Sep 14 15:50:02 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 14 Sep 2010 06:50:02 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <20100914135002.72B6A1A2097@async.async.caltech.edu> If you have control over all the code you can (probably?) always do that, perhaps at the cost of some extra code. But there are times---such as when writing an interpreter that interfaces with "any" Modula-3 code---that you may want to have thread-private data accessible without necessarily being able to access the thread closure. In these cases, you don't know how many threads you have but yet want to have "global" variables. It would be really nice to have some interface for doing this without going all the way through pthreads primitives (or something equivalent)... Mika Tony Hosking writes: >Why not just allocate in the heap and hold a reference in the thread = >closure? > >On 14 Sep 2010, at 00:14, Darko wrote: > >> I need to have certain data structures allocated on a per thread = >basis. Right now I'm thinking of using the thread id from ThreadF.MyId() = >to index a list. Is there a better, more portable way of allocating on a = >per-thread basis? >>=20 >> Cheers, >> Darko. >>=20 From jay.krell at cornell.edu Tue Sep 14 16:05:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 14:05:12 +0000 Subject: [M3devel] Per thread data In-Reply-To: <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, , <20100914045504.A62281A209C@async.async.caltech.edu>, , <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> Message-ID: Eh? Just one thread local for the entire process? I think not. More like: PROCEDURE AllocateThreadLocal(): INTEGER; PROCEDURE GetThreadLocal(INTEGER):REFANY; PROCEDURE SetThreadLocal(INTEGER;REFANY); or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. The first set of names sounds better, the second "scales" better. This seems like a constant dilemna. btw, important point I just remembered: unless you do extra work, thread locals are hidden from the garbage collector. This is why the thread implementations seemingly store extra data. The traced data is in globals, so the garbage collector can see them. ?- Jay ________________________________ > From: darko at darko.org > Date: Tue, 14 Sep 2010 06:13:26 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > I think a minimalist approach where you get to store and retrieve one > traced reference per thread would do the trick. If people want more > they can design their own abstraction on top of that. Maybe just add > the following to the Thread interface: > > PROCEDURE GetPrivate(): REFANY; > PROCEDURE SetPrivate(ref: REFANY); > > > On 14/09/2010, at 5:59 AM, Jay K wrote: > > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all > functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 > TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much > more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then > support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) > know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object > allocated for the same thread, so it needs to find the currently > running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in > the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no > calls on them can be re-entered, which also avoids the need for locking > them in a threaded environment, which is impractical. The result is > that I need one copy of each object in each thread. There is > approximately one allocated object per object type so space is not a > big issue. I'm looking at a small number of threads, probably maximum > two per processor core. With modern processors I'm assuming that a > linear search through a small array is actually quicker that a hash > table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread > basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating > on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some > thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much > as possible > > >>> and instead put what you need in the Closure and then pass > pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > > From jay.krell at cornell.edu Tue Sep 14 16:09:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 14:09:28 +0000 Subject: [M3devel] m3cc/m3gdb mangled names Message-ID: Two part proposal: if targeting a platform that m3gdb doesn't currently support, don't mangle the names ? I understand this set is subject to change, and therefore that's a flaw in the suggestion. if I can determine that neither -gstabs nor -gstabs+ are on the command line, ? and I think I can, then don't mangle the names. and then, along with the goal of making all optimizations work I want all the other -g options, like plain -g, to not crash. I expect these goals have somewhat coincident fixes. I expect to do this shortly. This is a brief period to object, and maybe for me to explain myself better than in the commit message, perhaps. ?- Jay From rodney_bates at lcwb.coop Tue Sep 14 17:17:47 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 14 Sep 2010 10:17:47 -0500 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <4C8F921B.6040005@lcwb.coop> Another way: Put your thread-specific data in local variables of the topmost procedure of your thread, i.e., the procedure that you override Thread.Closure.apply with. Then you can access it in either of two ways, or a mixture: 1) Nest other procedures inside the topmost procedure and use nonlocal references to the thread-specific data. 2) Pass it (probably by reference) to/thru any non-nested procedures you really must have. Any code you don't have control over would not have any way of knowing about your thread-specific data, except if you passed it as parameter(s). Darko wrote: > I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > Cheers, > Darko. > > From hosking at cs.purdue.edu Tue Sep 14 18:48:22 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 12:48:22 -0400 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , Message-ID: Ah, sorry. I misunderstood. Sounds like we need a thread-local pragma <*LOCAL*>? On 14 Sep 2010, at 08:59, Jay K wrote: > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much as possible > > >>> and instead put what you need in the Closure and then pass pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 14 22:08:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 20:08:21 +0000 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , Message-ID: Sure. <* ThreadLocal *> or such, be sure it mentions "thread". ?- Jay ________________________________ > Subject: Re: [M3devel] Per thread data > From: hosking at cs.purdue.edu > Date: Tue, 14 Sep 2010 12:48:22 -0400 > CC: darko at darko.org; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Ah, sorry. I misunderstood. Sounds like we need a thread-local pragma > <*LOCAL*>? > > On 14 Sep 2010, at 08:59, Jay K wrote: > > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all > functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 > TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much > more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then > support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) > know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object > allocated for the same thread, so it needs to find the currently > running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in > the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no > calls on them can be re-entered, which also avoids the need for locking > them in a threaded environment, which is impractical. The result is > that I need one copy of each object in each thread. There is > approximately one allocated object per object type so space is not a > big issue. I'm looking at a small number of threads, probably maximum > two per processor core. With modern processors I'm assuming that a > linear search through a small array is actually quicker that a hash > table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread > basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating > on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some > thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much > as possible > > >>> and instead put what you need in the Closure and then pass > pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > > From mika at async.async.caltech.edu Tue Sep 14 22:28:13 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 14 Sep 2010 13:28:13 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , Message-ID: <20100914202813.1CCF81A20A2@async.async.caltech.edu> Something that changes the meaning of the language in such a fundamental way I think ought to be implemented as a library so that we can simulate the behavior in other releases... not as a compiler pragma. Yes I know there's an efficiency and expressibility price for this. Mika Jay K writes: > >Sure. <* ThreadLocal *> or such=2C be sure it mentions "thread". > >=A0- Jay > > > >________________________________ >> Subject: Re: [M3devel] Per thread data >> From: hosking at cs.purdue.edu >> Date: Tue=2C 14 Sep 2010 12:48:22 -0400 >> CC: darko at darko.org=3B m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Ah=2C sorry. I misunderstood. Sounds like we need a thread-local pragma >> <*LOCAL*>? >> >> On 14 Sep 2010=2C at 08:59=2C Jay K wrote: >> >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? >> What language doesn't support heap allocation were they designed to suppo= >rt? >> It is because code often fails to pass all the parameters through all >> functions. >> >> Again the best current answer is: >> #ifdefed C that uses pthread_get/setspecific / Win32 >> TlsAlloc/GetValue/SetValue=2C ignoring user threads/OpenBSD. >> >> As well=2C you'd get very very far with merely: >> #ifdef _WIN32 >> __declspec(thread) >> #else >> __thread >> #endif >> >> Those work adequately for many many purposes=2C are more efficient=2C muc= >h >> more convenient=2C and very portable. >> I believe there is even an "official" C++ proposal along these lines. >> >> We could easily abstract this -- the first -- into Modula-3 and then >> support it on user threads as well. >> Can anyone propose something? >> It has to go in m3core=2C as that is the only code that (is supposed to) >> know which thread implementation is in use. >> >> - Jay >> >> >> > From: darko at darko.org >> > Date: Tue=2C 14 Sep 2010 05:34:59 -0700 >> > To: hosking at cs.purdue.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] Per thread data >> > >> > That's the idea but each object can only call another object >> allocated for the same thread=2C so it needs to find the currently >> running thread's copy of the desired object. >> > >> > On 14/09/2010=2C at 5:08 AM=2C Tony Hosking wrote: >> > >> > > If they are truly private to each thread=2C then allocating them in >> the heap while still not locking them would be adequate. Why not? >> > > >> > > On 14 Sep 2010=2C at 01:08=2C Darko wrote: >> > > >> > >> I have lots of objects that are implemented on the basis that no >> calls on them can be re-entered=2C which also avoids the need for locking >> them in a threaded environment=2C which is impractical. The result is >> that I need one copy of each object in each thread. There is >> approximately one allocated object per object type so space is not a >> big issue. I'm looking at a small number of threads=2C probably maximum >> two per processor core. With modern processors I'm assuming that a >> linear search through a small array is actually quicker that a hash >> table. >> > >> >> > >> On 13/09/2010=2C at 9:55 PM=2C Mika Nystrom wrote: >> > >> >> > >>> Darko writes: >> > >>>> I need to have certain data structures allocated on a per thread >> basis. =3D >> > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() = >to =3D >> > >>>> index a list. Is there a better=2C more portable way of allocating >> on a =3D >> > >>>> per-thread basis? >> > >>>> >> > >>>> Cheers=2C >> > >>>> Darko. >> > >>> >> > >>> In my experience what you suggest works just fine (remember to lock= > the >> > >>> doors=2C though!) But you can get disappointing performance on some >> thread >> > >>> implementations (ones that involve switching into supervisor mode m= >ore >> > >>> than necessary when accessing pthread structures). >> > >>> >> > >>> Generally speaking I avoid needing per-thread structures as much >> as possible >> > >>> and instead put what you need in the Closure and then pass >> pointers around. >> > >>> Of course you can mix the methods for a compromise between speed an= >d >> > >>> cluttered code... >> > >>> >> > >>> I think what you want is also not a list but a Table. >> > >>> >> > >>> Mika >> > >> >> > > >> > >> > = From hosking at cs.purdue.edu Tue Sep 14 22:37:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 16:37:59 -0400 Subject: [M3devel] Per thread data In-Reply-To: <20100914202813.1CCF81A20A2@async.async.caltech.edu> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , <20100914202813.1CCF81A20A2@async.async.caltech.edu> Message-ID: <5F561977-1C70-4060-9605-F4B834953799@cs.purdue.edu> Yeah, I thought of that afterwards. Probably need a ThreadLocal generic interface like Atomic. On 14 Sep 2010, at 16:28, Mika Nystrom wrote: > Something that changes the meaning of the language in such a fundamental > way I think ought to be implemented as a library so that we can simulate > the behavior in other releases... not as a compiler pragma. Yes I know > there's an efficiency and expressibility price for this. > > Mika > > Jay K writes: >> >> Sure. <* ThreadLocal *> or such=2C be sure it mentions "thread". >> >> =A0- Jay >> >> >> >> ________________________________ >>> Subject: Re: [M3devel] Per thread data >>> From: hosking at cs.purdue.edu >>> Date: Tue=2C 14 Sep 2010 12:48:22 -0400 >>> CC: darko at darko.org=3B m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> Ah=2C sorry. I misunderstood. Sounds like we need a thread-local pragma >>> <*LOCAL*>? >>> >>> On 14 Sep 2010=2C at 08:59=2C Jay K wrote: >>> >>> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? >>> What language doesn't support heap allocation were they designed to suppo= >> rt? >>> It is because code often fails to pass all the parameters through all >>> functions. >>> >>> Again the best current answer is: >>> #ifdefed C that uses pthread_get/setspecific / Win32 >>> TlsAlloc/GetValue/SetValue=2C ignoring user threads/OpenBSD. >>> >>> As well=2C you'd get very very far with merely: >>> #ifdef _WIN32 >>> __declspec(thread) >>> #else >>> __thread >>> #endif >>> >>> Those work adequately for many many purposes=2C are more efficient=2C muc= >> h >>> more convenient=2C and very portable. >>> I believe there is even an "official" C++ proposal along these lines. >>> >>> We could easily abstract this -- the first -- into Modula-3 and then >>> support it on user threads as well. >>> Can anyone propose something? >>> It has to go in m3core=2C as that is the only code that (is supposed to) >>> know which thread implementation is in use. >>> >>> - Jay >>> >>> >>>> From: darko at darko.org >>>> Date: Tue=2C 14 Sep 2010 05:34:59 -0700 >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Per thread data >>>> >>>> That's the idea but each object can only call another object >>> allocated for the same thread=2C so it needs to find the currently >>> running thread's copy of the desired object. >>>> >>>> On 14/09/2010=2C at 5:08 AM=2C Tony Hosking wrote: >>>> >>>>> If they are truly private to each thread=2C then allocating them in >>> the heap while still not locking them would be adequate. Why not? >>>>> >>>>> On 14 Sep 2010=2C at 01:08=2C Darko wrote: >>>>> >>>>>> I have lots of objects that are implemented on the basis that no >>> calls on them can be re-entered=2C which also avoids the need for locking >>> them in a threaded environment=2C which is impractical. The result is >>> that I need one copy of each object in each thread. There is >>> approximately one allocated object per object type so space is not a >>> big issue. I'm looking at a small number of threads=2C probably maximum >>> two per processor core. With modern processors I'm assuming that a >>> linear search through a small array is actually quicker that a hash >>> table. >>>>>> >>>>>> On 13/09/2010=2C at 9:55 PM=2C Mika Nystrom wrote: >>>>>> >>>>>>> Darko writes: >>>>>>>> I need to have certain data structures allocated on a per thread >>> basis. =3D >>>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() = >> to =3D >>>>>>>> index a list. Is there a better=2C more portable way of allocating >>> on a =3D >>>>>>>> per-thread basis? >>>>>>>> >>>>>>>> Cheers=2C >>>>>>>> Darko. >>>>>>> >>>>>>> In my experience what you suggest works just fine (remember to lock= >> the >>>>>>> doors=2C though!) But you can get disappointing performance on some >>> thread >>>>>>> implementations (ones that involve switching into supervisor mode m= >> ore >>>>>>> than necessary when accessing pthread structures). >>>>>>> >>>>>>> Generally speaking I avoid needing per-thread structures as much >>> as possible >>>>>>> and instead put what you need in the Closure and then pass >>> pointers around. >>>>>>> Of course you can mix the methods for a compromise between speed an= >> d >>>>>>> cluttered code... >>>>>>> >>>>>>> I think what you want is also not a list but a Table. >>>>>>> >>>>>>> Mika >>>>>> >>>>> >>>> >>> >> = From jay.krell at cornell.edu Tue Sep 14 22:38:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 20:38:24 +0000 Subject: [M3devel] Per thread data In-Reply-To: <20100914202813.1CCF81A20A2@async.async.caltech.edu> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , <20100914202813.1CCF81A20A2@async.async.caltech.edu> Message-ID: Thread.Local ? Also, if you are doing this, can you add NoInline? We are letting gcc be more aggressive lately. I want NoInline for the toplevel function in the thread implementations. I could probably fake it by making a call to <*EXTERN*> setjmp. It might also be nice to parallel more of C/gcc's features. <*volatile*> ? And if you are really aggressive, since these involve m3cg changes, move any typeids that mangle names to be immediately after the name they mangle?? Maybe that is overkill though. It's just for tracing of mangled names via infrastructure. Also, load/store should take some notion of a field. A name or a uid perhaps. But now I'm being greedy. I'm willing to first prototype field access via linear search. Mika I see your point. We could consider both. I can maybe do the library soon. Or someone else can. It's pretty easy. ? It really should be mostly #ifdefed C, plus either ?? 1) using UNTRACED ROOT or INTEGER instead of REFANY for the data ???? You could loophole between untraced root and integer. ????? Safety would imply providing integer and float/real options to safe code. ????? Possibly double/longreal (which would take two slots on 32bit targets). ????? I think the functions could be exposed to safe code. They'd raise ???? exceptions for invalid tls indeices ?? 2) some way to reveal the REFANYs to the garbage collector ???? 2a) possibly by stashing them all in globals as well ? ???? 2b) or by having the garbage collector use the per thread data functions, ? with the caveat that they can't be use across threads, which might ?? be a problem; a thread could perhaps fetch all of its per thread ?? data into locals before acknowleding suspension ? ? Many approaches would require the runtime to ???? know all the per thread data keys/indices, which I suspect is easy enough. I'd appreciate a fairly firm commit it will actually be used. Thanks. Maybe we can switch m3core to use itself. Maybe. ? (It'd have to not raise exceptions or use try, to avoid circular dependency.) Maybe just use an array and linear search, in m3core or your code.. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > Date: Tue, 14 Sep 2010 13:28:13 -0700 > From: mika at async.async.caltech.edu > > Something that changes the meaning of the language in such a fundamental > way I think ought to be implemented as a library so that we can simulate > the behavior in other releases... not as a compiler pragma. Yes I know > there's an efficiency and expressibility price for this. > > Mika > > Jay K writes: > > > >Sure. <* ThreadLocal *> or such=2C be sure it mentions "thread". > > > >=A0- Jay > > > > > > > >________________________________ > >> Subject: Re: [M3devel] Per thread data > >> From: hosking at cs.purdue.edu > >> Date: Tue=2C 14 Sep 2010 12:48:22 -0400 > >> CC: darko at darko.org=3B m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Ah=2C sorry. I misunderstood. Sounds like we need a thread-local pragma > >> <*LOCAL*>? > >> > >> On 14 Sep 2010=2C at 08:59=2C Jay K wrote: > >> > >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > >> What language doesn't support heap allocation were they designed to suppo= > >rt? > >> It is because code often fails to pass all the parameters through all > >> functions. > >> > >> Again the best current answer is: > >> #ifdefed C that uses pthread_get/setspecific / Win32 > >> TlsAlloc/GetValue/SetValue=2C ignoring user threads/OpenBSD. > >> > >> As well=2C you'd get very very far with merely: > >> #ifdef _WIN32 > >> __declspec(thread) > >> #else > >> __thread > >> #endif > >> > >> Those work adequately for many many purposes=2C are more efficient=2C muc= > >h > >> more convenient=2C and very portable. > >> I believe there is even an "official" C++ proposal along these lines. > >> > >> We could easily abstract this -- the first -- into Modula-3 and then > >> support it on user threads as well. > >> Can anyone propose something? > >> It has to go in m3core=2C as that is the only code that (is supposed to) > >> know which thread implementation is in use. > >> > >> - Jay > >> > >> > >> > From: darko at darko.org > >> > Date: Tue=2C 14 Sep 2010 05:34:59 -0700 > >> > To: hosking at cs.purdue.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] Per thread data > >> > > >> > That's the idea but each object can only call another object > >> allocated for the same thread=2C so it needs to find the currently > >> running thread's copy of the desired object. > >> > > >> > On 14/09/2010=2C at 5:08 AM=2C Tony Hosking wrote: > >> > > >> > > If they are truly private to each thread=2C then allocating them in > >> the heap while still not locking them would be adequate. Why not? > >> > > > >> > > On 14 Sep 2010=2C at 01:08=2C Darko wrote: > >> > > > >> > >> I have lots of objects that are implemented on the basis that no > >> calls on them can be re-entered=2C which also avoids the need for locking > >> them in a threaded environment=2C which is impractical. The result is > >> that I need one copy of each object in each thread. There is > >> approximately one allocated object per object type so space is not a > >> big issue. I'm looking at a small number of threads=2C probably maximum > >> two per processor core. With modern processors I'm assuming that a > >> linear search through a small array is actually quicker that a hash > >> table. > >> > >> > >> > >> On 13/09/2010=2C at 9:55 PM=2C Mika Nystrom wrote: > >> > >> > >> > >>> Darko writes: > >> > >>>> I need to have certain data structures allocated on a per thread > >> basis. =3D > >> > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() = > >to =3D > >> > >>>> index a list. Is there a better=2C more portable way of allocating > >> on a =3D > >> > >>>> per-thread basis? > >> > >>>> > >> > >>>> Cheers=2C > >> > >>>> Darko. > >> > >>> > >> > >>> In my experience what you suggest works just fine (remember to lock= > > the > >> > >>> doors=2C though!) But you can get disappointing performance on some > >> thread > >> > >>> implementations (ones that involve switching into supervisor mode m= > >ore > >> > >>> than necessary when accessing pthread structures). > >> > >>> > >> > >>> Generally speaking I avoid needing per-thread structures as much > >> as possible > >> > >>> and instead put what you need in the Closure and then pass > >> pointers around. > >> > >>> Of course you can mix the methods for a compromise between speed an= > >d > >> > >>> cluttered code... > >> > >>> > >> > >>> I think what you want is also not a list but a Table. > >> > >>> > >> > >>> Mika > >> > >> > >> > > > >> > > >> > > = From darko at darko.org Wed Sep 15 02:38:20 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 17:38:20 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, , <20100914045504.A62281A209C@async.async.caltech.edu>, , <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> Message-ID: <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable. I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that? On 14/09/2010, at 7:05 AM, Jay K wrote: > > Eh? Just one thread local for the entire process? I think not. > > More like: > > PROCEDURE AllocateThreadLocal(): INTEGER; > PROCEDURE GetThreadLocal(INTEGER):REFANY; > > PROCEDURE SetThreadLocal(INTEGER;REFANY); > > > or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. > The first set of names sounds better, the second "scales" better. > This seems like a constant dilemna. > > btw, important point I just remembered: unless you do extra work, > thread locals are hidden from the garbage collector. > > This is why the thread implementations seemingly store extra data. > The traced data is in globals, so the garbage collector can see them. > > - Jay > > ________________________________ >> From: darko at darko.org >> Date: Tue, 14 Sep 2010 06:13:26 -0700 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Per thread data >> >> I think a minimalist approach where you get to store and retrieve one >> traced reference per thread would do the trick. If people want more >> they can design their own abstraction on top of that. Maybe just add >> the following to the Thread interface: >> >> PROCEDURE GetPrivate(): REFANY; >> PROCEDURE SetPrivate(ref: REFANY); >> >> >> On 14/09/2010, at 5:59 AM, Jay K wrote: >> >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? >> What language doesn't support heap allocation were they designed to support? >> It is because code often fails to pass all the parameters through all >> functions. >> >> Again the best current answer is: >> #ifdefed C that uses pthread_get/setspecific / Win32 >> TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. >> >> As well, you'd get very very far with merely: >> #ifdef _WIN32 >> __declspec(thread) >> #else >> __thread >> #endif >> >> Those work adequately for many many purposes, are more efficient, much >> more convenient, and very portable. >> I believe there is even an "official" C++ proposal along these lines. >> >> We could easily abstract this -- the first -- into Modula-3 and then >> support it on user threads as well. >> Can anyone propose something? >> It has to go in m3core, as that is the only code that (is supposed to) >> know which thread implementation is in use. >> >> - Jay >> >> >>> From: darko at darko.org >>> Date: Tue, 14 Sep 2010 05:34:59 -0700 >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Per thread data >>> >>> That's the idea but each object can only call another object >> allocated for the same thread, so it needs to find the currently >> running thread's copy of the desired object. >>> >>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote: >>> >>>> If they are truly private to each thread, then allocating them in >> the heap while still not locking them would be adequate. Why not? >>>> >>>> On 14 Sep 2010, at 01:08, Darko wrote: >>>> >>>>> I have lots of objects that are implemented on the basis that no >> calls on them can be re-entered, which also avoids the need for locking >> them in a threaded environment, which is impractical. The result is >> that I need one copy of each object in each thread. There is >> approximately one allocated object per object type so space is not a >> big issue. I'm looking at a small number of threads, probably maximum >> two per processor core. With modern processors I'm assuming that a >> linear search through a small array is actually quicker that a hash >> table. >>>>> >>>>> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: >>>>> >>>>>> Darko writes: >>>>>>> I need to have certain data structures allocated on a per thread >> basis. = >>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >>>>>>> index a list. Is there a better, more portable way of allocating >> on a = >>>>>>> per-thread basis? >>>>>>> >>>>>>> Cheers, >>>>>>> Darko. >>>>>> >>>>>> In my experience what you suggest works just fine (remember to lock the >>>>>> doors, though!) But you can get disappointing performance on some >> thread >>>>>> implementations (ones that involve switching into supervisor mode more >>>>>> than necessary when accessing pthread structures). >>>>>> >>>>>> Generally speaking I avoid needing per-thread structures as much >> as possible >>>>>> and instead put what you need in the Closure and then pass >> pointers around. >>>>>> Of course you can mix the methods for a compromise between speed and >>>>>> cluttered code... >>>>>> >>>>>> I think what you want is also not a list but a Table. >>>>>> >>>>>> Mika >>>>> >>>> >>> >> > From jay.krell at cornell.edu Wed Sep 15 04:23:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Sep 2010 02:23:04 +0000 Subject: [M3devel] Per thread data In-Reply-To: <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, ,,<20100914045504.A62281A209C@async.async.caltech.edu>, ,,<458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, ,,, , , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org>, , <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> Message-ID: It's not a hash lookup. It is a direct array index. Disassemble kernel32!TlsGetValue. It's much cheaper than a hash lookup, much more expensive than reading a global or local. on Windows 7 x86: \bin\x86\cdb cmd 0:000> u kernel32!TlsGetValue kernel32!TlsGetValue: 750111cd ff2510080175 jmp dword ptr [kernel32!_imp__TlsGetValue (75010810)] 0:000> u poi(75010810) KERNELBASE!TlsGetValue: 76532c95 8bff mov edi,edi 76532c97 55 push ebp 76532c98 8bec mov ebp,esp 76532c9a 64a118000000 mov eax,dword ptr fs:[00000018h] ; get per thread data base 76532ca0 8b4d08 mov ecx,dword ptr [ebp+8] 76532ca3 83603400 and dword ptr [eax+34h],0 76532ca7 83f940 cmp ecx,40h ; compare index to 64 76532caa 7309 jae KERNELBASE!TlsGetValue+0x20 (76532cb5) ; if above, goto 76532cb5 76532cac 8b8488100e0000 mov eax,dword ptr [eax+ecx*4+0E10h] ; get the actual value 76532cb3 eb14 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end 76532cb5 81f940040000 cmp ecx,440h ; compare to 1088 76532cbb 7210 jb KERNELBASE!TlsGetValue+0x38 (76532ccd) if below, goto 76532ccd 76532cbd 680d0000c0 push 0C000000Dh ; invalid parameter 76532cc2 e86b390200 call KERNELBASE!BaseSetLastNTError (76556632) 76532cc7 33c0 xor eax,eax ; return 0 for failure or for TlsSetValue not called 76532cc9 5d pop ebp 76532cca c20400 ret 4 76532ccd 8b80940f0000 mov eax,dword ptr [eax+0F94h] ; get data base for values > 64 76532cd3 85c0 test eax,eax ; compare to null 76532cd5 74f0 je KERNELBASE!TlsGetValue+0x32 (76532cc7) ; if null, goto 76532cc7, which returns 0, this is if you have calls TlsAlloc but not TlsSetValue 76532cd7 8b848800ffffff mov eax,dword ptr [eax+ecx*4-100h] ; get the value for index > 64 (subtracting 64*4) 76532cde ebe9 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end But your proposal might be reasonable anyway. Except, wouldn't Thread.T have to be revealed in an .i3 file? - Jay > From: darko at darko.org > Date: Tue, 14 Sep 2010 17:38:20 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable. > > I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that? > > > On 14/09/2010, at 7:05 AM, Jay K wrote: > > > > > Eh? Just one thread local for the entire process? I think not. > > > > More like: > > > > PROCEDURE AllocateThreadLocal(): INTEGER; > > PROCEDURE GetThreadLocal(INTEGER):REFANY; > > > > PROCEDURE SetThreadLocal(INTEGER;REFANY); > > > > > > or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. > > The first set of names sounds better, the second "scales" better. > > This seems like a constant dilemna. > > > > btw, important point I just remembered: unless you do extra work, > > thread locals are hidden from the garbage collector. > > > > This is why the thread implementations seemingly store extra data. > > The traced data is in globals, so the garbage collector can see them. > > > > - Jay > > > > ________________________________ > >> From: darko at darko.org > >> Date: Tue, 14 Sep 2010 06:13:26 -0700 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Per thread data > >> > >> I think a minimalist approach where you get to store and retrieve one > >> traced reference per thread would do the trick. If people want more > >> they can design their own abstraction on top of that. Maybe just add > >> the following to the Thread interface: > >> > >> PROCEDURE GetPrivate(): REFANY; > >> PROCEDURE SetPrivate(ref: REFANY); > >> > >> > >> On 14/09/2010, at 5:59 AM, Jay K wrote: > >> > >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > >> What language doesn't support heap allocation were they designed to support? > >> It is because code often fails to pass all the parameters through all > >> functions. > >> > >> Again the best current answer is: > >> #ifdefed C that uses pthread_get/setspecific / Win32 > >> TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > >> > >> As well, you'd get very very far with merely: > >> #ifdef _WIN32 > >> __declspec(thread) > >> #else > >> __thread > >> #endif > >> > >> Those work adequately for many many purposes, are more efficient, much > >> more convenient, and very portable. > >> I believe there is even an "official" C++ proposal along these lines. > >> > >> We could easily abstract this -- the first -- into Modula-3 and then > >> support it on user threads as well. > >> Can anyone propose something? > >> It has to go in m3core, as that is the only code that (is supposed to) > >> know which thread implementation is in use. > >> > >> - Jay > >> > >> > >>> From: darko at darko.org > >>> Date: Tue, 14 Sep 2010 05:34:59 -0700 > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] Per thread data > >>> > >>> That's the idea but each object can only call another object > >> allocated for the same thread, so it needs to find the currently > >> running thread's copy of the desired object. > >>> > >>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > >>> > >>>> If they are truly private to each thread, then allocating them in > >> the heap while still not locking them would be adequate. Why not? > >>>> > >>>> On 14 Sep 2010, at 01:08, Darko wrote: > >>>> > >>>>> I have lots of objects that are implemented on the basis that no > >> calls on them can be re-entered, which also avoids the need for locking > >> them in a threaded environment, which is impractical. The result is > >> that I need one copy of each object in each thread. There is > >> approximately one allocated object per object type so space is not a > >> big issue. I'm looking at a small number of threads, probably maximum > >> two per processor core. With modern processors I'm assuming that a > >> linear search through a small array is actually quicker that a hash > >> table. > >>>>> > >>>>> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > >>>>> > >>>>>> Darko writes: > >>>>>>> I need to have certain data structures allocated on a per thread > >> basis. = > >>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > >>>>>>> index a list. Is there a better, more portable way of allocating > >> on a = > >>>>>>> per-thread basis? > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Darko. > >>>>>> > >>>>>> In my experience what you suggest works just fine (remember to lock the > >>>>>> doors, though!) But you can get disappointing performance on some > >> thread > >>>>>> implementations (ones that involve switching into supervisor mode more > >>>>>> than necessary when accessing pthread structures). > >>>>>> > >>>>>> Generally speaking I avoid needing per-thread structures as much > >> as possible > >>>>>> and instead put what you need in the Closure and then pass > >> pointers around. > >>>>>> Of course you can mix the methods for a compromise between speed and > >>>>>> cluttered code... > >>>>>> > >>>>>> I think what you want is also not a list but a Table. > >>>>>> > >>>>>> Mika > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Sep 15 05:00:34 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 20:00:34 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, , , <20100914045504.A62281A209C@async.async.caltech.edu>, , , <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , , , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org>, , <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> Message-ID: No, only the subtype has to be revealed. I think both approaches have their usefulness, the Get/Set is useful for libraries. On 14/09/2010, at 7:23 PM, Jay K wrote: > It's not a hash lookup. It is a direct array index. > Disassemble kernel32!TlsGetValue. > It's much cheaper than a hash lookup, much more expensive than reading a global or local. > > > on Windows 7 x86: > > \bin\x86\cdb cmd > 0:000> u kernel32!TlsGetValue > kernel32!TlsGetValue: > 750111cd ff2510080175 jmp dword ptr [kernel32!_imp__TlsGetValue (75010810)] > > 0:000> u poi(75010810) > KERNELBASE!TlsGetValue: > 76532c95 8bff mov edi,edi > 76532c97 55 push ebp > 76532c98 8bec mov ebp,esp > 76532c9a 64a118000000 mov eax,dword ptr fs:[00000018h] ; get per thread data base > 76532ca0 8b4d08 mov ecx,dword ptr [ebp+8] > 76532ca3 83603400 and dword ptr [eax+34h],0 > 76532ca7 83f940 cmp ecx,40h ; compare index to 64 > 76532caa 7309 jae KERNELBASE!TlsGetValue+0x20 (76532cb5) ; if above, goto 76532cb5 > 76532cac 8b8488100e0000 mov eax,dword ptr [eax+ecx*4+0E10h] ; get the actual value > 76532cb3 eb14 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end > 76532cb5 81f940040000 cmp ecx,440h ; compare to 1088 > 76532cbb 7210 jb KERNELBASE!TlsGetValue+0x38 (76532ccd) if below, goto 76532ccd > 76532cbd 680d0000c0 push 0C000000Dh ; invalid parameter > 76532cc2 e86b390200 call KERNELBASE!BaseSetLastNTError (76556632) > 76532cc7 33c0 xor eax,eax ; return 0 for failure or for TlsSetValue not called > 76532cc9 5d pop ebp > 76532cca c20400 ret 4 > 76532ccd 8b80940f0000 mov eax,dword ptr [eax+0F94h] ; get data base for values > 64 > 76532cd3 85c0 test eax,eax ; compare to null > 76532cd5 74f0 je KERNELBASE!TlsGetValue+0x32 (76532cc7) ; if null, goto 76532cc7, which returns 0, this is if you have calls TlsAlloc but not TlsSetValue > 76532cd7 8b848800ffffff mov eax,dword ptr [eax+ecx*4-100h] ; get the value for index > 64 (subtracting 64*4) > 76532cde ebe9 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end > > > > But your proposal might be reasonable anyway. > Except, wouldn't Thread.T have to be revealed in an .i3 file? > > > - Jay > > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 17:38:20 -0700 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable. > > > > I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that? > > > > > > On 14/09/2010, at 7:05 AM, Jay K wrote: > > > > > > > > Eh? Just one thread local for the entire process? I think not. > > > > > > More like: > > > > > > PROCEDURE AllocateThreadLocal(): INTEGER; > > > PROCEDURE GetThreadLocal(INTEGER):REFANY; > > > > > > PROCEDURE SetThreadLocal(INTEGER;REFANY); > > > > > > > > > or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. > > > The first set of names sounds better, the second "scales" better. > > > This seems like a constant dilemna. > > > > > > btw, important point I just remembered: unless you do extra work, > > > thread locals are hidden from the garbage collector. > > > > > > This is why the thread implementations seemingly store extra data. > > > The traced data is in globals, so the garbage collector can see them. > > > > > > - Jay > > > > > > ________________________________ > > >> From: darko at darko.org > > >> Date: Tue, 14 Sep 2010 06:13:26 -0700 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] Per thread data > > >> > > >> I think a minimalist approach where you get to store and retrieve one > > >> traced reference per thread would do the trick. If people want more > > >> they can design their own abstraction on top of that. Maybe just add > > >> the following to the Thread interface: > > >> > > >> PROCEDURE GetPrivate(): REFANY; > > >> PROCEDURE SetPrivate(ref: REFANY); > > >> > > >> > > >> On 14/09/2010, at 5:59 AM, Jay K wrote: > > >> > > >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > > >> What language doesn't support heap allocation were they designed to support? > > >> It is because code often fails to pass all the parameters through all > > >> functions. > > >> > > >> Again the best current answer is: > > >> #ifdefed C that uses pthread_get/setspecific / Win32 > > >> TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > >> > > >> As well, you'd get very very far with merely: > > >> #ifdef _WIN32 > > >> __declspec(thread) > > >> #else > > >> __thread > > >> #endif > > >> > > >> Those work adequately for many many purposes, are more efficient, much > > >> more convenient, and very portable. > > >> I believe there is even an "official" C++ proposal along these lines. > > >> > > >> We could easily abstract this -- the first -- into Modula-3 and then > > >> support it on user threads as well. > > >> Can anyone propose something? > > >> It has to go in m3core, as that is the only code that (is supposed to) > > >> know which thread implementation is in use. > > >> > > >> - Jay > > >> > > >> > > >>> From: darko at darko.org > > >>> Date: Tue, 14 Sep 2010 05:34:59 -0700 > > >>> To: hosking at cs.purdue.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] Per thread data > > >>> > > >>> That's the idea but each object can only call another object > > >> allocated for the same thread, so it needs to find the currently > > >> running thread's copy of the desired object. > > >>> > > >>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > >>> > > >>>> If they are truly private to each thread, then allocating them in > > >> the heap while still not locking them would be adequate. Why not? > > >>>> > > >>>> On 14 Sep 2010, at 01:08, Darko wrote: > > >>>> > > >>>>> I have lots of objects that are implemented on the basis that no > > >> calls on them can be re-entered, which also avoids the need for locking > > >> them in a threaded environment, which is impractical. The result is > > >> that I need one copy of each object in each thread. There is > > >> approximately one allocated object per object type so space is not a > > >> big issue. I'm looking at a small number of threads, probably maximum > > >> two per processor core. With modern processors I'm assuming that a > > >> linear search through a small array is actually quicker that a hash > > >> table. > > >>>>> > > >>>>> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >>>>> > > >>>>>> Darko writes: > > >>>>>>> I need to have certain data structures allocated on a per thread > > >> basis. = > > >>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>>>>> index a list. Is there a better, more portable way of allocating > > >> on a = > > >>>>>>> per-thread basis? > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> Darko. > > >>>>>> > > >>>>>> In my experience what you suggest works just fine (remember to lock the > > >>>>>> doors, though!) But you can get disappointing performance on some > > >> thread > > >>>>>> implementations (ones that involve switching into supervisor mode more > > >>>>>> than necessary when accessing pthread structures). > > >>>>>> > > >>>>>> Generally speaking I avoid needing per-thread structures as much > > >> as possible > > >>>>>> and instead put what you need in the Closure and then pass > > >> pointers around. > > >>>>>> Of course you can mix the methods for a compromise between speed and > > >>>>>> cluttered code... > > >>>>>> > > >>>>>> I think what you want is also not a list but a Table. > > >>>>>> > > >>>>>> Mika > > >>>>> > > >>>> > > >>> > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 15 14:59:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Sep 2010 12:59:17 +0000 Subject: [M3devel] uid == 0? Message-ID: It'd be super convenient if uid == 0 was invalid. But then, whey is NO_UID = 0xFFFFFFFF? You know, I recently introduced: typedef struct GTY(()) m3type { ? unsigned long id; ? tree GTY(()) t; } m3type_t; I think it might be useful to flesh this out a bunch, like: typedef struct GTY(()) m3type { ? unsigned long id; ? tree GTY(()) t; ? /* conceptually a union */ ? unsigned is_packed : 1; ? unsigned is_record : 1; ? unsigned is_enum : 1; ? unsigned is_object : 1; ? struct ? { ??? unsigned size; ??? unsigned long target_id; ? } packed; } m3type_t; or: typedef struct GTY(()) m3type { ? unsigned long id; ? tree GTY(()) t; ? /* conceptually a union */ ??? unsigned packed_size; (* or zero *) ??? unsigned long packed_target_id; (* or zero *) } m3type_t; ?- I think t will often have this information, but not always, like how to discern object from record? ?? Maybe it doesn't matter? ?- the gcc garbage collector might require more annotations for unions and I'd rather defer that ?- but there will be many of these (thousands?) ?- I'm lately a non-fan of bitfields in C, because I can't predict the layout easily. ?- Jay From jay.krell at cornell.edu Tue Sep 21 16:19:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Sep 2010 14:19:34 +0000 Subject: [M3devel] Hudson seems down. Message-ID: http://hudson.modula3.com:8080 ? Not that I doing much lately.. ?- Jay From kay.haeusler at elego.de Tue Sep 21 16:31:15 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Tue, 21 Sep 2010 16:31:15 +0200 Subject: [M3devel] Hudson seems down. In-Reply-To: References: Message-ID: <20100921163115.1722aba8@linden.elego.de> Hello Jay Jay K wrote: > http://hudson.modula3.com:8080 > > ? > > Not that I doing much lately.. I've restarted hudson -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From kay.haeusler at elego.de Tue Sep 21 16:38:27 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Tue, 21 Sep 2010 16:38:27 +0200 Subject: [M3devel] Hudson seems down. In-Reply-To: <20100921163115.1722aba8@linden.elego.de> References: <20100921163115.1722aba8@linden.elego.de> Message-ID: <20100921163827.5acb0e65@linden.elego.de> Kay H?usler wrote: > > http://hudson.modula3.com:8080 > > > > ? > > > > Not that I doing much lately.. > > I've restarted hudson Hudson is back -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jay.krell at cornell.edu Sat Sep 25 11:35:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Sep 2010 09:35:12 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix Message-ID: PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = ? (* LL = m *) ? VAR self := GetActivation(); ? BEGIN ??? IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; ??? IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; ??? XWait(m, c, self, alertable := TRUE); ? END AlertWait; The pthread code doesn't have the check for NIL and call to Die. Nor for that matter, the uses of ThreadDebug -- which I added. I think these should be more similar. What I was really wondering about, again, is more common code between Win32 and Posix in the thread code... ?- Jay From jay.krell at cornell.edu Sat Sep 25 12:47:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Sep 2010 10:47:56 +0000 Subject: [M3devel] uid to string conversion? (probably answered my own question) Message-ID: static void fmt_uid (unsigned long x, char *buf) { ? unsigned i = UID_SIZE; ? static const char alphabet[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; ? gcc_assert (sizeof(alphabet) == 63); ? if (x == NO_UID) ? { ??? static const char zzzzzz[] = "zzzzzz"; ??? memcpy (buf, zzzzzz, sizeof(zzzzzz)); ??? return; ? } ? buf[i] = 0; ? while (i) ? { ??? buf[--i] = alphabet[x % 62]; ??? x /= 62; ? } ? if (x || buf[0] < 'A' || buf[0] > 'Z') ??? fatal_error (" *** bad uid -> identifier conversion!!"); } 1) what guarantees buf[0] is valid, in that last chunk? Is it because uids have a limited range and they'd have to be too large to fail there? Because 62^6 is larger than 2^32? 2) The check is too tight anyway? It should allow also lowercase a-z? 1) I guess so: #include #include unsigned multu32(unsigned a, unsigned b) { ? unsigned long long c = (a * (unsigned long long)b); ? if (c != (unsigned)c) /* or ? if (c > ~(unsigned)0) */ ? { ??? printf("overflow %u * %u; %x * %x\n", a, b, a, b); ??? exit(0); ? } ? return c; } int main() { unsigned a = 1; unsigned i = { 0 }; for (; i < 20; ++i) { ? printf("%u: %u %x\n", i, a, a); ? a = multu32(a, 62); } return 0; } jbook2:p248 jay$ gcc 1.c jbook2:p248 jay$ ./a.out 0: 1 1 1: 62 3e 2: 3844 f04 3: 238328 3a2f8 4: 14776336 e17810 5: 916132832 369b13e0 overflow 916132832 * 62; 369b13e0 * 3e ?- Jay From dragisha at m3w.org Sat Sep 25 13:41:19 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Sep 2010 13:41:19 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? Message-ID: <1285414879.3024.0.camel@boromir.m3w.org> Anybody working UI's with Trestle? It is mapped no native widgets on Windows? What about Mac? -- Dragi?a Duri? From jay.krell at cornell.edu Sat Sep 25 14:31:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Sep 2010 12:31:18 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285414879.3024.0.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org> Message-ID: It draws all the controls itself. The Mac version is the X Windows version. ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sat, 25 Sep 2010 13:41:19 +0200 > Subject: [M3devel] UI, Trestle, native... Cocoa?? > > Anybody working UI's with Trestle? It is mapped no native widgets on > Windows? What about Mac? > -- > Dragi?a Duri? > From hosking at cs.purdue.edu Sat Sep 25 16:32:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Sep 2010 10:32:21 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: Message-ID: <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> Is it ok in the WIn32 implementation for the thread to be native. I think it is ok for pthread. On 25 Sep 2010, at 05:35, Jay K wrote: > > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > (* LL = m *) > VAR self := GetActivation(); > BEGIN > IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > XWait(m, c, self, alertable := TRUE); > END AlertWait; > > > The pthread code doesn't have the check for NIL and call to Die. > Nor for that matter, the uses of ThreadDebug -- which I added. > > I think these should be more similar. > > What I was really wondering about, again, is more common code between Win32 and Posix > in the thread code... > > - Jay > From dragisha at m3w.org Sat Sep 25 22:42:07 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Sep 2010 22:42:07 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org> Message-ID: <1285447327.3009.0.camel@boromir.m3w.org> Is it feasible to make it mora native to Mac? Interesting? On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: > It draws all the controls itself. > The Mac version is the X Windows version. > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Sat, 25 Sep 2010 13:41:19 +0200 > > Subject: [M3devel] UI, Trestle, native... Cocoa?? > > > > Anybody working UI's with Trestle? It is mapped no native widgets on > > Windows? What about Mac? > > -- > > Dragi?a Duri? > > > -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 26 13:45:53 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 26 Sep 2010 13:45:53 +0200 Subject: [M3devel] windows devel, howto? Message-ID: <1285501553.3009.2.camel@boromir.m3w.org> I see msvc 9.0 is requirement, but MS offers only latest and greatest 2010? Can someone spare few moments to coach me to Win Modula-3? :) TIA -- Dragi?a Duri? From jay.krell at cornell.edu Sun Sep 26 14:11:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 12:11:49 +0000 Subject: [M3devel] windows devel, howto? In-Reply-To: <1285501553.3009.2.camel@boromir.m3w.org> References: <1285501553.3009.2.camel@boromir.m3w.org> Message-ID: We don't require any particular version. I have tested with many, almost every single version from 2.0 though 9.0. 2008 is still available. http://www.microsoft.com/express/Downloads/ ?besides www.ebay.com And ./boot1.py has "special" support for Windows -- you can build a useful cross archive from Posix or whatever and then compiler the C and link on Windows. It even produces a nice little Makefile for Windows. ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 26 Sep 2010 13:45:53 +0200 > Subject: [M3devel] windows devel, howto? > > I see msvc 9.0 is requirement, but MS offers only latest and greatest > 2010? > > Can someone spare few moments to coach me to Win Modula-3? :) > > TIA > -- > Dragi?a Duri? > From jay.krell at cornell.edu Sun Sep 26 14:21:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 12:21:51 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> References: , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> Message-ID: I think it is problematic in both. If I understand you. The thread locals could be allocated on-demand which might address some situations. Though that can also fail. A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). ? That even allows you to fail (due to low memory). However that doesn't work as well as one might hope. In particular, any number of threads can be created before a particular .dll is loaded. And a .dll can be unloaded while the threads still exist -- making also thread detach not so ideal for freeing. What you have to do is: ? - be willing to allocate on demand? ? - have some story for failure ? - track all the thread locals through a global (!) and free them in thread/process detach ?? (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; ?? there is a parameter that distinguishes them; best to do nothing, quickly in ?? the ExitProcess). Best really really really really best to avoid thread locals. But that is probably impossible. Cygwin does wacky stuff where it puts its thread locals at the top of the stack. Which doesn't solve the problems. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 25 Sep 2010 10:32:21 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > Is it ok in the WIn32 implementation for the thread to be native. > I think it is ok for pthread. > > On 25 Sep 2010, at 05:35, Jay K wrote: > > > > > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > > (* LL = m *) > > VAR self := GetActivation(); > > BEGIN > > IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > > IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > > XWait(m, c, self, alertable := TRUE); > > END AlertWait; > > > > > > The pthread code doesn't have the check for NIL and call to Die. > > Nor for that matter, the uses of ThreadDebug -- which I added. > > > > I think these should be more similar. > > > > What I was really wondering about, again, is more common code between Win32 and Posix > > in the thread code... > > > > - Jay > > > From hosking at cs.purdue.edu Sun Sep 26 15:13:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Sep 2010 09:13:09 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> Message-ID: <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? On 26 Sep 2010, at 08:21, Jay K wrote: > > I think it is problematic in both. > If I understand you. > > > The thread locals could be allocated on-demand which might > address some situations. Though that can also fail. > > > A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > That even allows you to fail (due to low memory). > However that doesn't work as well as one might hope. > In particular, any number of threads can be created before a particular .dll is loaded. > And a .dll can be unloaded while the threads still exist -- making also thread detach > not so ideal for freeing. What you have to do is: > - be willing to allocate on demand > - have some story for failure > - track all the thread locals through a global (!) and free them in thread/process detach > (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > there is a parameter that distinguishes them; best to do nothing, quickly in > the ExitProcess). > > > Best really really really really best to avoid thread locals. > But that is probably impossible. > > > Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > Which doesn't solve the problems. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 25 Sep 2010 10:32:21 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >> >> Is it ok in the WIn32 implementation for the thread to be native. >> I think it is ok for pthread. >> >> On 25 Sep 2010, at 05:35, Jay K wrote: >> >>> >>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = >>> (* LL = m *) >>> VAR self := GetActivation(); >>> BEGIN >>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; >>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; >>> XWait(m, c, self, alertable := TRUE); >>> END AlertWait; >>> >>> >>> The pthread code doesn't have the check for NIL and call to Die. >>> Nor for that matter, the uses of ThreadDebug -- which I added. >>> >>> I think these should be more similar. >>> >>> What I was really wondering about, again, is more common code between Win32 and Posix >>> in the thread code... >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Sun Sep 26 15:51:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 13:51:22 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> References: , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> Message-ID: What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 26 Sep 2010 09:13:09 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? > > On 26 Sep 2010, at 08:21, Jay K wrote: > > > > > I think it is problematic in both. > > If I understand you. > > > > > > The thread locals could be allocated on-demand which might > > address some situations. Though that can also fail. > > > > > > A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > > That even allows you to fail (due to low memory). > > However that doesn't work as well as one might hope. > > In particular, any number of threads can be created before a particular .dll is loaded. > > And a .dll can be unloaded while the threads still exist -- making also thread detach > > not so ideal for freeing. What you have to do is: > > - be willing to allocate on demand > > - have some story for failure > > - track all the thread locals through a global (!) and free them in thread/process detach > > (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > > there is a parameter that distinguishes them; best to do nothing, quickly in > > the ExitProcess). > > > > > > Best really really really really best to avoid thread locals. > > But that is probably impossible. > > > > > > Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > > Which doesn't solve the problems. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 25 Sep 2010 10:32:21 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >> > >> Is it ok in the WIn32 implementation for the thread to be native. > >> I think it is ok for pthread. > >> > >> On 25 Sep 2010, at 05:35, Jay K wrote: > >> > >>> > >>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > >>> (* LL = m *) > >>> VAR self := GetActivation(); > >>> BEGIN > >>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > >>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > >>> XWait(m, c, self, alertable := TRUE); > >>> END AlertWait; > >>> > >>> > >>> The pthread code doesn't have the check for NIL and call to Die. > >>> Nor for that matter, the uses of ThreadDebug -- which I added. > >>> > >>> I think these should be more similar. > >>> > >>> What I was really wondering about, again, is more common code between Win32 and Posix > >>> in the thread code... > >>> > >>> - Jay > >>> > >> > > > From hosking at cs.purdue.edu Sun Sep 26 15:56:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Sep 2010 09:56:29 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> Message-ID: <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. On 26 Sep 2010, at 09:51, Jay K wrote: > > What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 26 Sep 2010 09:13:09 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >> >> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? >> >> On 26 Sep 2010, at 08:21, Jay K wrote: >> >>> >>> I think it is problematic in both. >>> If I understand you. >>> >>> >>> The thread locals could be allocated on-demand which might >>> address some situations. Though that can also fail. >>> >>> >>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). >>> That even allows you to fail (due to low memory). >>> However that doesn't work as well as one might hope. >>> In particular, any number of threads can be created before a particular .dll is loaded. >>> And a .dll can be unloaded while the threads still exist -- making also thread detach >>> not so ideal for freeing. What you have to do is: >>> - be willing to allocate on demand >>> - have some story for failure >>> - track all the thread locals through a global (!) and free them in thread/process detach >>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; >>> there is a parameter that distinguishes them; best to do nothing, quickly in >>> the ExitProcess). >>> >>> >>> Best really really really really best to avoid thread locals. >>> But that is probably impossible. >>> >>> >>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. >>> Which doesn't solve the problems. >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>> >>>> Is it ok in the WIn32 implementation for the thread to be native. >>>> I think it is ok for pthread. >>>> >>>> On 25 Sep 2010, at 05:35, Jay K wrote: >>>> >>>>> >>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = >>>>> (* LL = m *) >>>>> VAR self := GetActivation(); >>>>> BEGIN >>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; >>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; >>>>> XWait(m, c, self, alertable := TRUE); >>>>> END AlertWait; >>>>> >>>>> >>>>> The pthread code doesn't have the check for NIL and call to Die. >>>>> Nor for that matter, the uses of ThreadDebug -- which I added. >>>>> >>>>> I think these should be more similar. >>>>> >>>>> What I was really wondering about, again, is more common code between Win32 and Posix >>>>> in the thread code... >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Sep 26 15:59:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 13:59:11 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu> References: , , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , , , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu>, , <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu> Message-ID: Understood -- that is seemingly the point of the Win32 checks. Should they be present on Posix then too? Merely hitting "TRY" I expect would access violate. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 26 Sep 2010 09:56:29 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. > > On 26 Sep 2010, at 09:51, Jay K wrote: > > > > > What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 26 Sep 2010 09:13:09 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >> > >> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? > >> > >> On 26 Sep 2010, at 08:21, Jay K wrote: > >> > >>> > >>> I think it is problematic in both. > >>> If I understand you. > >>> > >>> > >>> The thread locals could be allocated on-demand which might > >>> address some situations. Though that can also fail. > >>> > >>> > >>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > >>> That even allows you to fail (due to low memory). > >>> However that doesn't work as well as one might hope. > >>> In particular, any number of threads can be created before a particular .dll is loaded. > >>> And a .dll can be unloaded while the threads still exist -- making also thread detach > >>> not so ideal for freeing. What you have to do is: > >>> - be willing to allocate on demand > >>> - have some story for failure > >>> - track all the thread locals through a global (!) and free them in thread/process detach > >>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > >>> there is a parameter that distinguishes them; best to do nothing, quickly in > >>> the ExitProcess). > >>> > >>> > >>> Best really really really really best to avoid thread locals. > >>> But that is probably impossible. > >>> > >>> > >>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > >>> Which doesn't solve the problems. > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >>>> > >>>> Is it ok in the WIn32 implementation for the thread to be native. > >>>> I think it is ok for pthread. > >>>> > >>>> On 25 Sep 2010, at 05:35, Jay K wrote: > >>>> > >>>>> > >>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > >>>>> (* LL = m *) > >>>>> VAR self := GetActivation(); > >>>>> BEGIN > >>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > >>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > >>>>> XWait(m, c, self, alertable := TRUE); > >>>>> END AlertWait; > >>>>> > >>>>> > >>>>> The pthread code doesn't have the check for NIL and call to Die. > >>>>> Nor for that matter, the uses of ThreadDebug -- which I added. > >>>>> > >>>>> I think these should be more similar. > >>>>> > >>>>> What I was really wondering about, again, is more common code between Win32 and Posix > >>>>> in the thread code... > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > From hosking at cs.purdue.edu Sun Sep 26 16:20:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Sep 2010 10:20:27 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , , , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu>, , <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu> Message-ID: We don't need the checks. If someone calls from native threads to M3 threads they are programming "UNSAFE"ly anyway, and will have to pay the piper. We could consider an UNSAFE interface that allows native threads to register themselves for GC, etc. But this would only be for super-hackers. On 26 Sep 2010, at 09:59, Jay K wrote: > > Understood -- that is seemingly the point of the Win32 checks. Should they be present on Posix then too? > > Merely hitting "TRY" I expect would access violate. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 26 Sep 2010 09:56:29 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >> >> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. >> >> On 26 Sep 2010, at 09:51, Jay K wrote: >> >>> >>> What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sun, 26 Sep 2010 09:13:09 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>> >>>> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? >>>> >>>> On 26 Sep 2010, at 08:21, Jay K wrote: >>>> >>>>> >>>>> I think it is problematic in both. >>>>> If I understand you. >>>>> >>>>> >>>>> The thread locals could be allocated on-demand which might >>>>> address some situations. Though that can also fail. >>>>> >>>>> >>>>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). >>>>> That even allows you to fail (due to low memory). >>>>> However that doesn't work as well as one might hope. >>>>> In particular, any number of threads can be created before a particular .dll is loaded. >>>>> And a .dll can be unloaded while the threads still exist -- making also thread detach >>>>> not so ideal for freeing. What you have to do is: >>>>> - be willing to allocate on demand >>>>> - have some story for failure >>>>> - track all the thread locals through a global (!) and free them in thread/process detach >>>>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; >>>>> there is a parameter that distinguishes them; best to do nothing, quickly in >>>>> the ExitProcess). >>>>> >>>>> >>>>> Best really really really really best to avoid thread locals. >>>>> But that is probably impossible. >>>>> >>>>> >>>>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. >>>>> Which doesn't solve the problems. >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>>>> >>>>>> Is it ok in the WIn32 implementation for the thread to be native. >>>>>> I think it is ok for pthread. >>>>>> >>>>>> On 25 Sep 2010, at 05:35, Jay K wrote: >>>>>> >>>>>>> >>>>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = >>>>>>> (* LL = m *) >>>>>>> VAR self := GetActivation(); >>>>>>> BEGIN >>>>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; >>>>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; >>>>>>> XWait(m, c, self, alertable := TRUE); >>>>>>> END AlertWait; >>>>>>> >>>>>>> >>>>>>> The pthread code doesn't have the check for NIL and call to Die. >>>>>>> Nor for that matter, the uses of ThreadDebug -- which I added. >>>>>>> >>>>>>> I think these should be more similar. >>>>>>> >>>>>>> What I was really wondering about, again, is more common code between Win32 and Posix >>>>>>> in the thread code... >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>> >>>>> >>>> >>> >> > From jay.krell at cornell.edu Sun Sep 26 16:36:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 14:36:43 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , , ,,<2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, ,,, , , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu>, , , , <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu>, , Message-ID: ok --- so we should remove the checks on Win32 then? I'd like the two or perhaps all three thread implementations to look more similar. Thanks, ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 26 Sep 2010 10:20:27 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > We don't need the checks. If someone calls from native threads to M3 threads they are programming "UNSAFE"ly anyway, and will have to pay the piper. We could consider an UNSAFE interface that allows native threads to register themselves for GC, etc. But this would only be for super-hackers. > > On 26 Sep 2010, at 09:59, Jay K wrote: > > > > > Understood -- that is seemingly the point of the Win32 checks. Should they be present on Posix then too? > > > > Merely hitting "TRY" I expect would access violate. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 26 Sep 2010 09:56:29 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >> > >> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. > >> > >> On 26 Sep 2010, at 09:51, Jay K wrote: > >> > >>> > >>> What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Sun, 26 Sep 2010 09:13:09 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >>>> > >>>> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? > >>>> > >>>> On 26 Sep 2010, at 08:21, Jay K wrote: > >>>> > >>>>> > >>>>> I think it is problematic in both. > >>>>> If I understand you. > >>>>> > >>>>> > >>>>> The thread locals could be allocated on-demand which might > >>>>> address some situations. Though that can also fail. > >>>>> > >>>>> > >>>>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > >>>>> That even allows you to fail (due to low memory). > >>>>> However that doesn't work as well as one might hope. > >>>>> In particular, any number of threads can be created before a particular .dll is loaded. > >>>>> And a .dll can be unloaded while the threads still exist -- making also thread detach > >>>>> not so ideal for freeing. What you have to do is: > >>>>> - be willing to allocate on demand > >>>>> - have some story for failure > >>>>> - track all the thread locals through a global (!) and free them in thread/process detach > >>>>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > >>>>> there is a parameter that distinguishes them; best to do nothing, quickly in > >>>>> the ExitProcess). > >>>>> > >>>>> > >>>>> Best really really really really best to avoid thread locals. > >>>>> But that is probably impossible. > >>>>> > >>>>> > >>>>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > >>>>> Which doesn't solve the problems. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >>>>>> > >>>>>> Is it ok in the WIn32 implementation for the thread to be native. > >>>>>> I think it is ok for pthread. > >>>>>> > >>>>>> On 25 Sep 2010, at 05:35, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > >>>>>>> (* LL = m *) > >>>>>>> VAR self := GetActivation(); > >>>>>>> BEGIN > >>>>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > >>>>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > >>>>>>> XWait(m, c, self, alertable := TRUE); > >>>>>>> END AlertWait; > >>>>>>> > >>>>>>> > >>>>>>> The pthread code doesn't have the check for NIL and call to Die. > >>>>>>> Nor for that matter, the uses of ThreadDebug -- which I added. > >>>>>>> > >>>>>>> I think these should be more similar. > >>>>>>> > >>>>>>> What I was really wondering about, again, is more common code between Win32 and Posix > >>>>>>> in the thread code... > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Sep 27 05:26:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Sep 2010 03:26:22 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , , ,,<2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, ,,, , , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu>, , , , <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu>, , Message-ID: Tony, I don't know, but sometimes I think you are too unforgiving of unsafe code. I guess in this case though it will null deref soon enough, and that is highly similar to anything else we might do. I have another take on things, not easy to achieve currently. That is, I should be able to write "some" program, any program, in C or C++, with an "extensibility model" -- where it can load .dlls discovered through some mechanism, not know that initial authoring/compile/link-time, and those .dlls should work whether they use C and/or C++ and/or Modula-3. I should be able to create threads using the native Win32 CreateThread or pthread_create. I shouldn't have to call Modula-3's Thread.Fork. This reality already exists for C and C++. But it isn't easy to achieve for Modula-3. Currently we basically divide the world between Modula-3 code and other code. They don't interact as well as they should. At least not in both directions. I can call C from Modula-3 just fine and use C/C++ on Modula-3 threads. But not the other way around. (There is an indication of a counterpoint, the existance of _beginthread/_beginthreadex suggests that C has the same problem, that native CreateThread won't do there either, but this is almost entirely false. _beginthread has no advantage over CreateThread if the caller is a .dll or if it uses the C runtime in a .dll, as the C runtime manages its thread locals in DllMain and on-demand. It makes some difference if you use the static C runtime (which is discouraged) and are in an .exe.) Partly I'm alluding to two different design principles: sort of more static, monolithic, where more stuff is known at build-time Every initialization function called from a central place that knows to coordinate and knows what call to call. vs. a more distributed dynamic construction where anyone can declare they have initialization and it discovered and called as needed In reality these are kind of the same. It's just that on both Windows and all/most Posix systems there already exists a central dynamic mechanism available to C and Modula-3, but Modula-3 doesn't use it. Specifically on Windows this is DllMain. C++ has these things, globals with constructors/destructors. You can have them in a .dll. They tie into DllMain. C++ has these everywhere and the problem is solved some way everywhere. I believe typical ELF systems use .init/.fini ELF sections, similar to how C++ constructors/destructors work -- section is an array of pointers that some special code knows to call at the right time. Very possible Modula-3 should use these mechanisms. However it is somewhat of a portability nightmare. By doing things itsself, Modula-3 gets *almost* as good functionality, with one portable implementation. Kind of like the $ORIGIN stuff. - Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 26 Sep 2010 10:20:27 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > We don't need the checks. If someone calls from native threads to M3 threads they are programming "UNSAFE"ly anyway, and will have to pay the piper. We could consider an UNSAFE interface that allows native threads to register themselves for GC, etc. But this would only be for super-hackers. > > On 26 Sep 2010, at 09:59, Jay K wrote: > > > > > Understood -- that is seemingly the point of the Win32 checks. Should they be present on Posix then too? > > > > Merely hitting "TRY" I expect would access violate. > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sun, 26 Sep 2010 09:56:29 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >> > >> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. > >> > >> On 26 Sep 2010, at 09:51, Jay K wrote: > >> > >>> > >>> What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Sun, 26 Sep 2010 09:13:09 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >>>> > >>>> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? > >>>> > >>>> On 26 Sep 2010, at 08:21, Jay K wrote: > >>>> > >>>>> > >>>>> I think it is problematic in both. > >>>>> If I understand you. > >>>>> > >>>>> > >>>>> The thread locals could be allocated on-demand which might > >>>>> address some situations. Though that can also fail. > >>>>> > >>>>> > >>>>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > >>>>> That even allows you to fail (due to low memory). > >>>>> However that doesn't work as well as one might hope. > >>>>> In particular, any number of threads can be created before a particular .dll is loaded. > >>>>> And a .dll can be unloaded while the threads still exist -- making also thread detach > >>>>> not so ideal for freeing. What you have to do is: > >>>>> - be willing to allocate on demand > >>>>> - have some story for failure > >>>>> - track all the thread locals through a global (!) and free them in thread/process detach > >>>>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > >>>>> there is a parameter that distinguishes them; best to do nothing, quickly in > >>>>> the ExitProcess). > >>>>> > >>>>> > >>>>> Best really really really really best to avoid thread locals. > >>>>> But that is probably impossible. > >>>>> > >>>>> > >>>>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > >>>>> Which doesn't solve the problems. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: hosking at cs.purdue.edu > >>>>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 > >>>>>> To: jay.krell at cornell.edu > >>>>>> CC: m3devel at elegosoft.com > >>>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >>>>>> > >>>>>> Is it ok in the WIn32 implementation for the thread to be native. > >>>>>> I think it is ok for pthread. > >>>>>> > >>>>>> On 25 Sep 2010, at 05:35, Jay K wrote: > >>>>>> > >>>>>>> > >>>>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > >>>>>>> (* LL = m *) > >>>>>>> VAR self := GetActivation(); > >>>>>>> BEGIN > >>>>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > >>>>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > >>>>>>> XWait(m, c, self, alertable := TRUE); > >>>>>>> END AlertWait; > >>>>>>> > >>>>>>> > >>>>>>> The pthread code doesn't have the check for NIL and call to Die. > >>>>>>> Nor for that matter, the uses of ThreadDebug -- which I added. > >>>>>>> > >>>>>>> I think these should be more similar. > >>>>>>> > >>>>>>> What I was really wondering about, again, is more common code between Win32 and Posix > >>>>>>> in the thread code... > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > From jay.krell at cornell.edu Mon Sep 27 14:49:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Sep 2010 12:49:59 +0000 Subject: [M3devel] enums in gdb Message-ID: finally! Main__FR1 (r=0x33054, t=0x33056) at Main.m3:29 29??? ? c := Color.Red; (gdb) 30??? ? c := Color.Orange; (gdb) p c $7 = Red (gdb) n 31??? ? c := Color.Green; (gdb) p c $8 = Orange (gdb) n 32??? ? c := Color.Blue; (gdb) p c $9 = Green (gdb) n 33??? ? c := Color.Indigo; (gdb) p c $10 = Blue (gdb) n 34??? ? c := Color.Violet; (gdb) p c $11 = Indigo (gdb) n 35??? ? r := 2; (gdb) p c $12 = Violet more testing and commit soon. And I'll try to make the names more fully qualified. Note there are scoping issues as well.. but still, progress. ?- Jay From hosking at cs.purdue.edu Mon Sep 27 17:48:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Sep 2010 11:48:35 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , , , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , , , , , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu>, , , , <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu>, , Message-ID: <9A6616C8-9F84-4B26-A416-19DE14B9C9F4@cs.purdue.edu> HI Jay, Sorry, I didn't mean to sound deprecating about interoperability with native threads. The only thing really needed is a contract that when a native thread calls into Modula-3 code that it must first register with the Modula-3 runtime so that the collector knows about it and can cope with any traced references it holds. As I noted, this should be a simple API addition to register the native thread. With respect to run-time module loading and initialisation from native code, we already have all the necessary machinery for that. 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 26 Sep 2010, at 23:26, Jay K wrote: > > Tony, I don't know, but sometimes I think you are too unforgiving of unsafe code. > I guess in this case though it will null deref soon enough, and that is highly similar to anything else we might do. > > > I have another take on things, not easy to achieve currently. > > > That is, I should be able to write "some" program, any program, in C or C++, with an "extensibility model" -- where it can load .dlls discovered through some mechanism, not know that initial authoring/compile/link-time, and those .dlls should work whether they use C and/or C++ and/or Modula-3. > > > I should be able to create threads using the native Win32 CreateThread or pthread_create. > I shouldn't have to call Modula-3's Thread.Fork. > > > This reality already exists for C and C++. > But it isn't easy to achieve for Modula-3. > Currently we basically divide the world between Modula-3 code and other code. > They don't interact as well as they should. > At least not in both directions. > I can call C from Modula-3 just fine and use C/C++ on Modula-3 threads. > But not the other way around. > > > (There is an indication of a counterpoint, the existance of _beginthread/_beginthreadex suggests that C has the same problem, that native CreateThread won't do there either, but this is almost entirely false. _beginthread has no advantage over CreateThread if the caller is a .dll or if it uses the C runtime in a .dll, as the C runtime manages its thread locals in DllMain and on-demand. It makes some difference if you use the static C runtime (which is discouraged) and are in an .exe.) > > > Partly I'm alluding to two different design principles: > sort of more static, monolithic, where more stuff is known at build-time > Every initialization function called from a central place that knows to coordinate and knows what call to call. > > vs. a more distributed dynamic construction where anyone can declare they have initialization and it discovered and called as needed > > > In reality these are kind of the same. It's just that on both Windows and all/most Posix systems there already exists a central dynamic mechanism available to C and Modula-3, but Modula-3 doesn't use it. > > Specifically on Windows this is DllMain. C++ has these things, globals with constructors/destructors. You can have them in a .dll. They tie into DllMain. > > > C++ has these everywhere and the problem is solved some way everywhere. > I believe typical ELF systems use .init/.fini ELF sections, similar to how C++ constructors/destructors work -- section is an array of pointers that some special code knows to call at the right time. > > > Very possible Modula-3 should use these mechanisms. > However it is somewhat of a portability nightmare. > By doing things itsself, Modula-3 gets *almost* as good functionality, with one portable implementation. > Kind of like the $ORIGIN stuff. > > > - Jay > > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 26 Sep 2010 10:20:27 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >> >> We don't need the checks. If someone calls from native threads to M3 threads they are programming "UNSAFE"ly anyway, and will have to pay the piper. We could consider an UNSAFE interface that allows native threads to register themselves for GC, etc. But this would only be for super-hackers. >> >> On 26 Sep 2010, at 09:59, Jay K wrote: >> >>> >>> Understood -- that is seemingly the point of the Win32 checks. Should they be present on Posix then too? >>> >>> Merely hitting "TRY" I expect would access violate. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sun, 26 Sep 2010 09:56:29 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>> >>>> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. >>>> >>>> On 26 Sep 2010, at 09:51, Jay K wrote: >>>> >>>>> >>>>> What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: hosking at cs.purdue.edu >>>>>> Date: Sun, 26 Sep 2010 09:13:09 -0400 >>>>>> To: jay.krell at cornell.edu >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>>>> >>>>>> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? >>>>>> >>>>>> On 26 Sep 2010, at 08:21, Jay K wrote: >>>>>> >>>>>>> >>>>>>> I think it is problematic in both. >>>>>>> If I understand you. >>>>>>> >>>>>>> >>>>>>> The thread locals could be allocated on-demand which might >>>>>>> address some situations. Though that can also fail. >>>>>>> >>>>>>> >>>>>>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). >>>>>>> That even allows you to fail (due to low memory). >>>>>>> However that doesn't work as well as one might hope. >>>>>>> In particular, any number of threads can be created before a particular .dll is loaded. >>>>>>> And a .dll can be unloaded while the threads still exist -- making also thread detach >>>>>>> not so ideal for freeing. What you have to do is: >>>>>>> - be willing to allocate on demand >>>>>>> - have some story for failure >>>>>>> - track all the thread locals through a global (!) and free them in thread/process detach >>>>>>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; >>>>>>> there is a parameter that distinguishes them; best to do nothing, quickly in >>>>>>> the ExitProcess). >>>>>>> >>>>>>> >>>>>>> Best really really really really best to avoid thread locals. >>>>>>> But that is probably impossible. >>>>>>> >>>>>>> >>>>>>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. >>>>>>> Which doesn't solve the problems. >>>>>>> >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 >>>>>>>> To: jay.krell at cornell.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>>>>>> >>>>>>>> Is it ok in the WIn32 implementation for the thread to be native. >>>>>>>> I think it is ok for pthread. >>>>>>>> >>>>>>>> On 25 Sep 2010, at 05:35, Jay K wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = >>>>>>>>> (* LL = m *) >>>>>>>>> VAR self := GetActivation(); >>>>>>>>> BEGIN >>>>>>>>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; >>>>>>>>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; >>>>>>>>> XWait(m, c, self, alertable := TRUE); >>>>>>>>> END AlertWait; >>>>>>>>> >>>>>>>>> >>>>>>>>> The pthread code doesn't have the check for NIL and call to Die. >>>>>>>>> Nor for that matter, the uses of ThreadDebug -- which I added. >>>>>>>>> >>>>>>>>> I think these should be more similar. >>>>>>>>> >>>>>>>>> What I was really wondering about, again, is more common code between Win32 and Posix >>>>>>>>> in the thread code... >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Mon Sep 27 22:12:01 2010 From: darko at darko.org (Darko) Date: Mon, 27 Sep 2010 13:12:01 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285447327.3009.0.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org> <1285447327.3009.0.camel@boromir.m3w.org> Message-ID: <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: > Is it feasible to make it mora native to Mac? Interesting? > > On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: >> It draws all the controls itself. >> The Mac version is the X Windows version. >> >> - Jay >> >> ---------------------------------------- >>> From: dragisha at m3w.org >>> To: m3devel at elegosoft.com >>> Date: Sat, 25 Sep 2010 13:41:19 +0200 >>> Subject: [M3devel] UI, Trestle, native... Cocoa?? >>> >>> Anybody working UI's with Trestle? It is mapped no native widgets on >>> Windows? What about Mac? >>> -- >>> Dragi?a Duri? >>> >> > > -- > Dragi?a Duri? > From rcolebur at SCIRES.COM Tue Sep 28 01:16:13 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 27 Sep 2010 19:16:13 -0400 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285414879.3024.0.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org> Message-ID: Yes, I have a number of GUIs using Trestle, FormsVBT, etc. on Windows and old HPUX. Regards, Randy -----Original Message----- From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Saturday, September 25, 2010 7:41 AM To: m3devel Subject: [M3devel] UI, Trestle, native... Cocoa?? Anybody working UI's with Trestle? It is mapped no native widgets on Windows? What about Mac? -- Dragi?a Duri? From rcolebur at SCIRES.COM Tue Sep 28 02:11:03 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 27 Sep 2010 20:11:03 -0400 Subject: [M3devel] windows devel, howto? In-Reply-To: <1285501553.3009.2.camel@boromir.m3w.org> References: <1285501553.3009.2.camel@boromir.m3w.org> Message-ID: I have cm3 running on Windows 2000, XP, Vista, and 7. I have used various editions of the free Microsoft Visual Studio Express C++ to provide for linking and C-compiler support, including the 2010 edition. I have provided some scripts (windows command shell files) etc that I use. See "scripts\dev\windows" and "scripts\install\windows". These deal effectively with the various flavors of the Microsoft VS tools (you may have to edit one line of the CMD file to match the version of VS you have--see embedded comments). I know Jay has provided some python scripts also that purportedly work for Windows, but I don't use these, preferring to stay with native windows command shell support. Once you get MS VS Express C++ installed and the minimal cm3 binary installation for cm3 (I recommend rooting the cm3 install at C:\cm3"), you can download the entire source code repository via CVS into a sandbox folder (e.g., C:\cm3\Sandbox), then use my scripts to build everything. You would copy the "scripts\install\windows\*.cmd" files to your "C:\cm3\bin" folder, edit "C:\cm3\bin\cm3CommandShell.CMD" to match your VS environment (the default is VS 2010), then cd to "scripts\dev\windows" and run "RCC_upgradeCM3.CMD -all" to rebuild everything. Alternately, you can try Jay's python scripts, but you would need to check with him on how to use these. Let me know if you have questions/concerns. Regards, Randy Coleburn -----Original Message----- From: Dragi?a Duri? [mailto:dragisha at m3w.org] Sent: Sunday, September 26, 2010 7:46 AM To: m3devel Subject: [M3devel] windows devel, howto? I see msvc 9.0 is requirement, but MS offers only latest and greatest 2010? Can someone spare few moments to coach me to Win Modula-3? :) TIA -- Dragi?a Duri? From jay.krell at cornell.edu Tue Sep 28 02:30:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Sep 2010 00:30:21 +0000 Subject: [M3devel] windows devel, howto? In-Reply-To: References: <1285501553.3009.2.camel@boromir.m3w.org>, Message-ID: Mine adjust automatically to whatever VS they find in %PATH%, %INCLUD%, %LIB%, and shouldn't need editing. VS installs a shortcut to launch cmd with %PATH%, %INCLUDE%, %LIB% set. You run that and then run from within there. The same .py files work across "all" platforms (well, I never got OpenBSD/sgimips to work). I use them on NetBSD, OpenBSD, Linux, Darwin, Windows, Solaris, FreeBSD, OSF/1. That portability is valuable. As well as side agenda of Python advocasy. I forget where was I on AIX, Irix, HP-UX, VMS (significant progress on all of them) but they probably work on most. *.sh is I grudgingly agree more portable, but not a pleasant programming language for working in and heavier weight on Windows (Cygwin). Meanwhile, in terms of portability, Hudson's Java is significant problem but otherwise Hudson is very nice. I am passionate in my distaste for .cmd. For native Windows I would strongly recommend JScript wrapped inside .cmd. .cmd is an awful language and should be avoided for almost any purpose, except it is nice for command line interaction. I speak from having been lured into using cmd more and more by powerful seeming features (e.g. for /f), only to become repeatly stymied by its many unavoidable limitations, idiosynchrocies and sort of bad performance. If you put this: @if (1 == 0) @end /* @cscript.exe /E:jscript /nologo "%~f0" %* @goto :eof */ at the top of a .cmd file, you can write the rest in JScript. JScript also has performance problems but I believe is the much preferable choice vs. .cmd. We should also consider rewriting more stuff in Modula-3. To whatever extent "scripting" languages are used vs. "other", I think maybe is a weakness in "other". Simply having good libraries and syntax for strings, arrays, hash tables goes a long way. e.g. C++ STL, and libm3 I think, to some extent. However there is the sticking point of "portable executable" -- running the source directly. Possibly one should only script a minimum, to use cm3 to build everything else. I'm also in general "lured" by these "scripting" languages. To whatever extent computers have become so much faster the past decades, scripting languages seem tempting to do more and more in. People write entire "applications" in Python. However the loss of static checking still bothers me sometimes. The "new" stuff Olaf put into Quake, e.g. enumerating files and directories, might make it viable here too. Except I still don't know how to "just run a quake file directly" vs. having an m3makefile, m3args, etc. Someone should look into that and fix it if possible -- writing "main" in quake? - Jay ---------------------------------------- > From: rcolebur at SCIRES.COM > To: dragisha at m3w.org; m3devel at elegosoft.com > Date: Mon, 27 Sep 2010 20:11:03 -0400 > Subject: Re: [M3devel] windows devel, howto? > > I have cm3 running on Windows 2000, XP, Vista, and 7. > > I have used various editions of the free Microsoft Visual Studio Express C++ to provide for linking and C-compiler support, including the 2010 edition. > > I have provided some scripts (windows command shell files) etc that I use. See "scripts\dev\windows" and "scripts\install\windows". These deal effectively with the various flavors of the Microsoft VS tools (you may have to edit one line of the CMD file to match the version of VS you have--see embedded comments). > > I know Jay has provided some python scripts also that purportedly work for Windows, but I don't use these, preferring to stay with native windows command shell support. > > Once you get MS VS Express C++ installed and the minimal cm3 binary installation for cm3 (I recommend rooting the cm3 install at C:\cm3"), you can download the entire source code repository via CVS into a sandbox folder (e.g., C:\cm3\Sandbox), then use my scripts to build everything. > > You would copy the "scripts\install\windows\*.cmd" files to your "C:\cm3\bin" folder, edit "C:\cm3\bin\cm3CommandShell.CMD" to match your VS environment (the default is VS 2010), then cd to "scripts\dev\windows" and run "RCC_upgradeCM3.CMD -all" to rebuild everything. Alternately, you can try Jay's python scripts, but you would need to check with him on how to use these. > > Let me know if you have questions/concerns. > > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Sunday, September 26, 2010 7:46 AM > To: m3devel > Subject: [M3devel] windows devel, howto? > > I see msvc 9.0 is requirement, but MS offers only latest and greatest > 2010? > > Can someone spare few moments to coach me to Win Modula-3? :) > > TIA > -- > Dragi?a Duri? > From rcolebur at SCIRES.COM Tue Sep 28 02:50:40 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Mon, 27 Sep 2010 20:50:40 -0400 Subject: [M3devel] windows devel, howto? In-Reply-To: References: <1285501553.3009.2.camel@boromir.m3w.org>, Message-ID: Jay: You've stated your dislike of CMD before and preference for Python. Unfortunately, I'm not a python programmer, yet. Perhaps someday. For those that aren't as passionate about disliking CMD, I merely offer the CMD scripts I've developed and use. These don't depend on anything else being installed (e.g., Python). Use/adapt them if you want. I'm not forcing these on anybody. As far as automatically adjusting for the version of VS, I haven't gone to that trouble. It is a single-line edit in my CMD file and I've given examples for all the versions of VS I've used in the in-line comments, so it is an easy edit. My CMD file does indeed call the VS CMD shortcut for setting up the VS environment; my observation is the location of this file has changed for different versions of VS, hence the need for the single-line edit to point to the correct version of the VC++ "vcvarsall.bat" command. Enough said. Regards, Randy Coleburn -----Original Message----- From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Monday, September 27, 2010 8:30 PM To: Coleburn, Randy; dragisha at m3w.org; m3devel Subject: RE: [M3devel] windows devel, howto? Mine adjust automatically to whatever VS they find in %PATH%, %INCLUD%, %LIB%, and shouldn't need editing. VS installs a shortcut to launch cmd with %PATH%, %INCLUDE%, %LIB% set. You run that and then run from within there. The same .py files work across "all" platforms (well, I never got OpenBSD/sgimips to work). I use them on NetBSD, OpenBSD, Linux, Darwin, Windows, Solaris, FreeBSD, OSF/1. That portability is valuable. As well as side agenda of Python advocasy. I forget where was I on AIX, Irix, HP-UX, VMS (significant progress on all of them) but they probably work on most. *.sh is I grudgingly agree more portable, but not a pleasant programming language for working in and heavier weight on Windows (Cygwin). Meanwhile, in terms of portability, Hudson's Java is significant problem but otherwise Hudson is very nice. I am passionate in my distaste for .cmd. For native Windows I would strongly recommend JScript wrapped inside .cmd. .cmd is an awful language and should be avoided for almost any purpose, except it is nice for command line interaction. I speak from having been lured into using cmd more and more by powerful seeming features (e.g. for /f), only to become repeatly stymied by its many unavoidable limitations, idiosynchrocies and sort of bad performance. If you put this: @if (1 == 0) @end /* @cscript.exe /E:jscript /nologo "%~f0" %* @goto :eof */ at the top of a .cmd file, you can write the rest in JScript. JScript also has performance problems but I believe is the much preferable choice vs. .cmd. We should also consider rewriting more stuff in Modula-3. To whatever extent "scripting" languages are used vs. "other", I think maybe is a weakness in "other". Simply having good libraries and syntax for strings, arrays, hash tables goes a long way. e.g. C++ STL, and libm3 I think, to some extent. However there is the sticking point of "portable executable" -- running the source directly. Possibly one should only script a minimum, to use cm3 to build everything else. I'm also in general "lured" by these "scripting" languages. To whatever extent computers have become so much faster the past decades, scripting languages seem tempting to do more and more in. People write entire "applications" in Python. However the loss of static checking still bothers me sometimes. The "new" stuff Olaf put into Quake, e.g. enumerating files and directories, might make it viable here too. Except I still don't know how to "just run a quake file directly" vs. having an m3makefile, m3args, etc. Someone should look into that and fix it if possible -- writing "main" in quake? - Jay ---------------------------------------- > From: rcolebur at SCIRES.COM > To: dragisha at m3w.org; m3devel at elegosoft.com > Date: Mon, 27 Sep 2010 20:11:03 -0400 > Subject: Re: [M3devel] windows devel, howto? > > I have cm3 running on Windows 2000, XP, Vista, and 7. > > I have used various editions of the free Microsoft Visual Studio Express C++ to provide for linking and C-compiler support, including the 2010 edition. > > I have provided some scripts (windows command shell files) etc that I use. See "scripts\dev\windows" and "scripts\install\windows". These deal effectively with the various flavors of the Microsoft VS tools (you may have to edit one line of the CMD file to match the version of VS you have--see embedded comments). > > I know Jay has provided some python scripts also that purportedly work for Windows, but I don't use these, preferring to stay with native windows command shell support. > > Once you get MS VS Express C++ installed and the minimal cm3 binary installation for cm3 (I recommend rooting the cm3 install at C:\cm3"), you can download the entire source code repository via CVS into a sandbox folder (e.g., C:\cm3\Sandbox), then use my scripts to build everything. > > You would copy the "scripts\install\windows\*.cmd" files to your "C:\cm3\bin" folder, edit "C:\cm3\bin\cm3CommandShell.CMD" to match your VS environment (the default is VS 2010), then cd to "scripts\dev\windows" and run "RCC_upgradeCM3.CMD -all" to rebuild everything. Alternately, you can try Jay's python scripts, but you would need to check with him on how to use these. > > Let me know if you have questions/concerns. > > Regards, > Randy Coleburn > > -----Original Message----- > From: Dragi?a Duri? [mailto:dragisha at m3w.org] > Sent: Sunday, September 26, 2010 7:46 AM > To: m3devel > Subject: [M3devel] windows devel, howto? > > I see msvc 9.0 is requirement, but MS offers only latest and greatest > 2010? > > Can someone spare few moments to coach me to Win Modula-3? :) > > TIA > -- > Dragi?a Duri? > From dragisha at m3w.org Tue Sep 28 08:23:04 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 28 Sep 2010 08:23:04 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org> <1285447327.3009.0.camel@boromir.m3w.org> <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> Message-ID: <1285654984.6634.18.camel@boromir.m3w.org> I am about to do a port of some simple (in its GUI aspect) application to Mac. I am also discouraged (at least tried to) to near death :) by a guy from another community, he is 1000% sure Modula-3 cannot be made to support Cocoa not a "g" of gracefully. Trestle under X did not took my breath. After peeking and pooking around sources a bit, I think it was very nice project in its time, and reasonable one to use 12-15yrs ago, but things moved on. In other words - I cannot think an explanation to my customer why a GUI appliction of mine is not more.... GUIsh... I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his testing on Windows while he was working with me on it) and from that experience I know it's not impossible to make native GUI work. In other words - count on me for low level binding/interfacing once I start doing my work on Mac - in few weeks time. On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: > I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: > > - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects > - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). > > If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. > > > On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: > > > Is it feasible to make it mora native to Mac? Interesting? > > > > On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: > >> It draws all the controls itself. > >> The Mac version is the X Windows version. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: dragisha at m3w.org > >>> To: m3devel at elegosoft.com > >>> Date: Sat, 25 Sep 2010 13:41:19 +0200 > >>> Subject: [M3devel] UI, Trestle, native... Cocoa?? > >>> > >>> Anybody working UI's with Trestle? It is mapped no native widgets on > >>> Windows? What about Mac? > >>> -- > >>> Dragi?a Duri? > >>> > >> > > > > -- > > Dragi?a Duri? > > > -- Dragi?a Duri? From jay.krell at cornell.edu Tue Sep 28 08:38:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Sep 2010 06:38:16 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285654984.6634.18.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, , <1285447327.3009.0.camel@boromir.m3w.org>, <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, <1285654984.6634.18.camel@boromir.m3w.org> Message-ID: I think what is a bit unusual about Trestle is how much it implements itself. It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. *and* it is multithreaded. Unusual for GUI libraries (e.g. Java swing). Whenever I read about it, I get lost once they start talking about the locking protocol. The "split" layout mechanism seems maybe nice. It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. I suspect the authors knew or discovered far more than any of us here. You probably can make a decent binding to Cocoa. But I don't know. Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? > Trestle under X did not took my breath I find Trestle GUI pretty difficult to interact with. Using scrollbars for example. I have trouble with most X GUI actually. The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. Qt looks very nice... - Jay ---------------------------------------- > From: dragisha at m3w.org > To: darko at darko.org > Date: Tue, 28 Sep 2010 08:23:04 +0200 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > I am about to do a port of some simple (in its GUI aspect) application > to Mac. > > I am also discouraged (at least tried to) to near death :) by a guy from > another community, he is 1000% sure Modula-3 cannot be made to support > Cocoa not a "g" of gracefully. > > Trestle under X did not took my breath. After peeking and pooking around > sources a bit, I think it was very nice project in its time, and > reasonable one to use 12-15yrs ago, but things moved on. In other words > - I cannot think an explanation to my customer why a GUI appliction of > mine is not more.... GUIsh... > > I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his > testing on Windows while he was working with me on it) and from that > experience I know it's not impossible to make native GUI work. > > In other words - count on me for low level binding/interfacing once I > start doing my work on Mac - in few weeks time. > > On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: > > I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: > > > > - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects > > - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). > > > > If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. > > > > > > On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: > > > > > Is it feasible to make it mora native to Mac? Interesting? > > > > > > On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: > > >> It draws all the controls itself. > > >> The Mac version is the X Windows version. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: dragisha at m3w.org > > >>> To: m3devel at elegosoft.com > > >>> Date: Sat, 25 Sep 2010 13:41:19 +0200 > > >>> Subject: [M3devel] UI, Trestle, native... Cocoa?? > > >>> > > >>> Anybody working UI's with Trestle? It is mapped no native widgets on > > >>> Windows? What about Mac? > > >>> -- > > >>> Dragi?a Duri? > > >>> > > >> > > > > > > -- > > > Dragi?a Duri? > > > > > > > -- > Dragi?a Duri? > From darko at darko.org Tue Sep 28 08:40:46 2010 From: darko at darko.org (Darko) Date: Mon, 27 Sep 2010 23:40:46 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285654984.6634.18.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org> <1285447327.3009.0.camel@boromir.m3w.org> <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> <1285654984.6634.18.camel@boromir.m3w.org> Message-ID: I think that guy is wrong. Objective C is a layer on top of C and all Obj-C operations can be boiled down to normal C calls. M3 can interface to any C calls so it's not too difficult. What might be a little challenging is getting Obj-C objects looking like M3 objects, but most probably that just requires some glue and weak references to interface with Obj-C reference counting based GC and having the right layout for Obj-C declared object fields. I agree that GUIs should look native because that's what user's want. If you're interested in experimenting with Mac interfaces there is fairly complete Carbon API implemented by the Mac module which I think is in the repository. On 27/09/2010, at 11:23 PM, Dragi?a Duri? wrote: > I am about to do a port of some simple (in its GUI aspect) application > to Mac. > > I am also discouraged (at least tried to) to near death :) by a guy from > another community, he is 1000% sure Modula-3 cannot be made to support > Cocoa not a "g" of gracefully. > > Trestle under X did not took my breath. After peeking and pooking around > sources a bit, I think it was very nice project in its time, and > reasonable one to use 12-15yrs ago, but things moved on. In other words > - I cannot think an explanation to my customer why a GUI appliction of > mine is not more.... GUIsh... > > I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his > testing on Windows while he was working with me on it) and from that > experience I know it's not impossible to make native GUI work. > > In other words - count on me for low level binding/interfacing once I > start doing my work on Mac - in few weeks time. > > On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: >> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: >> >> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects >> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). >> >> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. >> >> >> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: >> >>> Is it feasible to make it mora native to Mac? Interesting? >>> >>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: >>>> It draws all the controls itself. >>>> The Mac version is the X Windows version. >>>> >>>> - Jay >>>> >>>> ---------------------------------------- >>>>> From: dragisha at m3w.org >>>>> To: m3devel at elegosoft.com >>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 >>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? >>>>> >>>>> Anybody working UI's with Trestle? It is mapped no native widgets on >>>>> Windows? What about Mac? >>>>> -- >>>>> Dragi?a Duri? >>>>> >>>> >>> >>> -- >>> Dragi?a Duri? >>> >> > > -- > Dragi?a Duri? > From darko at darko.org Tue Sep 28 08:47:06 2010 From: darko at darko.org (Darko) Date: Mon, 27 Sep 2010 23:47:06 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org>, , <1285447327.3009.0.camel@boromir.m3w.org>, <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, <1285654984.6634.18.camel@boromir.m3w.org> Message-ID: <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters. On 27/09/2010, at 11:38 PM, Jay K wrote: > > I think what is a bit unusual about Trestle is how much it implements itself. > > > It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. > > > *and* it is multithreaded. > Unusual for GUI libraries (e.g. Java swing). > > > Whenever I read about it, I get lost once they start talking about the locking protocol. > > > The "split" layout mechanism seems maybe nice. > It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. > > > I suspect the authors knew or discovered far more than any of us here. > > > You probably can make a decent binding to Cocoa. > But I don't know. > > > Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? > > >> Trestle under X did not took my breath > > > I find Trestle GUI pretty difficult to interact with. > Using scrollbars for example. > I have trouble with most X GUI actually. > > > The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. > > > Qt looks very nice... > > > - Jay > > ---------------------------------------- >> From: dragisha at m3w.org >> To: darko at darko.org >> Date: Tue, 28 Sep 2010 08:23:04 +0200 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >> I am about to do a port of some simple (in its GUI aspect) application >> to Mac. >> >> I am also discouraged (at least tried to) to near death :) by a guy from >> another community, he is 1000% sure Modula-3 cannot be made to support >> Cocoa not a "g" of gracefully. >> >> Trestle under X did not took my breath. After peeking and pooking around >> sources a bit, I think it was very nice project in its time, and >> reasonable one to use 12-15yrs ago, but things moved on. In other words >> - I cannot think an explanation to my customer why a GUI appliction of >> mine is not more.... GUIsh... >> >> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his >> testing on Windows while he was working with me on it) and from that >> experience I know it's not impossible to make native GUI work. >> >> In other words - count on me for low level binding/interfacing once I >> start doing my work on Mac - in few weeks time. >> >> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: >>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: >>> >>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects >>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). >>> >>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. >>> >>> >>> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: >>> >>>> Is it feasible to make it mora native to Mac? Interesting? >>>> >>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: >>>>> It draws all the controls itself. >>>>> The Mac version is the X Windows version. >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: dragisha at m3w.org >>>>>> To: m3devel at elegosoft.com >>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 >>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? >>>>>> >>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on >>>>>> Windows? What about Mac? >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> >>>>> >>>> >>>> -- >>>> Dragi?a Duri? >>>> >>> >> >> -- >> Dragi?a Duri? >> From jay.krell at cornell.edu Tue Sep 28 10:26:05 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Sep 2010 08:26:05 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , <1285447327.3009.0.camel@boromir.m3w.org>, , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , <1285654984.6634.18.camel@boromir.m3w.org>, , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> Message-ID: I think you have a few unrelated choices: Make Trestle look like Macintosh when on Macintosh. This is altering some low level drawing code, mouse logic. Doable. It has little/nothing to do with Objective C or Cocoa. Wrap other GUI libraries. There are many to chose from. With more or less idiomatic wrappers. If you are going to do this, please do something that runs on more than one system. KDE, wxWidgets, FLTK, GTk+, etc. But GTk+ doesn't seem well supported on Windows. KDE would be my choice. It looks good, it seems to be fairly nice, complete, and evolving fairly rapidly, it has money behind it. An idiomatic wrapper for Cocoa is just one GUI library you could wrap, and it'd have the least value since it only runs on one system. Granted, a slowly growing in popularity system, and iPhone. If you get the hang of things, sure, go all out, wrap several. Please. SWIG might be useful here. Please whatever it is, make sure it gets static checking. Assume the C/C++ headers underneath you will change, and you want a compilation break when that happens. Instead of silent memory corruption. I don't think Trestle implemented on top of Cocoa makes much sense. It does make some. Using CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead of X Windows. But given that Trestle draws things itself, "porting" analogous to where the Win32 layer varies from the X layer, wouldn't give you something that looks like Macintosh. - Jay ---------------------------------------- > From: darko at darko.org > Date: Mon, 27 Sep 2010 23:47:06 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters. > > > On 27/09/2010, at 11:38 PM, Jay K wrote: > > > > > I think what is a bit unusual about Trestle is how much it implements itself. > > > > > > It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. > > > > > > *and* it is multithreaded. > > Unusual for GUI libraries (e.g. Java swing). > > > > > > Whenever I read about it, I get lost once they start talking about the locking protocol. > > > > > > The "split" layout mechanism seems maybe nice. > > It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. > > > > > > I suspect the authors knew or discovered far more than any of us here. > > > > > > You probably can make a decent binding to Cocoa. > > But I don't know. > > > > > > Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? > > > > > >> Trestle under X did not took my breath > > > > > > I find Trestle GUI pretty difficult to interact with. > > Using scrollbars for example. > > I have trouble with most X GUI actually. > > > > > > The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. > > > > > > Qt looks very nice... > > > > > > - Jay > > > > ---------------------------------------- > >> From: dragisha at m3w.org > >> To: darko at darko.org > >> Date: Tue, 28 Sep 2010 08:23:04 +0200 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > >> > >> I am about to do a port of some simple (in its GUI aspect) application > >> to Mac. > >> > >> I am also discouraged (at least tried to) to near death :) by a guy from > >> another community, he is 1000% sure Modula-3 cannot be made to support > >> Cocoa not a "g" of gracefully. > >> > >> Trestle under X did not took my breath. After peeking and pooking around > >> sources a bit, I think it was very nice project in its time, and > >> reasonable one to use 12-15yrs ago, but things moved on. In other words > >> - I cannot think an explanation to my customer why a GUI appliction of > >> mine is not more.... GUIsh... > >> > >> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his > >> testing on Windows while he was working with me on it) and from that > >> experience I know it's not impossible to make native GUI work. > >> > >> In other words - count on me for low level binding/interfacing once I > >> start doing my work on Mac - in few weeks time. > >> > >> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: > >>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: > >>> > >>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects > >>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). > >>> > >>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. > >>> > >>> > >>> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: > >>> > >>>> Is it feasible to make it mora native to Mac? Interesting? > >>>> > >>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: > >>>>> It draws all the controls itself. > >>>>> The Mac version is the X Windows version. > >>>>> > >>>>> - Jay > >>>>> > >>>>> ---------------------------------------- > >>>>>> From: dragisha at m3w.org > >>>>>> To: m3devel at elegosoft.com > >>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 > >>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? > >>>>>> > >>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on > >>>>>> Windows? What about Mac? > >>>>>> -- > >>>>>> Dragi?a Duri? > >>>>>> > >>>>> > >>>> > >>>> -- > >>>> Dragi?a Duri? > >>>> > >>> > >> > >> -- > >> Dragi?a Duri? > >> > From darko at darko.org Tue Sep 28 10:39:40 2010 From: darko at darko.org (Darko) Date: Tue, 28 Sep 2010 01:39:40 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , <1285447327.3009.0.camel@boromir.m3w.org>, , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , <1285654984.6634.18.camel@boromir.m3w.org>, , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> Message-ID: <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> I think the point is that GUI support for Cocoa and Windows is useful to myself and possibly other people, I'm not really counting how many platforms it will work on - I need those two platforms and I need them native. Actually I need Carbon and Windows right now but Cocoa would be very nice. Implementing Trestle to look like Cocoa would be non-trivial, and pointless. The idea is that you want your GUI to change when the underlying OS changes, which it does very regularly, or on Windows the user can change the look whenever they want. As far as static breaks go, there would be links to library calls so when they change the linking would break, but Mac OS APIs almost never change, they just get updated with new calls so it wouldn't really be a problem. I don't know if there is any subtle issues wrt Obj-C but I doubt it. On 28/09/2010, at 1:26 AM, Jay K wrote: > > I think you have a few unrelated choices: > > > Make Trestle look like Macintosh when on Macintosh. > This is altering some low level drawing code, mouse logic. Doable. > It has little/nothing to do with Objective C or Cocoa. > > > Wrap other GUI libraries. > There are many to chose from. > With more or less idiomatic wrappers. > If you are going to do this, please do something that runs on more than one system. > KDE, wxWidgets, FLTK, GTk+, etc. > But GTk+ doesn't seem well supported on Windows. > KDE would be my choice. It looks good, it seems to be fairly nice, complete, and evolving fairly rapidly, it has money behind it. > An idiomatic wrapper for Cocoa is just one GUI library you could wrap, and it'd have the least value since it only runs on one system. Granted, a slowly growing in popularity system, and iPhone. > > > If you get the hang of things, sure, go all out, wrap several. Please. > > > SWIG might be useful here. > > > Please whatever it is, make sure it gets static checking. > Assume the C/C++ headers underneath you will change, and you want a compilation break when that happens. Instead of silent memory corruption. > > > I don't think Trestle implemented on top of Cocoa makes much sense. > It does make some. Using CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead of X Windows. > But given that Trestle draws things itself, "porting" analogous to where the Win32 layer varies from the X layer, wouldn't give you something that looks like Macintosh. > > > > - Jay > > ---------------------------------------- >> From: darko at darko.org >> Date: Mon, 27 Sep 2010 23:47:06 -0700 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >> I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters. >> >> >> On 27/09/2010, at 11:38 PM, Jay K wrote: >> >>> >>> I think what is a bit unusual about Trestle is how much it implements itself. >>> >>> >>> It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. >>> >>> >>> *and* it is multithreaded. >>> Unusual for GUI libraries (e.g. Java swing). >>> >>> >>> Whenever I read about it, I get lost once they start talking about the locking protocol. >>> >>> >>> The "split" layout mechanism seems maybe nice. >>> It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. >>> >>> >>> I suspect the authors knew or discovered far more than any of us here. >>> >>> >>> You probably can make a decent binding to Cocoa. >>> But I don't know. >>> >>> >>> Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? >>> >>> >>>> Trestle under X did not took my breath >>> >>> >>> I find Trestle GUI pretty difficult to interact with. >>> Using scrollbars for example. >>> I have trouble with most X GUI actually. >>> >>> >>> The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. >>> >>> >>> Qt looks very nice... >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: dragisha at m3w.org >>>> To: darko at darko.org >>>> Date: Tue, 28 Sep 2010 08:23:04 +0200 >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >>>> >>>> I am about to do a port of some simple (in its GUI aspect) application >>>> to Mac. >>>> >>>> I am also discouraged (at least tried to) to near death :) by a guy from >>>> another community, he is 1000% sure Modula-3 cannot be made to support >>>> Cocoa not a "g" of gracefully. >>>> >>>> Trestle under X did not took my breath. After peeking and pooking around >>>> sources a bit, I think it was very nice project in its time, and >>>> reasonable one to use 12-15yrs ago, but things moved on. In other words >>>> - I cannot think an explanation to my customer why a GUI appliction of >>>> mine is not more.... GUIsh... >>>> >>>> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his >>>> testing on Windows while he was working with me on it) and from that >>>> experience I know it's not impossible to make native GUI work. >>>> >>>> In other words - count on me for low level binding/interfacing once I >>>> start doing my work on Mac - in few weeks time. >>>> >>>> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: >>>>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: >>>>> >>>>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects >>>>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). >>>>> >>>>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. >>>>> >>>>> >>>>> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: >>>>> >>>>>> Is it feasible to make it mora native to Mac? Interesting? >>>>>> >>>>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: >>>>>>> It draws all the controls itself. >>>>>>> The Mac version is the X Windows version. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: dragisha at m3w.org >>>>>>>> To: m3devel at elegosoft.com >>>>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 >>>>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? >>>>>>>> >>>>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on >>>>>>>> Windows? What about Mac? >>>>>>>> -- >>>>>>>> Dragi?a Duri? >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> >>>>> >>>> >>>> -- >>>> Dragi?a Duri? >>>> >> From jay.krell at cornell.edu Tue Sep 28 10:47:19 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Sep 2010 08:47:19 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, ,,, ,,<1285447327.3009.0.camel@boromir.m3w.org>, ,,<193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> Message-ID: > but Mac OS APIs almost never change Mostly agreed. But there can be silent breaks when only linking gets checked. At least libc across various systems has a bad track record. I think therefore we're talking about generating wrapper libraries, more or less idiomatic. > or on Windows the user can change the look whenever they want. This is actually allowed for to some extent. It is the point of GetSysColor. "Native" would be good imho because it just generally looks so much better. However it leads to loss of portability. I would really rather see KDE or wxWidgets or somesuch. They do look close to native and do things themselves to varying degrees. Look at our WinBase.i3 for a feel for what people have done in the past. That is seemingly a direct hand written translation. Do that for a few functions/structs? And then automate it somehow? There is "gccxml" that parses headers and spits out xml, you can then use xml-dom or xsl etc. There might also be enough runtime type information in Macintosh binaries, to save you from parsing declarations. Realize Carbon is dying to some degree -- stuff not being ported to 64bit. - Jay ---------------------------------------- > From: darko at darko.org > Date: Tue, 28 Sep 2010 01:39:40 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > I think the point is that GUI support for Cocoa and Windows is useful to myself and possibly other people, I'm not really counting how many platforms it will work on - I need those two platforms and I need them native. Actually I need Carbon and Windows right now but Cocoa would be very nice. > > Implementing Trestle to look like Cocoa would be non-trivial, and pointless. The idea is that you want your GUI to change when the underlying OS changes, which it does very regularly, or on Windows the user can change the look whenever they want. > > As far as static breaks go, there would be links to library calls so when they change the linking would break, but Mac OS APIs almost never change, they just get updated with new calls so it wouldn't really be a problem. I don't know if there is any subtle issues wrt Obj-C but I doubt it. > > > On 28/09/2010, at 1:26 AM, Jay K wrote: > > > > > I think you have a few unrelated choices: > > > > > > Make Trestle look like Macintosh when on Macintosh. > > This is altering some low level drawing code, mouse logic. Doable. > > It has little/nothing to do with Objective C or Cocoa. > > > > > > Wrap other GUI libraries. > > There are many to chose from. > > With more or less idiomatic wrappers. > > If you are going to do this, please do something that runs on more than one system. > > KDE, wxWidgets, FLTK, GTk+, etc. > > But GTk+ doesn't seem well supported on Windows. > > KDE would be my choice. It looks good, it seems to be fairly nice, complete, and evolving fairly rapidly, it has money behind it. > > An idiomatic wrapper for Cocoa is just one GUI library you could wrap, and it'd have the least value since it only runs on one system. Granted, a slowly growing in popularity system, and iPhone. > > > > > > If you get the hang of things, sure, go all out, wrap several. Please. > > > > > > SWIG might be useful here. > > > > > > Please whatever it is, make sure it gets static checking. > > Assume the C/C++ headers underneath you will change, and you want a compilation break when that happens. Instead of silent memory corruption. > > > > > > I don't think Trestle implemented on top of Cocoa makes much sense. > > It does make some. Using CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead of X Windows. > > But given that Trestle draws things itself, "porting" analogous to where the Win32 layer varies from the X layer, wouldn't give you something that looks like Macintosh. > > > > > > > > - Jay > > > > ---------------------------------------- > >> From: darko at darko.org > >> Date: Mon, 27 Sep 2010 23:47:06 -0700 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > >> > >> I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters. > >> > >> > >> On 27/09/2010, at 11:38 PM, Jay K wrote: > >> > >>> > >>> I think what is a bit unusual about Trestle is how much it implements itself. > >>> > >>> > >>> It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. > >>> > >>> > >>> *and* it is multithreaded. > >>> Unusual for GUI libraries (e.g. Java swing). > >>> > >>> > >>> Whenever I read about it, I get lost once they start talking about the locking protocol. > >>> > >>> > >>> The "split" layout mechanism seems maybe nice. > >>> It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. > >>> > >>> > >>> I suspect the authors knew or discovered far more than any of us here. > >>> > >>> > >>> You probably can make a decent binding to Cocoa. > >>> But I don't know. > >>> > >>> > >>> Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? > >>> > >>> > >>>> Trestle under X did not took my breath > >>> > >>> > >>> I find Trestle GUI pretty difficult to interact with. > >>> Using scrollbars for example. > >>> I have trouble with most X GUI actually. > >>> > >>> > >>> The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. > >>> > >>> > >>> Qt looks very nice... > >>> > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: dragisha at m3w.org > >>>> To: darko at darko.org > >>>> Date: Tue, 28 Sep 2010 08:23:04 +0200 > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > >>>> > >>>> I am about to do a port of some simple (in its GUI aspect) application > >>>> to Mac. > >>>> > >>>> I am also discouraged (at least tried to) to near death :) by a guy from > >>>> another community, he is 1000% sure Modula-3 cannot be made to support > >>>> Cocoa not a "g" of gracefully. > >>>> > >>>> Trestle under X did not took my breath. After peeking and pooking around > >>>> sources a bit, I think it was very nice project in its time, and > >>>> reasonable one to use 12-15yrs ago, but things moved on. In other words > >>>> - I cannot think an explanation to my customer why a GUI appliction of > >>>> mine is not more.... GUIsh... > >>>> > >>>> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his > >>>> testing on Windows while he was working with me on it) and from that > >>>> experience I know it's not impossible to make native GUI work. > >>>> > >>>> In other words - count on me for low level binding/interfacing once I > >>>> start doing my work on Mac - in few weeks time. > >>>> > >>>> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: > >>>>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: > >>>>> > >>>>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects > >>>>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). > >>>>> > >>>>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. > >>>>> > >>>>> > >>>>> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: > >>>>> > >>>>>> Is it feasible to make it mora native to Mac? Interesting? > >>>>>> > >>>>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: > >>>>>>> It draws all the controls itself. > >>>>>>> The Mac version is the X Windows version. > >>>>>>> > >>>>>>> - Jay > >>>>>>> > >>>>>>> ---------------------------------------- > >>>>>>>> From: dragisha at m3w.org > >>>>>>>> To: m3devel at elegosoft.com > >>>>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 > >>>>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? > >>>>>>>> > >>>>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on > >>>>>>>> Windows? What about Mac? > >>>>>>>> -- > >>>>>>>> Dragi?a Duri? > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> -- > >>>>>> Dragi?a Duri? > >>>>>> > >>>>> > >>>> > >>>> -- > >>>> Dragi?a Duri? > >>>> > >> > From wagner at elegosoft.com Tue Sep 28 10:53:06 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Sep 2010 10:53:06 +0200 Subject: [M3devel] windows devel, howto? In-Reply-To: References: <1285501553.3009.2.camel@boromir.m3w.org>, Message-ID: <20100928105306.c2fi8md1wss04wsg@mail.elegosoft.com> Quoting Jay K : > The "new" stuff Olaf put into Quake, e.g. enumerating files and > directories, might make it viable here too. Except I still don't > know how to "just run a quake file directly" vs. having an > m3makefile, m3args, etc. Someone should look into that and fix it if > possible -- writing "main" in quake? Perhaps we should add a new option to cm3: cm3 -quake to run arbitrarily named quake programs? Quake would then offer all the cm3 quake built-ins, too. 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 darko at darko.org Tue Sep 28 11:00:21 2010 From: darko at darko.org (Darko) Date: Tue, 28 Sep 2010 02:00:21 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> Message-ID: I've only encountered one changed function call in the Mac OS API in 25 years. It really never changes, with good reason - everything is distributed as binaries so they have no scope to change things unless they are new calls or symbols. Portability can be achieved at a higher level, which is the approach I take. The point is is to give the user the experience they're looking for, which his very important. It should be integrated as much as possible. For instance you can right click and get a menu in pretty much any text in Cocoa and look up the word in the dictionary. You get that for free and users expect it everywhere. Several APIs I've done are by hand using several regular expression search and replaces. Automating it is relatively easy because it doesn't have to be completely general, it only has to parse the header files you are targeting, not every C syntactic construct, which would be a very bad trip. When I did the Mac Carbon APIs I had a file of exceptions which handled the "too hard basket" of declarations. Trying to use the more powerful tools just means you have a steep learning curve and you end up with something messy and unpredictable which you have to hack anyway. I agree Carbon is dying, the whole API has been "deprecated" by Apple, but it is the only C based API to be had so I'm sort of stuck for now. 64 bit is no big deal I really don't need an address space bigger than 4GB and I can use long integers in 32 bit code. But Cocoa would be nice because all the new pretty elements are being built in it. On 28/09/2010, at 1:47 AM, Jay K wrote: > >> but Mac OS APIs almost never change > > > Mostly agreed. > But there can be silent breaks when only linking gets checked. > At least libc across various systems has a bad track record. > > > I think therefore we're talking about generating wrapper libraries, more or less idiomatic. > > >> or on Windows the user can change the look whenever they want. > > This is actually allowed for to some extent. > It is the point of GetSysColor. > > > "Native" would be good imho because it just generally looks so much better. > However it leads to loss of portability. > I would really rather see KDE or wxWidgets or somesuch. > They do look close to native and do things themselves to varying degrees. > > > Look at our WinBase.i3 for a feel for what people have done in the past. > That is seemingly a direct hand written translation. > Do that for a few functions/structs? > And then automate it somehow? > There is "gccxml" that parses headers and spits out xml, you can then use xml-dom or xsl etc. > There might also be enough runtime type information in Macintosh binaries, to save you from parsing declarations. > > > Realize Carbon is dying to some degree -- stuff not being ported to 64bit. > > > > - Jay > > > ---------------------------------------- >> From: darko at darko.org >> Date: Tue, 28 Sep 2010 01:39:40 -0700 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >> I think the point is that GUI support for Cocoa and Windows is useful to myself and possibly other people, I'm not really counting how many platforms it will work on - I need those two platforms and I need them native. Actually I need Carbon and Windows right now but Cocoa would be very nice. >> >> Implementing Trestle to look like Cocoa would be non-trivial, and pointless. The idea is that you want your GUI to change when the underlying OS changes, which it does very regularly, or on Windows the user can change the look whenever they want. >> >> As far as static breaks go, there would be links to library calls so when they change the linking would break, but Mac OS APIs almost never change, they just get updated with new calls so it wouldn't really be a problem. I don't know if there is any subtle issues wrt Obj-C but I doubt it. >> >> >> On 28/09/2010, at 1:26 AM, Jay K wrote: >> >>> >>> I think you have a few unrelated choices: >>> >>> >>> Make Trestle look like Macintosh when on Macintosh. >>> This is altering some low level drawing code, mouse logic. Doable. >>> It has little/nothing to do with Objective C or Cocoa. >>> >>> >>> Wrap other GUI libraries. >>> There are many to chose from. >>> With more or less idiomatic wrappers. >>> If you are going to do this, please do something that runs on more than one system. >>> KDE, wxWidgets, FLTK, GTk+, etc. >>> But GTk+ doesn't seem well supported on Windows. >>> KDE would be my choice. It looks good, it seems to be fairly nice, complete, and evolving fairly rapidly, it has money behind it. >>> An idiomatic wrapper for Cocoa is just one GUI library you could wrap, and it'd have the least value since it only runs on one system. Granted, a slowly growing in popularity system, and iPhone. >>> >>> >>> If you get the hang of things, sure, go all out, wrap several. Please. >>> >>> >>> SWIG might be useful here. >>> >>> >>> Please whatever it is, make sure it gets static checking. >>> Assume the C/C++ headers underneath you will change, and you want a compilation break when that happens. Instead of silent memory corruption. >>> >>> >>> I don't think Trestle implemented on top of Cocoa makes much sense. >>> It does make some. Using CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead of X Windows. >>> But given that Trestle draws things itself, "porting" analogous to where the Win32 layer varies from the X layer, wouldn't give you something that looks like Macintosh. >>> >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: darko at darko.org >>>> Date: Mon, 27 Sep 2010 23:47:06 -0700 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >>>> >>>> I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters. >>>> >>>> >>>> On 27/09/2010, at 11:38 PM, Jay K wrote: >>>> >>>>> >>>>> I think what is a bit unusual about Trestle is how much it implements itself. >>>>> >>>>> >>>>> It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. >>>>> >>>>> >>>>> *and* it is multithreaded. >>>>> Unusual for GUI libraries (e.g. Java swing). >>>>> >>>>> >>>>> Whenever I read about it, I get lost once they start talking about the locking protocol. >>>>> >>>>> >>>>> The "split" layout mechanism seems maybe nice. >>>>> It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. >>>>> >>>>> >>>>> I suspect the authors knew or discovered far more than any of us here. >>>>> >>>>> >>>>> You probably can make a decent binding to Cocoa. >>>>> But I don't know. >>>>> >>>>> >>>>> Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? >>>>> >>>>> >>>>>> Trestle under X did not took my breath >>>>> >>>>> >>>>> I find Trestle GUI pretty difficult to interact with. >>>>> Using scrollbars for example. >>>>> I have trouble with most X GUI actually. >>>>> >>>>> >>>>> The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. >>>>> >>>>> >>>>> Qt looks very nice... >>>>> >>>>> >>>>> - Jay >>>>> >>>>> ---------------------------------------- >>>>>> From: dragisha at m3w.org >>>>>> To: darko at darko.org >>>>>> Date: Tue, 28 Sep 2010 08:23:04 +0200 >>>>>> CC: m3devel at elegosoft.com >>>>>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >>>>>> >>>>>> I am about to do a port of some simple (in its GUI aspect) application >>>>>> to Mac. >>>>>> >>>>>> I am also discouraged (at least tried to) to near death :) by a guy from >>>>>> another community, he is 1000% sure Modula-3 cannot be made to support >>>>>> Cocoa not a "g" of gracefully. >>>>>> >>>>>> Trestle under X did not took my breath. After peeking and pooking around >>>>>> sources a bit, I think it was very nice project in its time, and >>>>>> reasonable one to use 12-15yrs ago, but things moved on. In other words >>>>>> - I cannot think an explanation to my customer why a GUI appliction of >>>>>> mine is not more.... GUIsh... >>>>>> >>>>>> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his >>>>>> testing on Windows while he was working with me on it) and from that >>>>>> experience I know it's not impossible to make native GUI work. >>>>>> >>>>>> In other words - count on me for low level binding/interfacing once I >>>>>> start doing my work on Mac - in few weeks time. >>>>>> >>>>>> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: >>>>>>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: >>>>>>> >>>>>>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects >>>>>>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). >>>>>>> >>>>>>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. >>>>>>> >>>>>>> >>>>>>> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: >>>>>>> >>>>>>>> Is it feasible to make it mora native to Mac? Interesting? >>>>>>>> >>>>>>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: >>>>>>>>> It draws all the controls itself. >>>>>>>>> The Mac version is the X Windows version. >>>>>>>>> >>>>>>>>> - Jay >>>>>>>>> >>>>>>>>> ---------------------------------------- >>>>>>>>>> From: dragisha at m3w.org >>>>>>>>>> To: m3devel at elegosoft.com >>>>>>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 >>>>>>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? >>>>>>>>>> >>>>>>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on >>>>>>>>>> Windows? What about Mac? >>>>>>>>>> -- >>>>>>>>>> Dragi?a Duri? >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dragi?a Duri? >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Dragi?a Duri? >>>>>> >>>> >> From wagner at elegosoft.com Tue Sep 28 11:12:23 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 28 Sep 2010 11:12:23 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org> <1285447327.3009.0.camel@boromir.m3w.org> <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> <1285654984.6634.18.camel@boromir.m3w.org> Message-ID: <20100928111223.zuty1ilds0gs4c0c@mail.elegosoft.com> Quoting Darko : > I agree that GUIs should look native because that's what user's > want. If you're interested in experimenting with Mac interfaces > there is fairly complete Carbon API implemented by the Mac module > which I think is in the repository. Where would that be? It would be nice if all GUI extensions could be checked-in to the cm3 repository, no matter whether they are for Trestle or native interfaces. That is, only if you are able and willing to contribute the code under an open source license of course. 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 darko at darko.org Tue Sep 28 12:03:47 2010 From: darko at darko.org (Darko) Date: Tue, 28 Sep 2010 03:03:47 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <20100928111223.zuty1ilds0gs4c0c@mail.elegosoft.com> References: <1285414879.3024.0.camel@boromir.m3w.org> <1285447327.3009.0.camel@boromir.m3w.org> <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> <1285654984.6634.18.camel@boromir.m3w.org> <20100928111223.zuty1ilds0gs4c0c@mail.elegosoft.com> Message-ID: <614B8DBB-2ECE-4D91-88DB-E4399C84EF3E@darko.org> Ok, maybe I didn't, I checked in the tools that created the interface. The API file itself is 3.2MB, will this upset anyone? On 28/09/2010, at 2:12 AM, Olaf Wagner wrote: > Quoting Darko : > >> I agree that GUIs should look native because that's what user's want. If you're interested in experimenting with Mac interfaces there is fairly complete Carbon API implemented by the Mac module which I think is in the repository. > > Where would that be? > > It would be nice if all GUI extensions could be checked-in to > the cm3 repository, no matter whether they are for Trestle or native > interfaces. That is, only if you are able and willing to contribute > the code under an open source license of course. > > 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 dmuysers at hotmail.com Tue Sep 28 11:59:19 2010 From: dmuysers at hotmail.com (Dirk Muysers) Date: Tue, 28 Sep 2010 11:59:19 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> Message-ID: The one that could be ported with only minimal work would be IUP (Portable User Interface) It looks native on Windows, Motif, and GTK+ and has a string-based API which makes it particularly easy to port. On Windows it allows only Latin-1 text for the moment, but the next version will have a unified UTF-8 interface. -------------------------------------------------- From: "Jay K" Sent: Tuesday, September 28, 2010 10:47 AM To: "Darko (M3)" Cc: "m3devel" Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > > but Mac OS APIs almost never change > > > Mostly agreed. > But there can be silent breaks when only linking gets checked. > At least libc across various systems has a bad track record. > > > I think therefore we're talking about generating wrapper libraries, more or less idiomatic. > > > > or on Windows the user can change the look whenever they want. > > This is actually allowed for to some extent. > It is the point of GetSysColor. > > > "Native" would be good imho because it just generally looks so much better. > However it leads to loss of portability. > I would really rather see KDE or wxWidgets or somesuch. > They do look close to native and do things themselves to varying degrees. > > > Look at our WinBase.i3 for a feel for what people have done in the past. > That is seemingly a direct hand written translation. > Do that for a few functions/structs? > And then automate it somehow? > There is "gccxml" that parses headers and spits out xml, you can then use xml-dom or xsl etc. > There might also be enough runtime type information in Macintosh binaries, to save you from parsing declarations. > > > Realize Carbon is dying to some degree -- stuff not being ported to 64bit. > > > > - Jay > > > ---------------------------------------- >> From: darko at darko.org >> Date: Tue, 28 Sep 2010 01:39:40 -0700 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >> I think the point is that GUI support for Cocoa and Windows is useful to myself and possibly other people, I'm not really counting how many platforms it will work on - I need those two platforms and I need them native. Actually I need Carbon and Windows right now but Cocoa would be very nice. >> >> Implementing Trestle to look like Cocoa would be non-trivial, and pointless. The idea is that you want your GUI to change when the underlying OS changes, which it does very regularly, or on Windows the user can change the look whenever they want. >> >> As far as static breaks go, there would be links to library calls so when they change the linking would break, but Mac OS APIs almost never change, they just get updated with new calls so it wouldn't really be a problem. I don't know if there is any subtle issues wrt Obj-C but I doubt it. >> >> >> On 28/09/2010, at 1:26 AM, Jay K wrote: >> >> > >> > I think you have a few unrelated choices: >> > >> > >> > Make Trestle look like Macintosh when on Macintosh. >> > This is altering some low level drawing code, mouse logic. Doable. >> > It has little/nothing to do with Objective C or Cocoa. >> > >> > >> > Wrap other GUI libraries. >> > There are many to chose from. >> > With more or less idiomatic wrappers. >> > If you are going to do this, please do something that runs on more than one system. >> > KDE, wxWidgets, FLTK, GTk+, etc. >> > But GTk+ doesn't seem well supported on Windows. >> > KDE would be my choice. It looks good, it seems to be fairly nice, complete, and evolving fairly rapidly, it has money behind it. >> > An idiomatic wrapper for Cocoa is just one GUI library you could wrap, and it'd have the least value since it only runs on one system. Granted, a slowly growing in popularity system, and iPhone. >> > >> > >> > If you get the hang of things, sure, go all out, wrap several. Please. >> > >> > >> > SWIG might be useful here. >> > >> > >> > Please whatever it is, make sure it gets static checking. >> > Assume the C/C++ headers underneath you will change, and you want a compilation break when that happens. Instead of silent memory corruption. >> > >> > >> > I don't think Trestle implemented on top of Cocoa makes much sense. >> > It does make some. Using CoreGraphics instead of X Windows. Using Carbon or Cocoa event manager instead of X Windows. >> > But given that Trestle draws things itself, "porting" analogous to where the Win32 layer varies from the X layer, wouldn't give you something that looks like Macintosh. >> > >> > >> > >> > - Jay >> > >> > ---------------------------------------- >> >> From: darko at darko.org >> >> Date: Mon, 27 Sep 2010 23:47:06 -0700 >> >> To: jay.krell at cornell.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >> >> >> I think that's the problem with implementing Trestle on another GUI, it's too idiosyncratic in its structure. Generated Obj-C interfaces using OBJECT are definitely the way to go. It mostly involves a thin layer but all field access is done using functions from what I understand so it won't be completely natural without some syntax extensions to M3. The question is if it matters. >> >> >> >> >> >> On 27/09/2010, at 11:38 PM, Jay K wrote: >> >> >> >>> >> >>> I think what is a bit unusual about Trestle is how much it implements itself. >> >>> >> >>> >> >>> It does *not* appear to be a thin wrapper around a native event or control or window management interface. It appears to handle event routing itself, clipping itself, some aspects of drawing itself. I think it might only depend on the ability to draw dots, and to get some form of keyboard/mouse events. >> >>> >> >>> >> >>> *and* it is multithreaded. >> >>> Unusual for GUI libraries (e.g. Java swing). >> >>> >> >>> >> >>> Whenever I read about it, I get lost once they start talking about the locking protocol. >> >>> >> >>> >> >>> The "split" layout mechanism seems maybe nice. >> >>> It bugs me how Windows encouraged pixel count layout and how much fixed size gui there is. >> >>> >> >>> >> >>> I suspect the authors knew or discovered far more than any of us here. >> >>> >> >>> >> >>> You probably can make a decent binding to Cocoa. >> >>> But I don't know. >> >>> >> >>> >> >>> Runtime and compiler support, often allow for nicer syntax, but I really don't know if a mere wrapper library will be nice/graceful or not. I would suggest looking into if you have enough "generation" ability to, e.g. spit the headers back out, or generate a nicer C++ library. And then you can probably without much difficulty make either a "straightforward" wrapper library or maybe even something a bit more idiomatic ... e.g. do you use OBJECT or not? >> >>> >> >>> >> >>>> Trestle under X did not took my breath >> >>> >> >>> >> >>> I find Trestle GUI pretty difficult to interact with. >> >>> Using scrollbars for example. >> >>> I have trouble with most X GUI actually. >> >>> >> >>> >> >>> The Win32 changes are a bit encouraging though. With only a little bit of change the GUI is a slightly less little bit better. We still don't have the dpi problem fixed properly. I don't have a high dpi system. >> >>> >> >>> >> >>> Qt looks very nice... >> >>> >> >>> >> >>> - Jay >> >>> >> >>> ---------------------------------------- >> >>>> From: dragisha at m3w.org >> >>>> To: darko at darko.org >> >>>> Date: Tue, 28 Sep 2010 08:23:04 +0200 >> >>>> CC: m3devel at elegosoft.com >> >>>> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >>>> >> >>>> I am about to do a port of some simple (in its GUI aspect) application >> >>>> to Mac. >> >>>> >> >>>> I am also discouraged (at least tried to) to near death :) by a guy from >> >>>> another community, he is 1000% sure Modula-3 cannot be made to support >> >>>> Cocoa not a "g" of gracefully. >> >>>> >> >>>> Trestle under X did not took my breath. After peeking and pooking around >> >>>> sources a bit, I think it was very nice project in its time, and >> >>>> reasonable one to use 12-15yrs ago, but things moved on. In other words >> >>>> - I cannot think an explanation to my customer why a GUI appliction of >> >>>> mine is not more.... GUIsh... >> >>>> >> >>>> I did a lot of Gtk+ in Modula-3, under Linux (and colleague did his >> >>>> testing on Windows while he was working with me on it) and from that >> >>>> experience I know it's not impossible to make native GUI work. >> >>>> >> >>>> In other words - count on me for low level binding/interfacing once I >> >>>> start doing my work on Mac - in few weeks time. >> >>>> >> >>>> On Mon, 2010-09-27 at 13:12 -0700, Darko wrote: >> >>>>> I can't say I'm interested in Trestle, and getting compatibility with Cocoa objects might be a hassle, but I am interested in Cocoa support in M3. The things that need to be done to make this happen are: >> >>>>> >> >>>>> - run time support for Objective-C objects, basically the ability to call Obj-C methods and reference Obj-C fields in objects >> >>>>> - conversion of Cocoa interfaces to M3. This can probably be automated to some degree, I've already gone through the process with Carbon API (admittedly from Pascal interfaces). >> >>>>> >> >>>>> If anyone wants to take on the first task I'd be happy to take on the second. Apple has Obj-C internals doco on the web. >> >>>>> >> >>>>> >> >>>>> On 25/09/2010, at 1:42 PM, Dragi?a Duri? wrote: >> >>>>> >> >>>>>> Is it feasible to make it mora native to Mac? Interesting? >> >>>>>> >> >>>>>> On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: >> >>>>>>> It draws all the controls itself. >> >>>>>>> The Mac version is the X Windows version. >> >>>>>>> >> >>>>>>> - Jay >> >>>>>>> >> >>>>>>> ---------------------------------------- >> >>>>>>>> From: dragisha at m3w.org >> >>>>>>>> To: m3devel at elegosoft.com >> >>>>>>>> Date: Sat, 25 Sep 2010 13:41:19 +0200 >> >>>>>>>> Subject: [M3devel] UI, Trestle, native... Cocoa?? >> >>>>>>>> >> >>>>>>>> Anybody working UI's with Trestle? It is mapped no native widgets on >> >>>>>>>> Windows? What about Mac? >> >>>>>>>> -- >> >>>>>>>> Dragi?a Duri? >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Dragi?a Duri? >> >>>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> Dragi?a Duri? >> >>>> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 28 12:38:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Sep 2010 10:38:21 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <614B8DBB-2ECE-4D91-88DB-E4399C84EF3E@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, , <1285447327.3009.0.camel@boromir.m3w.org>, <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, <1285654984.6634.18.camel@boromir.m3w.org>, , <20100928111223.zuty1ilds0gs4c0c@mail.elegosoft.com>, <614B8DBB-2ECE-4D91-88DB-E4399C84EF3E@darko.org> Message-ID: ?> The API file itself is 3.2MB, will this upset anyone? jbook2:m3cc jay$ du -hs gc* 105M??? gcc 116M??? gcc-4.5 ?64M??? gcc-apple jbook2:m3cc jay$ du -hs ../m3gdb/ 111M??? ../m3gdb/ Clearly you have done an inaduate job producing such a small file. :) jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/win32/ 1.1M??? /dev2/cm3/m3-libs/m3core/src/win32/ jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/unix/ 416K??? /dev2/cm3/m3-libs/m3core/src/unix/ jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/runtime/ 1.1M??? /dev2/cm3/m3-libs/m3core/src/runtime/ jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src 5.9M??? /dev2/cm3/m3-libs/m3core/src book2:m3cc jay$ du -hs /dev2/cm3/m3-ui/X11R4/src 524K??? /dev2/cm3/m3-ui/X11R4/src it should be ok. ?- Jay ---------------------------------------- > From: darko at darko.org > Date: Tue, 28 Sep 2010 03:03:47 -0700 > To: wagner at elegosoft.com > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > Ok, maybe I didn't, I checked in the tools that created the interface. The API file itself is 3.2MB, will this upset anyone? > > > On 28/09/2010, at 2:12 AM, Olaf Wagner wrote: > > > Quoting Darko : > > > >> I agree that GUIs should look native because that's what user's want. If you're interested in experimenting with Mac interfaces there is fairly complete Carbon API implemented by the Mac module which I think is in the repository. > > > > Where would that be? > > > > It would be nice if all GUI extensions could be checked-in to > > the cm3 repository, no matter whether they are for Trestle or native > > interfaces. That is, only if you are able and willing to contribute > > the code under an open source license of course. > > > > 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 darko at darko.org Tue Sep 28 12:41:13 2010 From: darko at darko.org (Darko) Date: Tue, 28 Sep 2010 03:41:13 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org>, , <1285447327.3009.0.camel@boromir.m3w.org>, <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, <1285654984.6634.18.camel@boromir.m3w.org>, , <20100928111223.zuty1ilds0gs4c0c@mail.elegosoft.com>, <614B8DBB-2ECE-4D91-88DB-E4399C84EF3E@darko.org> Message-ID: Ok, but it's a *single file*, all those examples are directories. CVS is so creaky I didn't want to assume. On 28/09/2010, at 3:38 AM, Jay K wrote: > > > The API file itself is 3.2MB, will this upset anyone? > > jbook2:m3cc jay$ du -hs gc* > 105M gcc > 116M gcc-4.5 > 64M gcc-apple > jbook2:m3cc jay$ du -hs ../m3gdb/ > 111M ../m3gdb/ > > > Clearly you have done an inaduate job producing such a small file. :) > > > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/win32/ > 1.1M /dev2/cm3/m3-libs/m3core/src/win32/ > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/unix/ > 416K /dev2/cm3/m3-libs/m3core/src/unix/ > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/runtime/ > 1.1M /dev2/cm3/m3-libs/m3core/src/runtime/ > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src > 5.9M /dev2/cm3/m3-libs/m3core/src > > book2:m3cc jay$ du -hs /dev2/cm3/m3-ui/X11R4/src > 524K /dev2/cm3/m3-ui/X11R4/src > > it should be ok. > > - Jay > > > ---------------------------------------- >> From: darko at darko.org >> Date: Tue, 28 Sep 2010 03:03:47 -0700 >> To: wagner at elegosoft.com >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? >> >> Ok, maybe I didn't, I checked in the tools that created the interface. The API file itself is 3.2MB, will this upset anyone? >> >> >> On 28/09/2010, at 2:12 AM, Olaf Wagner wrote: >> >>> Quoting Darko : >>> >>>> I agree that GUIs should look native because that's what user's want. If you're interested in experimenting with Mac interfaces there is fairly complete Carbon API implemented by the Mac module which I think is in the repository. >>> >>> Where would that be? >>> >>> It would be nice if all GUI extensions could be checked-in to >>> the cm3 repository, no matter whether they are for Trestle or native >>> interfaces. That is, only if you are able and willing to contribute >>> the code under an open source license of course. >>> >>> 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 Tue Sep 28 12:49:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Sep 2010 10:49:31 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , <1285447327.3009.0.camel@boromir.m3w.org>, , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <20100928111223.zuty1ilds0gs4c0c@mail.elegosoft.com>, , <614B8DBB-2ECE-4D91-88DB-E4399C84EF3E@darko.org>, , Message-ID: jbook2:gcc jay$ ls -lh MD* -rw-r--r--? 1 jay? staff?? 4.6M Sep 24 04:56 MD5SUMS jbook2:gcc jay$ pwd /dev2/cm3/m3-sys/m3cc/gcc ?- Jay ---------------------------------------- > From: darko at darko.org > Date: Tue, 28 Sep 2010 03:41:13 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > Ok, but it's a *single file*, all those examples are directories. CVS is so creaky I didn't want to assume. > > > On 28/09/2010, at 3:38 AM, Jay K wrote: > > > > > > The API file itself is 3.2MB, will this upset anyone? > > > > jbook2:m3cc jay$ du -hs gc* > > 105M gcc > > 116M gcc-4.5 > > 64M gcc-apple > > jbook2:m3cc jay$ du -hs ../m3gdb/ > > 111M ../m3gdb/ > > > > > > Clearly you have done an inaduate job producing such a small file. :) > > > > > > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/win32/ > > 1.1M /dev2/cm3/m3-libs/m3core/src/win32/ > > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/unix/ > > 416K /dev2/cm3/m3-libs/m3core/src/unix/ > > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src/runtime/ > > 1.1M /dev2/cm3/m3-libs/m3core/src/runtime/ > > jbook2:m3cc jay$ du -hs /dev2/cm3/m3-libs/m3core/src > > 5.9M /dev2/cm3/m3-libs/m3core/src > > > > book2:m3cc jay$ du -hs /dev2/cm3/m3-ui/X11R4/src > > 524K /dev2/cm3/m3-ui/X11R4/src > > > > it should be ok. > > > > - Jay > > > > > > ---------------------------------------- > >> From: darko at darko.org > >> Date: Tue, 28 Sep 2010 03:03:47 -0700 > >> To: wagner at elegosoft.com > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > >> > >> Ok, maybe I didn't, I checked in the tools that created the interface. The API file itself is 3.2MB, will this upset anyone? > >> > >> > >> On 28/09/2010, at 2:12 AM, Olaf Wagner wrote: > >> > >>> Quoting Darko : > >>> > >>>> I agree that GUIs should look native because that's what user's want. If you're interested in experimenting with Mac interfaces there is fairly complete Carbon API implemented by the Mac module which I think is in the repository. > >>> > >>> Where would that be? > >>> > >>> It would be nice if all GUI extensions could be checked-in to > >>> the cm3 repository, no matter whether they are for Trestle or native > >>> interfaces. That is, only if you are able and willing to contribute > >>> the code under an open source license of course. > >>> > >>> 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 mika at async.async.caltech.edu Wed Sep 29 09:50:52 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 29 Sep 2010 00:50:52 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> Message-ID: <20100929075052.B5BDD1A20B0@async.async.caltech.edu> Darko writes: ... >Several APIs I've done are by hand using several regular expression = >search and replaces. Automating it is relatively easy because it doesn't = >have to be completely general, it only has to parse the header files you = >are targeting, not every C syntactic construct, which would be a very = >bad trip. When I did the Mac Carbon APIs I had a file of exceptions = >which handled the "too hard basket" of declarations. Trying to use the = >more powerful tools just means you have a steep learning curve and you = >end up with something messy and unpredictable which you have to hack = >anyway. ... My advice would be not to parse C at all. Just translate the reference manual's specs into some specification language (I use Scheme or Modula-3 but you could use XML) and generate glue code in both C and Modula-3. It's a lot saner... you can use your regex translation machine the first time of course, but then maintain the linkage in a language that actually specifies things properly. Mika From dragisha at m3w.org Wed Sep 29 09:55:03 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 29 Sep 2010 09:55:03 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <20100929075052.B5BDD1A20B0@async.async.caltech.edu> References: <1285414879.3024.0.camel@boromir.m3w.org> , , , , , , <1285447327.3009.0.camel@boromir.m3w.org> , , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> , , , <1285654984.6634.18.camel@boromir.m3w.org> , , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> , , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> Message-ID: <1285746903.2775.16.camel@boromir.m3w.org> Why don't use swig? Ref manual route is sanest, escaping all .h mumbo jumbo, but it's also with most work involved... On Wed, 2010-09-29 at 00:50 -0700, Mika Nystrom wrote: > My advice would be not to parse C at all. Just translate the > reference manual's > specs into some specification language (I use Scheme or Modula-3 but > you could > use XML) and generate glue code in both C and Modula-3. It's a lot > saner... > you can use your regex translation machine the first time of course, > but then > maintain the linkage in a language that actually specifies things > properly. > > -- Dragi?a Duri? From jay.krell at cornell.edu Wed Sep 29 10:00:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Sep 2010 08:00:55 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285746903.2775.16.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org>,, , , ,, , , <1285447327.3009.0.camel@boromir.m3w.org>,, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>,, , , <1285654984.6634.18.camel@boromir.m3w.org>,, , ,, , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>,, ,, <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org>, , , <20100929075052.B5BDD1A20B0@async.async.caltech.edu>, <1285746903.2775.16.camel@boromir.m3w.org> Message-ID: There are several obvious approaches, with several obvious tradeoffs. I've used regexps surprisingly successfully. Manual from documentation is very voluminous/tedious. Headers are generally such a subset of C that writing a parser is not too impossible. ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: mika at async.async.caltech.edu > Date: Wed, 29 Sep 2010 09:55:03 +0200 > CC: m3devel at elegosoft.com; darko at darko.org > Subject: Re: [M3devel] UI, Trestle, native... Cocoa?? > > Why don't use swig? > > Ref manual route is sanest, escaping all .h mumbo jumbo, but it's also > with most work involved... > > On Wed, 2010-09-29 at 00:50 -0700, Mika Nystrom wrote: > > My advice would be not to parse C at all. Just translate the > > reference manual's > > specs into some specification language (I use Scheme or Modula-3 but > > you could > > use XML) and generate glue code in both C and Modula-3. It's a lot > > saner... > > you can use your regex translation machine the first time of course, > > but then > > maintain the linkage in a language that actually specifies things > > properly. > > > > > -- > Dragi?a Duri? > From dragisha at m3w.org Wed Sep 29 10:05:50 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 29 Sep 2010 10:05:50 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org> ,, , , ,, , , <1285447327.3009.0.camel@boromir.m3w.org> ,, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> ,, , , <1285654984.6634.18.camel@boromir.m3w.org> ,, , ,, , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> ,, ,, <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> , , ,<20100929075052.B5BDD1A20B0@async.async.caltech.edu> ,<1285746903.2775.16.camel@boromir.m3w.org> Message-ID: <1285747550.2775.18.camel@boromir.m3w.org> C hader files to AST's... And manipulation with some scripting (fast turnaround) lang from there... But... before cpp or after cpp? On Wed, 2010-09-29 at 08:00 +0000, Jay K wrote: > There are several obvious approaches, with several obvious tradeoffs. > I've used regexps surprisingly successfully. > Manual from documentation is very voluminous/tedious. > Headers are generally such a subset of C that writing a parser is not > too impossible. -- Dragi?a Duri? From darko at darko.org Wed Sep 29 11:01:12 2010 From: darko at darko.org (Darko) Date: Wed, 29 Sep 2010 02:01:12 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <20100929075052.B5BDD1A20B0@async.async.caltech.edu> References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> Message-ID: <6B65B727-AD08-4928-AEDF-9773BD97D1B9@darko.org> The only specification there is is the headers. The reference manual is a collection of annotated headers, much like M3's library documentation. Why introduce an intermediate representation? The APIs are usually quite straight forward and use a very limited subset of C, namely constant, type and function declarations which can readily be parsed. More problematic things like elaborate macros are seldom used and often can be taken literally instead of being evaluated properly. The trickiest things to parse are function pointer declarations, and there are usually so few of those that you can do them manually. I don't understand where the payoff is in doing anything else when there is no way of reliably automating it and making it output something clean, putting you back to square one and having to hack anyway. A hacked parser of a C subset is the most direct and reliable route I think. I already have a little "programmable" parser which is half way there. It understands expressions with function call syntax and lets you define infix, postfix, prefix and groupfix (eg "{ ... }") operators with precedence. With a couple of extensions I think I can make the headers look like a series of simple declaration expressions. Throw in an exception mechanism which lets you insert hand made expressions when you encounter specific symbols and it's done (plus generating the M3 interfaces, of course). On 29/09/2010, at 12:50 AM, Mika Nystrom wrote: > Darko writes: > ... >> Several APIs I've done are by hand using several regular expression = >> search and replaces. Automating it is relatively easy because it doesn't = >> have to be completely general, it only has to parse the header files you = >> are targeting, not every C syntactic construct, which would be a very = >> bad trip. When I did the Mac Carbon APIs I had a file of exceptions = >> which handled the "too hard basket" of declarations. Trying to use the = >> more powerful tools just means you have a steep learning curve and you = >> end up with something messy and unpredictable which you have to hack = >> anyway. > ... > > My advice would be not to parse C at all. Just translate the reference manual's > specs into some specification language (I use Scheme or Modula-3 but you could > use XML) and generate glue code in both C and Modula-3. It's a lot saner... > you can use your regex translation machine the first time of course, but then > maintain the linkage in a language that actually specifies things properly. > > Mika From mika at async.async.caltech.edu Wed Sep 29 11:45:14 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 29 Sep 2010 02:45:14 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285746903.2775.16.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org> , , , , , , <1285447327.3009.0.camel@boromir.m3w.org> , , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> , , , <1285654984.6634.18.camel@boromir.m3w.org> , , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> , , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> <1285746903.2775.16.camel@boromir.m3w.org> Message-ID: <20100929094514.55BA61A20AE@async.async.caltech.edu> Well last time I tried it, its Modula-3 support seemed rather buggy... but sure, if it works. Mika =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Why don't use swig? > >Ref manual route is sanest, escaping all .h mumbo jumbo, but it's also >with most work involved... > >On Wed, 2010-09-29 at 00:50 -0700, Mika Nystrom wrote: >> My advice would be not to parse C at all. Just translate the >> reference manual's >> specs into some specification language (I use Scheme or Modula-3 but >> you could >> use XML) and generate glue code in both C and Modula-3. It's a lot >> saner... >> you can use your regex translation machine the first time of course, >> but then >> maintain the linkage in a language that actually specifies things >> properly. >> >> >-- >Dragi??a Duri?? From mika at async.async.caltech.edu Wed Sep 29 11:53:09 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Wed, 29 Sep 2010 02:53:09 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <6B65B727-AD08-4928-AEDF-9773BD97D1B9@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> <6B65B727-AD08-4928-AEDF-9773BD97D1B9@darko.org> Message-ID: <20100929095309.CBBA61A20AD@async.async.caltech.edu> Darko writes: ... > >I don't understand where the payoff is in doing anything else when there = >is no way of reliably automating it and making it output something = >clean, putting you back to square one and having to hack anyway. A = ... As long as you also generate syntax-correct C code from a higher-level specification there should be no extra "hacking" involved. The main thing you can get with a higher-level representation is the same thing you get with .i3s: annotation of memory management. If your library allocates and deallocates objects, you can then automatically generate wrappers that use WeakRefs for instance. (If you like.) Or you can generate another, totally different interface automatically (the one on the "other side" of the glue code). There are many things you can do with a suitable higher-level specification that you can't do with .h files alone... Sorry, I mean there are many guarantees you can provide that you can't get with .h files. Generally there are too many things you can do with .h files that you really don't want to do... And in my experience C headers sometimes use nasty things. Macros are a pain for instance. Sure you can make syntactically correct .i3s fairly easily, but there is no way of knowing how to call them from reading just the .h; the programmer is reduced to reading machine-generated interfaces, which is never a pleasant thing. Mika From darko at darko.org Wed Sep 29 12:16:37 2010 From: darko at darko.org (Darko) Date: Wed, 29 Sep 2010 03:16:37 -0700 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <20100929095309.CBBA61A20AD@async.async.caltech.edu> References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> <6B65B727-AD08-4928-AEDF-9773BD97D1B9@darko.org> <20100929095309.CBBA61A20AD@async.async.caltech.edu> Message-ID: <2BBD172C-ACDD-4F62-B27C-4D471A82898C@darko.org> I agree there is benefit in having some high level semantics, but they can be easily derived or entered manually in a high level spec that complements what has been parsed. The tool can accommodate those requirements. But most of the work is getting the declaration information and that's not practical to do manually. For instance the Carbon interfaces I translated resulted in an interface file with over 60,000 lines. The Cocoa interfaces are somewhere in the order of 5 - 10 times that size and growing. I'm not suggesting macros should be attempted to be parsed and I think no programmer can code without referring to the reference manual. In most cases the text that is in the reference manuals for Cocoa is derived from comments in the header files. One of the benefits of your own tool is that you have a high degree of control over the translation and that means you can make the generated interface more predicable, making the reference material more useful. For instance when the Carbon interfaces were translated the C idiom of passing pointers in function call parameters was converted to VAR parameters in M3 since that was the intention in 99% of cases. On 29/09/2010, at 2:53 AM, Mika Nystrom wrote: > Darko writes: > ... >> >> I don't understand where the payoff is in doing anything else when there = >> is no way of reliably automating it and making it output something = >> clean, putting you back to square one and having to hack anyway. A = > ... > > As long as you also generate syntax-correct C code from a higher-level > specification there should be no extra "hacking" involved. > > The main thing you can get with a higher-level representation is the > same thing you get with .i3s: annotation of memory management. If your > library allocates and deallocates objects, you can then automatically > generate wrappers that use WeakRefs for instance. (If you like.) > Or you can generate another, totally different interface automatically > (the one on the "other side" of the glue code). There are many things > you can do with a suitable higher-level specification that you can't do > with .h files alone... Sorry, I mean there are many guarantees you can > provide that you can't get with .h files. Generally there are too many > things you can do with .h files that you really don't want to do... > > And in my experience C headers sometimes use nasty things. Macros are a > pain for instance. Sure you can make syntactically correct .i3s fairly > easily, but there is no way of knowing how to call them from reading just > the .h; the programmer is reduced to reading machine-generated interfaces, > which is never a pleasant thing. > > Mika From dragisha at m3w.org Wed Sep 29 12:39:02 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 29 Sep 2010 12:39:02 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <20100929094514.55BA61A20AE@async.async.caltech.edu> References: <1285414879.3024.0.camel@boromir.m3w.org> , , , , , , <1285447327.3009.0.camel@boromir.m3w.org> , , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org> , , , <1285654984.6634.18.camel@boromir.m3w.org> , , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org> , , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> <1285746903.2775.16.camel@boromir.m3w.org> <20100929094514.55BA61A20AE@async.async.caltech.edu> Message-ID: <1285756742.2775.19.camel@boromir.m3w.org> Direct to Modula-3 sources is one possible way. But there is also XML route. What we need is someone else to parse C for us first. On Wed, 2010-09-29 at 02:45 -0700, Mika Nystrom wrote: > > Well last time I tried it, its Modula-3 support seemed rather buggy... > but > sure, if it works. > > Mika > > =?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: > >Why don't use swig? -- Dragi?a Duri? From rodney_bates at lcwb.coop Wed Sep 29 18:47:46 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 29 Sep 2010 11:47:46 -0500 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <6B65B727-AD08-4928-AEDF-9773BD97D1B9@darko.org> References: <1285414879.3024.0.camel@boromir.m3w.org>, , , , , , <1285447327.3009.0.camel@boromir.m3w.org>, , , <193B0D3A-5D86-420D-9D05-C1A0FAF08A0D@darko.org>, , , <1285654984.6634.18.camel@boromir.m3w.org>, , , , <7406E83B-2377-4436-8ABD-F2AFE0D54D2F@darko.org>, , <3AA011EE-CDEE-463E-B2D3-E277D843B8FC@darko.org> <20100929075052.B5BDD1A20B0@async.async.caltech.edu> <6B65B727-AD08-4928-AEDF-9773BD97D1B9@darko.org> Message-ID: <4CA36DB2.9070903@lcwb.coop> Darko wrote: > > I don't understand where the payoff is in doing anything else when there is no way of reliably automating it and making it > output something clean, putting you back to square one and having to hack anyway. A hacked parser of a C subset is the > most direct and reliable route I think. I already have a little "programmable" parser which is half way there. It > understands expressions with function call syntax and lets you define infix, postfix, prefix and groupfix (eg "{ ... }") > operators with precedence. With a couple of extensions I think I can make the headers look like a series of simple > declaration expressions. Throw in an exception mechanism which lets you insert hand made expressions when you encounter > specific symbols and it's done (plus generating the M3 interfaces, of course). > > Hmm. I once wrote a C parser using Cocktail rex/lalr, with either Modula-2 or Modula-3 semantic actions to build an AST. The really tricky part was unwinding C's half-inside-out syntax for type definitions. Without jumping into the wars over which way is inside-out, C is nonetheless inconsistent. Declarators are the unusual way, but only with respect to one type, function parameters and array bounds being the usual way. Programmer-defined specifiers are the usual way. Putting this into an AST involves selectively inverting, if it is to be an AS that makes any sense of the recursive system of type constructors and type definitions. Maybe I could drag that one out and spruce it up some way. OTOH, C programmers almost never actually use the recursive system of types except for a few well-known idioms of fixed shape and depth, so maybe a parser/AST builder that only handles a severe subset is adequate. From darko at darko.org Thu Sep 30 05:32:38 2010 From: darko at darko.org (Darko) Date: Wed, 29 Sep 2010 20:32:38 -0700 Subject: [M3devel] Compiler crash Message-ID: <49BF0F40-B717-4F3C-8CA8-B5F1939956A6@darko.org> Came across this today while compiling: PROCEDURE NewArray(tc: INTEGER; d1, d2, d3, d4: CARDINAL := 0): Val = VAR d: CARDINAL; BEGIN RETURN RTAllocator.NewTracedArray(tc, SUBARRAY(IntArray{d1, d2, d3, d4}, 0, d)); END NewArray; (Yes, It's not finished and won't work until d is assigned a number between 1 and 4) *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/exprs/Expr.m3", line 308 *** $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-14 21:27:23 configuration: /Users/darko/app/cm3/bin/cm3.cfg host: I386_DARWIN target: I386_DARWIN $ uname -a Darwin Lucifer.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 I'm willing to wager it's still in the latest release. - Darko From jay.krell at cornell.edu Thu Sep 30 13:14:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Sep 2010 11:14:45 +0000 Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg? Message-ID: So..we can't fully cross build a 64bit target from a 32bit host because some code wants to declare arrays that fill memory, like so that indexing them never fails an overflow check: TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example I'm faced with a few choices: ?- do nothing ?- have the front end pin the sizes to its maximum ??? Leading to such code to fail if it actually operates on data larger than 2GB ?- use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less ?- use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long", ???? (roughly: "long" suffices instead on most 64bit systems) ? - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c Extremely similarly btw: TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example TYPE T2 = RECORD a,b,c:T1; END; which is just to say, it isn't just about total array sizes, but also field offsets. (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...) I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code. e.g. m3front/src/types/Type.i3/Info, and then all its users. Should these types use a different and unsafe form? Do we have a convenient unsafe form? ?- Jay From dragisha at m3w.org Thu Sep 30 13:24:29 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 30 Sep 2010 13:24:29 +0200 Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg? In-Reply-To: References: Message-ID: <1285845869.2729.7.camel@boromir.m3w.org> I went this route a decade or so ago... When I was porting pm3 to Linux/ALPHA... John Polstra employed same technique later for ezm3... Standard bootstrap process splits build process at assembly level. For Windows it is split at object code level. What I did was to split it ad GCC "IR" level. that way, 32->64 bit crosscompiler was never required. On Thu, 2010-09-30 at 11:14 +0000, Jay K wrote: > So..we can't fully cross build a 64bit target from a 32bit host > because some code > wants to declare arrays that fill memory, like so that indexing them > never fails > an overflow check: > > > -- Dragi?a Duri? From hosking at cs.purdue.edu Thu Sep 30 15:35:15 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Sep 2010 09:35:15 -0400 Subject: [M3devel] Compiler crash In-Reply-To: <49BF0F40-B717-4F3C-8CA8-B5F1939956A6@darko.org> References: <49BF0F40-B717-4F3C-8CA8-B5F1939956A6@darko.org> Message-ID: I believe this is a known defect, but can you please enter a bug report into the online bug tracker? For now, you can try expressing it in a slightly different way to get round the compiler problem (separate the IntArray as a separate variable). On 29 Sep 2010, at 23:32, Darko wrote: > Came across this today while compiling: > > PROCEDURE NewArray(tc: INTEGER; d1, d2, d3, d4: CARDINAL := 0): Val = > VAR > d: CARDINAL; > BEGIN > RETURN RTAllocator.NewTracedArray(tc, SUBARRAY(IntArray{d1, d2, d3, d4}, 0, d)); > END NewArray; > > (Yes, It's not finished and won't work until d is assigned a number between 1 and 4) > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/exprs/Expr.m3", line 308 > *** > > $ cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /Users/darko/app/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > $ uname -a > Darwin Lucifer.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 > > > I'm willing to wager it's still in the latest release. > > - Darko > From hosking at cs.purdue.edu Thu Sep 30 15:42:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Sep 2010 09:42:59 -0400 Subject: [M3devel] INTEGER vs. LONGINT vs. Target.Int in m3cg? In-Reply-To: References: Message-ID: <12EA8842-293E-4891-928A-B583756BBEBF@cs.purdue.edu> Whenever you cross build you should do a subsequent native bootstrap to eliminate those. On 30 Sep 2010, at 07:14, Jay K wrote: > > So..we can't fully cross build a 64bit target from a 32bit host because some code > wants to declare arrays that fill memory, like so that indexing them never fails > an overflow check: > > > TYPE T = ARRAY [0..LAST(INTEGER)] OF CHAR; for example > > > I'm faced with a few choices: > - do nothing > - have the front end pin the sizes to its maximum > Leading to such code to fail if it actually operates on data larger than 2GB > - use Target.Int a lot more, and in parse.c TARGET_INTEGER more, INTEGER less > - use LONGINT a lot more (zero vs. a lot), and in parse.c "long long" in place of "long", > (roughly: "long" suffices instead on most 64bit systems) > - possibly a hybrid of previous two: Target.Int in m3middle/m3front, long long in parse.c > > > Extremely similarly btw: > > > TYPE T1 = ARRAY [0..16_LAST(INTEGER) DIV 4] OF CHAR; for example > TYPE T2 = RECORD a,b,c:T1; END; > > > which is just to say, it isn't just about total array sizes, but also field offsets. > > > (I'll add the obvious: this is the sort of thing where C++ operator overloading really shines...) > > > > I'm dreading that the sort of conservative/portable answer -- Target.Int and TARGET_INTEGER, will touch *a lot* of code. > e.g. m3front/src/types/Type.i3/Info, and then all its users. > > Should these types use a different and unsafe form? > Do we have a convenient unsafe form? > > - Jay > From dragisha at m3w.org Thu Sep 30 22:41:00 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 30 Sep 2010 22:41:00 +0200 Subject: [M3devel] Windows... cm3... linking... Message-ID: <1285879260.3196.2.camel@boromir.m3w.org> Anybody doing this? What is m3makefile "magic" for it? -- Dragi?a Duri? From jay.krell at cornell.edu Wed Sep 1 01:09:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:09:56 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , Message-ID: I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. Yucky. I'm also going to try giving temporaries types. ?Another m3cg change like pop_struct. ?Given the latest internal error I saw. ?Maybe review m3cg for more missing type information. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > t1 must still be passed in registers. The ABI can't be changed by that. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 09:15:32 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > What happens if you take the address of t inside ActionLookup? > > What happens if you take the address of t1 inside main? > > > > On 31 Aug 2010, at 07:25, Jay K wrote: > > > > > > > > Given something like this: > > > > > > jbook2:p247 jay$ more 1.c > > > #include > > > > > > typedef struct { long code; long value; } T1; > > > > > > void ActionLookup(T1 t, long code, long value); > > > > > > void ActionLookup(T1 t, long code, long value) > > > { > > > assert(t.code == code); > > > assert(t.value == value); > > > } > > > > > > int main() > > > { > > > T1 t1 = {2,2}; > > > ActionLookup(t1, 2, 2); > > > return 0; > > > } > > > j > > > > > > > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > > > > > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > > Darn. > > > > > > > > > If m3cg were higher level this could be better. > > > > > > > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > > > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > > > > > > > Maybe we should have M3CG include field references? > > > > > > > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > > > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > > > > > > > - Jay > > > > > > From jay.krell at cornell.edu Wed Sep 1 01:05:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:05:08 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , Message-ID: t1 must still be passed in registers. The ABI can't be changed by that. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 09:15:32 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > What happens if you take the address of t inside ActionLookup? > What happens if you take the address of t1 inside main? > > On 31 Aug 2010, at 07:25, Jay K wrote: > > > > > Given something like this: > > > > jbook2:p247 jay$ more 1.c > > #include > > > > typedef struct { long code; long value; } T1; > > > > void ActionLookup(T1 t, long code, long value); > > > > void ActionLookup(T1 t, long code, long value) > > { > > assert(t.code == code); > > assert(t.value == value); > > } > > > > int main() > > { > > T1 t1 = {2,2}; > > ActionLookup(t1, 2, 2); > > return 0; > > } > > j > > > > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > Darn. > > > > > > If m3cg were higher level this could be better. > > > > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > > > > Maybe we should have M3CG include field references? > > > > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > > > > - Jay > > > From jay.krell at cornell.edu Wed Sep 1 01:13:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:13:04 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , Message-ID: Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. It might also be good to have the backend feed its computed sizes/alignments back to the front end. It'd be via more files. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 23:09:56 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > Yucky. > > I'm also going to try giving temporaries types. > Another m3cg change like pop_struct. > Given the latest internal error I saw. > Maybe review m3cg for more missing type information. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] a trouble with passing records by value.. > > Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > > > > t1 must still be passed in registers. The ABI can't be changed by that. > > > > - Jay > > > > ---------------------------------------- > > > From: hosking at cs.purdue.edu > > > Date: Tue, 31 Aug 2010 09:15:32 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > What happens if you take the address of t inside ActionLookup? > > > What happens if you take the address of t1 inside main? > > > > > > On 31 Aug 2010, at 07:25, Jay K wrote: > > > > > > > > > > > Given something like this: > > > > > > > > jbook2:p247 jay$ more 1.c > > > > #include > > > > > > > > typedef struct { long code; long value; } T1; > > > > > > > > void ActionLookup(T1 t, long code, long value); > > > > > > > > void ActionLookup(T1 t, long code, long value) > > > > { > > > > assert(t.code == code); > > > > assert(t.value == value); > > > > } > > > > > > > > int main() > > > > { > > > > T1 t1 = {2,2}; > > > > ActionLookup(t1, 2, 2); > > > > return 0; > > > > } > > > > j > > > > > > > > > > > > on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > > > > > > > > > > > However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > > > the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > > > but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > > > Darn. > > > > > > > > > > > > If m3cg were higher level this could be better. > > > > > > > > > > > > There should be a viable compromise where the parameter is passed in registers, and only "homed" > > > > to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > > > But given the inefficiency of field accesses, I'm not sure it is worth trying? > > > > > > > > > > > > Maybe we should have M3CG include field references? > > > > > > > > > > > > There is this basic problem that the interface between m3front and m3cc isn't really at the > > > > right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > > > > > > > > > > > - Jay > > > > > > > > > > From jay.krell at cornell.edu Wed Sep 1 01:19:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:19:48 +0000 Subject: [M3devel] break in cvsup Message-ID: "../src/FileAttr.m3", line 792: undefined (Utime.struct_timeval) "../src/FileAttr.m3", line 794: unknown qualification '.' (gettimeofday) "../src/FileAttr.m3", line 797: unknown qualification '.' (utimes) 3 errors encountered presumably my fault; can't look for a bit though, sorry ?- Jay From jay.krell at cornell.edu Wed Sep 1 01:53:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Aug 2010 23:53:26 +0000 Subject: [M3devel] break in cvsup In-Reply-To: References: Message-ID: oh probably just something dumb locally ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Tue, 31 Aug 2010 23:19:48 +0000 > Subject: [M3devel] break in cvsup > > > "../src/FileAttr.m3", line 792: undefined (Utime.struct_timeval) > "../src/FileAttr.m3", line 794: unknown qualification '.' (gettimeofday) > "../src/FileAttr.m3", line 797: unknown qualification '.' (utimes) > 3 errors encountered > > > presumably my fault; can't look for a bit though, sorry > > > - Jay > > > > > From jay.krell at cornell.edu Wed Sep 1 02:03:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 00:03:48 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 29 Aug 2010 13:15:44 +0200 > From: wagner at elegosoft.com > > BTW, CI is working quite well now, and produces nightly snapshots > that can be downloaded for almost all supported platforms, so this > is better than ever before. See > > http://hudson.modula3.com:8080/view/cm3-current/ > > for details. => http://www.opencm3.net/snaps/snapshot-index.html Nice! Even NT386 is working well enough (though with odd archive names :) ) ?- Jay From jay.krell at cornell.edu Wed Sep 1 02:13:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 00:13:03 +0000 Subject: [M3devel] break in cvsup In-Reply-To: References: , Message-ID: a backup in /Users/jay/dev2/cm3/m3-tools/cvsup.1/ can do that.. ?- Jay ---------------------------------------- > oh probably just something dumb locally > > - Jay > > ---------------------------------------- > > > > "../src/FileAttr.m3", line 792: undefined (Utime.struct_timeval) > > "../src/FileAttr.m3", line 794: unknown qualification '.' (gettimeofday) > > "../src/FileAttr.m3", line 797: unknown qualification '.' (utimes) > > 3 errors encountered > > > > presumably my fault; can't look for a bit though, sorry From hosking at cs.purdue.edu Wed Sep 1 02:58:07 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 20:58:07 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , Message-ID: <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> On 31 Aug 2010, at 19:09, Jay K wrote: > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > Yucky. I strongly advise against that hack. > I'm also going to try giving temporaries types. > Another m3cg change like pop_struct. > Given the latest internal error I saw. > Maybe review m3cg for more missing type information. This would be better... > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] a trouble with passing records by value.. >> Date: Tue, 31 Aug 2010 23:05:08 +0000 >> >> >> t1 must still be passed in registers. The ABI can't be changed by that. >> >> - Jay >> >> ---------------------------------------- >>> From: hosking at cs.purdue.edu >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] a trouble with passing records by value.. >>> >>> What happens if you take the address of t inside ActionLookup? >>> What happens if you take the address of t1 inside main? >>> >>> On 31 Aug 2010, at 07:25, Jay K wrote: >>> >>>> >>>> Given something like this: >>>> >>>> jbook2:p247 jay$ more 1.c >>>> #include >>>> >>>> typedef struct { long code; long value; } T1; >>>> >>>> void ActionLookup(T1 t, long code, long value); >>>> >>>> void ActionLookup(T1 t, long code, long value) >>>> { >>>> assert(t.code == code); >>>> assert(t.value == value); >>>> } >>>> >>>> int main() >>>> { >>>> T1 t1 = {2,2}; >>>> ActionLookup(t1, 2, 2); >>>> return 0; >>>> } >>>> j >>>> >>>> >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. >>>> >>>> >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. >>>> Darn. >>>> >>>> >>>> If m3cg were higher level this could be better. >>>> >>>> >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? >>>> >>>> >>>> Maybe we should have M3CG include field references? >>>> >>>> >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. >>>> >>>> >>>> - Jay >>>> >>> >> > From hosking at cs.purdue.edu Wed Sep 1 02:59:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 20:59:09 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , Message-ID: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> On 31 Aug 2010, at 19:13, Jay K wrote: > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. Why would it not? We specify alignment... > It might also be good to have the backend feed its computed sizes/alignments back to the front end. > It'd be via more files. YUCK!!!!!!!!! Not a good plan... > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> Date: Tue, 31 Aug 2010 23:09:56 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> >> >> I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. >> Yucky. >> >> I'm also going to try giving temporaries types. >> Another m3cg change like pop_struct. >> Given the latest internal error I saw. >> Maybe review m3cg for more missing type information. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] a trouble with passing records by value.. >>> Date: Tue, 31 Aug 2010 23:05:08 +0000 >>> >>> >>> t1 must still be passed in registers. The ABI can't be changed by that. >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>> >>>> What happens if you take the address of t inside ActionLookup? >>>> What happens if you take the address of t1 inside main? >>>> >>>> On 31 Aug 2010, at 07:25, Jay K wrote: >>>> >>>>> >>>>> Given something like this: >>>>> >>>>> jbook2:p247 jay$ more 1.c >>>>> #include >>>>> >>>>> typedef struct { long code; long value; } T1; >>>>> >>>>> void ActionLookup(T1 t, long code, long value); >>>>> >>>>> void ActionLookup(T1 t, long code, long value) >>>>> { >>>>> assert(t.code == code); >>>>> assert(t.value == value); >>>>> } >>>>> >>>>> int main() >>>>> { >>>>> T1 t1 = {2,2}; >>>>> ActionLookup(t1, 2, 2); >>>>> return 0; >>>>> } >>>>> j >>>>> >>>>> >>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. >>>>> >>>>> >>>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, >>>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, >>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. >>>>> Darn. >>>>> >>>>> >>>>> If m3cg were higher level this could be better. >>>>> >>>>> >>>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" >>>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. >>>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? >>>>> >>>>> >>>>> Maybe we should have M3CG include field references? >>>>> >>>>> >>>>> There is this basic problem that the interface between m3front and m3cc isn't really at the >>>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. >>>>> >>>>> >>>>> - Jay >>>>> >>>> >>> >> > From jay.krell at cornell.edu Wed Sep 1 03:45:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 01:45:44 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> References: , ,,, , , , , , , <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> Message-ID: Both the frontend and backend seem to layout types. This is bad. I know we pass sizes/alignments to the backend, but to what extent does it have its own notions and make its own decisions? I don't fully know. It is ok if they agree, but they absolutely must agree. I suppose it is much less bad, and maybe they can disagree, because we never access fields, from the backend's point of view -- so it doesn't matter much if it thinks they are elsewhere. But what about e.g. the overall size of a record? We don't specify the layout of stack frames I believe. Perhaps we should? Perhaps every function should have one "big" local record that contains its locals? This will lead to increase correctness by decreased mismatch between backend and frontend, but it would also tie the optimizer's hand a bunch, e.g. no "stack packing" (placing locals in the same location if their lifetimes don't overlap), no removal of unused locals. There is I believe a real mismatch between the frontend and backend. I'm wondering if my feeding any type information to the backend is such a good idea afterall. It provides wonderful improvements to debugging, but feeds into this "conflict". If we only tell the backend we just have blocks of sizes/alignments, and we add offsets to those blocks, cast, deref, we will continue to avoid, e.g. backend record layout mattering. Just then a matter of dealing with records by value in a way that works. - Jay > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 20:59:09 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > On 31 Aug 2010, at 19:13, Jay K wrote: > > > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. > > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. > > Why would it not? We specify alignment... > > > It might also be good to have the backend feed its computed sizes/alignments back to the front end. > > It'd be via more files. > > YUCK!!!!!!!!! Not a good plan... > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> Date: Tue, 31 Aug 2010 23:09:56 +0000 > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] a trouble with passing records by value.. > >> > >> > >> I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > >> Yucky. > >> > >> I'm also going to try giving temporaries types. > >> Another m3cg change like pop_struct. > >> Given the latest internal error I saw. > >> Maybe review m3cg for more missing type information. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: jay.krell at cornell.edu > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: RE: [M3devel] a trouble with passing records by value.. > >>> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >>> > >>> > >>> t1 must still be passed in registers. The ABI can't be changed by that. > >>> > >>> - Jay > >>> > >>> ---------------------------------------- > >>>> From: hosking at cs.purdue.edu > >>>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >>>> To: jay.krell at cornell.edu > >>>> CC: m3devel at elegosoft.com > >>>> Subject: Re: [M3devel] a trouble with passing records by value.. > >>>> > >>>> What happens if you take the address of t inside ActionLookup? > >>>> What happens if you take the address of t1 inside main? > >>>> > >>>> On 31 Aug 2010, at 07:25, Jay K wrote: > >>>> > >>>>> > >>>>> Given something like this: > >>>>> > >>>>> jbook2:p247 jay$ more 1.c > >>>>> #include > >>>>> > >>>>> typedef struct { long code; long value; } T1; > >>>>> > >>>>> void ActionLookup(T1 t, long code, long value); > >>>>> > >>>>> void ActionLookup(T1 t, long code, long value) > >>>>> { > >>>>> assert(t.code == code); > >>>>> assert(t.value == value); > >>>>> } > >>>>> > >>>>> int main() > >>>>> { > >>>>> T1 t1 = {2,2}; > >>>>> ActionLookup(t1, 2, 2); > >>>>> return 0; > >>>>> } > >>>>> j > >>>>> > >>>>> > >>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > >>>>> > >>>>> > >>>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > >>>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > >>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > >>>>> Darn. > >>>>> > >>>>> > >>>>> If m3cg were higher level this could be better. > >>>>> > >>>>> > >>>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > >>>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > >>>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > >>>>> > >>>>> > >>>>> Maybe we should have M3CG include field references? > >>>>> > >>>>> > >>>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > >>>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > >>>>> > >>>>> > >>>>> - Jay > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 1 04:00:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 02:00:58 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> References: , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> Message-ID: > I strongly advise against that hack. It's not my favorite, but I'm possibly in a jam here between providing type information for debugging with stock gdb, and I suspect an overall poor story regarding type information and backend/frontend interface. One option is to give up on type information. i.e. go back to the historical way i.e. before August 2010. That worked ok as far as most people observed (except for stock gdb..) However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. I suspect we never historically passed records in registers, and that we must continue not to. Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if it notices their address taken. It might suffice, besides giving up on type information, to mark all records as "addressable". Or, again, to slightly hack the backend. Maybe only for SPARC64. The bigger controversial question is if we should change m3cg (the interface) to know about "field references". And then, again, should layout be done by the frontend, backend, or both? There are arguments for all three options. I think the current *design* is frontend only. But I think the current *implementation* is both (except for NT386). And probably the right way is backend only. This would also generally fix the pesky "load/store use bitfields" thing. Debuggability with stock gdb does seem like a nice idea. But I see now it might conflict tremendously with our odd structuring. I'll keep poking at it. e.g.: good type information, including for temporaries, and mark all record types/values as addressable. We should still consider the notion of "field references" in the m3cg interface. Right? I'm not crazy in the "mismatch" I seem to "detect"? Probably besides given the field "name", we should pass what the frontend thinks is the offset, type, alignment. This will serve two purposes. For NT386, it will let it continue to be fairly typeless, at least for now. For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. I still have to understand how bitfields fit here also. Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! - Jay > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 20:58:07 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > Yucky. > > I strongly advise against that hack. > > > I'm also going to try giving temporaries types. > > Another m3cg change like pop_struct. > > Given the latest internal error I saw. > > Maybe review m3cg for more missing type information. > > This would be better... > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: RE: [M3devel] a trouble with passing records by value.. > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed by that. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > >>> > >>> What happens if you take the address of t inside ActionLookup? > >>> What happens if you take the address of t1 inside main? > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > >>> > >>>> > >>>> Given something like this: > >>>> > >>>> jbook2:p247 jay$ more 1.c > >>>> #include > >>>> > >>>> typedef struct { long code; long value; } T1; > >>>> > >>>> void ActionLookup(T1 t, long code, long value); > >>>> > >>>> void ActionLookup(T1 t, long code, long value) > >>>> { > >>>> assert(t.code == code); > >>>> assert(t.value == value); > >>>> } > >>>> > >>>> int main() > >>>> { > >>>> T1 t1 = {2,2}; > >>>> ActionLookup(t1, 2, 2); > >>>> return 0; > >>>> } > >>>> j > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > >>>> Darn. > >>>> > >>>> > >>>> If m3cg were higher level this could be better. > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? > >>>> > >>>> > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > >>>> > >>>> > >>>> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Sep 1 04:24:07 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 31 Aug 2010 21:24:07 -0500 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , Message-ID: <4C7DB947.5030707@lcwb.coop> If the writers of an ABI actually *required* that small structs/records be passed in registers, then they have made a big blunder. In C, formal parameters are l-values, and in Modula-3, they are designators, regardless of the parameter mode. Thus taking their address must always be possible, to comply with language semantics, which means they must be in memory. The only possible resolutions are 1) Declare that language semantics trump ABI requirements and defy the ABI. 2) Pass them in registers at the time of control transfer, but store them in memory in the prologue, then access them from memory thereafter. As for 1), any usable ABI will have to have an alternate, in-memory method of passing things by value (if for no other reason, because they can be too big for registers), so it is hard to imagine how just using this mechanism in more cases could cause any trouble that didn't already exist anyway. I guess the one case that would preclude doing 1) would be if you wanted to allow calls and prologues generated by different compilers to work, and you couldn't rely on getting all compilers to do 1). As for 2), in some stack runtime models, passing in registers is probably less efficient than just letting the call-site code store parameters directly into the being-constructed activation record. Of course, if the compiler can ascertain that the address is never taken, then it could avoid storing them, but this doesn't absolve an ABI from providing an adequate mechanism for those cases when this can't be done. And of course, making formals be l-values/designators applies to most/all other types besides structs/records. Jay K wrote: > t1 must still be passed in registers. The ABI can't be changed by that. > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Tue, 31 Aug 2010 09:15:32 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> >> What happens if you take the address of t inside ActionLookup? >> What happens if you take the address of t1 inside main? >> >> On 31 Aug 2010, at 07:25, Jay K wrote: >> >>> Given something like this: >>> >>> jbook2:p247 jay$ more 1.c >>> #include >>> >>> typedef struct { long code; long value; } T1; >>> >>> void ActionLookup(T1 t, long code, long value); >>> >>> void ActionLookup(T1 t, long code, long value) >>> { >>> assert(t.code == code); >>> assert(t.value == value); >>> } >>> >>> int main() >>> { >>> T1 t1 = {2,2}; >>> ActionLookup(t1, 2, 2); >>> return 0; >>> } >>> j >>> >>> >>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. >>> >>> >>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, >>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, >>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. >>> Darn. >>> >>> >>> If m3cg were higher level this could be better. >>> >>> >>> There should be a viable compromise where the parameter is passed in registers, and only "homed" >>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. >>> But given the inefficiency of field accesses, I'm not sure it is worth trying? >>> >>> >>> Maybe we should have M3CG include field references? >>> >>> >>> There is this basic problem that the interface between m3front and m3cc isn't really at the >>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. >>> >>> >>> - Jay >>> > From hosking at cs.purdue.edu Wed Sep 1 04:22:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 31 Aug 2010 22:22:16 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu> Message-ID: <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> I believe there is one way out here. Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. We can even rely on Modula-3 run-time support to interpret the UIDs. I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? On 31 Aug 2010, at 22:00, Jay K wrote: > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 1 06:13:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 04:13:08 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7DB947.5030707@lcwb.coop> References: , , , , <4C7DB947.5030707@lcwb.coop> Message-ID: > Date: Tue, 31 Aug 2010 21:24:07 -0500 > From: rodney_bates@ > > If the writers of an ABI actually *required* that small structs/records be > passed in registers Yes, they have. The rules are hard for me to understand. It isn't just based on size. > then they have made a big blunder. No they have not. They know what they are doing. > Thus taking their address must always be possible, If they have to be in memory, then they will be put in memory, at or before the address is taken. That doesn't mean the parameters have to be passed in memory. > 1) Declare that language semantics trump ABI requirements and defy the ABI. Not necessary. Granted, we don't have to follow the ABI. The ABI is for interoperability with C. I'm plenty willing to say you can't pass records by value between C and Modula-3. > 2) Pass them in registers at the time of control transfer, but store them > in memory in the prologue, then access them from memory thereafter. The backend does that as needed for C already. Data can live in multiple places. Just that there can be only be one mutable location at a time. Look at the code generated Tony asked about, add like printr("%p\n", &t); you'll see the registers get written to the stack. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 1 06:26:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 04:26:48 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> References: , ,,, , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> Message-ID: > I don't particularly understand the SPARC64_SOLARIS issue When a record is passed by value SPARC64_SOLARIS backend goes to figure out the ABI for it and it hits an assertion failure. Historically no type was associated with parameters and locals in the backend. At least not for records. Maybe they had a size and an alignment. But certainly no fields. You know -- imagine a record with non-zero size but zero fields. Wierd eh? The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. (gcc can cope with some such cases the comments say, but still..) If you start but don't finish fixing this problem, by giving types to parameters, you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. I don't fully understand/remember the problem, but it is easy to uncover. Part of the problem was plain missing type information -- I fixed that in m3front. If you both imported and defined a type, you wouldn't get the information. m3front was deliberately skipping imported types, even if they coincided with locally defined types. If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, if the supertype matches. That's still not the extent of the problem on AMD64_DARWIN though. Test case p247 covers much of this. It just passes a record with a pointer and integer by value. Two integers (in record) have same problem. To try to summarize: There has been a historical lack of use of type information in the backend. Mostly the backend does get good type information from frontend, but it didn't associate it with locals/parameters. And it is better now. (globals are worse still I believe) I'm not 100% sure, but it appears to me that both the frontend and backend layout records. That is, determine the offset of each field, such as by adding up the sizes of preceding fields. (It is more involved than that, due to alignment.) I am concerned that these two layouts might not agree, and the result would be terrible. - Jay From: hosking at cs.purdue.edu Date: Tue, 31 Aug 2010 22:22:16 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] a trouble with passing records by value.. I believe there is one way out here. Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. We can even rely on Modula-3 run-time support to interpret the UIDs. I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? On 31 Aug 2010, at 22:00, Jay K wrote: > I strongly advise against that hack. It's not my favorite, but I'm possibly in a jam here between providing type information for debugging with stock gdb, and I suspect an overall poor story regarding type information and backend/frontend interface. One option is to give up on type information. i.e. go back to the historical way i.e. before August 2010. That worked ok as far as most people observed (except for stock gdb..) However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. I suspect we never historically passed records in registers, and that we must continue not to. Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if it notices their address taken. It might suffice, besides giving up on type information, to mark all records as "addressable". Or, again, to slightly hack the backend. Maybe only for SPARC64. The bigger controversial question is if we should change m3cg (the interface) to know about "field references". And then, again, should layout be done by the frontend, backend, or both? There are arguments for all three options. I think the current *design* is frontend only. But I think the current *implementation* is both (except for NT386). And probably the right way is backend only. This would also generally fix the pesky "load/store use bitfields" thing. Debuggability with stock gdb does seem like a nice idea. But I see now it might conflict tremendously with our odd structuring. I'll keep poking at it. e.g.: good type information, including for temporaries, and mark all record types/values as addressable. We should still consider the notion of "field references" in the m3cg interface. Right? I'm not crazy in the "mismatch" I seem to "detect"? Probably besides given the field "name", we should pass what the frontend thinks is the offset, type, alignment. This will serve two purposes. For NT386, it will let it continue to be fairly typeless, at least for now. For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. I still have to understand how bitfields fit here also. Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! - Jay > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 20:58:07 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > Yucky. > > I strongly advise against that hack. > > > I'm also going to try giving temporaries types. > > Another m3cg change like pop_struct. > > Given the latest internal error I saw. > > Maybe review m3cg for more missing type information. > > This would be better... > > > > > - Jay > > > > ---------------------------------------- > >> From: jay.krell at cornell.edu > >> To: hosking at cs.purdue.edu > >> CC: m3devel at elegosoft.com > >> Subject: RE: [M3devel] a trouble with passing records by value.. > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed by that. > >> > >> - Jay > >> > >> ---------------------------------------- > >>> From: hosking at cs.purdue.edu > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >>> To: jay.krell at cornell.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > >>> > >>> What happens if you take the address of t inside ActionLookup? > >>> What happens if you take the address of t1 inside main? > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > >>> > >>>> > >>>> Given something like this: > >>>> > >>>> jbook2:p247 jay$ more 1.c > >>>> #include > >>>> > >>>> typedef struct { long code; long value; } T1; > >>>> > >>>> void ActionLookup(T1 t, long code, long value); > >>>> > >>>> void ActionLookup(T1 t, long code, long value) > >>>> { > >>>> assert(t.code == code); > >>>> assert(t.value == value); > >>>> } > >>>> > >>>> int main() > >>>> { > >>>> T1 t1 = {2,2}; > >>>> ActionLookup(t1, 2, 2); > >>>> return 0; > >>>> } > >>>> j > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > >>>> Darn. > >>>> > >>>> > >>>> If m3cg were higher level this could be better. > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? > >>>> > >>>> > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > >>>> > >>>> > >>>> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Wed Sep 1 08:15:05 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Sep 2010 08:15:05 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, ,,<20100827180902.GA8903@topoi.pooq.com>, ,,, ,,<20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com> Message-ID: <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> Quoting Jay K : > ---------------------------------------- >> Date: Sun, 29 Aug 2010 13:15:44 +0200 >> From: wagner at elegosoft.com >> >> BTW, CI is working quite well now, and produces nightly snapshots >> that can be downloaded for almost all supported platforms, so this >> is better than ever before. See >> >> http://hudson.modula3.com:8080/view/cm3-current/ >> >> for details. > > => http://www.opencm3.net/snaps/snapshot-index.html > > Nice! > > Even NT386 is working well enough (though with odd archive names :) ) Sorry for that. I'm really in favour of using the new canonical ones, but haven't got round to change them where I can. I think FreeBSD4 should be my first candidate, as this keeps to confuse people... 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 Sep 1 08:43:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 06:43:46 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> Message-ID: That's not what I meant. I've complained enough about that. :) The NT386 archive has "cygwin" in its name. I'd also like to drop "vendor"/"hardware", at least pc/unknown. Unless anyone thinks this is "programmable": run config.guess locally and then download matching archive. - Jay > Date: Wed, 1 Sep 2010 08:15:05 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Jay K : > > > ---------------------------------------- > >> Date: Sun, 29 Aug 2010 13:15:44 +0200 > >> From: wagner at elegosoft.com > >> > >> BTW, CI is working quite well now, and produces nightly snapshots > >> that can be downloaded for almost all supported platforms, so this > >> is better than ever before. See > >> > >> http://hudson.modula3.com:8080/view/cm3-current/ > >> > >> for details. > > > > => http://www.opencm3.net/snaps/snapshot-index.html > > > > Nice! > > > > Even NT386 is working well enough (though with odd archive names :) ) > > Sorry for that. I'm really in favour of using the new canonical ones, > but haven't got round to change them where I can. > > I think FreeBSD4 should be my first candidate, as this keeps to confuse > people... > > 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 Sep 1 09:57:33 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 01 Sep 2010 09:57:33 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100901081505.b6xkpnmxccw8c4so@mail.elegosoft.com> Message-ID: <20100901095733.d2ml7w8xi8koo4gs@mail.elegosoft.com> Quoting Jay K : > That's not what I meant. I've complained enough about that. :) > The NT386 archive has "cygwin" in its name. Ah, that, sorry, the sleep still in my eyes led me to misread odd as old. Please add something appropriate for Windows in http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/sysinfo.sh?annotate=1.104 line 112 in function build_platform. Probably some environment variable extract? > I'd also like to drop "vendor"/"hardware", at least pc/unknown. > Unless anyone thinks this is "programmable": run config.guess > locally and then download matching archive. I think we should have a common format there. I agree that the -unknown- is unfortunate, but i386-apple- actually adds a bit of information (for those wondering about Darwin). If it looks better and doesn't break any scripts I won't object to any changes though. Olaf > - Jay > >> Date: Wed, 1 Sep 2010 08:15:05 +0200 >> From: wagner at elegosoft.com >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] CM3 services and Elego support, was: Re: >> conversion to another version control system >> >> Quoting Jay K : >> >> > ---------------------------------------- >> >> Date: Sun, 29 Aug 2010 13:15:44 +0200 >> >> From: wagner at elegosoft.com >> >> >> >> BTW, CI is working quite well now, and produces nightly snapshots >> >> that can be downloaded for almost all supported platforms, so this >> >> is better than ever before. See >> >> >> >> http://hudson.modula3.com:8080/view/cm3-current/ >> >> >> >> for details. >> > >> > => http://www.opencm3.net/snaps/snapshot-index.html >> > >> > Nice! >> > >> > Even NT386 is working well enough (though with odd archive names :) ) >> >> Sorry for that. I'm really in favour of using the new canonical ones, >> but haven't got round to change them where I can. >> >> I think FreeBSD4 should be my first candidate, as this keeps to confuse >> people... >> >> 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 Sep 1 11:05:57 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 09:05:57 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, Message-ID: oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type information adequately.. the backend thought all the records were one word/register/integer, and was reasonably well passing that first word/integer in a register. I needed to call layout_type. Testing another fix currently, but it works with both p247 and netobj, previously of which had conflicting requirements -- marking all records as addressable would break netobj, an assertion failure in tree-nested.c, and not fixable I believe with type information on temporaries (though I never tried that.. not sure we even ever have any temporary records..) ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Wed, 1 Sep 2010 04:26:48 +0000 > > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the > backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > > > If you start but don't finish fixing this problem, by giving types to > parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably > all AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that > in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they > coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque > error in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the > backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and > backend layout records. > That is, determine the offset of each field, such as by adding up > the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the > result would be terrible. > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in > which we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that > we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the > records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for > temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg > interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for > the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes > are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system > is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of > "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is > passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass > unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is > worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front > and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front > wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > From jay.krell at cornell.edu Wed Sep 1 13:41:20 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 11:41:20 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , Message-ID: Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. They don't. I think we should probably ? - not call layout_type ? - be sure to pass size/align to backend, and have it just set the values, if the rest of the ??? backend is ok with that. e.g.? m3cg_declare_field and m3cg_declare_record don't take an alignment. Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size and records are aligned on the highest alignment among their members. I have to poke around more. I'm going to disable this code again. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Wed, 1 Sep 2010 09:05:57 +0000 > > > oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type > information adequately.. the backend thought all the records were one word/register/integer, > and was reasonably well passing that first word/integer in a register. > > > I needed to call layout_type. > > > Testing another fix currently, but it works with both p247 and netobj, previously > of which had conflicting requirements -- marking all records as addressable > would break netobj, an assertion failure in tree-nested.c, and not fixable > I believe with type information on temporaries (though I never tried that.. > not sure we even ever have any temporary records..) > > - Jay > > > ________________________________ > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] a trouble with passing records by value.. > > Date: Wed, 1 Sep 2010 04:26:48 +0000 > > > > > I don't particularly understand the SPARC64_SOLARIS issue > > > > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > > out the ABI for it and it hits an assertion failure. > > > > > > Historically no type was associated with parameters and locals in the > > backend. > > At least not for records. > > Maybe they had a size and an alignment. > > But certainly no fields. > > > > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > > (gcc can cope with some such cases the comments say, but still..) > > > > > > If you start but don't finish fixing this problem, by giving types to > > parameters, > > you can then quickly run into problems in AMD64_DARWIN, and probably > > all AMD64 targets. > > I don't fully understand/remember the problem, but it is easy to uncover. > > > > > > Part of the problem was plain missing type information -- I fixed that > > in m3front. > > If you both imported and defined a type, you wouldn't get the information. > > m3front was deliberately skipping imported types, even if they > > coincided with locally defined types. > > If you fix that by defining "everything", you get duplicate opaque > > error in m3linker. I allow that now, > > if the supertype matches. > > > > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > > > > Test case p247 covers much of this. > > It just passes a record with a pointer and integer by value. > > Two integers (in record) have same problem. > > > > > > To try to summarize: > > There has been a historical lack of use of type information in the > > backend. > > Mostly the backend does get good type information from frontend, but > > it didn't associate it with locals/parameters. And it is better now. > > (globals are worse still I believe) > > > > > > I'm not 100% sure, but it appears to me that both the frontend and > > backend layout records. > > That is, determine the offset of each field, such as by adding up > > the sizes of preceding fields. > > (It is more involved than that, due to alignment.) > > I am concerned that these two layouts might not agree, and the > > result would be terrible. > > > > > > - Jay > > > > > > ________________________________ > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 22:22:16 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > I believe there is one way out here. > > Modula-3's dynamic types (UID-based) give a story for debugging in > > which we interpret the layout dynamically based on the Modula-3 type. > > We can even rely on Modula-3 run-time support to interpret the UIDs. > > > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > > elaborate? > > > > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > > > I strongly advise against that hack. > > > > > > It's not my favorite, but I'm possibly in > > a jam here between providing type information > > for debugging with stock gdb, and I suspect an > > overall poor story regarding type information > > and backend/frontend interface. > > > > > > One option is to give up on type information. > > i.e. go back to the historical way i.e. before August 2010. > > That worked ok as far as most people observed (except for stock gdb..) > > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > > > > I suspect we never historically passed records in registers, and that > > we must continue not to. > > Because of how fields are referenced. Unless maybe gcc "homes" the > > records as needed, if > > it notices their address taken. > > > > > > It might suffice, besides giving up on type information, to > > mark all records as "addressable". Or, again, to slightly > > hack the backend. Maybe only for SPARC64. > > > > > > The bigger controversial question is if we should change > > m3cg (the interface) to know about "field references". > > > > > > And then, again, should layout be done by the frontend, backend, > > or both? There are arguments for all three options. > > I think the current *design* is frontend only. > > But I think the current *implementation* is both (except for NT386). > > And probably the right way is backend only. > > > > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > > > > Debuggability with stock gdb does seem like a nice idea. > > But I see now it might conflict tremendously with our odd structuring. > > > > > > I'll keep poking at it. e.g.: good type information, including for > > temporaries, > > and mark all record types/values as addressable. > > > > > > We should still consider the notion of "field references" in the m3cg > > interface. > > Right? I'm not crazy in the "mismatch" I seem to "detect"? > > Probably besides given the field "name", we should pass what the frontend > > thinks is the offset, type, alignment. This will serve two purposes. > > For NT386, it will let it continue to be fairly typeless, at least for now. > > For m3cc, it can maybe assert that the layouts agree -- at least for > > the fields that are accessed. > > > > > > I still have to understand how bitfields fit here also. > > Though I checked -- it is quite nice afterall that offsets and sizes > > are given in bits instead of bytes! > > > > > > - Jay > > > > > > > > > From: hosking at cs.purdue.edu > > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > > to never pass structs in registers. > > > > Yucky. > > > > > > I strongly advise against that hack. > > > > > > > I'm also going to try giving temporaries types. > > > > Another m3cg change like pop_struct. > > > > Given the latest internal error I saw. > > > > Maybe review m3cg for more missing type information. > > > > > > This would be better... > > > > > > > > > > > - Jay > > > > > > > > ---------------------------------------- > > > >> From: jay.krell at cornell.edu > > > >> To: hosking at cs.purdue.edu > > > >> CC: m3devel at elegosoft.com > > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > >> > > > >> > > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > > >> > > > >> - Jay > > > >> > > > >> ---------------------------------------- > > > >>> From: hosking at cs.purdue.edu > > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > > >>> To: jay.krell at cornell.edu > > > >>> CC: m3devel at elegosoft.com > > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > > >>> > > > >>> What happens if you take the address of t inside ActionLookup? > > > >>> What happens if you take the address of t1 inside main? > > > >>> > > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > > >>> > > > >>>> > > > >>>> Given something like this: > > > >>>> > > > >>>> jbook2:p247 jay$ more 1.c > > > >>>> #include > > > >>>> > > > >>>> typedef struct { long code; long value; } T1; > > > >>>> > > > >>>> void ActionLookup(T1 t, long code, long value); > > > >>>> > > > >>>> void ActionLookup(T1 t, long code, long value) > > > >>>> { > > > >>>> assert(t.code == code); > > > >>>> assert(t.value == value); > > > >>>> } > > > >>>> > > > >>>> int main() > > > >>>> { > > > >>>> T1 t1 = {2,2}; > > > >>>> ActionLookup(t1, 2, 2); > > > >>>> return 0; > > > >>>> } > > > >>>> j > > > >>>> > > > >>>> > > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > > registers. Good. > > > >>>> > > > >>>> > > > >>>> However, one of the unfortunate aspects of our Modula-3 system > > is that when you reference e.g. t1.value, > > > >>>> the backend isn't told you are accessing the "value" "field" of > > "t1", and it figures out where that is, > > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > > have an address. Therefore it can't be in registers. > > > >>>> Darn. > > > >>>> > > > >>>> > > > >>>> If m3cg were higher level this could be better. > > > >>>> > > > >>>> > > > >>>> There should be a viable compromise where the parameter is > > passed in registers, and only "homed" > > > >>>> to some stack location if its address is used -- e.g. to pass > > unused parameters in registers. > > > >>>> But given the inefficiency of field accesses, I'm not sure it is > > worth trying? > > > >>>> > > > >>>> > > > >>>> Maybe we should have M3CG include field references? > > > >>>> > > > >>>> > > > >>>> There is this basic problem that the interface between m3front > > and m3cc isn't really at the > > > >>>> right level for m3cc. But it is probably for m3front. m3front > > wants a lower level code generator. > > > >>>> > > > >>>> > > > >>>> - Jay > > > From jay.krell at cornell.edu Wed Sep 1 13:50:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 11:50:11 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , , Message-ID: I should point out that the there is still missing type information -- typeids that are referenced but never defined, and typeids used before they are defined. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] a trouble with passing records by value.. > Date: Wed, 1 Sep 2010 11:41:20 +0000 > > > Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. > They don't. > > I think we should probably > - not call layout_type > - be sure to pass size/align to backend, and have it just set the values, if the rest of the > backend is ok with that. > > e.g. m3cg_declare_field and m3cg_declare_record don't take an alignment. > > Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size > and records are aligned on the highest alignment among their members. > > I have to poke around more. I'm going to disable this code again. > > - Jay > > ---------------------------------------- > > From: jay.krell at cornell.edu > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: RE: [M3devel] a trouble with passing records by value.. > > Date: Wed, 1 Sep 2010 09:05:57 +0000 > > > > > > oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type > > information adequately.. the backend thought all the records were one word/register/integer, > > and was reasonably well passing that first word/integer in a register. > > > > > > I needed to call layout_type. > > > > > > Testing another fix currently, but it works with both p247 and netobj, previously > > of which had conflicting requirements -- marking all records as addressable > > would break netobj, an assertion failure in tree-nested.c, and not fixable > > I believe with type information on temporaries (though I never tried that.. > > not sure we even ever have any temporary records..) > > > > - Jay > > > > > > ________________________________ > > > From: jay.krell at cornell.edu > > > To: hosking at cs.purdue.edu > > > CC: m3devel at elegosoft.com > > > Subject: RE: [M3devel] a trouble with passing records by value.. > > > Date: Wed, 1 Sep 2010 04:26:48 +0000 > > > > > > > I don't particularly understand the SPARC64_SOLARIS issue > > > > > > > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > > > out the ABI for it and it hits an assertion failure. > > > > > > > > > Historically no type was associated with parameters and locals in the > > > backend. > > > At least not for records. > > > Maybe they had a size and an alignment. > > > But certainly no fields. > > > > > > > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > > > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > > > (gcc can cope with some such cases the comments say, but still..) > > > > > > > > > If you start but don't finish fixing this problem, by giving types to > > > parameters, > > > you can then quickly run into problems in AMD64_DARWIN, and probably > > > all AMD64 targets. > > > I don't fully understand/remember the problem, but it is easy to uncover. > > > > > > > > > Part of the problem was plain missing type information -- I fixed that > > > in m3front. > > > If you both imported and defined a type, you wouldn't get the information. > > > m3front was deliberately skipping imported types, even if they > > > coincided with locally defined types. > > > If you fix that by defining "everything", you get duplicate opaque > > > error in m3linker. I allow that now, > > > if the supertype matches. > > > > > > > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > > > > > > > Test case p247 covers much of this. > > > It just passes a record with a pointer and integer by value. > > > Two integers (in record) have same problem. > > > > > > > > > To try to summarize: > > > There has been a historical lack of use of type information in the > > > backend. > > > Mostly the backend does get good type information from frontend, but > > > it didn't associate it with locals/parameters. And it is better now. > > > (globals are worse still I believe) > > > > > > > > > I'm not 100% sure, but it appears to me that both the frontend and > > > backend layout records. > > > That is, determine the offset of each field, such as by adding up > > > the sizes of preceding fields. > > > (It is more involved than that, due to alignment.) > > > I am concerned that these two layouts might not agree, and the > > > result would be terrible. > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > > From: hosking at cs.purdue.edu > > > Date: Tue, 31 Aug 2010 22:22:16 -0400 > > > To: jay.krell at cornell.edu > > > CC: m3devel at elegosoft.com > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > I believe there is one way out here. > > > Modula-3's dynamic types (UID-based) give a story for debugging in > > > which we interpret the layout dynamically based on the Modula-3 type. > > > We can even rely on Modula-3 run-time support to interpret the UIDs. > > > > > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > > > elaborate? > > > > > > > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > > > > > I strongly advise against that hack. > > > > > > > > > It's not my favorite, but I'm possibly in > > > a jam here between providing type information > > > for debugging with stock gdb, and I suspect an > > > overall poor story regarding type information > > > and backend/frontend interface. > > > > > > > > > One option is to give up on type information. > > > i.e. go back to the historical way i.e. before August 2010. > > > That worked ok as far as most people observed (except for stock gdb..) > > > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > > > > > > > I suspect we never historically passed records in registers, and that > > > we must continue not to. > > > Because of how fields are referenced. Unless maybe gcc "homes" the > > > records as needed, if > > > it notices their address taken. > > > > > > > > > It might suffice, besides giving up on type information, to > > > mark all records as "addressable". Or, again, to slightly > > > hack the backend. Maybe only for SPARC64. > > > > > > > > > The bigger controversial question is if we should change > > > m3cg (the interface) to know about "field references". > > > > > > > > > And then, again, should layout be done by the frontend, backend, > > > or both? There are arguments for all three options. > > > I think the current *design* is frontend only. > > > But I think the current *implementation* is both (except for NT386). > > > And probably the right way is backend only. > > > > > > > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > > > > > > > Debuggability with stock gdb does seem like a nice idea. > > > But I see now it might conflict tremendously with our odd structuring. > > > > > > > > > I'll keep poking at it. e.g.: good type information, including for > > > temporaries, > > > and mark all record types/values as addressable. > > > > > > > > > We should still consider the notion of "field references" in the m3cg > > > interface. > > > Right? I'm not crazy in the "mismatch" I seem to "detect"? > > > Probably besides given the field "name", we should pass what the frontend > > > thinks is the offset, type, alignment. This will serve two purposes. > > > For NT386, it will let it continue to be fairly typeless, at least for now. > > > For m3cc, it can maybe assert that the layouts agree -- at least for > > > the fields that are accessed. > > > > > > > > > I still have to understand how bitfields fit here also. > > > Though I checked -- it is quite nice afterall that offsets and sizes > > > are given in bits instead of bytes! > > > > > > > > > - Jay > > > > > > > > > > > > > From: hosking at cs.purdue.edu > > > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > > > To: jay.krell at cornell.edu > > > > CC: m3devel at elegosoft.com > > > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > > > to never pass structs in registers. > > > > > Yucky. > > > > > > > > I strongly advise against that hack. > > > > > > > > > I'm also going to try giving temporaries types. > > > > > Another m3cg change like pop_struct. > > > > > Given the latest internal error I saw. > > > > > Maybe review m3cg for more missing type information. > > > > > > > > This would be better... > > > > > > > > > > > > > > - Jay > > > > > > > > > > ---------------------------------------- > > > > >> From: jay.krell at cornell.edu > > > > >> To: hosking at cs.purdue.edu > > > > >> CC: m3devel at elegosoft.com > > > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > > > >> > > > > >> > > > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > > > >> > > > > >> - Jay > > > > >> > > > > >> ---------------------------------------- > > > > >>> From: hosking at cs.purdue.edu > > > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > > > >>> To: jay.krell at cornell.edu > > > > >>> CC: m3devel at elegosoft.com > > > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > > > >>> > > > > >>> What happens if you take the address of t inside ActionLookup? > > > > >>> What happens if you take the address of t1 inside main? > > > > >>> > > > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > > > >>> > > > > >>>> > > > > >>>> Given something like this: > > > > >>>> > > > > >>>> jbook2:p247 jay$ more 1.c > > > > >>>> #include > > > > >>>> > > > > >>>> typedef struct { long code; long value; } T1; > > > > >>>> > > > > >>>> void ActionLookup(T1 t, long code, long value); > > > > >>>> > > > > >>>> void ActionLookup(T1 t, long code, long value) > > > > >>>> { > > > > >>>> assert(t.code == code); > > > > >>>> assert(t.value == value); > > > > >>>> } > > > > >>>> > > > > >>>> int main() > > > > >>>> { > > > > >>>> T1 t1 = {2,2}; > > > > >>>> ActionLookup(t1, 2, 2); > > > > >>>> return 0; > > > > >>>> } > > > > >>>> j > > > > >>>> > > > > >>>> > > > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > > > registers. Good. > > > > >>>> > > > > >>>> > > > > >>>> However, one of the unfortunate aspects of our Modula-3 system > > > is that when you reference e.g. t1.value, > > > > >>>> the backend isn't told you are accessing the "value" "field" of > > > "t1", and it figures out where that is, > > > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > > > have an address. Therefore it can't be in registers. > > > > >>>> Darn. > > > > >>>> > > > > >>>> > > > > >>>> If m3cg were higher level this could be better. > > > > >>>> > > > > >>>> > > > > >>>> There should be a viable compromise where the parameter is > > > passed in registers, and only "homed" > > > > >>>> to some stack location if its address is used -- e.g. to pass > > > unused parameters in registers. > > > > >>>> But given the inefficiency of field accesses, I'm not sure it is > > > worth trying? > > > > >>>> > > > > >>>> > > > > >>>> Maybe we should have M3CG include field references? > > > > >>>> > > > > >>>> > > > > >>>> There is this basic problem that the interface between m3front > > > and m3cc isn't really at the > > > > >>>> right level for m3cc. But it is probably for m3front. m3front > > > wants a lower level code generator. > > > > >>>> > > > > >>>> > > > > >>>> - Jay > > > > > > From hosking at cs.purdue.edu Wed Sep 1 15:51:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 09:51:42 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> Message-ID: <74ADF74D-BEB2-4694-A04D-FD3BC403B8AB@cs.purdue.edu> Surely we can give the backend enough opaque information about record types (size, alignment, etc.) without revealing their complete structure... So, layout is still computed by the front-end and the back-end just sees a bag of bits. Or is that the exact problem you are facing... On 1 Sep 2010, at 00:26, Jay K wrote: > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > > > If you start but don't finish fixing this problem, by giving types to parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and backend layout records. > That is, determine the offset of each field, such as by adding up the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the result would be terrible. > > > - Jay > > > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Wed Sep 1 15:52:55 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 09:52:55 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , , Message-ID: <32B40A2C-E4B8-41B3-A2F8-74BE670382C0@cs.purdue.edu> Type ids can always be looked up via the Modula-3 run-time. On 1 Sep 2010, at 07:50, Jay K wrote: > > I should point out that the there is still missing type information -- typeids that are > referenced but never defined, and typeids used before they are defined. > > > - Jay > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: hosking at cs.purdue.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] a trouble with passing records by value.. >> Date: Wed, 1 Sep 2010 11:41:20 +0000 >> >> >> Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. >> They don't. >> >> I think we should probably >> - not call layout_type >> - be sure to pass size/align to backend, and have it just set the values, if the rest of the >> backend is ok with that. >> >> e.g. m3cg_declare_field and m3cg_declare_record don't take an alignment. >> >> Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size >> and records are aligned on the highest alignment among their members. >> >> I have to poke around more. I'm going to disable this code again. >> >> - Jay >> >> ---------------------------------------- >>> From: jay.krell at cornell.edu >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: RE: [M3devel] a trouble with passing records by value.. >>> Date: Wed, 1 Sep 2010 09:05:57 +0000 >>> >>> >>> oops..sorry..I should have taken the hint from the generated code.. I wasn't defining the type >>> information adequately.. the backend thought all the records were one word/register/integer, >>> and was reasonably well passing that first word/integer in a register. >>> >>> >>> I needed to call layout_type. >>> >>> >>> Testing another fix currently, but it works with both p247 and netobj, previously >>> of which had conflicting requirements -- marking all records as addressable >>> would break netobj, an assertion failure in tree-nested.c, and not fixable >>> I believe with type information on temporaries (though I never tried that.. >>> not sure we even ever have any temporary records..) >>> >>> - Jay >>> >>> >>> ________________________________ >>>> From: jay.krell at cornell.edu >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: RE: [M3devel] a trouble with passing records by value.. >>>> Date: Wed, 1 Sep 2010 04:26:48 +0000 >>>> >>>>> I don't particularly understand the SPARC64_SOLARIS issue >>>> >>>> >>>> When a record is passed by value SPARC64_SOLARIS backend goes to figure >>>> out the ABI for it and it hits an assertion failure. >>>> >>>> >>>> Historically no type was associated with parameters and locals in the >>>> backend. >>>> At least not for records. >>>> Maybe they had a size and an alignment. >>>> But certainly no fields. >>>> >>>> >>>> You know -- imagine a record with non-zero size but zero fields. Wierd eh? >>>> The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. >>>> (gcc can cope with some such cases the comments say, but still..) >>>> >>>> >>>> If you start but don't finish fixing this problem, by giving types to >>>> parameters, >>>> you can then quickly run into problems in AMD64_DARWIN, and probably >>>> all AMD64 targets. >>>> I don't fully understand/remember the problem, but it is easy to uncover. >>>> >>>> >>>> Part of the problem was plain missing type information -- I fixed that >>>> in m3front. >>>> If you both imported and defined a type, you wouldn't get the information. >>>> m3front was deliberately skipping imported types, even if they >>>> coincided with locally defined types. >>>> If you fix that by defining "everything", you get duplicate opaque >>>> error in m3linker. I allow that now, >>>> if the supertype matches. >>>> >>>> >>>> That's still not the extent of the problem on AMD64_DARWIN though. >>>> >>>> >>>> Test case p247 covers much of this. >>>> It just passes a record with a pointer and integer by value. >>>> Two integers (in record) have same problem. >>>> >>>> >>>> To try to summarize: >>>> There has been a historical lack of use of type information in the >>>> backend. >>>> Mostly the backend does get good type information from frontend, but >>>> it didn't associate it with locals/parameters. And it is better now. >>>> (globals are worse still I believe) >>>> >>>> >>>> I'm not 100% sure, but it appears to me that both the frontend and >>>> backend layout records. >>>> That is, determine the offset of each field, such as by adding up >>>> the sizes of preceding fields. >>>> (It is more involved than that, due to alignment.) >>>> I am concerned that these two layouts might not agree, and the >>>> result would be terrible. >>>> >>>> >>>> - Jay >>>> >>>> >>>> ________________________________ >>>> From: hosking at cs.purdue.edu >>>> Date: Tue, 31 Aug 2010 22:22:16 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>> >>>> I believe there is one way out here. >>>> Modula-3's dynamic types (UID-based) give a story for debugging in >>>> which we interpret the layout dynamically based on the Modula-3 type. >>>> We can even rely on Modula-3 run-time support to interpret the UIDs. >>>> >>>> I don't particularly understand the SPARC64_SOLARIS issue. Can you >>>> elaborate? >>>> >>>> >>>> On 31 Aug 2010, at 22:00, Jay K wrote: >>>> >>>>> I strongly advise against that hack. >>>> >>>> >>>> It's not my favorite, but I'm possibly in >>>> a jam here between providing type information >>>> for debugging with stock gdb, and I suspect an >>>> overall poor story regarding type information >>>> and backend/frontend interface. >>>> >>>> >>>> One option is to give up on type information. >>>> i.e. go back to the historical way i.e. before August 2010. >>>> That worked ok as far as most people observed (except for stock gdb..) >>>> However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. >>>> >>>> >>>> I suspect we never historically passed records in registers, and that >>>> we must continue not to. >>>> Because of how fields are referenced. Unless maybe gcc "homes" the >>>> records as needed, if >>>> it notices their address taken. >>>> >>>> >>>> It might suffice, besides giving up on type information, to >>>> mark all records as "addressable". Or, again, to slightly >>>> hack the backend. Maybe only for SPARC64. >>>> >>>> >>>> The bigger controversial question is if we should change >>>> m3cg (the interface) to know about "field references". >>>> >>>> >>>> And then, again, should layout be done by the frontend, backend, >>>> or both? There are arguments for all three options. >>>> I think the current *design* is frontend only. >>>> But I think the current *implementation* is both (except for NT386). >>>> And probably the right way is backend only. >>>> >>>> >>>> This would also generally fix the pesky "load/store use bitfields" thing. >>>> >>>> >>>> Debuggability with stock gdb does seem like a nice idea. >>>> But I see now it might conflict tremendously with our odd structuring. >>>> >>>> >>>> I'll keep poking at it. e.g.: good type information, including for >>>> temporaries, >>>> and mark all record types/values as addressable. >>>> >>>> >>>> We should still consider the notion of "field references" in the m3cg >>>> interface. >>>> Right? I'm not crazy in the "mismatch" I seem to "detect"? >>>> Probably besides given the field "name", we should pass what the frontend >>>> thinks is the offset, type, alignment. This will serve two purposes. >>>> For NT386, it will let it continue to be fairly typeless, at least for now. >>>> For m3cc, it can maybe assert that the layouts agree -- at least for >>>> the fields that are accessed. >>>> >>>> >>>> I still have to understand how bitfields fit here also. >>>> Though I checked -- it is quite nice afterall that offsets and sizes >>>> are given in bits instead of bytes! >>>> >>>> >>>> - Jay >>>> >>>> >>>> >>>>> From: hosking at cs.purdue.edu >>>>> Date: Tue, 31 Aug 2010 20:58:07 -0400 >>>>> To: jay.krell at cornell.edu >>>>> CC: m3devel at elegosoft.com >>>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>>> >>>>> >>>>> >>>>> On 31 Aug 2010, at 19:09, Jay K wrote: >>>>> >>>>>> >>>>>> I'm possibly going to try changing the target-specific code in gcc >>>> to never pass structs in registers. >>>>>> Yucky. >>>>> >>>>> I strongly advise against that hack. >>>>> >>>>>> I'm also going to try giving temporaries types. >>>>>> Another m3cg change like pop_struct. >>>>>> Given the latest internal error I saw. >>>>>> Maybe review m3cg for more missing type information. >>>>> >>>>> This would be better... >>>>> >>>>>> >>>>>> - Jay >>>>>> >>>>>> ---------------------------------------- >>>>>>> From: jay.krell at cornell.edu >>>>>>> To: hosking at cs.purdue.edu >>>>>>> CC: m3devel at elegosoft.com >>>>>>> Subject: RE: [M3devel] a trouble with passing records by value.. >>>>>>> Date: Tue, 31 Aug 2010 23:05:08 +0000 >>>>>>> >>>>>>> >>>>>>> t1 must still be passed in registers. The ABI can't be changed by that. >>>>>>> >>>>>>> - Jay >>>>>>> >>>>>>> ---------------------------------------- >>>>>>>> From: hosking at cs.purdue.edu >>>>>>>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >>>>>>>> To: jay.krell at cornell.edu >>>>>>>> CC: m3devel at elegosoft.com >>>>>>>> Subject: Re: [M3devel] a trouble with passing records by value.. >>>>>>>> >>>>>>>> What happens if you take the address of t inside ActionLookup? >>>>>>>> What happens if you take the address of t1 inside main? >>>>>>>> >>>>>>>> On 31 Aug 2010, at 07:25, Jay K wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Given something like this: >>>>>>>>> >>>>>>>>> jbook2:p247 jay$ more 1.c >>>>>>>>> #include >>>>>>>>> >>>>>>>>> typedef struct { long code; long value; } T1; >>>>>>>>> >>>>>>>>> void ActionLookup(T1 t, long code, long value); >>>>>>>>> >>>>>>>>> void ActionLookup(T1 t, long code, long value) >>>>>>>>> { >>>>>>>>> assert(t.code == code); >>>>>>>>> assert(t.value == value); >>>>>>>>> } >>>>>>>>> >>>>>>>>> int main() >>>>>>>>> { >>>>>>>>> T1 t1 = {2,2}; >>>>>>>>> ActionLookup(t1, 2, 2); >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> j >>>>>>>>> >>>>>>>>> >>>>>>>>> on some platforms, such as AMD64_DARWIN, T1 is passed in >>>> registers. Good. >>>>>>>>> >>>>>>>>> >>>>>>>>> However, one of the unfortunate aspects of our Modula-3 system >>>> is that when you reference e.g. t1.value, >>>>>>>>> the backend isn't told you are accessing the "value" "field" of >>>> "t1", and it figures out where that is, >>>>>>>>> but rather 64bits at offset 64bits into t1. Therefore t1 must >>>> have an address. Therefore it can't be in registers. >>>>>>>>> Darn. >>>>>>>>> >>>>>>>>> >>>>>>>>> If m3cg were higher level this could be better. >>>>>>>>> >>>>>>>>> >>>>>>>>> There should be a viable compromise where the parameter is >>>> passed in registers, and only "homed" >>>>>>>>> to some stack location if its address is used -- e.g. to pass >>>> unused parameters in registers. >>>>>>>>> But given the inefficiency of field accesses, I'm not sure it is >>>> worth trying? >>>>>>>>> >>>>>>>>> >>>>>>>>> Maybe we should have M3CG include field references? >>>>>>>>> >>>>>>>>> >>>>>>>>> There is this basic problem that the interface between m3front >>>> and m3cc isn't really at the >>>>>>>>> right level for m3cc. But it is probably for m3front. m3front >>>> wants a lower level code generator. >>>>>>>>> >>>>>>>>> >>>>>>>>> - Jay >>>> >>> >> > From rodney_bates at lcwb.coop Wed Sep 1 16:41:13 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 01 Sep 2010 09:41:13 -0500 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> Message-ID: <4C7E6609.4000107@lcwb.coop> Jay K wrote: > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the > backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > Is it possible the assertion is just overzealous and can be removed? Or, if the assertion is really needed, can gcc be changed so it no longer needs it? Would this approach be a simpler way? I sounds like it might at least be a more local change, instead of the pervasive problems that have emerged from putting type info in at the front of gcc. Or, are you trying to avoid internal changes to gcc at all cost? > > If you start but don't finish fixing this problem, by giving types to > parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably all > AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that > in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they > coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque error > in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the > backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and > backend layout records. > That is, determine the offset of each field, such as by adding up > the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the result > would be terrible. > > > - Jay > > > ------------------------------------------------------------------------ > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in which > we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and > that we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the > records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" > thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for > temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the > m3cg interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the > frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least > for now. > For m3cc, it can maybe assert that the layouts agree -- at least for > the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes > are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in > gcc to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed > by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 > system is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" > of "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is > passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass > unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it > is worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between > m3front and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front > wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > > From hosking at cs.purdue.edu Wed Sep 1 16:54:43 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 10:54:43 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7E6609.4000107@lcwb.coop> References: , , , , , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> <4C7E6609.4000107@lcwb.coop> Message-ID: <29E75898-3FBC-4C65-8200-78F448B18183@cs.purdue.edu> I would very much hesitate to remove these internal assertions in GCC since they tend to be needed to catch invariants that the rest of the compiler relies upon. Especially, internal changes to the backend of gcc is something to be strongly avoided. My inclination would be to type the record in a way that forces gcc to assume the worst and not pass the record in a register. I don't know what the sparc64 ABI says about passing structs, but surely we can type it in such as way as to get the behaviour the CM3 front-end expects. On 1 Sep 2010, at 10:41, Rodney M. Bates wrote: > > > Jay K wrote: >> > I don't particularly understand the SPARC64_SOLARIS issue >> When a record is passed by value SPARC64_SOLARIS backend goes to figure >> out the ABI for it and it hits an assertion failure. >> Historically no type was associated with parameters and locals in the backend. >> At least not for records. >> Maybe they had a size and an alignment. >> But certainly no fields. >> You know -- imagine a record with non-zero size but zero fields. Wierd eh? >> The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. >> (gcc can cope with some such cases the comments say, but still..) >> > > Is it possible the assertion is just overzealous and can be removed? > Or, if the assertion is really needed, can gcc be changed so it no > longer needs it? Would this approach be a simpler way? I sounds like > it might at least be a more local change, instead of the pervasive > problems that have emerged from putting type info in at the front of > gcc. > > Or, are you trying to avoid internal changes to gcc at all cost? > > >> If you start but don't finish fixing this problem, by giving types to parameters, >> you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. >> I don't fully understand/remember the problem, but it is easy to uncover. >> Part of the problem was plain missing type information -- I fixed that in m3front. >> If you both imported and defined a type, you wouldn't get the information. >> m3front was deliberately skipping imported types, even if they coincided with locally defined types. >> If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, >> if the supertype matches. >> That's still not the extent of the problem on AMD64_DARWIN though. >> Test case p247 covers much of this. >> It just passes a record with a pointer and integer by value. >> Two integers (in record) have same problem. >> To try to summarize: >> There has been a historical lack of use of type information in the backend. >> Mostly the backend does get good type information from frontend, but >> it didn't associate it with locals/parameters. And it is better now. >> (globals are worse still I believe) >> I'm not 100% sure, but it appears to me that both the frontend and backend layout records. >> That is, determine the offset of each field, such as by adding up the sizes of preceding fields. >> (It is more involved than that, due to alignment.) >> I am concerned that these two layouts might not agree, and the result would be terrible. >> - Jay >> ------------------------------------------------------------------------ >> From: hosking at cs.purdue.edu >> Date: Tue, 31 Aug 2010 22:22:16 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> I believe there is one way out here. >> Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. >> We can even rely on Modula-3 run-time support to interpret the UIDs. >> I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? >> On 31 Aug 2010, at 22:00, Jay K wrote: >> > I strongly advise against that hack. >> It's not my favorite, but I'm possibly in >> a jam here between providing type information >> for debugging with stock gdb, and I suspect an >> overall poor story regarding type information >> and backend/frontend interface. >> One option is to give up on type information. >> i.e. go back to the historical way i.e. before August 2010. >> That worked ok as far as most people observed (except for stock gdb..) >> However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. >> I suspect we never historically passed records in registers, and >> that we must continue not to. >> Because of how fields are referenced. Unless maybe gcc "homes" the >> records as needed, if >> it notices their address taken. >> It might suffice, besides giving up on type information, to >> mark all records as "addressable". Or, again, to slightly >> hack the backend. Maybe only for SPARC64. >> The bigger controversial question is if we should change >> m3cg (the interface) to know about "field references". >> And then, again, should layout be done by the frontend, backend, >> or both? There are arguments for all three options. >> I think the current *design* is frontend only. >> But I think the current *implementation* is both (except for NT386). >> And probably the right way is backend only. >> This would also generally fix the pesky "load/store use bitfields" >> thing. >> Debuggability with stock gdb does seem like a nice idea. >> But I see now it might conflict tremendously with our odd structuring. >> I'll keep poking at it. e.g.: good type information, including for >> temporaries, >> and mark all record types/values as addressable. >> We should still consider the notion of "field references" in the >> m3cg interface. >> Right? I'm not crazy in the "mismatch" I seem to "detect"? >> Probably besides given the field "name", we should pass what the >> frontend >> thinks is the offset, type, alignment. This will serve two purposes. >> For NT386, it will let it continue to be fairly typeless, at least >> for now. >> For m3cc, it can maybe assert that the layouts agree -- at least for >> the fields that are accessed. >> I still have to understand how bitfields fit here also. >> Though I checked -- it is quite nice afterall that offsets and sizes >> are given in bits instead of bytes! >> - Jay >> > From: hosking at cs.purdue.edu >> > Date: Tue, 31 Aug 2010 20:58:07 -0400 >> > To: jay.krell at cornell.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] a trouble with passing records by value.. >> > > > > On 31 Aug 2010, at 19:09, Jay K wrote: >> > > > > > I'm possibly going to try changing the target-specific code in >> gcc to never pass structs in registers. >> > > Yucky. >> > > I strongly advise against that hack. >> > > > I'm also going to try giving temporaries types. >> > > Another m3cg change like pop_struct. >> > > Given the latest internal error I saw. >> > > Maybe review m3cg for more missing type information. >> > > This would be better... >> > > > > > - Jay >> > > > > ---------------------------------------- >> > >> From: jay.krell at cornell.edu >> > >> To: hosking at cs.purdue.edu >> > >> CC: m3devel at elegosoft.com >> > >> Subject: RE: [M3devel] a trouble with passing records by value.. >> > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 >> > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed >> by that. >> > >> > >> - Jay >> > >> > >> ---------------------------------------- >> > >>> From: hosking at cs.purdue.edu >> > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 >> > >>> To: jay.krell at cornell.edu >> > >>> CC: m3devel at elegosoft.com >> > >>> Subject: Re: [M3devel] a trouble with passing records by value.. >> > >>> > >>> What happens if you take the address of t inside ActionLookup? >> > >>> What happens if you take the address of t1 inside main? >> > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: >> > >>> > >>>> > >>>> Given something like this: >> > >>>> > >>>> jbook2:p247 jay$ more 1.c >> > >>>> #include >> > >>>> > >>>> typedef struct { long code; long value; } T1; >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value); >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value) >> > >>>> { >> > >>>> assert(t.code == code); >> > >>>> assert(t.value == value); >> > >>>> } >> > >>>> > >>>> int main() >> > >>>> { >> > >>>> T1 t1 = {2,2}; >> > >>>> ActionLookup(t1, 2, 2); >> > >>>> return 0; >> > >>>> } >> > >>>> j >> > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in >> registers. Good. >> > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 >> system is that when you reference e.g. t1.value, >> > >>>> the backend isn't told you are accessing the "value" "field" >> of "t1", and it figures out where that is, >> > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must >> have an address. Therefore it can't be in registers. >> > >>>> Darn. >> > >>>> > >>>> > >>>> If m3cg were higher level this could be better. >> > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is >> passed in registers, and only "homed" >> > >>>> to some stack location if its address is used -- e.g. to pass >> unused parameters in registers. >> > >>>> But given the inefficiency of field accesses, I'm not sure it >> is worth trying? >> > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? >> > >>>> > >>>> > >>>> There is this basic problem that the interface between >> m3front and m3cc isn't really at the >> > >>>> right level for m3cc. But it is probably for m3front. m3front >> wants a lower level code generator. >> > >>>> > >>>> > >>>> - Jay From jay.krell at cornell.edu Wed Sep 1 16:58:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 14:58:24 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <29E75898-3FBC-4C65-8200-78F448B18183@cs.purdue.edu> References: , , ,,, , ,,, ,,, , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , , , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu>, , <4C7E6609.4000107@lcwb.coop>, <29E75898-3FBC-4C65-8200-78F448B18183@cs.purdue.edu> Message-ID: 1) I'm not sure there is a type that lets SPARC64_SOLARIS just work and be correct. 2) I want the type to be correct so that debugging with stock gdb works. Currently I'm fighting with getting unaligned bitfields.. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Wed, 1 Sep 2010 10:54:43 -0400 > To: rodney_bates at lcwb.coop > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I would very much hesitate to remove these internal assertions in GCC since they tend to be needed to catch invariants that the rest of the compiler relies upon. Especially, internal changes to the backend of gcc is something to be strongly avoided. My inclination would be to type the record in a way that forces gcc to assume the worst and not pass the record in a register. I don't know what the sparc64 ABI says about passing structs, but surely we can type it in such as way as to get the behaviour the CM3 front-end expects. > > On 1 Sep 2010, at 10:41, Rodney M. Bates wrote: > > > > > > > Jay K wrote: > >> > I don't particularly understand the SPARC64_SOLARIS issue > >> When a record is passed by value SPARC64_SOLARIS backend goes to figure > >> out the ABI for it and it hits an assertion failure. > >> Historically no type was associated with parameters and locals in the backend. > >> At least not for records. > >> Maybe they had a size and an alignment. > >> But certainly no fields. > >> You know -- imagine a record with non-zero size but zero fields. Wierd eh? > >> The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > >> (gcc can cope with some such cases the comments say, but still..) > >> > > > > Is it possible the assertion is just overzealous and can be removed? > > Or, if the assertion is really needed, can gcc be changed so it no > > longer needs it? Would this approach be a simpler way? I sounds like > > it might at least be a more local change, instead of the pervasive > > problems that have emerged from putting type info in at the front of > > gcc. > > > > Or, are you trying to avoid internal changes to gcc at all cost? > > > > > >> If you start but don't finish fixing this problem, by giving types to parameters, > >> you can then quickly run into problems in AMD64_DARWIN, and probably all AMD64 targets. > >> I don't fully understand/remember the problem, but it is easy to uncover. > >> Part of the problem was plain missing type information -- I fixed that in m3front. > >> If you both imported and defined a type, you wouldn't get the information. > >> m3front was deliberately skipping imported types, even if they coincided with locally defined types. > >> If you fix that by defining "everything", you get duplicate opaque error in m3linker. I allow that now, > >> if the supertype matches. > >> That's still not the extent of the problem on AMD64_DARWIN though. > >> Test case p247 covers much of this. > >> It just passes a record with a pointer and integer by value. > >> Two integers (in record) have same problem. > >> To try to summarize: > >> There has been a historical lack of use of type information in the backend. > >> Mostly the backend does get good type information from frontend, but > >> it didn't associate it with locals/parameters. And it is better now. > >> (globals are worse still I believe) > >> I'm not 100% sure, but it appears to me that both the frontend and backend layout records. > >> That is, determine the offset of each field, such as by adding up the sizes of preceding fields. > >> (It is more involved than that, due to alignment.) > >> I am concerned that these two layouts might not agree, and the result would be terrible. > >> - Jay > >> ------------------------------------------------------------------------ > >> From: hosking at cs.purdue.edu > >> Date: Tue, 31 Aug 2010 22:22:16 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] a trouble with passing records by value.. > >> I believe there is one way out here. > >> Modula-3's dynamic types (UID-based) give a story for debugging in which we interpret the layout dynamically based on the Modula-3 type. > >> We can even rely on Modula-3 run-time support to interpret the UIDs. > >> I don't particularly understand the SPARC64_SOLARIS issue. Can you elaborate? > >> On 31 Aug 2010, at 22:00, Jay K wrote: > >> > I strongly advise against that hack. > >> It's not my favorite, but I'm possibly in > >> a jam here between providing type information > >> for debugging with stock gdb, and I suspect an > >> overall poor story regarding type information > >> and backend/frontend interface. > >> One option is to give up on type information. > >> i.e. go back to the historical way i.e. before August 2010. > >> That worked ok as far as most people observed (except for stock gdb..) > >> However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > >> I suspect we never historically passed records in registers, and > >> that we must continue not to. > >> Because of how fields are referenced. Unless maybe gcc "homes" the > >> records as needed, if > >> it notices their address taken. > >> It might suffice, besides giving up on type information, to > >> mark all records as "addressable". Or, again, to slightly > >> hack the backend. Maybe only for SPARC64. > >> The bigger controversial question is if we should change > >> m3cg (the interface) to know about "field references". > >> And then, again, should layout be done by the frontend, backend, > >> or both? There are arguments for all three options. > >> I think the current *design* is frontend only. > >> But I think the current *implementation* is both (except for NT386). > >> And probably the right way is backend only. > >> This would also generally fix the pesky "load/store use bitfields" > >> thing. > >> Debuggability with stock gdb does seem like a nice idea. > >> But I see now it might conflict tremendously with our odd structuring. > >> I'll keep poking at it. e.g.: good type information, including for > >> temporaries, > >> and mark all record types/values as addressable. > >> We should still consider the notion of "field references" in the > >> m3cg interface. > >> Right? I'm not crazy in the "mismatch" I seem to "detect"? > >> Probably besides given the field "name", we should pass what the > >> frontend > >> thinks is the offset, type, alignment. This will serve two purposes. > >> For NT386, it will let it continue to be fairly typeless, at least > >> for now. > >> For m3cc, it can maybe assert that the layouts agree -- at least for > >> the fields that are accessed. > >> I still have to understand how bitfields fit here also. > >> Though I checked -- it is quite nice afterall that offsets and sizes > >> are given in bits instead of bytes! > >> - Jay > >> > From: hosking at cs.purdue.edu > >> > Date: Tue, 31 Aug 2010 20:58:07 -0400 > >> > To: jay.krell at cornell.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] a trouble with passing records by value.. > >> > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > >> > > > > > I'm possibly going to try changing the target-specific code in > >> gcc to never pass structs in registers. > >> > > Yucky. > >> > > I strongly advise against that hack. > >> > > > I'm also going to try giving temporaries types. > >> > > Another m3cg change like pop_struct. > >> > > Given the latest internal error I saw. > >> > > Maybe review m3cg for more missing type information. > >> > > This would be better... > >> > > > > > - Jay > >> > > > > ---------------------------------------- > >> > >> From: jay.krell at cornell.edu > >> > >> To: hosking at cs.purdue.edu > >> > >> CC: m3devel at elegosoft.com > >> > >> Subject: RE: [M3devel] a trouble with passing records by value.. > >> > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > >> > >> > >> > >> t1 must still be passed in registers. The ABI can't be changed > >> by that. > >> > >> > >> - Jay > >> > >> > >> ---------------------------------------- > >> > >>> From: hosking at cs.purdue.edu > >> > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > >> > >>> To: jay.krell at cornell.edu > >> > >>> CC: m3devel at elegosoft.com > >> > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > >> > >>> > >>> What happens if you take the address of t inside ActionLookup? > >> > >>> What happens if you take the address of t1 inside main? > >> > >>> > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > >> > >>> > >>>> > >>>> Given something like this: > >> > >>>> > >>>> jbook2:p247 jay$ more 1.c > >> > >>>> #include > >> > >>>> > >>>> typedef struct { long code; long value; } T1; > >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value); > >> > >>>> > >>>> void ActionLookup(T1 t, long code, long value) > >> > >>>> { > >> > >>>> assert(t.code == code); > >> > >>>> assert(t.value == value); > >> > >>>> } > >> > >>>> > >>>> int main() > >> > >>>> { > >> > >>>> T1 t1 = {2,2}; > >> > >>>> ActionLookup(t1, 2, 2); > >> > >>>> return 0; > >> > >>>> } > >> > >>>> j > >> > >>>> > >>>> > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > >> registers. Good. > >> > >>>> > >>>> > >>>> However, one of the unfortunate aspects of our Modula-3 > >> system is that when you reference e.g. t1.value, > >> > >>>> the backend isn't told you are accessing the "value" "field" > >> of "t1", and it figures out where that is, > >> > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > >> have an address. Therefore it can't be in registers. > >> > >>>> Darn. > >> > >>>> > >>>> > >>>> If m3cg were higher level this could be better. > >> > >>>> > >>>> > >>>> There should be a viable compromise where the parameter is > >> passed in registers, and only "homed" > >> > >>>> to some stack location if its address is used -- e.g. to pass > >> unused parameters in registers. > >> > >>>> But given the inefficiency of field accesses, I'm not sure it > >> is worth trying? > >> > >>>> > >>>> > >>>> Maybe we should have M3CG include field references? > >> > >>>> > >>>> > >>>> There is this basic problem that the interface between > >> m3front and m3cc isn't really at the > >> > >>>> right level for m3cc. But it is probably for m3front. m3front > >> wants a lower level code generator. > >> > >>>> > >>>> > >>>> - Jay > From jay.krell at cornell.edu Wed Sep 1 16:59:46 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 14:59:46 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <74ADF74D-BEB2-4694-A04D-FD3BC403B8AB@cs.purdue.edu> References: , ,,, , , , , , , <1C5B5A72-C897-4AA6-B89B-0A4BA0B4B339@cs.purdue.edu>, , <14DADCB1-C5A6-4399-9441-77870DC22FBF@cs.purdue.edu> , <74ADF74D-BEB2-4694-A04D-FD3BC403B8AB@cs.purdue.edu> Message-ID: Yes and yes -- that isn't adequate, and I'd like stock gdb to work. ?- Jay ________________________________ > Subject: Re: [M3devel] a trouble with passing records by value.. > From: hosking at cs.purdue.edu > Date: Wed, 1 Sep 2010 09:51:42 -0400 > CC: m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Surely we can give the backend enough opaque information about record > types (size, alignment, etc.) without revealing their complete > structure... So, layout is still computed by the front-end and the > back-end just sees a bag of bits. Or is that the exact problem you are > facing... > > On 1 Sep 2010, at 00:26, Jay K wrote: > > > I don't particularly understand the SPARC64_SOLARIS issue > > > When a record is passed by value SPARC64_SOLARIS backend goes to figure > out the ABI for it and it hits an assertion failure. > > > Historically no type was associated with parameters and locals in the > backend. > At least not for records. > Maybe they had a size and an alignment. > But certainly no fields. > > > You know -- imagine a record with non-zero size but zero fields. Wierd eh? > The SPARC64_SOLARIS code in gcc doesn't like that and fails an assertion. > (gcc can cope with some such cases the comments say, but still..) > > > If you start but don't finish fixing this problem, by giving types to > parameters, > you can then quickly run into problems in AMD64_DARWIN, and probably > all AMD64 targets. > I don't fully understand/remember the problem, but it is easy to uncover. > > > Part of the problem was plain missing type information -- I fixed that > in m3front. > If you both imported and defined a type, you wouldn't get the information. > m3front was deliberately skipping imported types, even if they > coincided with locally defined types. > If you fix that by defining "everything", you get duplicate opaque > error in m3linker. I allow that now, > if the supertype matches. > > > That's still not the extent of the problem on AMD64_DARWIN though. > > > Test case p247 covers much of this. > It just passes a record with a pointer and integer by value. > Two integers (in record) have same problem. > > > To try to summarize: > There has been a historical lack of use of type information in the > backend. > Mostly the backend does get good type information from frontend, but > it didn't associate it with locals/parameters. And it is better now. > (globals are worse still I believe) > > > I'm not 100% sure, but it appears to me that both the frontend and > backend layout records. > That is, determine the offset of each field, such as by adding up > the sizes of preceding fields. > (It is more involved than that, due to alignment.) > I am concerned that these two layouts might not agree, and the > result would be terrible. > > > - Jay > > > ________________________________ > From: hosking at cs.purdue.edu > Date: Tue, 31 Aug 2010 22:22:16 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > I believe there is one way out here. > Modula-3's dynamic types (UID-based) give a story for debugging in > which we interpret the layout dynamically based on the Modula-3 type. > We can even rely on Modula-3 run-time support to interpret the UIDs. > > I don't particularly understand the SPARC64_SOLARIS issue. Can you > elaborate? > > > On 31 Aug 2010, at 22:00, Jay K wrote: > > > I strongly advise against that hack. > > > It's not my favorite, but I'm possibly in > a jam here between providing type information > for debugging with stock gdb, and I suspect an > overall poor story regarding type information > and backend/frontend interface. > > > One option is to give up on type information. > i.e. go back to the historical way i.e. before August 2010. > That worked ok as far as most people observed (except for stock gdb..) > However that isn't quite adequate. It doesn't work for SPARC64_SOLARIS. > > > I suspect we never historically passed records in registers, and that > we must continue not to. > Because of how fields are referenced. Unless maybe gcc "homes" the > records as needed, if > it notices their address taken. > > > It might suffice, besides giving up on type information, to > mark all records as "addressable". Or, again, to slightly > hack the backend. Maybe only for SPARC64. > > > The bigger controversial question is if we should change > m3cg (the interface) to know about "field references". > > > And then, again, should layout be done by the frontend, backend, > or both? There are arguments for all three options. > I think the current *design* is frontend only. > But I think the current *implementation* is both (except for NT386). > And probably the right way is backend only. > > > This would also generally fix the pesky "load/store use bitfields" thing. > > > Debuggability with stock gdb does seem like a nice idea. > But I see now it might conflict tremendously with our odd structuring. > > > I'll keep poking at it. e.g.: good type information, including for > temporaries, > and mark all record types/values as addressable. > > > We should still consider the notion of "field references" in the m3cg > interface. > Right? I'm not crazy in the "mismatch" I seem to "detect"? > Probably besides given the field "name", we should pass what the frontend > thinks is the offset, type, alignment. This will serve two purposes. > For NT386, it will let it continue to be fairly typeless, at least for now. > For m3cc, it can maybe assert that the layouts agree -- at least for > the fields that are accessed. > > > I still have to understand how bitfields fit here also. > Though I checked -- it is quite nice afterall that offsets and sizes > are given in bits instead of bytes! > > > - Jay > > > > > From: hosking at cs.purdue.edu > > Date: Tue, 31 Aug 2010 20:58:07 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] a trouble with passing records by value.. > > > > > > > > On 31 Aug 2010, at 19:09, Jay K wrote: > > > > > > > > I'm possibly going to try changing the target-specific code in gcc > to never pass structs in registers. > > > Yucky. > > > > I strongly advise against that hack. > > > > > I'm also going to try giving temporaries types. > > > Another m3cg change like pop_struct. > > > Given the latest internal error I saw. > > > Maybe review m3cg for more missing type information. > > > > This would be better... > > > > > > > > - Jay > > > > > > ---------------------------------------- > > >> From: jay.krell at cornell.edu > > >> To: hosking at cs.purdue.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: RE: [M3devel] a trouble with passing records by value.. > > >> Date: Tue, 31 Aug 2010 23:05:08 +0000 > > >> > > >> > > >> t1 must still be passed in registers. The ABI can't be changed by that. > > >> > > >> - Jay > > >> > > >> ---------------------------------------- > > >>> From: hosking at cs.purdue.edu > > >>> Date: Tue, 31 Aug 2010 09:15:32 -0400 > > >>> To: jay.krell at cornell.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] a trouble with passing records by value.. > > >>> > > >>> What happens if you take the address of t inside ActionLookup? > > >>> What happens if you take the address of t1 inside main? > > >>> > > >>> On 31 Aug 2010, at 07:25, Jay K wrote: > > >>> > > >>>> > > >>>> Given something like this: > > >>>> > > >>>> jbook2:p247 jay$ more 1.c > > >>>> #include > > >>>> > > >>>> typedef struct { long code; long value; } T1; > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value); > > >>>> > > >>>> void ActionLookup(T1 t, long code, long value) > > >>>> { > > >>>> assert(t.code == code); > > >>>> assert(t.value == value); > > >>>> } > > >>>> > > >>>> int main() > > >>>> { > > >>>> T1 t1 = {2,2}; > > >>>> ActionLookup(t1, 2, 2); > > >>>> return 0; > > >>>> } > > >>>> j > > >>>> > > >>>> > > >>>> on some platforms, such as AMD64_DARWIN, T1 is passed in > registers. Good. > > >>>> > > >>>> > > >>>> However, one of the unfortunate aspects of our Modula-3 system > is that when you reference e.g. t1.value, > > >>>> the backend isn't told you are accessing the "value" "field" of > "t1", and it figures out where that is, > > >>>> but rather 64bits at offset 64bits into t1. Therefore t1 must > have an address. Therefore it can't be in registers. > > >>>> Darn. > > >>>> > > >>>> > > >>>> If m3cg were higher level this could be better. > > >>>> > > >>>> > > >>>> There should be a viable compromise where the parameter is > passed in registers, and only "homed" > > >>>> to some stack location if its address is used -- e.g. to pass > unused parameters in registers. > > >>>> But given the inefficiency of field accesses, I'm not sure it is > worth trying? > > >>>> > > >>>> > > >>>> Maybe we should have M3CG include field references? > > >>>> > > >>>> > > >>>> There is this basic problem that the interface between m3front > and m3cc isn't really at the > > >>>> right level for m3cc. But it is probably for m3front. m3front > wants a lower level code generator. > > >>>> > > >>>> > > >>>> - Jay > > > From hendrik at topoi.pooq.com Wed Sep 1 17:29:27 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Sep 2010 11:29:27 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: Message-ID: <20100901152927.GA28881@topoi.pooq.com> On Wed, Sep 01, 2010 at 11:41:20AM +0000, Jay K wrote: > > Hm. So now I've started asserting that the backend and frontend agree on the sizes of records. > They don't. > > I think we should probably > ? - not call layout_type > ? - be sure to pass size/align to backend, and have it just set the values, if the rest of the > ??? backend is ok with that. > > e.g.? m3cg_declare_field and m3cg_declare_record don't take an alignment. > > Though it is easy to compute at this point -- integers/floats/pointers are aligned on their size > and records are aligned on the highest alignment among their members. I seem to remember an exception on one of the old IBM "workstations". Its structires were 32-bit aligned (and its 64-bit floats were 32-bit aligned *except* that structures whose first actual field was a 64-bit float had to be 64-bit aligned. "First actual field" meancould mean the first field of the first field of the first field of ... of the first field. I've never figured out the reason for that crazy rule. long floats anywhere else in the structure didn't matter. Let's hope you don't have to be copatible with *that* C compiler! -- hendrik > > I have to poke around more. I'm going to disable this code again. > > ?- Jay > From hendrik at topoi.pooq.com Wed Sep 1 17:36:31 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Sep 2010 11:36:31 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> References: <7CFC7B0B-806C-4B2D-A609-524FD3492AC7@cs.purdue.edu> Message-ID: <20100901153631.GB28881@topoi.pooq.com> On Tue, Aug 31, 2010 at 08:59:09PM -0400, Tony Hosking wrote: > On 31 Aug 2010, at 19:13, Jay K wrote: > > > Another change we need is to check that the backend and frontend agree on the sizes and alignments of types. > > gcc does have a "packed" notion. It might be useful, like if it lets us set size/alignment and impedes repeat computation. > > Why would it not? We specify alignment... > > > It might also be good to have the backend feed its computed sizes/alignments back to the front end. > > It'd be via more files. > > YUCK!!!!!!!!! Not a good plan... I've always thought back ends and front ends should communicate more, but not if they are separatee processes run at separate times; especially if the feedback would involve some kind of surrogate time travel. But failing that, it might be good to have a suite of sizes/alignment tests, where the front end explicitly reports sizes and aligmment and the back end does the same. It that's done by generating all these numbers into the executable and writing them out at run-time, that would be OK. -- hendrik From hendrik at topoi.pooq.com Wed Sep 1 17:47:14 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Wed, 1 Sep 2010 11:47:14 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7DB947.5030707@lcwb.coop> References: <4C7DB947.5030707@lcwb.coop> Message-ID: <20100901154713.GC28881@topoi.pooq.com> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: > If the writers of an ABI actually *required* that small structs/records be > passed in registers, then they have made a big blunder. In C, formal > parameters are l-values, but they are copies of the corresponding actual parameters. > and in Modula-3, they are designators, regardless > of the parameter mode. Thus taking their address must always be possible, > to comply with language semantics, which means they must be in memory. > > The only possible resolutions are > > 1) Declare that language semantics trump ABI requirements and defy the ABI. On most platforms I ever had to be binary-compatible with in a C interpreter I dealt with long long ago, declaring the formal parameters as "..." (like printf) kept them in storage on the stack. -- hendrik > > 2) Pass them in registers at the time of control transfer, but store them > in memory in the prologue, then access them from memory thereafter. That's what the more optimizing compilers did, except they only ccopied them to memory if the called code actually needed them to be in memory. And they also watched out for functions whose addresses were taken, or were accessible by external linkage. But it mattered whether the function had a prototoype, and whether parameters were declared as "...". -- hendrik From jay.krell at cornell.edu Wed Sep 1 18:10:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 16:10:02 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <20100901154713.GC28881@topoi.pooq.com> References: , , <4C7DB947.5030707@lcwb.coop>, <20100901154713.GC28881@topoi.pooq.com> Message-ID: "..." won't let me see things gdb. Clever hack though. The backend below parse.c implements the ABI, and generation of debugging information, as long as you give it correctly typed trees. So yes, we would generally be compatible with the C compiler. Except, well, except that m3front does the same work. Not good. ?- Jay ---------------------------------------- > Date: Wed, 1 Sep 2010 11:47:14 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: > > If the writers of an ABI actually *required* that small structs/records be > > passed in registers, then they have made a big blunder. In C, formal > > parameters are l-values, > > but they are copies of the corresponding actual parameters. > > > and in Modula-3, they are designators, regardless > > of the parameter mode. Thus taking their address must always be possible, > > to comply with language semantics, which means they must be in memory. > > > > The only possible resolutions are > > > > 1) Declare that language semantics trump ABI requirements and defy the ABI. > > On most platforms I ever had to be binary-compatible with in a C > interpreter I dealt with long long ago, declaring the formal parameters > as "..." (like printf) kept them in storage on the stack. > > -- hendrik > > > > > 2) Pass them in registers at the time of control transfer, but store them > > in memory in the prologue, then access them from memory thereafter. > > That's what the more optimizing compilers did, except they only ccopied > them to memory if the called code actually needed them to be in memory. > And they also watched out for functions whose addresses were taken, or > were accessible by external linkage. > > But it mattered whether the function had a prototoype, and whether > parameters were declared as "...". > > -- hendrik From jay.krell at cornell.edu Wed Sep 1 18:30:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Sep 2010 16:30:35 +0000 Subject: [M3devel] debugging with stock gdb Message-ID: Here's a quick sample of what you can do now in gdb, so much better than before. Records used to have no types. This is on Darwin. jbook2:m3cc jay$ gdb /cm3/bin/Juno GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009) (gdb) break RTType__Expand (gdb) run Breakpoint 1, RTType__Expand (M3_DaARCY_m=0x1010cccd0) at ../src/runtime/common/RTType.m3:715 715??? ??? new : InfoMap; (gdb) n 716??? ??? pi, pt: SlotPtr; (gdb) n 719??? ??? IF m.map = NIL THEN (gdb) 721??? ????? m.cnt? := 0; (gdb) info locals M3_AcxOUs_key2 = 4312105936 M3_AcxOUs_key1 = 4321920593 M3_EM4UH1_pt = (struct {...} ***) 0x0 M3_EM4UH1_pi = (struct {...} ***) 0x0 M3_BQo8Jp_new = { ? name = 0x0, ? is_equal = 0x0, ? rehash = 0x0, ? initial_size = 0, ? full = 0, ? cnt = 0, ? max = 0, ? mask = 0, ? map = 0x0 } (gdb) p **M3_DaARCY_m $1 = { ? name = 0x1010e2ca0, ? is_equal = 0x8, ? rehash = 0x7364697565707974, ? initial_size = 0, ? full = 2, ? cnt = 4312673440, ? max = 6, ? mask = 126875185803874, ? map = 0x2 } ?- Jay From hosking at cs.purdue.edu Wed Sep 1 21:23:17 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 1 Sep 2010 15:23:17 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , <4C7DB947.5030707@lcwb.coop>, <20100901154713.GC28881@topoi.pooq.com> Message-ID: <9D70491C-0B0A-4FC2-B4E9-A2E7EE35337F@cs.purdue.edu> Surely there are ways to type things such that the backend is forced to compute the same layout as the front-end. Can we type fields as bitfields to get what's needed? On 1 Sep 2010, at 12:10, Jay K wrote: > > "..." won't let me see things gdb. > Clever hack though. > > > The backend below parse.c implements the ABI, and generation of debugging information, > as long as you give it correctly typed trees. So yes, we would generally be compatible > with the C compiler. Except, well, except that m3front does the same work. Not good. > > > - Jay > > ---------------------------------------- >> Date: Wed, 1 Sep 2010 11:47:14 -0400 >> From: hendrik at topoi.pooq.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] a trouble with passing records by value.. >> >> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: >>> If the writers of an ABI actually *required* that small structs/records be >>> passed in registers, then they have made a big blunder. In C, formal >>> parameters are l-values, >> >> but they are copies of the corresponding actual parameters. >> >>> and in Modula-3, they are designators, regardless >>> of the parameter mode. Thus taking their address must always be possible, >>> to comply with language semantics, which means they must be in memory. >>> >>> The only possible resolutions are >>> >>> 1) Declare that language semantics trump ABI requirements and defy the ABI. >> >> On most platforms I ever had to be binary-compatible with in a C >> interpreter I dealt with long long ago, declaring the formal parameters >> as "..." (like printf) kept them in storage on the stack. >> >> -- hendrik >> >>> >>> 2) Pass them in registers at the time of control transfer, but store them >>> in memory in the prologue, then access them from memory thereafter. >> >> That's what the more optimizing compilers did, except they only ccopied >> them to memory if the called code actually needed them to be in memory. >> And they also watched out for functions whose addresses were taken, or >> were accessible by external linkage. >> >> But it mattered whether the function had a prototoype, and whether >> parameters were declared as "...". >> >> -- hendrik > From dabenavidesd at yahoo.es Wed Sep 1 23:53:33 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 1 Sep 2010 21:53:33 +0000 (GMT) Subject: [M3devel] debugging with stock gdb Message-ID: <583899.90242.qm@web29704.mail.ird.yahoo.com> Hi all: Yes I think this might be useful specially debugging when no stock m3gdb available. I wanted to also consider this case you have great disassemblers, debuggers and plenty of useful tools for easier debugging. If you could do that would be great for all the developers planning transition to Modula-3 from other languages. But thinking in the core developers testers, users as you have seen probably the best resource at hand even in the case there are better ones is just to keep the new environment enhancing and porting. Most of code debuggers are written from runtime environments so the advantage would be cumbersome because we need also a lot of tools to keep track of all variety of this third party tools distributors. Also if in such an effort you can actually test changes in fewer platforms. In the other case would be newer things to ask and use on the new stock debugger. So keeping the changes in this way will get more of the same characteristics at some level less or more but in the end you will you would just have to keep an effort in the same way, not too many in a lot of different ways certainly. By the end of the day it will be just less output for the same work and as a contrast more output for same work, so a lot easier if not new things were added. A wanted feature might be a less harder work to port to new system, this was achieved using the native code generators but this was a lot of effort to put it to work still. I guess this efforts could be later enhanced for the good of the native platform and others also. In other projects efforts are working towards that end, like openwatcom. As being openned they have more customers, users and developers with different needs and they are working to adapt their system to that. Perhaps no with the same effort to put it to work in other systems but certainly to their system that's an useful advantage to host more users with same system Probably this kind of systems doesn't allow too much new tools if they want to maintain the user base, but they wanted and have to move forward with new ones. As a result the system is enhanced but the cost or effort could be less than the actual to get a new runtime environment to work in top of it. Main thing here was to try to save some time in getting user and easily adapted to your users, but you have spent more time in that case for that thing than keeping up to date of others. So you might wonder how this might happen. Well in such a case we need a little more of illustration we can take advantage of a useful paper to look for standing with the challenges that anyway come like this side effect of independent works of related efforts or works and so much of the forks and third party options and distributions. This might be a penalty for this customer base but how it would if they were not there for us? well it might interesting to have a read of https://168.176.86.16/~danielb/Taking_control.pdf (just accept security domain error and add security exception to download it) This resumes some techniques useful for this kind of tricky questions, downloaded from: http://ciozone.madisonlogic.com/black_duck_software/ You will need to fill a survey. Well that's all I have in mind well and a last long ago sentence from a paper "The Modula-3 compiler generates the intermediate code of the GNU compiler. Therefore, any system that can run GNU C can run Modula-3" p. 28 in http://www.liacs.nl/~llexx/APPARC/DELIVERABLES/PME4a.ps.gz I guess that is not the same case for the symbols of the new stock debugger, what do you think? Thanks in advance --- El mi?, 1/9/10, Jay K escribi?: > De: Jay K > Asunto: [M3devel] debugging with stock gdb > Para: "m3devel" > Fecha: mi?rcoles, 1 de septiembre, 2010 11:30 > > Here's a quick sample of what you can do now in gdb, so > much better than before. > Records used to have no types. > This is on Darwin. > > > jbook2:m3cc jay$ gdb /cm3/bin/Juno > GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 > 02:43:13 UTC 2009) > > (gdb) break RTType__Expand > (gdb) run > Breakpoint 1, RTType__Expand (M3_DaARCY_m=0x1010cccd0) at > ../src/runtime/common/RTType.m3:715 > 715 new : InfoMap; > (gdb) n > 716 pi, pt: SlotPtr; > (gdb) n > 719 IF m.map = NIL THEN > (gdb) > 721 m.cnt := 0; > (gdb) info locals > M3_AcxOUs_key2 = 4312105936 > M3_AcxOUs_key1 = 4321920593 > M3_EM4UH1_pt = (struct {...} ***) 0x0 > M3_EM4UH1_pi = (struct {...} ***) 0x0 > M3_BQo8Jp_new = { > name = 0x0, > is_equal = 0x0, > rehash = 0x0, > initial_size = 0, > full = 0, > cnt = 0, > max = 0, > mask = 0, > map = 0x0 > } > (gdb) p **M3_DaARCY_m > $1 = { > name = 0x1010e2ca0, > is_equal = 0x8, > rehash = 0x7364697565707974, > initial_size = 0, > full = 2, > cnt = 4312673440, > max = 6, > mask = 126875185803874, > map = 0x2 > } > > > - Jay > > > > From jay.krell at cornell.edu Thu Sep 2 06:31:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Sep 2010 04:31:47 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <9D70491C-0B0A-4FC2-B4E9-A2E7EE35337F@cs.purdue.edu> References: , , , , <4C7DB947.5030707@lcwb.coop>, , <20100901154713.GC28881@topoi.pooq.com>, , <9D70491C-0B0A-4FC2-B4E9-A2E7EE35337F@cs.purdue.edu> Message-ID: Well, I'd like to be able to dereference pointers in stock gdb and also see floats properly. But yes, I put in use of bitfields for things with offset or size not a multiple of 8 (or "unit", whatever). I put in asserts that record sizes match between frontend and backend. It seems to work, at least on AMD64_DARWIN. That still leaves room for fields to be placed wrong though. It's a start. I should be able to go back and assert those too. There's still a fair amount more to do here, including objects, enums, globals, constants, packed. - Jay > From: hosking at cs.purdue.edu > Date: Wed, 1 Sep 2010 15:23:17 -0400 > To: jay.krell at cornell.edu > CC: hendrik at topoi.pooq.com; m3devel at elegosoft.com > Subject: Re: [M3devel] a trouble with passing records by value.. > > Surely there are ways to type things such that the backend is forced to compute the same layout as the front-end. Can we type fields as bitfields to get what's needed? > > > On 1 Sep 2010, at 12:10, Jay K wrote: > > > > > "..." won't let me see things gdb. > > Clever hack though. > > > > > > The backend below parse.c implements the ABI, and generation of debugging information, > > as long as you give it correctly typed trees. So yes, we would generally be compatible > > with the C compiler. Except, well, except that m3front does the same work. Not good. > > > > > > - Jay > > > > ---------------------------------------- > >> Date: Wed, 1 Sep 2010 11:47:14 -0400 > >> From: hendrik at topoi.pooq.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] a trouble with passing records by value.. > >> > >> On Tue, Aug 31, 2010 at 09:24:07PM -0500, Rodney M. Bates wrote: > >>> If the writers of an ABI actually *required* that small structs/records be > >>> passed in registers, then they have made a big blunder. In C, formal > >>> parameters are l-values, > >> > >> but they are copies of the corresponding actual parameters. > >> > >>> and in Modula-3, they are designators, regardless > >>> of the parameter mode. Thus taking their address must always be possible, > >>> to comply with language semantics, which means they must be in memory. > >>> > >>> The only possible resolutions are > >>> > >>> 1) Declare that language semantics trump ABI requirements and defy the ABI. > >> > >> On most platforms I ever had to be binary-compatible with in a C > >> interpreter I dealt with long long ago, declaring the formal parameters > >> as "..." (like printf) kept them in storage on the stack. > >> > >> -- hendrik > >> > >>> > >>> 2) Pass them in registers at the time of control transfer, but store them > >>> in memory in the prologue, then access them from memory thereafter. > >> > >> That's what the more optimizing compilers did, except they only ccopied > >> them to memory if the called code actually needed them to be in memory. > >> And they also watched out for functions whose addresses were taken, or > >> were accessible by external linkage. > >> > >> But it mattered whether the function had a prototoype, and whether > >> parameters were declared as "...". > >> > >> -- hendrik > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Sep 2 16:39:12 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 02 Sep 2010 09:39:12 -0500 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: , , , , <4C7DB947.5030707@lcwb.coop> Message-ID: <4C7FB710.7000204@lcwb.coop> Jay K wrote: > > Date: Tue, 31 Aug 2010 21:24:07 -0500 > > From: rodney_bates@ > > > > If the writers of an ABI actually *required* that small > structs/records be > > passed in registers > > > Yes, they have. The rules are hard for me to understand. It isn't just > based on size. > > > > then they have made a big blunder. > > > No they have not. They know what they are doing. When the ABI requires a compiler to do it wrong for the language semantics, which it must then compensate for at a place that's outside the jurisdiction of the ABI, the ABI has a design bug. At least when the language in question is one of those the ABI designers considered, which has to be the case with C. > > > > Thus taking their address must always be possible, > > > If they have to be in memory, then they will be put in memory, at or before > the address is taken. That doesn't mean the parameters have to be passed > in memory. > > > > 1) Declare that language semantics trump ABI requirements and defy > the ABI. > > Not necessary. > Granted, we don't have to follow the ABI. The ABI is for > interoperability with C. > I'm plenty willing to say you can't pass records by value between C and > Modula-3. > > > > > 2) Pass them in registers at the time of control transfer, but store them > > in memory in the prologue, then access them from memory thereafter. > > > The backend does that as needed for C already. > > > Data can live in multiple places. > Just that there can be only be one mutable location at a time. > > > Look at the code generated Tony asked about, add like > printr("%p\n", &t); > > > you'll see the registers get written to the stack. > > > - Jay From jay.krell at cornell.edu Thu Sep 2 16:59:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Sep 2010 14:59:13 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <4C7FB710.7000204@lcwb.coop> References: , , , , , , , <4C7DB947.5030707@lcwb.coop>, , <4C7FB710.7000204@lcwb.coop> Message-ID: Short answer: Consider: void F1(int a) { printf("%p\n", &a); } void F2(struct { int b,c;} d) { printf("%p\n", &d); } Longer anser: There is no ABI bug. Really. How parameters are passed does not imply where they must be at all times. C has the same feature set as Modula-3. In general and here specifically. You can pass structs by value in C and you can take the address of such a struct. The ABI is never perfectly efficient for all scenarios. If one could predict that all structed passed by value will have their address taken, then a different choice might be made. However the reality is that sometimes their address is taken, sometimes not. One ABI must be formulated (for interop) that strikes an efficiency balance, and always works. Consider that I can take the address of integers and floats and pointers passed by value! Yet they are very very often passed in registers. (see the "short answer"). A record is just a smaller or larger collection of integers/floats/pointers. The difference is mainly in the layout of the in-memory location, and the possibility of large size. - Jay > Date: Thu, 2 Sep 2010 09:39:12 -0500 > From: rodney_bates > To: m3devel > Subject: Re: [M3devel] a trouble with passing records by value.. > > Jay K wrote: > > > Date: Tue, 31 Aug 2010 21:24:07 -0500 > > > From: rodney_bates@ > > > > > > If the writers of an ABI actually *required* that small > > structs/records be > > > passed in registers > > > > > > Yes, they have. The rules are hard for me to understand. It isn't just > > based on size. > > > > > > > then they have made a big blunder. > > > > > > No they have not. They know what they are doing. > > When the ABI requires a compiler to do it wrong for the language semantics, > which it must then compensate for at a place that's outside the jurisdiction > of the ABI, the ABI has a design bug. At least when the language in question > is one of those the ABI designers considered, which has to be the case > with C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Sep 2 19:50:33 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Thu, 2 Sep 2010 13:50:33 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: <4C7FB710.7000204@lcwb.coop> Message-ID: <20100902175032.GA1879@topoi.pooq.com> On Thu, Sep 02, 2010 at 02:59:13PM +0000, Jay K wrote: > > Short answer: > > > Consider: > void F1(int a) { printf("%p\n", &a); } > void F2(struct { int b,c;} d) { printf("%p\n", &d); } > > > Longer anser: > > > There is no ABI bug. Really. > > > How parameters are passed does not imply where they must be at all times. > > > C has the same feature set as Modula-3. In general and here specifically. > You can pass structs by value in C and you can take the address of such a struct. > > > The ABI is never perfectly efficient for all scenarios. > If one could predict that all structed passed by value will have their > address taken, then a different choice might be made. > However the reality is that sometimes their address is taken, sometimes not. > One ABI must be formulated (for interop) that strikes an efficiency balance, and always works. > > > Consider that I can take the address of integers and floats and pointers passed by value! > Yet they are very very often passed in registers. (see the "short answer"). > > > A record is just a smaller or larger collection of integers/floats/pointers. > > > The difference is mainly in the layout of the in-memory location, and > the possibility of large size. > To avoid going into assembly langauge in my C interpreter, on many platforms I did the following hack: Pack the parameters into a large struct (like struct big{char space[1000];} ), calculating parameter positions myself. The type of the space array was completely irrelevant -- as long as it ws big enough. Then I pass the struct by value to the called program, ignoring the types the called program wanted -- you can do this with enough casts. This worked for a *lot* of systems. To avoid wasting too much stack space, I had a variety of struct types available, of different sizes, each with its own code. -- hendrik From mark at wickensonline.co.uk Thu Sep 2 20:29:32 2010 From: mark at wickensonline.co.uk (Mark Wickens) Date: Thu, 02 Sep 2010 19:29:32 +0100 Subject: [M3devel] CM3 on Solaris 2.6/GNU Message-ID: <1283452172.6292.2.camel@x60.hecnet.eu> Hi guys, My conquest of Modula-3 on old hardware has started once again now that I have Solaris 2.6 running on the SPARCbook 3. What would be my options for getting it on there? The machine has 64 MB of RAM and a few hundred MB of disk space - is it going to have to be a cross-compile, if anything? Cheers, Mark. From jay.krell at cornell.edu Thu Sep 2 23:24:50 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Sep 2010 21:24:50 +0000 Subject: [M3devel] CM3 on Solaris 2.6/GNU In-Reply-To: <1283452172.6292.2.camel@x60.hecnet.eu> References: <1283452172.6292.2.camel@x60.hecnet.eu> Message-ID: You have a working C compiler on it? Does 2.6 have pthreads? Our userthreads won't work on 2.6 at least for a small reason, maybe for larger reasons. (makecontext in 2.8 and some versions of 2.9 have the stack direction wrong; we could easily enough make our code work on those I think) There's a problem in head on sparc. Been a while, sorry. I do need to look into it. Try the release branch? Go to any working machine -- any machine with cm3. Preferably a fast one. And it should have Python. cd scripts/python ./boot1.py SOLgnu wait a bit, it's not fast because the first thing it does is build a cross cm3cg. ls *.tar.gz *tgz make some guesses and attempts ok -- copy the *gz to the Solaris 2.6 machine extract it cd into it look at the top of Makefile, see if it is sane make ./cm3 If it says "can't find cm3.cfg", good, proceed... If it doesn't say that, bad, go back and debug... "proceed": I use python/boot2.sh, but with only 64MB.. the backend won't compile in 128MB.. Canadian cross might do. There is clearly an intent for it to work but I haven't used it much. You'd likely need to work out other cross issues -- get a working cross gcc in the usual way.. This machine is probably intolerably slow, to me. Even though I did use machines with much less memory. Get me ssh access, I might might might might might look. If 2.6 doesn't have pthreads, or adequate pthreads, you'd need to hack on it to use the Sun threads or userthreads, neither is particularly automatic. Both are probably possible. - Jay > From: mark at wickensonline.co.uk > To: m3devel at elegosoft.com > Date: Thu, 2 Sep 2010 19:29:32 +0100 > Subject: [M3devel] CM3 on Solaris 2.6/GNU > > Hi guys, > > My conquest of Modula-3 on old hardware has started once again now that > I have Solaris 2.6 running on the SPARCbook 3. What would be my options > for getting it on there? The machine has 64 MB of RAM and a few hundred > MB of disk space - is it going to have to be a cross-compile, if > anything? > > Cheers, Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 3 04:57:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 02:57:52 +0000 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: <20100902175032.GA1879@topoi.pooq.com> References: <4C7FB710.7000204@lcwb.coop>, , <20100902175032.GA1879@topoi.pooq.com> Message-ID: > To avoid going into assembly langauge in my C interpreter, on many platforms I did the > following hack: > > Pack the parameters into a large struct (like struct big{char space[1000];} ), calculating > parameter positions myself. The type of the space array was completely irrelevant -- as > long as it ws big enough. > > Then I pass the struct by value to the called program, ignoring the types the called > program wanted -- you can do this with enough casts. > > This worked for a *lot* of systems. > > To avoid wasting too much stack space, I had a variety of struct types available, of > different sizes, each with its own code. > > -- hendrik Debugging would suffer like it did/does today. Code quality would suffer. Hey, I wanted to pass the static link in an extra parameter concocted by the frontend but Tony didn't want that loss of code quality. (Letting gcc do the work here has a few advantages: the optimizer can decide which locals even need to be in the struct, and 32bit x86 can use a register for the extra parameter, whereas it otherwise might not). ?- Jay From jay.krell at cornell.edu Fri Sep 3 12:24:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 10:24:54 +0000 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: ---------------------------------------- > Date: Sun, 29 Aug 2010 15:58:21 +0200 > From: wagner > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system > > Quoting Jay K : > > > I think I would settle for SVN. > > Though SVN has completely broken branching last I checked, and they > > acknowledged it. > > SVN also has relatively large dependencies to build from source. > > Branching in SVN is OK, merging is still wanting in case of tree > conflicts. Last I knew, svn wouldn't keep track if particular changes were merged or not. You were supposed to note in the commit comment what you merged and then know in future to ignore them. Therefore, you can't merge. Therefore, branching is just copying. All systems support that. ?? Ok, so they might have copy-on-write cheaper branching. Not impressive. ?? Perforce does branching darn near perfectly. Also last I knew I think SVN only really supported like temporary single level branches off of trunk. Perforce allows arbitrary deep hiearchies and a model where developers stay in their branches indefinitely, with regular merging in both directions. Model where branches aren't meant to be temporary or experimental, but are meant for "staging" or "isolation", give places for work to stabilize before moving around, and do that as a matter of course for all changes. You do then have to build all the various branches and regularly merge (they call it "integrate"). It is great for large teams. SVN's model seems to be that branches are all temporary/experimental and expected to eventually merge to trunk and then go away. > > I would also like a system that doesn't drop files/directories all > > over the place. Just in the root of a checkout should > > suffice and be ideal. CVS is awful here and I believe SVN is too. > > The working copy overhaul expected to be included in SVN 1.7 will > keep all metadata at the root of the checkout in an SQL database. Excellent! Maybe wait for that? :) ?- Jay From jay.krell at cornell.edu Fri Sep 3 12:29:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 10:29:00 +0000 Subject: [M3devel] AMD64_FREEBSD to gcc 4.5? Message-ID: AMD64_FREEBSD to gcc 4.5? There are a few options for me to do this: ? - just make the "small" change and see what happens in Hudson ? ?? ? ("small" as in a small textual diff, but not small in meaning) ? - ssh as hudson to the hudson node and work/test in $HOME/jay or such ? - setup a VM and test it there; not difficult x86/AMD64 platforms have had a high rate of working here and there aren't many left, so option #1 doesn't seem too bad. "Philosophically" #1 is the worst, least responsible, option. But probably ok. I can at least do a quick cross build of cm3 only. ? (still todo: enable cross building the whole system, for our ?? unusual but useful definition of "cross build") ?- Jay From wagner at elegosoft.com Fri Sep 3 12:45:40 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 12:45:40 +0200 Subject: [M3devel] CM3 services and Elego support, was: Re: conversion to another version control system In-Reply-To: References: <20100827173502.GA8777@topoi.pooq.com>, , , , <20100827180902.GA8903@topoi.pooq.com>, , , , , , , , <20100827205555.dm6ju3ywkkwcsc0o@mail.elegosoft.com>, , , , <20100827193836.GC8903@topoi.pooq.com>, , , , <45AF1046-B964-4509-878D-406269EEA3EC@darko.org>, , <1282983172.2770.71.camel@boromir.m3w.org>, , <1AC6963E-3FE2-435B-8F6A-B3F45DC2E723@darko.org>, <20100829131544.cbyqmdpi8gc8ogog@mail.elegosoft.com>, , <20100829155821.hylysl3alck4oc0s@mail.elegosoft.com> Message-ID: <20100903124540.qsd9e5bsgs4w0o8g@mail.elegosoft.com> Quoting Jay K : >> Date: Sun, 29 Aug 2010 15:58:21 +0200 >> From: wagner >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: RE: [M3devel] CM3 services and Elego support, was: Re: >> conversion to another version control system >> >> Quoting Jay K : >> >> > I think I would settle for SVN. >> > Though SVN has completely broken branching last I checked, and they >> > acknowledged it. >> > SVN also has relatively large dependencies to build from source. >> >> Branching in SVN is OK, merging is still wanting in case of tree >> conflicts. > > Last I knew, svn wouldn't keep track if particular changes were > merged or not. > You were supposed to note in the commit comment what you merged > and then know in future to ignore them. It does that now. Merge tracking was a feature in 1.5 IIRC. > Therefore, you can't merge. > Therefore, branching is just copying. All systems support that. > ?? Ok, so they might have copy-on-write cheaper branching. Not impressive. > ?? Perforce does branching darn near perfectly. > Also last I knew I think SVN only really supported like temporary > single level > branches off of trunk. Perforce allows arbitrary deep hiearchies and a model > where developers stay in their branches indefinitely, with regular merging > in both directions. Model where branches aren't meant to be temporary > or experimental, but are meant for "staging" or "isolation", give places > for work to stabilize before moving around, and do that as a matter of > course for all changes. You do then have to build all the various branches > and regularly merge (they call it "integrate"). It is great for large teams. > > SVN's model seems to be that branches are all temporary/experimental > and expected to eventually merge to trunk and then go away. SVN does not enforce any branching/merging patterns. Our customers use it with very different branching setups. It supports arbitrary branching of development lines to any depth. >> > I would also like a system that doesn't drop files/directories all >> > over the place. Just in the root of a checkout should >> > suffice and be ideal. CVS is awful here and I believe SVN is too. >> >> The working copy overhaul expected to be included in SVN 1.7 will >> keep all metadata at the root of the checkout in an SQL database. > > Excellent! > Maybe wait for that? :) No problem from my side. I'm not in a hurry to replace the existing CVS setup. It would be cool if we could run CVS and GIT copies of the CM3 repo in parallel for some time (r/o but regularly sync'ed), so that people can try and see what works best for them. 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 Fri Sep 3 12:49:29 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 12:49:29 +0200 Subject: [M3devel] AMD64_FREEBSD to gcc 4.5? In-Reply-To: References: Message-ID: <20100903124929.q4ygisaf440kgwg0@mail.elegosoft.com> Quoting Jay K : > AMD64_FREEBSD to gcc 4.5? > > There are a few options for me to do this: > > ? - just make the "small" change and see what happens in Hudson > ? ?? ? ("small" as in a small textual diff, but not small in meaning) > ? - ssh as hudson to the hudson node and work/test in $HOME/jay or such > ? - setup a VM and test it there; not difficult > > x86/AMD64 platforms have had a high rate of working here and there > aren't many left, so option #1 doesn't seem too bad. > > "Philosophically" #1 is the worst, least responsible, option. > But probably ok. > > I can at least do a quick cross build of cm3 only. > ? (still todo: enable cross building the whole system, for our > ?? unusual but useful definition of "cross build") AMD64_FREEBSD is one of the platforms that does quick continuous builds, I'd go ahead and just make the small change if you can roll it back easily. If you want I can also give you an account on my home system for testing. 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 Fri Sep 3 12:53:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 10:53:51 +0000 Subject: [M3devel] symlink grief? Message-ID: ?+++ /cm3/bin/cm3? -ship -DROOT=/home/jay/dev2/cm3 +++ --- shipping from I386_LINUX --- "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: quake runtime error: unable to create directory "/cm3": errno=17 --procedure--? -line-? -file--- make_dir?????????? --? ??????????????????? 1? /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP Fatal Error: package build failed ?*** execution of [, ????? RETURN FALSE; ??? END; ? END IsDirectory; Maybe the right thing is to mimic Posix and allow code like: PROCEDURE IsDirectory (path: TEXT): BOOLEAN = ? VAR s: File.Status; ? BEGIN ??? TRY ????? s := FS.LinkStatus (path); ????? RETURN (s.type = FS.SymblicLinkFileType); ??? EXCEPT OSError.E => ????? RETURN FALSE; ??? END; ? END IsDirectory; or such? Not sure it is needed. Or FS.StatusNoLinkResolve? Is that clearer? There are a few basic problems here: ? - The "Modula-3 code base" has been written I assume without symlinks in mind. ?? ? - I don't have symlinks in mind, much at all, since I'm usually not on a system with them. ? I don't have a mental model of how to program with them, etc. ? Maybe some short document I can read and memorize? ?- Jay From wagner at elegosoft.com Fri Sep 3 13:10:51 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 13:10:51 +0200 Subject: [M3devel] symlink grief? In-Reply-To: References: Message-ID: <20100903131051.nwppumquscgos08s@mail.elegosoft.com> Symbolic links usually `just work'. If you have changed stat to lstat for all use cases, that will of course cause problems. I thought your changes were local to the rmrec implementation for quake. Aren't they? If not, it will be better to revert them. Olaf PS: Windows NTFS does support symbolic links, too, though I've probably never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link Quoting Jay K : > ?+++ /cm3/bin/cm3? -ship -DROOT=/home/jay/dev2/cm3 +++ > --- shipping from I386_LINUX --- > > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: > quake runtime error: unable to create directory "/cm3": errno=17 > > --procedure--? -line-? -file--- > make_dir?????????? --? > ??????????????????? 1? /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP > > Fatal Error: package build failed > ?*** execution of [, > > > /cm3 is a symlink to /home/jay/cm3 > They both exist. > /home/jay/cm3 is a directory. > > I predict no good answers here. > ?- a code base that historically used stat, that I changed to lstat. > > I think maybe I should put it back to stat. > And maybe come up with new functions for fs_rmrec to use. > > Wild guess... we have code like: > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > ? VAR s: File.Status; > ? BEGIN > ??? TRY > ????? s := FS.Status (path); > ????? RETURN (s.type = FS.DirectoryFileType); > ??? EXCEPT OSError.E => > ????? RETURN FALSE; > ??? END; > ? END IsDirectory; > > > Maybe the right thing is to mimic Posix and allow code like: > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > ? VAR s: File.Status; > ? BEGIN > ??? TRY > ????? s := FS.LinkStatus (path); > ????? RETURN (s.type = FS.SymblicLinkFileType); > ??? EXCEPT OSError.E => > ????? RETURN FALSE; > ??? END; > ? END IsDirectory; > > or such? > > Not sure it is needed. > > Or FS.StatusNoLinkResolve? Is that clearer? > > There are a few basic problems here: > ? - The "Modula-3 code base" has been written I assume without > symlinks in mind. ?? > ? - I don't have symlinks in mind, much at all, since I'm usually > not on a system with them. > ? I don't have a mental model of how to program with them, etc. > ? Maybe some short document I can read and memorize? > > > ?- Jay > -- 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 Sep 3 13:17:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 11:17:09 +0000 Subject: [M3devel] symlink grief? In-Reply-To: <20100903131051.nwppumquscgos08s@mail.elegosoft.com> References: , <20100903131051.nwppumquscgos08s@mail.elegosoft.com> Message-ID: No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3. How about: PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER = ? VAR statBuf: Ustat.struct_stat; ? BEGIN ??? IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s, ADR(statBuf)) < 0 THEN ????? RETURN -1; ??? END; ??? status.type := FilePosix.FileTypeFromStatbuf(statBuf); ??? (* Could make following assignments conditional on type: *) ??? status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL); ??? status.size := statBuf.st_size; ??? IF status.size < 0L THEN RETURN -1 END; ??? RETURN 0 ? END CStatus; I can look again, *maybe* rmrec can avoid calling here. Though probably the best way to achieve that is by writing two independent versions in C. I think the Modula-3 file system libraries are just too keen on calling stat, which fails for dangling symlinks. ?- Jay ---------------------------------------- > Date: Fri, 3 Sep 2010 13:10:51 +0200 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] symlink grief? > > Symbolic links usually `just work'. > If you have changed stat to lstat for all use cases, that will of > course cause problems. I thought your changes were local to the > rmrec implementation for quake. Aren't they? > > If not, it will be better to revert them. > > Olaf > > PS: Windows NTFS does support symbolic links, too, though I've probably > never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link > > Quoting Jay K : > > > +++ /cm3/bin/cm3 -ship -DROOT=/home/jay/dev2/cm3 +++ > > --- shipping from I386_LINUX --- > > > > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: > > quake runtime error: unable to create directory "/cm3": errno=17 > > > > --procedure-- -line- -file--- > > make_dir -- > > 1 /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP > > > > Fatal Error: package build failed > > *** execution of [, > > > > > > > > /cm3 is a symlink to /home/jay/cm3 > > They both exist. > > /home/jay/cm3 is a directory. > > > > I predict no good answers here. > > - a code base that historically used stat, that I changed to lstat. > > > > I think maybe I should put it back to stat. > > And maybe come up with new functions for fs_rmrec to use. > > > > Wild guess... we have code like: > > > > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > > VAR s: File.Status; > > BEGIN > > TRY > > s := FS.Status (path); > > RETURN (s.type = FS.DirectoryFileType); > > EXCEPT OSError.E => > > RETURN FALSE; > > END; > > END IsDirectory; > > > > > > Maybe the right thing is to mimic Posix and allow code like: > > > > > > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > > VAR s: File.Status; > > BEGIN > > TRY > > s := FS.LinkStatus (path); > > RETURN (s.type = FS.SymblicLinkFileType); > > EXCEPT OSError.E => > > RETURN FALSE; > > END; > > END IsDirectory; > > > > or such? > > > > Not sure it is needed. > > > > Or FS.StatusNoLinkResolve? Is that clearer? > > > > There are a few basic problems here: > > - The "Modula-3 code base" has been written I assume without > > symlinks in mind. ?? > > - I don't have symlinks in mind, much at all, since I'm usually > > not on a system with them. > > I don't have a mental model of how to program with them, etc. > > Maybe some short document I can read and memorize? > > > > > > - Jay > > > > > > -- > 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 Sep 3 13:27:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 11:27:38 +0000 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? Message-ID: more type improvements in m3cc/parse.c? So, the initial goal of fixing SPARC64_SOLARIS without breaking anything seems to have worked. ?I have to check all the platforms still. And debugging of records is much much better in gdb. ? (again, needs testing..) Now I'd like to continue: ?enums ?packed ?objects ?function pointer types ?arrays ?open arrays ? ? This requires a fairly complete understanding of the "object model". Basically what Modula-3 looks like in C. ? Yes, this dovetails into generating C. Stuff like: ?Are enums always 32 bits? ?Or are they chosen among 8, 16, 32 bits, as needed to fit their values? ?Or are they always integer sized but we limit them to 2^32 values? ? ? What can/does packed do? The language spec was deliberately vague. It can add arbitrary padding to the end of records? It removes any possible padding at end of records? It can shrink enums and subranges to other than 8/16/32/64 bits? ?It can grow enums/subranges? ? ? ?What do objects look like? ?I assume they are something like C++ classes with single inheritance. ?A vtable pointer followed by the data. ? What do arrays look like? ?This was answered recently. Including it here for completeness. ?I should commit what was said. ? What are the ramifications of the ability to do type switching at runtime? Maybe another field in objects? What do exceptions look like? ?Just records? ? Just read m3front to learn all this? And look at generated code? I can, but I'm lazy. If anyone knows all this stuff off the top of their head, checking it into doc/notes/objectmodel.txt is roughly my preference. I will have to put together a bunch of small samples, that both RTIO.PrintWhatever their data, and step through in gdb and see if things match. How much, if any of this is subject to change? I suspect none of it. Sure, you are supposed to know it when you write Modula-3. But parse.c can/should, caveat about making the same decisions as m3front. Thanks, ?- Jay From jay.krell at cornell.edu Fri Sep 3 13:28:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 11:28:48 +0000 Subject: [M3devel] field accesses in m3cg? Message-ID: Thoughts on exposing higher level "field load/store" in m3cg? I'm wary of it currently. Would rather do other stuff for now. It'd let the bitfield refs be replaced by something "proper". But it opens up more danger in terms of frontend/backend layout disagreement. ?- Jay From jay.krell at cornell.edu Fri Sep 3 14:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 12:19:08 +0000 Subject: [M3devel] SPARC64_SOLARIS still not quite wokring Message-ID: Just a note that there are further problems. Later.. == package /home/jay/dev2/cm3/m3-obliq/obliqrt == ?+++ /cm3.sparc64/bin/cm3??? -build -DROOT=/home/jay/dev2/cm3 +++ --- building in SPARC64_SOLARIS --- ignoring ../src/m3overrides /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemVar?? -T.M3IMPTAB stubgen: Processing ObValue.RemVar /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemArray?? -T.M3IMPTAB stubgen: Processing ObValue.RemArray /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemObj?? -T.M3IMPTAB stubgen: Processing ObValue.RemObj /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemEngine?? -T.M3IMPTAB stubgen: Processing ObValue.RemEngine /cm3.sparc64/bin/stubgen -v1 -sno ObValue.RemFileSystem?? -T.M3IMPTAB stubgen: Processing ObValue.RemFileSystem /cm3.sparc64/bin/stubgen -v1 -sno ObValue.NonRemObjHook?? -T.M3IMPTAB stubgen: Processing ObValue.NonRemObjHook /cm3.sparc64/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB /cm3.sparc64/bin/shobjcodegen: Processing ObValue.ReplObjStd /cm3.sparc64/bin/shobjcodegen: method? listed in SHARED UPDATE METHODS pragma not declared /cm3.sparc64/bin/shobjcodegen: Method error -- no stubs produced. "/cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl", line 55: quake runtime error: exit 1: /cm3.sparc64/bin/shobjcodegen -o ObValue -p -so ObValue.ReplObjStd -i ObValueRep -T.M3IMPTAB --procedure--? -line-? -file--- exec?????????????? --? _v_sharedobjv1????? 55? /cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl sharedobjv1??????? 62? /cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl sharedobj????????? 70? /cm3.sparc64/pkg/sharedobj/src/sharedobj.tmpl include_dir??????? 53? /home/jay/dev2/cm3/m3-obliq/obliqrt/src/m3makefile ??????????????????? 5? /home/jay/dev2/cm3/m3-obliq/obliqrt/SPARC64_SOLARIS/m3make.args From jay.krell at cornell.edu Fri Sep 3 14:37:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 12:37:37 +0000 Subject: [M3devel] I386_LINUX -O3 Message-ID: It looks like I386_LINUX -O3 is broken now. Probably due to the types on trees in parse.c I gets just to the start of InitRuntime and accesses NULL. I don't remember if I tested unpotimized or -O2 or -O3 in the bulk of my testing here. Later.. ?- Jay From wagner at elegosoft.com Fri Sep 3 14:38:25 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 03 Sep 2010 14:38:25 +0200 Subject: [M3devel] symlink grief? In-Reply-To: References: , <20100903131051.nwppumquscgos08s@mail.elegosoft.com> Message-ID: <20100903143825.t378qzdqsc0cgwc4@mail.elegosoft.com> Quoting Jay K : > No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3. > How about: > > PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER = > ? VAR statBuf: Ustat.struct_stat; > ? BEGIN > ??? IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s, > ADR(statBuf)) < 0 THEN > ????? RETURN -1; > ??? END; > ??? status.type := FilePosix.FileTypeFromStatbuf(statBuf); > ??? (* Could make following assignments conditional on type: *) > ??? status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL); > ??? status.size := statBuf.st_size; > ??? IF status.size < 0L THEN RETURN -1 END; > ??? RETURN 0 > ? END CStatus; Could be worth a try, Olaf > > I can look again, *maybe* rmrec can avoid calling here. > Though probably the best way to achieve that is by writing two > independent versions in C. > I think the Modula-3 file system libraries are just too keen on > calling stat, which fails > for dangling symlinks. > > ?- Jay > > ---------------------------------------- >> Date: Fri, 3 Sep 2010 13:10:51 +0200 >> From: wagner at elegosoft.com >> To: m3devel at elegosoft.com >> Subject: Re: [M3devel] symlink grief? >> >> Symbolic links usually `just work'. >> If you have changed stat to lstat for all use cases, that will of >> course cause problems. I thought your changes were local to the >> rmrec implementation for quake. Aren't they? >> >> If not, it will be better to revert them. >> >> Olaf >> >> PS: Windows NTFS does support symbolic links, too, though I've probably >> never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link >> >> Quoting Jay K : >> >> > +++ /cm3/bin/cm3 -ship -DROOT=/home/jay/dev2/cm3 +++ >> > --- shipping from I386_LINUX --- >> > >> > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: >> > quake runtime error: unable to create directory "/cm3": errno=17 >> > >> > --procedure-- -line- -file--- >> > make_dir -- >> > 1 >> /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP >> > >> > Fatal Error: package build failed >> > *** execution of [, >> > >> > >> > >> > /cm3 is a symlink to /home/jay/cm3 >> > They both exist. >> > /home/jay/cm3 is a directory. >> > >> > I predict no good answers here. >> > - a code base that historically used stat, that I changed to lstat. >> > >> > I think maybe I should put it back to stat. >> > And maybe come up with new functions for fs_rmrec to use. >> > >> > Wild guess... we have code like: >> > >> > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = >> > VAR s: File.Status; >> > BEGIN >> > TRY >> > s := FS.Status (path); >> > RETURN (s.type = FS.DirectoryFileType); >> > EXCEPT OSError.E => >> > RETURN FALSE; >> > END; >> > END IsDirectory; >> > >> > >> > Maybe the right thing is to mimic Posix and allow code like: >> > >> > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = >> > VAR s: File.Status; >> > BEGIN >> > TRY >> > s := FS.LinkStatus (path); >> > RETURN (s.type = FS.SymblicLinkFileType); >> > EXCEPT OSError.E => >> > RETURN FALSE; >> > END; >> > END IsDirectory; >> > >> > or such? >> > >> > Not sure it is needed. >> > >> > Or FS.StatusNoLinkResolve? Is that clearer? >> > >> > There are a few basic problems here: >> > - The "Modula-3 code base" has been written I assume without >> > symlinks in mind. ?? >> > - I don't have symlinks in mind, much at all, since I'm usually >> > not on a system with them. >> > I don't have a mental model of how to program with them, etc. >> > Maybe some short document I can read and memorize? >> > >> > >> > - Jay >> > >> >> >> >> -- >> 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 hosking at cs.purdue.edu Fri Sep 3 15:34:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 3 Sep 2010 09:34:29 -0400 Subject: [M3devel] field accesses in m3cg? In-Reply-To: References: Message-ID: <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu> On 3 Sep 2010, at 07:28, Jay K wrote: > > Thoughts on exposing higher level "field load/store" in m3cg? > I'm wary of it currently. > Would rather do other stuff for now. > > It'd let the bitfield refs be replaced by something "proper". > > But it opens up more danger in terms of frontend/backend layout disagreement. I worry about this. > > - Jay > > > > > From hendrik at topoi.pooq.com Fri Sep 3 16:02:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Fri, 3 Sep 2010 10:02:37 -0400 Subject: [M3devel] a trouble with passing records by value.. In-Reply-To: References: <20100902175032.GA1879@topoi.pooq.com> Message-ID: <20100903140236.GA4701@topoi.pooq.com> On Fri, Sep 03, 2010 at 02:57:52AM +0000, Jay K wrote: > > > To avoid going into assembly langauge in my C interpreter, on many platforms I did the > > following hack: > > > > Pack the parameters into a large struct (like struct big{char space[1000];} ), calculating > > parameter positions myself. The type of the space array was completely irrelevant -- as > > long as it ws big enough. > > > > Then I pass the struct by value to the called program, ignoring the types the called > > program wanted -- you can do this with enough casts. > > > > This worked for a *lot* of systems. > > > > To avoid wasting too much stack space, I had a variety of struct types available, of > > different sizes, each with its own code. > > > > -- hendrik > > > Debugging would suffer like it did/does today. Well, it was an interpreter, and so gdb would be useless anyway. > Code quality would suffer. Yeah. Interpreters aren't known for optimising register allocation for the interpreted program anyway. > > > Hey, I wanted to pass the static link in an extra parameter concocted by the > frontend but Tony didn't want that loss of code quality. The extra parameter would be the way to do it if you had to generate standard C code, but it's not if you are able to rely on gcc extras. > (Letting gcc do the work here has a few advantages: the optimizer > can decide which locals even need to be in the struct, and 32bit x86 > can use a register for the extra parameter, whereas it otherwise might not). > > > ?- Jay > From jay.krell at cornell.edu Fri Sep 3 16:31:59 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 14:31:59 +0000 Subject: [M3devel] I386_LINUX -O3 In-Reply-To: References: Message-ID: -O2 crashes also. Non-optimized works. I can't look more till next week, might try setting up Hudson job for this. Jay/phone > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 3 Sep 2010 12:37:37 +0000 > Subject: [M3devel] I386_LINUX -O3 > > > It looks like I386_LINUX -O3 is broken now. > Probably due to the types on trees in parse.c > I gets just to the start of InitRuntime and accesses NULL. > > I don't remember if I tested unpotimized or -O2 or -O3 in the bulk of my testing here. > > Later.. > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Fri Sep 3 17:34:48 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Fri, 03 Sep 2010 08:34:48 -0700 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? In-Reply-To: References: Message-ID: <20100903153448.952911A20A7@async.async.caltech.edu> Jay can you please not use the term "object model" for what you're describing here? I think "object model" should be limited to what is in the Green Book and Cardelli's paper on the Modula-3 type system. What you're talking about is "object implementation", specific to CM3 and perhaps a few other compilers, not the Modula-3 programming language. It is very confusing to see the expression used to cover both concepts, which, though obviously related, are quite different. And no you don't have to know many of these things when programming in Modula-3. As you say, the book is sometimes deliberately vague. For some of the points you raise, the programmer should write the program so it can deal with any possible implementation; for some others it helps if he knows, but if he doesn't, the compiler may reject some perfectly legal Modula-3 programs ("implementation restrictions"). Just please don't mix that up with the language definition... Mika Jay K writes: > >more type improvements in m3cc/parse.c? > > >So=2C the initial goal of fixing SPARC64_SOLARIS >without breaking anything seems to have worked. >=A0I have to check all the platforms still. > > >And debugging of records is much much better in gdb. >=A0 (again=2C needs testing..) > > >Now I'd like to continue: >=A0enums >=A0packed >=A0objects >=A0function pointer types >=A0arrays >=A0open arrays >=A0 >=A0 >This requires a fairly complete understanding of the "object model". >Basically what Modula-3 looks like in C. >=A0 Yes=2C this dovetails into generating C. > > >Stuff like: >=A0Are enums always 32 bits? >=A0Or are they chosen among 8=2C 16=2C 32 bits=2C as needed to fit their va= >lues? >=A0Or are they always integer sized but we limit them to 2^32 values? >=A0 >=A0 >What can/does packed do? >The language spec was deliberately vague. >It can add arbitrary padding to the end of records? >It removes any possible padding at end of records? >It can shrink enums and subranges to other than 8/16/32/64 bits? >=A0It can grow enums/subranges? >=A0 >=A0 >=A0What do objects look like? >=A0I assume they are something like C++ classes with single inheritance. >=A0A vtable pointer followed by the data. >=A0 > >What do arrays look like? >=A0This was answered recently. Including it here for completeness. >=A0I should commit what was said. > >=A0 >What are the ramifications of the ability to do type switching at runtime? >Maybe another field in objects? > > >What do exceptions look like? >=A0Just records? >=A0 > >Just read m3front to learn all this? >And look at generated code? >I can=2C but I'm lazy. > > >If anyone knows all this stuff off the top of their head=2C >checking it into doc/notes/objectmodel.txt is roughly >my preference. > > >I will have to put together a bunch of small samples=2C that >both RTIO.PrintWhatever their data=2C and step through in gdb >and see if things match. > > >How much=2C if any of this is subject to change? >I suspect none of it. >Sure=2C you are supposed to know it when you write Modula-3. >But parse.c can/should=2C caveat about making the same decisions as m3front= >. > > >Thanks=2C >=A0- Jay = From jay.krell at cornell.edu Fri Sep 3 22:19:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 20:19:11 +0000 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? In-Reply-To: <20100903153448.952911A20A7@async.async.caltech.edu> References: , <20100903153448.952911A20A7@async.async.caltech.edu> Message-ID: Stan Lippmann's excellent book "The C Object Model".. but ok.. Looks like I missed "not" at important place: Modula-3 programmer does NOT need to know this stuff generally. But Modula-3 implementer does. Jay/phone > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? > Date: Fri, 3 Sep 2010 08:34:48 -0700 > From: mika at async.async.caltech.edu > > > Jay can you please not use the term "object model" for what you're > describing here? I think "object model" should be limited to what > is in the Green Book and Cardelli's paper on the Modula-3 type system. > What you're talking about is "object implementation", specific to CM3 and > perhaps a few other compilers, not the Modula-3 programming language. > It is very confusing to see the expression used to cover both concepts, > which, though obviously related, are quite different. > > And no you don't have to know many of these things when programming > in Modula-3. As you say, the book is sometimes deliberately vague. > For some of the points you raise, the programmer should write the program > so it can deal with any possible implementation; for some others it helps > if he knows, but if he doesn't, the compiler may reject some perfectly > legal Modula-3 programs ("implementation restrictions"). Just please > don't mix that up with the language definition... > > Mika > > Jay K writes: > > > >more type improvements in m3cc/parse.c? > > > > > >So=2C the initial goal of fixing SPARC64_SOLARIS > >without breaking anything seems to have worked. > >=A0I have to check all the platforms still. > > > > > >And debugging of records is much much better in gdb. > >=A0 (again=2C needs testing..) > > > > > >Now I'd like to continue: > >=A0enums > >=A0packed > >=A0objects > >=A0function pointer types > >=A0arrays > >=A0open arrays > >=A0 > >=A0 > >This requires a fairly complete understanding of the "object model". > >Basically what Modula-3 looks like in C. > >=A0 Yes=2C this dovetails into generating C. > > > > > >Stuff like: > >=A0Are enums always 32 bits? > >=A0Or are they chosen among 8=2C 16=2C 32 bits=2C as needed to fit their va= > >lues? > >=A0Or are they always integer sized but we limit them to 2^32 values? > >=A0 > >=A0 > >What can/does packed do? > >The language spec was deliberately vague. > >It can add arbitrary padding to the end of records? > >It removes any possible padding at end of records? > >It can shrink enums and subranges to other than 8/16/32/64 bits? > >=A0It can grow enums/subranges? > >=A0 > >=A0 > >=A0What do objects look like? > >=A0I assume they are something like C++ classes with single inheritance. > >=A0A vtable pointer followed by the data. > >=A0 > > > >What do arrays look like? > >=A0This was answered recently. Including it here for completeness. > >=A0I should commit what was said. > > > >=A0 > >What are the ramifications of the ability to do type switching at runtime? > >Maybe another field in objects? > > > > > >What do exceptions look like? > >=A0Just records? > >=A0 > > > >Just read m3front to learn all this? > >And look at generated code? > >I can=2C but I'm lazy. > > > > > >If anyone knows all this stuff off the top of their head=2C > >checking it into doc/notes/objectmodel.txt is roughly > >my preference. > > > > > >I will have to put together a bunch of small samples=2C that > >both RTIO.PrintWhatever their data=2C and step through in gdb > >and see if things match. > > > > > >How much=2C if any of this is subject to change? > >I suspect none of it. > >Sure=2C you are supposed to know it when you write Modula-3. > >But parse.c can/should=2C caveat about making the same decisions as m3front= > >. > > > > > >Thanks=2C > >=A0- Jay = -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Sep 3 23:00:52 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 3 Sep 2010 21:00:52 +0000 Subject: [M3devel] symlink grief? In-Reply-To: <20100903143825.t378qzdqsc0cgwc4@mail.elegosoft.com> References: , <20100903131051.nwppumquscgos08s@mail.elegosoft.com>, , <20100903143825.t378qzdqsc0cgwc4@mail.elegosoft.com> Message-ID: Clarification: There were changes at both levels. The toplevel ones maybe all unnecessary. I'll maybe look at this more but I also suspect it is ok now. Another approach would be to avoid stat altogether here, in rmrec. One can deduce the type by calling unlink and/or rmdir & checking the error. Or just rewrite rmrec in C.. - jay/phone > Date: Fri, 3 Sep 2010 14:38:25 +0200 > From: wagner at elegosoft.com > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] symlink grief? > > Quoting Jay K : > > > No they were in a very central place m3-libs/libm3/src/os/POSIX/FSPosix.m3. > > How about: > > > > PROCEDURE CStatus(s: Ctypes.char_star; VAR status: File.Status): INTEGER = > > VAR statBuf: Ustat.struct_stat; > > BEGIN > > IF Ustat.stat(s, ADR(statBuf)) < 0 AND Ustat.lstat(s, > > ADR(statBuf)) < 0 THEN > > RETURN -1; > > END; > > status.type := FilePosix.FileTypeFromStatbuf(statBuf); > > (* Could make following assignments conditional on type: *) > > status.modificationTime := FLOAT(statBuf.st_mtime, LONGREAL); > > status.size := statBuf.st_size; > > IF status.size < 0L THEN RETURN -1 END; > > RETURN 0 > > END CStatus; > > Could be worth a try, > > Olaf > > > > > I can look again, *maybe* rmrec can avoid calling here. > > Though probably the best way to achieve that is by writing two > > independent versions in C. > > I think the Modula-3 file system libraries are just too keen on > > calling stat, which fails > > for dangling symlinks. > > > > - Jay > > > > ---------------------------------------- > >> Date: Fri, 3 Sep 2010 13:10:51 +0200 > >> From: wagner at elegosoft.com > >> To: m3devel at elegosoft.com > >> Subject: Re: [M3devel] symlink grief? > >> > >> Symbolic links usually `just work'. > >> If you have changed stat to lstat for all use cases, that will of > >> course cause problems. I thought your changes were local to the > >> rmrec implementation for quake. Aren't they? > >> > >> If not, it will be better to revert them. > >> > >> Olaf > >> > >> PS: Windows NTFS does support symbolic links, too, though I've probably > >> never used them: http://en.wikipedia.org/wiki/NTFS_symbolic_link > >> > >> Quoting Jay K : > >> > >> > +++ /cm3/bin/cm3 -ship -DROOT=/home/jay/dev2/cm3 +++ > >> > --- shipping from I386_LINUX --- > >> > > >> > "/home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP", line 1: > >> > quake runtime error: unable to create directory "/cm3": errno=17 > >> > > >> > --procedure-- -line- -file--- > >> > make_dir -- > >> > 1 > >> /home/jay/dev2/cm3/m3-libs/m3core/I386_LINUX/.M3SHIP > >> > > >> > Fatal Error: package build failed > >> > *** execution of [, > >> > > >> > > >> > > >> > /cm3 is a symlink to /home/jay/cm3 > >> > They both exist. > >> > /home/jay/cm3 is a directory. > >> > > >> > I predict no good answers here. > >> > - a code base that historically used stat, that I changed to lstat. > >> > > >> > I think maybe I should put it back to stat. > >> > And maybe come up with new functions for fs_rmrec to use. > >> > > >> > Wild guess... we have code like: > >> > > >> > > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > >> > VAR s: File.Status; > >> > BEGIN > >> > TRY > >> > s := FS.Status (path); > >> > RETURN (s.type = FS.DirectoryFileType); > >> > EXCEPT OSError.E => > >> > RETURN FALSE; > >> > END; > >> > END IsDirectory; > >> > > >> > > >> > Maybe the right thing is to mimic Posix and allow code like: > >> > > >> > > >> > PROCEDURE IsDirectory (path: TEXT): BOOLEAN = > >> > VAR s: File.Status; > >> > BEGIN > >> > TRY > >> > s := FS.LinkStatus (path); > >> > RETURN (s.type = FS.SymblicLinkFileType); > >> > EXCEPT OSError.E => > >> > RETURN FALSE; > >> > END; > >> > END IsDirectory; > >> > > >> > or such? > >> > > >> > Not sure it is needed. > >> > > >> > Or FS.StatusNoLinkResolve? Is that clearer? > >> > > >> > There are a few basic problems here: > >> > - The "Modula-3 code base" has been written I assume without > >> > symlinks in mind. ?? > >> > - I don't have symlinks in mind, much at all, since I'm usually > >> > not on a system with them. > >> > I don't have a mental model of how to program with them, etc. > >> > Maybe some short document I can read and memorize? > >> > > >> > > >> > - Jay > >> > > >> > >> > >> > >> -- > >> 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 rodney_bates at lcwb.coop Sun Sep 5 21:03:50 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 05 Sep 2010 14:03:50 -0500 Subject: [M3devel] Modula-3 object model details? more type improvements in m3cc/parse.c? In-Reply-To: References: Message-ID: <4C83E996.2090609@lcwb.coop> Jay K wrote: > more type improvements in m3cc/parse.c? > > > So, the initial goal of fixing SPARC64_SOLARIS > without breaking anything seems to have worked. > I have to check all the platforms still. > > > And debugging of records is much much better in gdb. > (again, needs testing..) > > > Now I'd like to continue: > enums > packed > objects > function pointer types > arrays > open arrays > > > This requires a fairly complete understanding of the "object model". > Basically what Modula-3 looks like in C. > Yes, this dovetails into generating C. Because of the much stronger type system, much of the code written will not be dependent on this stuff, the exception being unsafe code. So, the language specifies very little of it. The below is what I understand about our compiler. There may be some target dependencies here. > > > Stuff like: > Are enums always 32 bits? > Or are they chosen among 8, 16, 32 bits, as needed to fit their values? ^Yes. Except when packed, see below. There is nothing in the language that requires this, but the binary values are equal to the ORD function. It is hard to imagine a perverse enough machine for which it would make sense for a compiler to do it any other way. But the type system of the language would allow some other encoding. ORD and VAL would then require runtime computation. > Or are they always integer sized but we limit them to 2^32 values? > > > What can/does packed do? > The language spec was deliberately vague. > a) It can add arbitrary padding to the end of records? > b) It removes any possible padding at end of records? > c) It can shrink enums and subranges to other than 8/16/32/64 bits? > d) It can grow enums/subranges? 1) BITS ... never changes the legal value set. An implication is that if the number of bits given is too small for the value set, as the compiler has chosen to represent it, the compiler must give an error. 2) Packed types have no effect on target layout at all, except when the packed type is used for an array element or field of a record or object. So a packed type in a VAR declaration, for example, accomplishes nothing. (Although it can make the static rules harder to satisfy.) 3) An element or field of packed type can have no padding added ahead of it. 4) An element or field of packed type must occupy exactly the given number of bits. The compiler can either satisfy 3) and 4), or it can refuse, with an error message. These are the only rules. So the implications for your questions above (I added letter designations to them) are: The language makes no statement about a) and b) The compiler can do what it likes at the end of a record, regardless of whether it contains packed fields. Packed types constrain padding only before a packed field. I suppose, if there were an inner record that was a packed field of an outer record, and the compiler had previously laid out the inner record type with trailing padding, and it considered that padding part of the inner record type, then it would then have to require the BITS count to be enough to hold the entire inner record, including its trailing padding. I don't think our compilers ever add trailing padding to anything. Only leading padding ahead of non-packed fields/elements, when needed for alignment or convenience. It can do both c) and d) in order to satisfy 3) and/or 4), in fact it must, or else emit an error message. > > > What do objects look like? > I assume they are something like C++ classes with single inheritance. > A vtable pointer followed by the data. > There are two redundant mechanisms for finding the code body of a dispatching method. Every traced heap object (M3 object or not) has a word at negative displacement that is used by the allocator/GC, for TYPECASEing, etc. You can see its layout in RT0.RefHeader. The biggest part of its contents is a subscript into a table of all the reference types. This is field typecode of RefHeader. This table is in the runtime system, initialized partly by compiled code, partly at program startup. It has one pointer for every reference type in the complete program, counting all the separate compilations. The subscripts to this table are the TYPECODEs. The pointers point to a record of runtime description of the type. These records are of type RT0.Typecell, extended by RT0.ObjectTypecell. The latter has field DefaultMethods, which points to the expected array of pointers to method code bodies for each method of the object, with subscripts laid out statically, in order of the method declarations. But this was apparently judged too slow somewhere along the way, so each object has, at displacement 0, a pointer leading directly to the table of method bodies. Beyond that, it's just the fields of the object, just like a record. BTW, reading this stuff in the RTS is a wonderful example of a seldom-mentioned advantage of static typing. It's all coded using unsafe techniques. No doubt this is necessary for bootstrapping. But the pointers are often of type ADDRESS, and figuring out what thing/things they can point to is much harder than if they were typed. Comments are called for. > > What do arrays look like? > This was answered recently. Including it here for completeness. > I should commit what was said. > > > What are the ramifications of the ability to do type switching at runtime? > Maybe another field in objects? > Not sure what you mean. Do your mean ISTYPE, NARROW, TYPECASE, etc., which all involve testing the allocated type of an object at runtime? These use the typecode/Typecell mechanism. > > What do exceptions look like? > Just records? > > > Just read m3front to learn all this? > And look at generated code? > I can, but I'm lazy. > > > If anyone knows all this stuff off the top of their head, > checking it into doc/notes/objectmodel.txt is roughly > my preference. > > > I will have to put together a bunch of small samples, that > both RTIO.PrintWhatever their data, and step through in gdb > and see if things match. > > > How much, if any of this is subject to change? > I suspect none of it. > Sure, you are supposed to know it when you write Modula-3. > But parse.c can/should, caveat about making the same decisions as m3front. > > > Thanks, > - Jay From wagner at elegosoft.com Mon Sep 6 09:57:42 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 06 Sep 2010 09:57:42 +0200 Subject: [M3devel] Fwd: [CM3] #1149: cm3 compiler looping Message-ID: <20100906095742.927ik5z9ic4kk84k@mail.elegosoft.com> FYI ----- Forwarded message from bugs at elego.de ----- Date: Sat, 04 Sep 2010 12:22:52 -0000 From: CM3 Reply-To: CM3 Subject: [CM3] #1149: cm3 compiler looping To: peter.mckinna at gmail.com, wagner at elego.de #1149: cm3 compiler looping ------------------------------------------+--------------------------------- Reporter: peter.mckinna@? | Owner: wagner Type: sw-bug | Status: new Priority: medium | Milestone: Component: sys | Version: 5.8.6 Severity: serious | Keywords: Relnote: | Org: Estimatedhours: 0 | Hours: 0 Billable: 1 | Totalhours: 0 Internal: 0 | ------------------------------------------+--------------------------------- Htr: copy the following files to a src directory and run cm3. A.i3 INTERFACE A; TYPE CBase <: CBasePublic; CBasePublic = BRANDED OBJECT METHODS area(parm: INTEGER): INTEGER; END; END A. A.m3 MODULE A; BEGIN END A. B.i3 INTERFACE B; IMPORT A; TYPE CSubobj1 <: CSubobj1Public; CSubobj1Public = A.CBase BRANDED OBJECT METHODS area1(parm: INTEGER); END; END B. B.m3 UNSAFE MODULE B; IMPORT BRaw; IMPORT IO; PROCEDURE A1(self : CSubobj1; parm : INTEGER) = BEGIN END A1; REVEAL CSubobj1 = CSubobj1Public BRANDED OBJECT OVERRIDES area1 := A1; END; BEGIN END B. BRaw.i3 INTERFACE BRaw; FROM A IMPORT CBase; REVEAL CSubobj1 = CBase; END BRaw. m3makefile import("libm3") module("A") interface("BRaw") module ("B") library("test") Fix: Env: ------------------------------------------+--------------------------------- the cm3 compiler loops on a reveal statement using 100% cpu. I was making changes to swig generator and inadvertently generated some degenerate code. I have distilled the problem to the sources. It is caused by the reveal stmt in BRaw,i3 -- Ticket URL: CM3 Critical Mass Modula3 Compiler ----- End forwarded message ----- -- 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 Mon Sep 6 21:50:26 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 6 Sep 2010 15:50:26 -0400 Subject: [M3devel] cvsup crash Message-ID: <20100906195026.GA25815@topoi.pooq.com> Is this a known problem? From the mentions of cvsup on this list a few months ago I suspect it might be. But I'm mentioning it in case it's not known. I installed cm3 from the cm3-LINUXLIBC6-REL.deb I downloaded on Sept 5. I than ran cvsup to update my copy of the Modula 3 CVS that I acquired some months ago. This time I did specify the 'cvsroot' option I had forgotten that time. But this time, cvsup crashed: hendrik at lovesong:~/newcm3/trywholecvs$ cvsup cvsupfile-cm3 *** *** runtime error: *** An array subscript was out of range. *** file "../src/vbt/VBTRep.m3", line 644 *** Aborted hendrik at lovesong:~/newcm3/trywholecvs$ Just in case it's relevant, my cvsupfile-cm3 file: # # If not running X, or invoking cvsup from a non-interactive script, then # run it as follows: # # cvsup -g -L 2 cvsupfile.cm3 # # To use the GUI, omit the -g option # # Defaults that apply to all the collections # This host address is permanent: *default host=modula3.elegosoft.com # Please change the local destination as you like # *default base=/usr/tmp/cvs # *default prefix=/usr/tmp/cvs *default base=/farhome/hendrik/newcm3/trywholecvs/cvs *default prefix=/farhome/hendrik/newcm3/trywholecvs/cvs # Use release=cvs to get the full repository, . to checkout the latest # sources, or a cvs tag *default release=cvs *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress *default preserve # cm3 is the complete source file collection, including everything # I had access to from the CM3 4.1 and CM3 5.1 releases made by Critical # Mass, Inc., and all subsequent updates, fixes, and additions of the # open source CM3 distribution # cm3 includes all the cm3-xxx collections below cm3 # scanner and parser generators from the California Institute of Technology #cm3-caltech-parser # cm3 documentation in html and pdf format #cm3-doc # cm3 communication packages distribution (tcp, network objects, serial lines) #cm3-m3-comm # cm3 database related packages (odbc, smalldb, stablegen, postgres) #cm3-m3-db # miscellaneous cm3 demo programs (cube, calculator, fisheye, sharedboard, # mentor) #cm3-m3-demo # games (columns, badbricks, tetris, solitaire, maze) #cm3-m3-games # the lectern documentation tools packages #cm3-m3-lectern # cm3 standard libraries (m3core, libm3, lists, tables, tempfiles, digraphs, # slisp, parseparams, realgeometry, libsio) #cm3-m3-libs # mail packages (llscan, postcard, webcard) #cm3-m3-mail # packages related to the obliq language #cm3-m3-obliq # the SRC package tools #cm3-m3-pkgtools # m3 and quake comopiler, linker, interpreter, installation and support #cm3-m3-sys # miscellaneous tools from pretty printing to heap and thread monitors #cm3-m3-tools # graphical user interface packages (trestle, X11, motif, formsvbt, # videovbt, zeus etc.) #cm3-m3-ui # WWW related packages (http, proxy, web, webcat, webscape, deckscape) #cm3-m3-www # cm3 shell scripts #cm3-scripts # cm3 WWW pages #cm3-www # a CVSROOT directory cvsroot The cvsup I used identifies itself as: hendrik at lovesong:~$ cvsup -v CVSup client, GUI version Copyright 1996-2003 John D. Polstra Software version: release_branch_cm3_5_8 Protocol version: 17.0 Operating system: LINUXLIBC6 http://www.cvsup.org/ Report problems to cvsup-bugs at polstra.com CVSup is a registered trademark of John D. Polstra hendrik at lovesong:~$ -- hendrik From hendrik at topoi.pooq.com Mon Sep 6 22:36:08 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Mon, 6 Sep 2010 16:36:08 -0400 Subject: [M3devel] versioning of .deb Message-ID: <20100906203607.GA26003@topoi.pooq.com> I used cm3-LINUXLIBC6-REL.deb, and it installed cleanly. But as is, it won't pass muster as a submission to Debian. Not that I expected it to, and I'm happy with where it puts files, especially for a package that's still 'experimental' (but not in the Debian-technical sense of the 'experimental' distro, which is even freakier than sid). But one thing it should do, which it doesn't, is include a version number in its name. I'm not sure what the exact rules are in Debian for delimiting a version number, but I'm sure *you*'d find it useful to know which version of a package is involved when getting bug reports. -- hendrik From dabenavidesd at yahoo.es Tue Sep 7 00:36:26 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 6 Sep 2010 22:36:26 +0000 (GMT) Subject: [M3devel] cvsup crash In-Reply-To: <20100906195026.GA25815@topoi.pooq.com> Message-ID: <663789.72909.qm@web29704.mail.ird.yahoo.com> Hi all: perhaps this change was made in support of that days before: https://mail.elegosoft.com/pipermail/m3commit/2010-September/008793.html need to check it really what that means. This perhaps relates to the abstract visibility of memory of the M3CG machine? A similar setting could be written on the ldb debugger as it mentioned the Cedar Abstract machine setting as an example for using its Abstract Memory Interfaces, on which could had interactive debuggers interpreters. This all was based on the Mesa stack machine with some basic extension for Automatic Storage Management. There some types of docs related to it on: http://www.digibarn.com/friends/alanfreier/princops/00yTableOfContents.html Hope this helps a bit --- El lun, 6/9/10, hendrik at topoi.pooq.com escribi?: > De: hendrik at topoi.pooq.com > Asunto: [M3devel] cvsup crash > Para: m3devel at elegosoft.com > Fecha: lunes, 6 de septiembre, 2010 14:50 > Is this a known problem? From > the mentions of cvsup on this list a few > months ago I suspect it might be. But I'm mentioning > it in case it's > not known. > > I installed cm3 from the cm3-LINUXLIBC6-REL.deb I > downloaded on Sept 5. > I than ran cvsup to update my copy of the Modula 3 CVS that > I acquired > some months ago. This time I did specify the > 'cvsroot' option I had > forgotten that time. > > But this time, cvsup crashed: > > hendrik at lovesong:~/newcm3/trywholecvs$ cvsup cvsupfile-cm3 > > > *** > *** runtime error: > *** An array subscript was out of range. > *** file "../src/vbt/VBTRep.m3", line 644 > *** > > Aborted > hendrik at lovesong:~/newcm3/trywholecvs$ > > > Just in case it's relevant, my cvsupfile-cm3 file: > > # > # If not running X, or invoking cvsup from a > non-interactive script, > then > # run it as follows: > # > # cvsup -g -L 2 cvsupfile.cm3 > # > # To use the GUI, omit the -g option > # > > # Defaults that apply to all the collections > > # This host address is permanent: > *default host=modula3.elegosoft.com > > # Please change the local destination as you like > # *default base=/usr/tmp/cvs > # *default prefix=/usr/tmp/cvs > *default base=/farhome/hendrik/newcm3/trywholecvs/cvs > *default prefix=/farhome/hendrik/newcm3/trywholecvs/cvs > > # Use release=cvs to get the full repository, . to checkout > the latest > # sources, or a cvs tag > *default release=cvs > *default delete use-rel-suffix > > # If your network link is a T1 or faster, comment out the > following > line. > *default compress > *default preserve > > # cm3 is the complete source file collection, including > everything > # I had access to from the CM3 4.1 and CM3 5.1 releases > made by Critical > # Mass, Inc., and all subsequent updates, fixes, and > additions of the > # open source CM3 distribution > # cm3 includes all the cm3-xxx collections below > cm3 > > # scanner and parser generators from the California > Institute of > Technology > #cm3-caltech-parser > > # cm3 documentation in html and pdf format > #cm3-doc > > # cm3 communication packages distribution (tcp, network > objects, serial > lines) > #cm3-m3-comm > > # cm3 database related packages (odbc, smalldb, stablegen, > postgres) > #cm3-m3-db > > # miscellaneous cm3 demo programs (cube, calculator, > fisheye, > sharedboard, > # mentor) > #cm3-m3-demo > > # games (columns, badbricks, tetris, solitaire, maze) > #cm3-m3-games > > # the lectern documentation tools packages > #cm3-m3-lectern > > # cm3 standard libraries (m3core, libm3, lists, tables, > tempfiles, > digraphs, > # slisp, parseparams, realgeometry, libsio) > #cm3-m3-libs > > # mail packages (llscan, postcard, webcard) > #cm3-m3-mail > > # packages related to the obliq language > #cm3-m3-obliq > > # the SRC package tools > #cm3-m3-pkgtools > > # m3 and quake comopiler, linker, interpreter, installation > and support > #cm3-m3-sys > > # miscellaneous tools from pretty printing to heap and > thread monitors > #cm3-m3-tools > # graphical user interface packages (trestle, X11, motif, > formsvbt, > # videovbt, zeus etc.) > #cm3-m3-ui > > # WWW related packages (http, proxy, web, webcat, webscape, > deckscape) > #cm3-m3-www > > # cm3 shell scripts > #cm3-scripts > > # cm3 WWW pages > #cm3-www > > # a CVSROOT directory > cvsroot > > > The cvsup I used identifies itself as: > > hendrik at lovesong:~$ cvsup -v > CVSup client, GUI version > Copyright 1996-2003 John D. Polstra > Software version: release_branch_cm3_5_8 > Protocol version: 17.0 > Operating system: LINUXLIBC6 > http://www.cvsup.org/ > Report problems to cvsup-bugs at polstra.com > CVSup is a registered trademark of John D. Polstra > hendrik at lovesong:~$ > > > -- hendrik > > From jay.krell at cornell.edu Tue Sep 7 02:23:15 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Sep 2010 00:23:15 +0000 Subject: [M3devel] cvsup crash In-Reply-To: <663789.72909.qm@web29704.mail.ird.yahoo.com> References: <20100906195026.GA25815@topoi.pooq.com>, <663789.72909.qm@web29704.mail.ird.yahoo.com> Message-ID: Sorry, no. Point there was considering forcing records into memory to help pass them as parameters but I abandoned that approach anyway. It caused other problems -- specifically an assertion failure in the backend related to records and nested functions. Current source passes on more type information than ever before to compiler, and is working in some ways more than ever before, but there are problems under optimization that need more investigation. We only pass on an "intermediate" level of type information, and the frontend does layout itself, so while "good", it is also dangerous. Anyway, to be looked into further. The unfortunate plain truth, it seems, is we have a fairly large code base, with little use, and little expertise. The original authors are all gone. I don't know cvsup. Given how poor cvs is in the first place, and how many promising alternatives there are now, it seems a waste to invest in learning to use cvsup, or spending much time debugging it and fixing it. But maybe we'll get it working. - Jay > Date: Mon, 6 Sep 2010 22:36:26 +0000 > From: dabenavidesd at yahoo.es > To: m3devel at elegosoft.com; hendrik at topoi.pooq.com > Subject: Re: [M3devel] cvsup crash > > Hi all: > perhaps this change was made in support of that days before: > https://mail.elegosoft.com/pipermail/m3commit/2010-September/008793.html > need to check it really what that means. > This perhaps relates to the abstract visibility of memory of the M3CG machine? > A similar setting could be written on the ldb debugger as it mentioned the Cedar Abstract machine setting as an example for using its Abstract Memory Interfaces, on which could had interactive debuggers interpreters. > This all was based on the Mesa stack machine with some basic extension for Automatic Storage Management. There some types of docs related to it on: > http://www.digibarn.com/friends/alanfreier/princops/00yTableOfContents.html > Hope this helps a bit > > --- El lun, 6/9/10, hendrik at topoi.pooq.com escribi?: > > > De: hendrik at topoi.pooq.com > > Asunto: [M3devel] cvsup crash > > Para: m3devel at elegosoft.com > > Fecha: lunes, 6 de septiembre, 2010 14:50 > > Is this a known problem? From > > the mentions of cvsup on this list a few > > months ago I suspect it might be. But I'm mentioning > > it in case it's > > not known. > > > > I installed cm3 from the cm3-LINUXLIBC6-REL.deb I > > downloaded on Sept 5. > > I than ran cvsup to update my copy of the Modula 3 CVS that > > I acquired > > some months ago. This time I did specify the > > 'cvsroot' option I had > > forgotten that time. > > > > But this time, cvsup crashed: > > > > hendrik at lovesong:~/newcm3/trywholecvs$ cvsup cvsupfile-cm3 > > > > > > *** > > *** runtime error: > > *** An array subscript was out of range. > > *** file "../src/vbt/VBTRep.m3", line 644 > > *** > > > > Aborted > > hendrik at lovesong:~/newcm3/trywholecvs$ > > > > > > Just in case it's relevant, my cvsupfile-cm3 file: > > > > # > > # If not running X, or invoking cvsup from a > > non-interactive script, > > then > > # run it as follows: > > # > > # cvsup -g -L 2 cvsupfile.cm3 > > # > > # To use the GUI, omit the -g option > > # > > > > # Defaults that apply to all the collections > > > > # This host address is permanent: > > *default host=modula3.elegosoft.com > > > > # Please change the local destination as you like > > # *default base=/usr/tmp/cvs > > # *default prefix=/usr/tmp/cvs > > *default base=/farhome/hendrik/newcm3/trywholecvs/cvs > > *default prefix=/farhome/hendrik/newcm3/trywholecvs/cvs > > > > # Use release=cvs to get the full repository, . to checkout > > the latest > > # sources, or a cvs tag > > *default release=cvs > > *default delete use-rel-suffix > > > > # If your network link is a T1 or faster, comment out the > > following > > line. > > *default compress > > *default preserve > > > > # cm3 is the complete source file collection, including > > everything > > # I had access to from the CM3 4.1 and CM3 5.1 releases > > made by Critical > > # Mass, Inc., and all subsequent updates, fixes, and > > additions of the > > # open source CM3 distribution > > # cm3 includes all the cm3-xxx collections below > > cm3 > > > > # scanner and parser generators from the California > > Institute of > > Technology > > #cm3-caltech-parser > > > > # cm3 documentation in html and pdf format > > #cm3-doc > > > > # cm3 communication packages distribution (tcp, network > > objects, serial > > lines) > > #cm3-m3-comm > > > > # cm3 database related packages (odbc, smalldb, stablegen, > > postgres) > > #cm3-m3-db > > > > # miscellaneous cm3 demo programs (cube, calculator, > > fisheye, > > sharedboard, > > # mentor) > > #cm3-m3-demo > > > > # games (columns, badbricks, tetris, solitaire, maze) > > #cm3-m3-games > > > > # the lectern documentation tools packages > > #cm3-m3-lectern > > > > # cm3 standard libraries (m3core, libm3, lists, tables, > > tempfiles, > > digraphs, > > # slisp, parseparams, realgeometry, libsio) > > #cm3-m3-libs > > > > # mail packages (llscan, postcard, webcard) > > #cm3-m3-mail > > > > # packages related to the obliq language > > #cm3-m3-obliq > > > > # the SRC package tools > > #cm3-m3-pkgtools > > > > # m3 and quake comopiler, linker, interpreter, installation > > and support > > #cm3-m3-sys > > > > # miscellaneous tools from pretty printing to heap and > > thread monitors > > #cm3-m3-tools > > # graphical user interface packages (trestle, X11, motif, > > formsvbt, > > # videovbt, zeus etc.) > > #cm3-m3-ui > > > > # WWW related packages (http, proxy, web, webcat, webscape, > > deckscape) > > #cm3-m3-www > > > > # cm3 shell scripts > > #cm3-scripts > > > > # cm3 WWW pages > > #cm3-www > > > > # a CVSROOT directory > > cvsroot > > > > > > The cvsup I used identifies itself as: > > > > hendrik at lovesong:~$ cvsup -v > > CVSup client, GUI version > > Copyright 1996-2003 John D. Polstra > > Software version: release_branch_cm3_5_8 > > Protocol version: 17.0 > > Operating system: LINUXLIBC6 > > http://www.cvsup.org/ > > Report problems to cvsup-bugs at polstra.com > > CVSup is a registered trademark of John D. Polstra > > hendrik at lovesong:~$ > > > > > > -- hendrik > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 7 04:26:45 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 6 Sep 2010 22:26:45 -0400 Subject: [M3devel] cvsup crash In-Reply-To: References: <20100906195026.GA25815@topoi.pooq.com>, <663789.72909.qm@web29704.mail.ird.yahoo.com> Message-ID: It is certainly worth On 6 Sep 2010, at 20:23, Jay K wrote: > I don't know cvsup. > Given how poor cvs is in the first place, and how many promising alternatives there are now, > it seems a waste to invest in learning to use cvsup, or spending much time debugging it and fixing it. > But maybe we'll get it working. It is certainly worth fixing bugs exposed by cvsup. It used to run. Why does it not run now? Has there been regression in the CM3 implementation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 7 05:21:30 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Sep 2010 03:21:30 +0000 Subject: [M3devel] cvsup crash In-Reply-To: References: <20100906195026.GA25815@topoi.pooq.com>, , <663789.72909.qm@web29704.mail.ird.yahoo.com>, , Message-ID: > It is certainly worth fixing bugs exposed by cvsup. It used to run. Why does it not run now? Has there been regression in the CM3 implementation? Very little is known. I don't think we should be so quick to assume a regression in cm3. For example, cvsup only recently was ever made to work with non-userthreads. And this version has seen extremely little use. Perhaps it never actually worked with non-user threads. It previously depended on all threads surviving fork(). Bugs could easily be in cvsup itself. As well, don't we know that Trestle has forever had several race conditions? Having recently fixed a few? It's been my experience that the less something is used, the more bugs it has.. Modula-3 * cvsup + trestle... - Jay From: hosking at cs.purdue.edu Date: Mon, 6 Sep 2010 22:26:45 -0400 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com; hendrik at topoi.pooq.com Subject: Re: [M3devel] cvsup crash It is certainly worth On 6 Sep 2010, at 20:23, Jay K wrote: I don't know cvsup. Given how poor cvs is in the first place, and how many promising alternatives there are now, it seems a waste to invest in learning to use cvsup, or spending much time debugging it and fixing it. But maybe we'll get it working. It is certainly worth fixing bugs exposed by cvsup. It used to run. Why does it not run now? Has there been regression in the CM3 implementation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Tue Sep 7 10:31:52 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Sep 2010 10:31:52 +0200 Subject: [M3devel] cvsup crash In-Reply-To: References: <20100906195026.GA25815@topoi.pooq.com>, , <663789.72909.qm@web29704.mail.ird.yahoo.com>, , Message-ID: <20100907103152.w5t3pt1zhwco0gwo@mail.elegosoft.com> Quoting Jay K : > > It is certainly worth fixing bugs exposed by cvsup. It used to > run. Why does it not run now? Has there been regression in the CM3 > implementation? > > Very little is known. I don't think we should be so quick to assume > a regression in cm3. > For example, cvsup only recently was ever made to work with non-userthreads. > And this version has seen extremely little use. Perhaps it never > actually worked with non-user threads. > It previously depended on all threads surviving fork(). The server uses fork. The client doesn't. The problem reported here is on the client side. > Bugs could easily be in cvsup itself. Well, it used to run without problems and is still replicating the CM3 repository regularly to several sites (in an older version). So I think it is likely that we introduced the bugs recently. > As well, don't we know that Trestle has forever had several race conditions? > Having recently fixed a few? > > It's been my experience that the less something is used, the more > bugs it has.. > Modula-3 * cvsup + trestle... The GUI may be disabled with the -g parameter, IIRC. Olaf > From: hosking at cs.purdue.edu > Date: Mon, 6 Sep 2010 22:26:45 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com; hendrik at topoi.pooq.com > Subject: Re: [M3devel] cvsup crash > > > It is certainly worth > > > On 6 Sep 2010, at 20:23, Jay K wrote: > > I don't know cvsup. > Given how poor cvs is in the first place, and how many promising > alternatives there are now, > it seems a waste to invest in learning to use cvsup, or spending > much time debugging it and fixing it. > But maybe we'll get it working. > > It is certainly worth fixing bugs exposed by cvsup. It used to run. > Why does it not run now? Has there been regression in the CM3 > implementation? -- 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 Sep 7 10:52:13 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Sep 2010 10:52:13 +0200 Subject: [M3devel] versioning of .deb In-Reply-To: <20100906203607.GA26003@topoi.pooq.com> References: <20100906203607.GA26003@topoi.pooq.com> Message-ID: <20100907105213.yb1pvnz6sw8o4k4c@mail.elegosoft.com> Quoting hendrik at topoi.pooq.com: > I used cm3-LINUXLIBC6-REL.deb, and it installed cleanly. But as is, it > won't pass muster as a submission to Debian. Not that I expected it to, > and I'm happy with where it puts files, especially for a package that's > still 'experimental' (but not in the Debian-technical sense of the > 'experimental' distro, which is even freakier than sid). > > But one thing it should do, which it doesn't, is include a version > number in its name. I'm not sure what the exact rules are in Debian for > delimiting a version number, but I'm sure *you*'d find it useful to know > which version of a package is involved when getting bug reports. Sure. Anybody cares to fix that? I've been uneasy with providing these unfinished types of platform-specific archives all the time. 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 Tue Sep 7 17:47:29 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Sep 2010 11:47:29 -0400 Subject: [M3devel] cvsup crash In-Reply-To: <20100907103152.w5t3pt1zhwco0gwo@mail.elegosoft.com> References: <20100907103152.w5t3pt1zhwco0gwo@mail.elegosoft.com> Message-ID: <20100907154729.GA29532@topoi.pooq.com> On Tue, Sep 07, 2010 at 10:31:52AM +0200, Olaf Wagner wrote: > Quoting Jay K : > >> > It is certainly worth fixing bugs exposed by cvsup. It used to >> run. Why does it not run now? Has there been regression in the CM3 >> implementation? >> >> Very little is known. I don't think we should be so quick to assume a >> regression in cm3. >> For example, cvsup only recently was ever made to work with non-userthreads. >> And this version has seen extremely little use. Perhaps it never >> actually worked with non-user threads. >> It previously depended on all threads surviving fork(). > > The server uses fork. The client doesn't. The problem reported here > is on the client side. > >> Bugs could easily be in cvsup itself. > > Well, it used to run without problems and is still replicating the > CM3 repository regularly to several sites (in an older version). > So I think it is likely that we introduced the bugs recently. > >> As well, don't we know that Trestle has forever had several race conditions? >> Having recently fixed a few? >> >> It's been my experience that the less something is used, the more >> bugs it has.. >> Modula-3 * cvsup + trestle... > > The GUI may be disabled with the -g parameter, IIRC. It may well be a new GUI bug. I could try and rerun with the -g parameter, but if it works it won't be conclusive, because the copied CVS tree probably doesn't start in the same state. -- hendrik From hendrik at topoi.pooq.com Tue Sep 7 17:48:37 2010 From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com) Date: Tue, 7 Sep 2010 11:48:37 -0400 Subject: [M3devel] versioning of .deb In-Reply-To: <20100907105213.yb1pvnz6sw8o4k4c@mail.elegosoft.com> References: <20100906203607.GA26003@topoi.pooq.com> <20100907105213.yb1pvnz6sw8o4k4c@mail.elegosoft.com> Message-ID: <20100907154837.GB29532@topoi.pooq.com> On Tue, Sep 07, 2010 at 10:52:13AM +0200, Olaf Wagner wrote: > Quoting hendrik at topoi.pooq.com: > >> I used cm3-LINUXLIBC6-REL.deb, and it installed cleanly. But as is, it >> won't pass muster as a submission to Debian. Not that I expected it to, >> and I'm happy with where it puts files, especially for a package that's >> still 'experimental' (but not in the Debian-technical sense of the >> 'experimental' distro, which is even freakier than sid). >> >> But one thing it should do, which it doesn't, is include a version >> number in its name. I'm not sure what the exact rules are in Debian for >> delimiting a version number, but I'm sure *you*'d find it useful to know >> which version of a package is involved when getting bug reports. > > Sure. Anybody cares to fix that? I've been uneasy with providing > these unfinished types of platform-specific archives all the time. I'll try to find out just what their version-numbering scheme is. Is seems to have changed in the past year. -- hendrik From wagner at elegosoft.com Tue Sep 7 17:44:02 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 07 Sep 2010 17:44:02 +0200 Subject: [M3devel] CM3 CVS mirror for test Message-ID: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com> Hi, I've now converted the four cm3-current-*-LINUXLIBC6 jobs to use the CVS repository at :pserver:anonymous at cm3cvs.acme-works.com/usr/cvs, which should be synchronized with the repo on birch every half hour. A first build run has shown that either Hudson updates the CVS/Root files correctly or does a complete new checkout, so we don't need to update the workspaces manually. When more Hudson clients are available again, we should change two or three more to use the mirror. 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 Sep 8 09:49:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 08 Sep 2010 09:49:11 +0200 Subject: [M3devel] CM3 CVS mirror for test In-Reply-To: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com> References: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com> Message-ID: <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> Quoting Olaf Wagner : > Hi, > > I've now converted the four cm3-current-*-LINUXLIBC6 jobs to use > the CVS repository at :pserver:anonymous at cm3cvs.acme-works.com/usr/cvs, > which should be synchronized with the repo on birch every half hour. > > A first build run has shown that either Hudson updates the CVS/Root > files correctly or does a complete new checkout, so we don't need to > update the workspaces manually. > > When more Hudson clients are available again, we should change two > or three more to use the mirror. I have also changed the NetBSD and OpenBSD jobs now. openbsd-jkrell seems to be too slow to be productive though (all jobs timed out). Anyway, I think we should perhaps redirect one more client and then watch how things work out for some time. Olaf PS: The ppc-linux setup seems still to be broken (mkdirs failed). -- 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 Sep 8 12:09:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 8 Sep 2010 10:09:44 +0000 Subject: [M3devel] CM3 CVS mirror for test In-Reply-To: <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> References: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com>, <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> Message-ID: > I have also changed the NetBSD and OpenBSD jobs now. openbsd-jkrell > seems to be too slow to be productive though (all jobs timed out). Something may be off here? It has worked well so long w/o much change? I notice: ? PID USERNAME PRI NICE? SIZE?? RES STATE???? WAIT????? TIME??? CPU COMMAND ... ?3970 jay??????? 2??? 0 4064K 4056K idle????? poll????? 0:00? 0.00% stubgen ? 609 jay??????? 2??? 0 3792K 4008K idle????? poll????? 0:00? 0.00% stubgen 24031 jay??????? 2??? 0 3924K 3984K idle????? poll????? 0:00? 0.00% stubgen ?suspicious considering I hadn't touched the machine in days. ?- Jay From jay.krell at cornell.edu Wed Sep 8 12:13:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 8 Sep 2010 10:13:04 +0000 Subject: [M3devel] CM3 CVS mirror for test In-Reply-To: <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> References: <20100907174402.z2l87nj1o0owswwg@mail.elegosoft.com>, <20100908094911.sfq9a0zkow88s0k4@mail.elegosoft.com> Message-ID: PS: The ppc-linux setup seems still to be broken (mkdirs failed). I'll "recross" to make sure the stat/lstat latest is there. That is, I'll rebuild cm3 cross and copy it around. ?- Jay From wagner at elegosoft.com Thu Sep 9 15:49:10 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 09 Sep 2010 15:49:10 +0200 Subject: [M3devel] Out of office and connectivity Message-ID: <20100909154910.e7s1xqgbpcc8kw04@mail.elegosoft.com> I will be on holiday from September 10th till September 26th. There won't probably be many opportunities to read (and answer) my mail. In cases of emergency you may try to contact me via my mobile phone (voice/sms, no email access). Usually, someone at Elego should be able to provide backup. 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 Sat Sep 11 10:32:25 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 08:32:25 +0000 Subject: [M3devel] granular trace options in cm3cg? Message-ID: Does anyone (Tony?) ever use -ffvars_trace, -fsource_line_trace, etc.? I only ever use -y for trace all. Very useful. I'm considering a change, that'll make the tracing more systematic and more complete, and it'd be slightly easier if I only supported -y. You know -- something like, the serialization macros could do all the work. Each operation would probably be on just one line -- well, that I'm already going to try. ? - Jay From jay.krell at cornell.edu Sat Sep 11 11:35:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 09:35:32 +0000 Subject: [M3devel] another strike against the wierd use of bitfields Message-ID: configure -enable-checking reports ../src/text/TextConv.m3: In function 'TextConv__Explode': ../src/text/TextConv.m3:348: error: GIMPLE register modified with BIT_FIELD_REF BIT_FIELD_REF = 0B; ../src/text/TextConv.m3:348: error: GIMPLE register modified with BIT_FIELD_REF BIT_FIELD_REF = D.1977; ../src/text/TextConv.m3:348: internal compiler error: verify_stmts failed Please submit a full bug report, ?- Jay From jay.krell at cornell.edu Sun Sep 12 00:02:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 22:02:45 +0000 Subject: [M3devel] invalid trees, debugging Message-ID: So, when you configure -enable-checking, you get lots of errors. This should have been done all along and now we have dug a hole for ourselves to get out of. Some of them I've fixed, some of them I've hacked to warnings for now. They should all be fixed. The errors from -enable-checking have helped me, I believe, restore inlining. ?? I haven't finished testing these changes or commited them yet. ?? It looks like, in particular, we weren't forming RETURN_EXPR correctly. ?? It looks like they don't like merely the NOP_EXPR we wrap the store with. I was also running afoul of the gcc garbage collector. That might have been the bigger problem, recent, my fault. Anyway, some of the errors are related to the debugging information. I repeat, again, my belief, that the "normal" way of outputing debugging information, is to do nothing, except create well formed, well typed trees. That lets any debug format work. The way as I understand cm3cg works is by tunneling custom information on the side. ?At least for types. Granted, for line numbers it does the right thing -- good data. Here is an example where the debugging information is wierd: ../src/M3x86.m3: In function 'M3x86__start_int_proc': ../src/M3x86.m3:3291:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in compute_record_mode, at stor-layout.c:1559 Please submit a full bug report, I'm using I386_DARWIN currently and m3gdb doesn't build here. At least for that reason, I'm not likely to test m3gdb. In some cases I might migt might downgrade the experience with it, to fix these errors. I kind of suspect there is a way to tunnel the information without breaking configure -enable-checking. But I'm not sure. Hopefully this is ok. If people insist I can turn off the checking again on my machine and just proceed with the fixes I have. ?- Jay From jay.krell at cornell.edu Sun Sep 12 01:26:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Sep 2010 23:26:40 +0000 Subject: [M3devel] invalid trees, debugging In-Reply-To: References: Message-ID: This was placing the gcc GTY annotation at the wrong spot, sorry, nevermind. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Sat, 11 Sep 2010 22:02:45 +0000 > Subject: [M3devel] invalid trees, debugging > > > So, when you configure -enable-checking, you get lots of errors. > This should have been done all along and now we have dug a hole for ourselves to get out of. > Some of them I've fixed, some of them I've hacked to warnings for now. > They should all be fixed. > The errors from -enable-checking have helped me, I believe, restore inlining. > I haven't finished testing these changes or commited them yet. > It looks like, in particular, we weren't forming RETURN_EXPR correctly. > It looks like they don't like merely the NOP_EXPR we wrap the store with. > > > I was also running afoul of the gcc garbage collector. > That might have been the bigger problem, recent, my fault. > > > Anyway, some of the errors are related to the debugging information. > I repeat, again, my belief, that the "normal" way of outputing debugging information, is > to do nothing, except create well formed, well typed trees. > That lets any debug format work. > The way as I understand cm3cg works is by tunneling custom information on the side. > At least for types. Granted, for line numbers it does the right thing -- good data. > > > Here is an example where the debugging information is wierd: > > ../src/M3x86.m3: In function 'M3x86__start_int_proc': > ../src/M3x86.m3:3291:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in compute_record_mode, at stor-layout.c:1559 > Please submit a full bug report, > > > I'm using I386_DARWIN currently and m3gdb doesn't build here. > At least for that reason, I'm not likely to test m3gdb. > In some cases I might migt might downgrade the experience with it, to fix these errors. > I kind of suspect there is a way to tunnel the information without breaking configure -enable-checking. > But I'm not sure. > > > Hopefully this is ok. > If people insist I can turn off the checking again on my machine and just proceed with the fixes I have. > > > - Jay > From jay.krell at cornell.edu Mon Sep 13 00:50:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Sep 2010 22:50:04 +0000 Subject: [M3devel] more combinations to test? Message-ID: I'd be super nice if we had some automation around: ? testing cm3cg -O, -O1, -O2, -O3 ?? m3cc/gcc/configure -enable-checking ?? m3cc/gcc/configure -enable-checking=all I'd settle for just -O3 and -enable-checking=all. I have a suspicion that if -enable-checking=all was done all along, we wouldn't have such problems with volatile and optimization. Currently cm3cg built with -enable-checking hits lots of problems, or at least many instances of a few problems. For now I change them warnings while I work through them. Having Hudson do this, and having then the record logged would be good. ? (It is a large log/record, as we hit many warnings per file, mostly ? converting integer types.) On the other hand, I'm not sure any of this is worth much. cm3cg -O3 is noticable slow to run. Possibly more time is spent in it than it saves. And -enable-checking maybe only fixes things that matter if optimizing -- based on what has historically worked. ?- Jay From hosking at cs.purdue.edu Mon Sep 13 00:52:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Sep 2010 18:52:14 -0400 Subject: [M3devel] more combinations to test? In-Reply-To: References: Message-ID: <76B77E55-97DD-4628-8446-46EB2ACA1A49@cs.purdue.edu> I think all of this is worthwhile. Probably enough to test -O and -O3. On 12 Sep 2010, at 18:50, Jay K wrote: > > I'd be super nice if we had some automation around: > testing cm3cg -O, -O1, -O2, -O3 > m3cc/gcc/configure -enable-checking > m3cc/gcc/configure -enable-checking=all > > I'd settle for just -O3 and -enable-checking=all. > > I have a suspicion that if -enable-checking=all was done all along, > we wouldn't have such problems with volatile and optimization. > > > Currently cm3cg built with -enable-checking hits lots of problems, > or at least many instances of a few problems. For now I change > them warnings while I work through them. > > > Having Hudson do this, and having then the record logged would be good. > (It is a large log/record, as we hit many warnings per file, mostly > converting integer types.) > > On the other hand, I'm not sure any of this is worth much. > cm3cg -O3 is noticable slow to run. > Possibly more time is spent in it than it saves. > And -enable-checking maybe only fixes things that matter if optimizing -- based > on what has historically worked. > > > - Jay > > > > From jay.krell at cornell.edu Mon Sep 13 01:53:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Sep 2010 23:53:18 +0000 Subject: [M3devel] field accesses in m3cg? In-Reply-To: <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu> References: , <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu> Message-ID: The more I look at this, the more I think we need to do it. If we want to stop hacking optimizations off, use -O3, use configure -enable-checking. The "failsafe" replacement for bitfields doesn't even work, though I'm trying to make it work. Inevitably, for now, we are trading one set of deoptimizations vs. another. For example, the heavy use of volatile was a big deoptimization that enabled ? "all" the rest to be done..at least from parse.c's point of view, though presumably ?? volatile stopped a lot of code below. Now I'm trying throwing around TREE_ADDRESSABLE, which I'm sure will ?also pessimize. We'll see. I'm not convinced that using ADDR_EXPR ?is equivalent to TREE_ADDRESSABLE. We'll see. It wasn't enough to throw in TREE_ADDRESSABLE on load/store with offset != 0. I'm trying it on all load/store now. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Fri, 3 Sep 2010 09:34:29 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] field accesses in m3cg? > > On 3 Sep 2010, at 07:28, Jay K wrote: > > > > > Thoughts on exposing higher level "field load/store" in m3cg? > > I'm wary of it currently. > > Would rather do other stuff for now. > > > > It'd let the bitfield refs be replaced by something "proper". > > > > But it opens up more danger in terms of frontend/backend layout disagreement. > > I worry about this. > > > > > - Jay > > > > > > > > > > > From jay.krell at cornell.edu Mon Sep 13 02:25:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 00:25:10 +0000 Subject: [M3devel] field accesses in m3cg? In-Reply-To: References: , , <12F96C86-5A6D-4E0F-AB64-FD8B1BD2D2C5@cs.purdue.edu>, Message-ID: No luck. In a jam between bitfields and configure -enable-checking: ?? ? error ("statement makes a memory store, but has no VDEFS"); ?? gimple_stmt (stderr, stmt, 0, TDF_VOPS); the "failsafe" form doesn't hit that error, but crashes somewhere. I'll probably have to debug said crash. I wonder..maybe we can prototype/synthesize field accesses? ie: without a frontend/m3cg change? In parse.c given an offset load/store, we could look at the base, and if it is a record just walk the fields linearly until the offset matches and then generate a component/field reference? Obviously it'd be better to do something without linear search. Similarly but easier for arrays. Heck, I have to imagine that arrays aren't a problem with the non-bitfield form. This still leaves some missing parts, mainly type information for other things, like packed and maybe opaque. I have to understand packed better. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Sun, 12 Sep 2010 23:53:18 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] field accesses in m3cg? > > > The more I look at this, the more I think we need to do it. > If we want to stop hacking optimizations off, use -O3, use configure -enable-checking. > The "failsafe" replacement for bitfields doesn't even work, though I'm trying to make it work. > > Inevitably, for now, we are trading one set of deoptimizations vs. another. > For example, the heavy use of volatile was a big deoptimization that enabled > "all" the rest to be done..at least from parse.c's point of view, though presumably > volatile stopped a lot of code below. > > Now I'm trying throwing around TREE_ADDRESSABLE, which I'm sure will > also pessimize. We'll see. I'm not convinced that using ADDR_EXPR > is equivalent to TREE_ADDRESSABLE. We'll see. > > It wasn't enough to throw in TREE_ADDRESSABLE on load/store with offset != 0. > I'm trying it on all load/store now. > > - Jay > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Fri, 3 Sep 2010 09:34:29 -0400 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] field accesses in m3cg? > > > > On 3 Sep 2010, at 07:28, Jay K wrote: > > > > > > > > Thoughts on exposing higher level "field load/store" in m3cg? > > > I'm wary of it currently. > > > Would rather do other stuff for now. > > > > > > It'd let the bitfield refs be replaced by something "proper". > > > > > > But it opens up more danger in terms of frontend/backend layout disagreement. > > > > I worry about this. > > > > > > > > - Jay > > > > > > > > > > > > > > > > > > From jay.krell at cornell.edu Mon Sep 13 02:30:54 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 00:30:54 +0000 Subject: [M3devel] more packed questions Message-ID: T = BITS 2 FOR [0..3]; makes sense to me T = BITS 10 FOR [0..3]; What does that do? It is legal, and allocates 10 bits, and uses a certain 2 of them? Which 2? Probably, it depends on endian and read the code, and it is meant to mean the same thing in C, if embedded in a struct, as a 10 bit bitfield that only happens to contain values 0..3? TYPE T1 = RECORD a:INTEGER END; TYPE T2 = BITS 64 FOR T1; ?legal? ?Sticks 0 or 32 bits after T1/a? ? ? ?My goal is to generate accurate type information in parse.c. ?Debugging in stock gdb should work. ?And then furthermore try converting offset loads/stores ?to component/array_refs. ?And then furthermore, let all of -O3 work. ? ? ? - Jay From jay.krell at cornell.edu Mon Sep 13 02:33:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 00:33:34 +0000 Subject: [M3devel] representation of enums? Message-ID: How are enums represented? As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? An enum with 128 or 255 values -- 8 bits or 16? I assume 8. Packable into fewer bits, if they fit presumably. ?- Jay From hosking at cs.purdue.edu Mon Sep 13 02:44:49 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Sep 2010 20:44:49 -0400 Subject: [M3devel] representation of enums? In-Reply-To: References: Message-ID: <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> On 12 Sep 2010, at 20:33, Jay K wrote: > > How are enums represented? > > As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? Stored, yes. All operations on enum are as INTEGER. > An enum with 128 or 255 values -- 8 bits or 16? > I assume 8. 8 > Packable into fewer bits, if they fit presumably. BITS FOR, yes. > > - Jay > > > > > From jay.krell at cornell.edu Mon Sep 13 03:27:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 01:27:34 +0000 Subject: [M3devel] representation of enums? In-Reply-To: <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> References: , <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> Message-ID: Values are sign extended or zero extended? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 12 Sep 2010 20:44:49 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] representation of enums? > > On 12 Sep 2010, at 20:33, Jay K wrote: > > > > > How are enums represented? > > > > As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? > > Stored, yes. All operations on enum are as INTEGER. > > > An enum with 128 or 255 values -- 8 bits or 16? > > I assume 8. > > 8 > > > Packable into fewer bits, if they fit presumably. > > BITS FOR, yes. > > > > > - Jay > > > > > > > > > > > From rcolebur at SCIRES.COM Mon Sep 13 04:45:57 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Sun, 12 Sep 2010 22:45:57 -0400 Subject: [M3devel] [M3commit] CVS Update: cm3 In-Reply-To: <20100913022909.0BAB52474033@birch.elegosoft.com> References: <20100913022909.0BAB52474033@birch.elegosoft.com> Message-ID: Sorry, the dependency should have read "...being present in C:\cm3\bin" --Randy -----Original Message----- From: Randy Coleburn [mailto:rcoleburn at elego.de] Sent: Monday, September 13, 2010 12:29 AM To: m3commit at elegosoft.com Subject: [M3commit] CVS Update: cm3 CVSROOT: /usr/cvs Changes by: rcoleburn at birch. 10/09/13 04:29:08 Added files: cm3/scripts/install/windows/: CommandPromptHere.reg cm3CommandPromptHere.reg Log message: Use these 2 registry files to add context menu entries to Windows Explorer. Double-click to install. cm3CommandPromptHere.reg: Right click on a folder in explorer, choose "cm3 Command Prompt Here" and it brings up a new command prompt window ready for using cm3 in that directory. Depends on cm3CommandShell.cmd being present in C:\CM3. CommandPromptHere.reg: Right click on a folder in explorer, choose "Command Prompt Here" and it brings up a new command prompt window in that directory. From jay.krell at cornell.edu Mon Sep 13 09:18:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 07:18:12 +0000 Subject: [M3devel] tracing implementation minutae -- parity with automatic tracing of mangled names? Message-ID: wherever we have: static void m3cg_import_global (void) { ? NAME?????? (name, name_length); ... ? TYPEID???? (id); ... ? DECL_NAME (v) = fix_name (name, name_length, id); ? if (option_trace_all) ??? fprintf (stderr, " ...%s...", .. POINTER (DECL_NAME (v))); The "automatic tracing" can't achieve parity. I see three choices: ? - don't achieve parity -- don't print the m3 mangled name ? - leave in some manual tracing ? - move the TYPEID parameters to right after the NAME parameters, ?? and then introduce a new macro M3NAME that reads them in succession ?? and traces them with parity The last works, but touches, well, not necessarily the m3cg interface and all the implementations, etc., but at least the binary writer/reader. Seems a bit expensive..but maybe not. ?- Jay From jay.krell at cornell.edu Mon Sep 13 12:31:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 10:31:32 +0000 Subject: [M3devel] convert vs. cast in parse.c? Message-ID: Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"? Thanks, ?- Jay From jay.krell at cornell.edu Mon Sep 13 12:40:45 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 10:40:45 +0000 Subject: [M3devel] unnecessary temporaries Message-ID: parse.c seems to go crazy sometimes on the temporaries. Here, in min, max, and check_eq: Index: parse.c =================================================================== RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v retrieving revision 1.314 diff -u -r1.314 parse.c --- parse.c??? 13 Sep 2010 09:59:25 -0000??? 1.314 +++ parse.c??? 13 Sep 2010 10:24:16 -0000 @@ -4791,11 +4791,8 @@ ?{ ?? MTYPE (t); ? -? tree t1 = declare_temp (t); -? tree t2 = declare_temp (t); - -? add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); -? add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); +? tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); +? tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); ? ?? EXPR_REF (-2) = m3_build3 (COND_EXPR, t, ????????????????????????????? m3_build2 (LE_EXPR, boolean_type_node, t2, t1), @@ -4808,11 +4805,8 @@ ?{ ?? MTYPE (t); ? -? tree t1 = declare_temp (t); -? tree t2 = declare_temp (t); - -? add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); -? add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); +? tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); +? tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); ? ?? EXPR_REF (-2) = m3_build3 (COND_EXPR, t, ????????????????????????????? m3_build2 (LE_EXPR, boolean_type_node, t1, t2), @@ -5679,11 +5673,10 @@ ?? MTYPE2? (t, T); ?? INTEGER (code); ? -? tree temp1 = declare_temp (t); -? tree temp2 = declare_temp (t); - -? m3_store (temp1, 0, t, T, t, T); -? m3_store (temp2, 0, t, T, t, T); +? tree temp1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); +? tree temp2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); +? EXPR_POP (); +? EXPR_POP (); ?? add_stmt (build3 (COND_EXPR, t_void, ???????????????????? m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2), ???????????????????? generate_fault (code), and in the unoptimized m3core/src/text/TextCat PROCEDURE MyGetChars (t: T;? VAR a: ARRAY OF CHAR;? start: CARDINAL) = ? VAR u: TEXT;? a_offset, t_offset, u_offset: CARDINAL := 0; ? BEGIN ??? u := t.a; ??? IF (t_offset + t.a_len > start) THEN ????? u_offset := MAX (start - t_offset, 0); ????? u.get_chars (SUBARRAY (a, a_offset, NUMBER (a) - a_offset), u_offset); 7 instructions go down to 3, 4 memory operations saved, and 16 bytes of stack are saved (presumably 12, rounded) --- I386_DARWIN.3/TextCat.ms??? 2010-09-13 03:18:45.000000000 -0700 +++ I386_DARWIN.4/TextCat.ms??? 2010-09-13 03:19:40.000000000 -0700 @@ -835,7 +835,7 @@ ?LCFI41: ???? movl??? %esp, %ebp ?LCFI42: -??? subl??? $88, %esp +??? subl??? $72, %esp ?LCFI43: ???? movl??? -16(%ebp), %eax ???? andl??? $0, %eax @@ -879,18 +879,14 @@ ???? movl??? 16(%ebp), %eax ???? cmpl??? %eax, %edx ???? jle??? L54 -??? movl??? $0, -32(%ebp) ???? movl??? 16(%ebp), %edx ???? movl??? -20(%ebp), %eax ???? movl??? %edx, %ecx ???? subl??? %eax, %ecx ???? movl??? %ecx, %eax -??? movl??? %eax, -36(%ebp) -??? movl??? -36(%ebp), %edx -??? movl??? -32(%ebp), %eax -??? cmpl??? %edx, %eax -??? jge??? L49 -??? movl??? %edx, %eax +??? testl??? %eax, %eax +??? jns??? L49 +??? movl??? $0, %eax Reasonable, eh? Or should I be nervous? check_eq in particular -- if you get it wrong, such that it is underaggressive, correct programs will work the same. I guess I should make sure m3tests is full of failure cases for that. Ok, in m3front, it looks like all the uses of check_eq are related to runtime assignments of open arrays, to make sure their sizes match, or such, either for assignment or passing a parameter. ?- Jay From jay.krell at cornell.edu Mon Sep 13 12:54:03 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 10:54:03 +0000 Subject: [M3devel] unnecessary temporaries In-Reply-To: References: Message-ID: Hm, test r003 should show a difference, at least unoptimized, but it doesn't seem to. I think I'll just #if out my change here unless/until I/anyone can confirm the expected change. Between min and max, just checking one should suffice. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu; m3devel at elegosoft.com > Date: Mon, 13 Sep 2010 10:40:45 +0000 > Subject: [M3devel] unnecessary temporaries > > > parse.c seems to go crazy sometimes on the temporaries. > > Here, in min, max, and check_eq: > > Index: parse.c > =================================================================== > RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v > retrieving revision 1.314 > diff -u -r1.314 parse.c > --- parse.c 13 Sep 2010 09:59:25 -0000 1.314 > +++ parse.c 13 Sep 2010 10:24:16 -0000 > @@ -4791,11 +4791,8 @@ > { > MTYPE (t); > > - tree t1 = declare_temp (t); > - tree t2 = declare_temp (t); > - > - add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); > - add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); > + tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); > + tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); > > EXPR_REF (-2) = m3_build3 (COND_EXPR, t, > m3_build2 (LE_EXPR, boolean_type_node, t2, t1), > @@ -4808,11 +4805,8 @@ > { > MTYPE (t); > > - tree t1 = declare_temp (t); > - tree t2 = declare_temp (t); > - > - add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1))); > - add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2))); > + tree t1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); > + tree t2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); > > EXPR_REF (-2) = m3_build3 (COND_EXPR, t, > m3_build2 (LE_EXPR, boolean_type_node, t1, t2), > @@ -5679,11 +5673,10 @@ > MTYPE2 (t, T); > INTEGER (code); > > - tree temp1 = declare_temp (t); > - tree temp2 = declare_temp (t); > - > - m3_store (temp1, 0, t, T, t, T); > - m3_store (temp2, 0, t, T, t, T); > + tree temp1 = stabilize_reference (m3_cast (t, EXPR_REF (-1))); > + tree temp2 = stabilize_reference (m3_cast (t, EXPR_REF (-2))); > + EXPR_POP (); > + EXPR_POP (); > add_stmt (build3 (COND_EXPR, t_void, > m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2), > generate_fault (code), > > > and in the unoptimized > > m3core/src/text/TextCat > > PROCEDURE MyGetChars (t: T; VAR a: ARRAY OF CHAR; start: CARDINAL) = > VAR u: TEXT; a_offset, t_offset, u_offset: CARDINAL := 0; > BEGIN > u := t.a; > IF (t_offset + t.a_len > start) THEN > u_offset := MAX (start - t_offset, 0); > u.get_chars (SUBARRAY (a, a_offset, NUMBER (a) - a_offset), u_offset); > > > > 7 instructions go down to 3, 4 memory operations saved, and 16 bytes of stack are saved (presumably 12, rounded) > > > > --- I386_DARWIN.3/TextCat.ms 2010-09-13 03:18:45.000000000 -0700 > +++ I386_DARWIN.4/TextCat.ms 2010-09-13 03:19:40.000000000 -0700 > @@ -835,7 +835,7 @@ > LCFI41: > movl %esp, %ebp > LCFI42: > - subl $88, %esp > + subl $72, %esp > LCFI43: > movl -16(%ebp), %eax > andl $0, %eax > @@ -879,18 +879,14 @@ > movl 16(%ebp), %eax > cmpl %eax, %edx > jle L54 > - movl $0, -32(%ebp) > movl 16(%ebp), %edx > movl -20(%ebp), %eax > movl %edx, %ecx > subl %eax, %ecx > movl %ecx, %eax > - movl %eax, -36(%ebp) > - movl -36(%ebp), %edx > - movl -32(%ebp), %eax > - cmpl %edx, %eax > - jge L49 > - movl %edx, %eax > + testl %eax, %eax > + jns L49 > + movl $0, %eax > > > Reasonable, eh? > Or should I be nervous? > > > check_eq in particular -- if you get it wrong, such that it is underaggressive, correct programs > will work the same. > > > I guess I should make sure m3tests is full of failure cases for that. > Ok, in m3front, it looks like all the uses of check_eq are related to runtime assignments > of open arrays, to make sure their sizes match, or such, either for assignment or passing a parameter. > > > - Jay > > From hosking at cs.purdue.edu Mon Sep 13 15:48:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 13 Sep 2010 09:48:46 -0400 Subject: [M3devel] representation of enums? In-Reply-To: References: , <8CE162E2-AC97-4923-9CF4-0FB3F5549617@cs.purdue.edu> Message-ID: Zeros. On 12 Sep 2010, at 21:27, Jay K wrote: > > Values are sign extended or zero extended? > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 12 Sep 2010 20:44:49 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] representation of enums? >> >> On 12 Sep 2010, at 20:33, Jay K wrote: >> >>> >>> How are enums represented? >>> >>> As the smallest of 8, 16, 32 bit unsigned integer that can hold all the values? >> >> Stored, yes. All operations on enum are as INTEGER. >> >>> An enum with 128 or 255 values -- 8 bits or 16? >>> I assume 8. >> >> 8 >> >>> Packable into fewer bits, if they fit presumably. >> >> BITS FOR, yes. >> >>> >>> - Jay >>> >>> >>> >>> >>> >> > From hosking at cs.purdue.edu Mon Sep 13 22:22:11 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 13 Sep 2010 16:22:11 -0400 Subject: [M3devel] convert vs. cast in parse.c? In-Reply-To: References: Message-ID: m3_cast uses a NOP_EXPR, which assumes no code needs generating to effect the type change (i.e., bits are compatible, no extension necessary, etc.). convert is provided to perform all reasonable conversions. It generates code as necessary (see comments below from c-convert.c). Looking at the comments for VIEW_CONVERT_EXPR, I wonder if we should be using that for LOOPHOLE on floats to avoid the need for the temporary? I'm not sure we should ever be using CONVERT_EXPR explicitly ? probably better to use convert and get the CONVERT_EXPR from that as necessary? /* Change of width--truncation and extension of integers or reals-- is represented with NOP_EXPR. Proper functioning of many things assumes that no other conversions can be NOP_EXPRs. Conversion between integer and pointer is represented with CONVERT_EXPR. Converting integer to real uses FLOAT_EXPR and real to integer uses FIX_TRUNC_EXPR. Here is a list of all the functions that assume that widening and narrowing is always done with a NOP_EXPR: In convert.c, convert_to_integer. In c-typeck.c, build_binary_op (boolean ops), and c_common_truthvalue_conversion. In expr.c: expand_expr, for operands of a MULT_EXPR. In fold-const.c: fold. In tree.c: get_narrower and get_unwidened. */ /* Subroutines of `convert'. */ /* Create an expression whose value is that of EXPR, converted to type TYPE. The TREE_TYPE of the value is always TYPE. This function implements all reasonable conversions; callers should filter out those that are not permitted by the language being compiled. */ tree convert (tree type, tree expr) Also: NOP_EXPR These nodes are used to represent conversions that do not require any code-generation. For example, conversion of a char* to an int* does not require any code be generated; such a conversion is represented by a NOP_EXPR. The single operand is the expression to be converted. The conversion from a pointer to a reference is also represented with a NOP_EXPR. CONVERT_EXPR These nodes are similar to NOP_EXPRs, but are used in those situations where code may need to be generated. For example, if an int* is converted to an intcode may need to be generated on some platforms. These nodes are never used for C++-specific conversions, like conversions between pointers to different classes in an inheritance hierarchy. Any adjustments that need to be made in such cases are always indicated explicitly. Similarly, a user-defined conversion is never represented by a CONVERT_EXPR; instead, the function calls are made explicit. FIXED_CONVERT_EXPR These nodes are used to represent conversions that involve fixed-point values. For example, from a fixed-point value to another fixed-point value, from an integer to a fixed-point value, from a fixed-point value to an integer, from a floating-point value to a fixed-point value, or from a fixed-point value to a floating-point value. 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 13 Sep 2010, at 06:31, Jay K wrote: > > Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"? > > Thanks, > - Jay > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Mon Sep 13 22:56:15 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 13 Sep 2010 15:56:15 -0500 Subject: [M3devel] more packed questions In-Reply-To: References: Message-ID: <4C8E8FEF.1060801@lcwb.coop> Jay K wrote: > T = BITS 2 FOR [0..3]; makes sense to me > > > T = BITS 10 FOR [0..3]; > What does that do? > It is legal, and allocates 10 bits, and uses a certain 2 of them? Yes, but only for an array element or field of a record or object. > Which 2? The least significant 2. Actually, the value would be treated as occupying all 10, but the bounds rules of the language would ensure that only values in 0..3 are ever stored therein. Same as just [0..3], the compiler can allocate whatever number of bits it wants (but at least 2) but ensure stored values are in the range. > Probably, it depends on endian and read the code, and it is meant > to mean the same thing in C, if embedded in a struct, as > a 10 bit bitfield that only happens to contain values 0..3? > > > TYPE T1 = RECORD a:INTEGER END; > TYPE T2 = BITS 64 FOR T1; > legal? > Sticks 0 or 32 bits after T1/a? First, it doesn't do anything unless T2 is used as an array element or a field. If so, then that element/field occupies 64 bits itself. Where within those bits the compiler puts the T1 record is not specified by the language, and this case is not as obvious as INTEGER or [0..3]. I would expect a compiler would, on a 32-bit machine, put the T1 within the 64 bits of the T2 the same way it would allocate fields in a record, i.e., the lowest-numbered 4 bytes of the 8. This would effectively do what you speculated. > > > My goal is to generate accurate type information in parse.c. > Debugging in stock gdb should work. > And then furthermore try converting offset loads/stores > to component/array_refs. > And then furthermore, let all of -O3 work. > > > - Jay From jay.krell at cornell.edu Tue Sep 14 01:51:44 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Sep 2010 23:51:44 +0000 Subject: [M3devel] a likely way to force passing records by address Message-ID: tree.h /* For a PARM_DECL, records the data type used to pass the argument, ?? which may be different from the type seen in the program.? */ #define DECL_ARG_TYPE(NODE) (PARM_DECL_CHECK (NODE)->decl_common.initial) We could probably use this to easily/quickly solve the SPARC64 record problem. But forcing records to always be passed by address. And then dispense with any long tedious attempt to make the trees better-formed/typed. But the better formed/typed trees have the advantage of better debugging with gdb and probably able to allow more optimizations. Really the SPARC64 problems (assertion failures in backend compiling caltech-parser) triggered this, but are no longer the point). ? ?- Jay From jay.krell at cornell.edu Tue Sep 14 04:28:14 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 02:28:14 +0000 Subject: [M3devel] convert vs. cast in parse.c? In-Reply-To: References: , Message-ID: I don't know. I'm not too concerned with float/loophole at the moment. Granted, probably a good way is take address, cast to new pointer type, deref -- you know, the "safe" load/store pattern. "view convert" sounds like it might be equivalent but more efficient (ie: not introduce pessimization associated with address-taken). I agree though, now that you mention it, sounds useful. My more immediate concern is 1) the min/max change I made, though that seems clearly to preserve preexisting semantics 2) changes to let configure -enable-checking to work. Many of the errors around operations that mix integer types, in comparison, assignment, plus, multiply, etc. > (i.e., bits are compatible, no extension necessary, etc.). What would qualify there? I can think of only a few: signed to/from unsigned, of same size pointer to/from integer, of same size (loophole) possibly loophole, of same size (e.g. int32 <=> float, int64 <=> double, heck float or double <=> pointer) enum <=> integer, of same size and NOT anything involving a change in size possibly, like boolean <=> int8/uint8, if boolean is 8 bits - Jay Subject: Re: convert vs. cast in parse.c? From: hosking at cs.purdue.edu Date: Mon, 13 Sep 2010 16:22:11 -0400 CC: m3devel at elegosoft.com To: jay.krell at cornell.edu m3_cast uses a NOP_EXPR, which assumes no code needs generating to effect the type change (i.e., bits are compatible, no extension necessary, etc.). convert is provided to perform all reasonable conversions. It generates code as necessary (see comments below from c-convert.c). Looking at the comments for VIEW_CONVERT_EXPR, I wonder if we should be using that for LOOPHOLE on floats to avoid the need for the temporary? I'm not sure we should ever be using CONVERT_EXPR explicitly ? probably better to use convert and get the CONVERT_EXPR from that as necessary? /* Change of width--truncation and extension of integers or reals-- is represented with NOP_EXPR. Proper functioning of many things assumes that no other conversions can be NOP_EXPRs. Conversion between integer and pointer is represented with CONVERT_EXPR. Converting integer to real uses FLOAT_EXPR and real to integer uses FIX_TRUNC_EXPR. Here is a list of all the functions that assume that widening and narrowing is always done with a NOP_EXPR: In convert.c, convert_to_integer. In c-typeck.c, build_binary_op (boolean ops), and c_common_truthvalue_conversion. In expr.c: expand_expr, for operands of a MULT_EXPR. In fold-const.c: fold. In tree.c: get_narrower and get_unwidened. */ /* Subroutines of `convert'. */ /* Create an expression whose value is that of EXPR, converted to type TYPE. The TREE_TYPE of the value is always TYPE. This function implements all reasonable conversions; callers should filter out those that are not permitted by the language being compiled. */ tree convert (tree type, tree expr) Also: NOP_EXPR These nodes are used to represent conversions that do not require any code-generation. For example, conversion of a char* to an int* does not require any code be generated; such a conversion is represented by a NOP_EXPR. The single operand is the expression to be converted. The conversion from a pointer to a reference is also represented with a NOP_EXPR. CONVERT_EXPR These nodes are similar to NOP_EXPRs, but are used in those situations where code may need to be generated. For example, if an int* is converted to an intcode may need to be generated on some platforms. These nodes are never used for C++-specific conversions, like conversions between pointers to different classes in an inheritance hierarchy. Any adjustments that need to be made in such cases are always indicated explicitly. Similarly, a user-defined conversion is never represented by a CONVERT_EXPR; instead, the function calls are made explicit. FIXED_CONVERT_EXPR These nodes are used to represent conversions that involve fixed-point values. For example, from a fixed-point value to another fixed-point value, from an integer to a fixed-point value, from a fixed-point value to an integer, from a floating-point value to a fixed-point value, or from a fixed-point value to a floating-point value. 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 13 Sep 2010, at 06:31, Jay K wrote: Tony, et. al. can you help me understand when in parse.c to use "convert" vs. "cast"? Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Sep 14 06:14:38 2010 From: darko at darko.org (Darko) Date: Mon, 13 Sep 2010 21:14:38 -0700 Subject: [M3devel] Per thread data Message-ID: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? Cheers, Darko. From mika at async.async.caltech.edu Tue Sep 14 06:55:04 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Mon, 13 Sep 2010 21:55:04 -0700 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <20100914045504.A62281A209C@async.async.caltech.edu> Darko writes: >I need to have certain data structures allocated on a per thread basis. = >Right now I'm thinking of using the thread id from ThreadF.MyId() to = >index a list. Is there a better, more portable way of allocating on a = >per-thread basis? > >Cheers, >Darko. In my experience what you suggest works just fine (remember to lock the doors, though!) But you can get disappointing performance on some thread implementations (ones that involve switching into supervisor mode more than necessary when accessing pthread structures). Generally speaking I avoid needing per-thread structures as much as possible and instead put what you need in the Closure and then pass pointers around. Of course you can mix the methods for a compromise between speed and cluttered code... I think what you want is also not a list but a Table. Mika From dragisha at m3w.org Tue Sep 14 06:57:33 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Tue, 14 Sep 2010 06:57:33 +0200 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <1284440253.2748.36.camel@boromir.m3w.org> Only "better" would be using same storage as for MyId... Access time would be same as for that value, and if you use MyId access time is access to TLS (thread local storage) plus your structure manipulation. IMO, some IntRefTbl is better idea than list. If you decide to use same storage, then it's pthread.getspecific and pthread.setspecific you are looking for. On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: > I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > Cheers, > Darko. > -- Dragi?a Duri? From darko at darko.org Tue Sep 14 07:08:14 2010 From: darko at darko.org (Darko) Date: Mon, 13 Sep 2010 22:08:14 -0700 Subject: [M3devel] Per thread data In-Reply-To: <20100914045504.A62281A209C@async.async.caltech.edu> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <20100914045504.A62281A209C@async.async.caltech.edu> Message-ID: <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > Darko writes: >> I need to have certain data structures allocated on a per thread basis. = >> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >> index a list. Is there a better, more portable way of allocating on a = >> per-thread basis? >> >> Cheers, >> Darko. > > In my experience what you suggest works just fine (remember to lock the > doors, though!) But you can get disappointing performance on some thread > implementations (ones that involve switching into supervisor mode more > than necessary when accessing pthread structures). > > Generally speaking I avoid needing per-thread structures as much as possible > and instead put what you need in the Closure and then pass pointers around. > Of course you can mix the methods for a compromise between speed and > cluttered code... > > I think what you want is also not a list but a Table. > > Mika From darko at darko.org Tue Sep 14 07:08:19 2010 From: darko at darko.org (Darko) Date: Mon, 13 Sep 2010 22:08:19 -0700 Subject: [M3devel] Per thread data In-Reply-To: <1284440253.2748.36.camel@boromir.m3w.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <1284440253.2748.36.camel@boromir.m3w.org> Message-ID: <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> I'm guessing that the pthread calls wouldn't be portable to Win32? Which is ok if there are similar calls for Win threads. On 13/09/2010, at 9:57 PM, Dragi?a Duri? wrote: > Only "better" would be using same storage as for MyId... Access time > would be same as for that value, and if you use MyId access time is > access to TLS (thread local storage) plus your structure manipulation. > IMO, some IntRefTbl is better idea than list. > > If you decide to use same storage, then it's pthread.getspecific and > pthread.setspecific you are looking for. > > On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? >> >> Cheers, >> Darko. >> > > -- > Dragi?a Duri? > From jay.krell at cornell.edu Tue Sep 14 07:36:38 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 05:36:38 +0000 Subject: [M3devel] Per thread data In-Reply-To: <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <1284440253.2748.36.camel@boromir.m3w.org>, <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> Message-ID: Best results imho would be use lightly #ifdefed C and ignore OpenBSD. Perhaps we should provide something for Modula-3, that is then portable to user threads. The Win32 equivalent is "thread local storage", or, if you are picky and care "fiber local storage". TlsAlloc TlsGetValue TlsSetValue TlsFree Search the web, you'll find the documentation right away. There are also Fls functions. They aren't in XP and fibers are exceedingly rarely used. Fiber local storage is thread local if fibers aren't in use. That is, using FLS is like a "superset" of TLS. You can't go wrong by using it, except you need to handle the LoadLibrary/GetProcAddress to see if the functions are available or not. For TLS (and FLS?), there is an array of 64 and an array of 1024, pointers. Each thread local is a pointer. You can heap allocate therein. Note that the heap allocation can fail. And Tls can be exhausted. The maximum number of thread locals is 1088. On older operating systems it is 64. TlsGet/SetValue just index into the appropriate array. If you are in an .exe, or a .dll that the .exe statically depends upon, or depend on Vista or newer, than __declspec(thread) is more convenient, faster, and I think has no limits. You just put that marker on your data and voila, the compiler, linker, and loader collaborate. (as well as the context switcher, which must be involved in both mechanisms). That is __declspec(thread) does not work in .dlls that are loaded via LoadLibrary, prior to Vista. This is a major downer, though decreasing in time now, as __declspec(thread) is so preferable. Non-Win32 systems often have "__thread" that is equivalent ot __declspec(thread), probably without an equivalent dlopen limitation, but of varying efficiency -- really, read the spec, it is confusing, there are so many "models" for the linker/loader to worry about. Current gcc emulates __thread in terms of "whatever" (tls or pthread) if there isn't anything better. I did some experiments though and __thread didn't seem all that much faster, at least once you go to the worst of the "models". "models" include like in the executable or a shared object, position-independent or not. m3core uses pthread_getspecific/setspecific -- like for every occurence of "TRY" -- but those experiments were around having it use __thread if it is available. Ultimately we just want to dramatically reduce the use of that specific data anyway -- by having a stack walker or using whatever the underlying native exception handling mechanism is.. There is surprisingly more to this subject. Imagine you have a few thread locals and you pack them together into a heap allocated struct/record. It is tempting to think DllMain(THREAD_ATTACH) is the place to do the allocation. It is, but threads can be created before your .dll is loaded, and you won't get notifications for them. So you are still left having to do the allocation on-demand. You are still left with "failure points" on every access. Thread locals are also "fragile", nearly as much so as globals. Like, written when you don't realize and their value "lost". What I mean, is, imagine this code: f = fopen(...) if (!f) return errno; errno is a thread local on all modern systems. Then imagine similar: f = fopen(...) if (!f) return errno; g = fopen(...) if (!g) { fclose(f); /* preferably in a destructor or finally! */ return errno; } See the bug? fclose might have clobbered errno. As well, accessing thread locals is always going to much slower than accessing a function local or parameter. You really should try to avoid them. - Jay > From: darko at darko.org > Date: Mon, 13 Sep 2010 22:08:19 -0700 > To: dragisha at m3w.org > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > I'm guessing that the pthread calls wouldn't be portable to Win32? Which is ok if there are similar calls for Win threads. > > > On 13/09/2010, at 9:57 PM, Dragi?a Duri? wrote: > > > Only "better" would be using same storage as for MyId... Access time > > would be same as for that value, and if you use MyId access time is > > access to TLS (thread local storage) plus your structure manipulation. > > IMO, some IntRefTbl is better idea than list. > > > > If you decide to use same storage, then it's pthread.getspecific and > > pthread.setspecific you are looking for. > > > > On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: > >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > >> > >> Cheers, > >> Darko. > >> > > > > -- > > Dragi?a Duri? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Sep 14 14:07:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 08:07:39 -0400 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: Why not just allocate in the heap and hold a reference in the thread closure? On 14 Sep 2010, at 00:14, Darko wrote: > I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > Cheers, > Darko. > From hosking at cs.purdue.edu Tue Sep 14 14:08:39 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 08:08:39 -0400 Subject: [M3devel] Per thread data In-Reply-To: <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <20100914045504.A62281A209C@async.async.caltech.edu> <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> Message-ID: If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? On 14 Sep 2010, at 01:08, Darko wrote: > I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > > On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > >> Darko writes: >>> I need to have certain data structures allocated on a per thread basis. = >>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >>> index a list. Is there a better, more portable way of allocating on a = >>> per-thread basis? >>> >>> Cheers, >>> Darko. >> >> In my experience what you suggest works just fine (remember to lock the >> doors, though!) But you can get disappointing performance on some thread >> implementations (ones that involve switching into supervisor mode more >> than necessary when accessing pthread structures). >> >> Generally speaking I avoid needing per-thread structures as much as possible >> and instead put what you need in the Closure and then pass pointers around. >> Of course you can mix the methods for a compromise between speed and >> cluttered code... >> >> I think what you want is also not a list but a Table. >> >> Mika > From hosking at cs.purdue.edu Tue Sep 14 14:09:46 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 08:09:46 -0400 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <1284440253.2748.36.camel@boromir.m3w.org>, <4117A2C1-3D13-44F7-B793-FA669942AE4A@darko.org> Message-ID: I really don't understand any of this motivation for a language that has heap allocation. Where is the overhead to just holding a reference to heap-allocated state from each thread? On 14 Sep 2010, at 01:36, Jay K wrote: > Best results imho would be use lightly #ifdefed C and ignore OpenBSD. > Perhaps we should provide something for Modula-3, that is then portable to user threads. > > > The Win32 equivalent is "thread local storage", or, if you are picky and care "fiber local storage". > TlsAlloc > TlsGetValue > TlsSetValue > TlsFree > > > Search the web, you'll find the documentation right away. > > > There are also Fls functions. They aren't in XP and fibers are exceedingly rarely used. > Fiber local storage is thread local if fibers aren't in use. > That is, using FLS is like a "superset" of TLS. You can't go wrong by using it, except you need to handle the LoadLibrary/GetProcAddress to see if the functions are available or not. > > > For TLS (and FLS?), there is an array of 64 and an array of 1024, pointers. Each thread local is a pointer. You can heap allocate therein. Note that the heap allocation can fail. And Tls can be exhausted. > The maximum number of thread locals is 1088. > On older operating systems it is 64. > TlsGet/SetValue just index into the appropriate array. > > > If you are in an .exe, or a .dll that the .exe statically depends upon, or depend on Vista or newer, than __declspec(thread) is more convenient, faster, and I think has no limits. You just put that marker on your data and voila, the compiler, linker, and loader collaborate. (as well as the context switcher, which must be involved in both mechanisms). > > > That is __declspec(thread) does not work in .dlls that are loaded via LoadLibrary, prior to Vista. > This is a major downer, though decreasing in time now, as __declspec(thread) is so preferable. > > > Non-Win32 systems often have "__thread" that is equivalent ot __declspec(thread), probably without an equivalent dlopen limitation, but of varying efficiency -- really, read the spec, it is confusing, there are so many "models" for the linker/loader to worry about. > > > Current gcc emulates __thread in terms of "whatever" (tls or pthread) if there isn't anything better. > > > I did some experiments though and __thread didn't seem all that much faster, at least once you go to the worst of the "models". > "models" include like in the executable or a shared object, position-independent or not. > > > m3core uses pthread_getspecific/setspecific -- like for every occurence of "TRY" -- but those experiments were around having it use __thread if it is available. > Ultimately we just want to dramatically reduce the use of that specific data anyway -- by having a stack walker or using whatever the underlying native exception handling mechanism is.. > > > There is surprisingly more to this subject. Imagine you have a few thread locals and you pack them together into a heap allocated struct/record. > It is tempting to think DllMain(THREAD_ATTACH) is the place to do the allocation. It is, but threads can be created before your .dll is loaded, and you won't get notifications for them. So you are still left having to do the allocation on-demand. You are still left with "failure points" on every access. > > > Thread locals are also "fragile", nearly as much so as globals. > Like, written when you don't realize and their value "lost". > > > What I mean, is, imagine this code: > > > f = fopen(...) > if (!f) > return errno; > > errno is a thread local on all modern systems. > Then imagine similar: > > > f = fopen(...) > if (!f) > return errno; > g = fopen(...) > if (!g) > { > fclose(f); /* preferably in a destructor or finally! */ > return errno; > } > > > See the bug? fclose might have clobbered errno. > > > As well, accessing thread locals is always going to much slower than accessing a function local or parameter. > You really should try to avoid them. > > > - Jay > > > > > From: darko at darko.org > > Date: Mon, 13 Sep 2010 22:08:19 -0700 > > To: dragisha at m3w.org > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > I'm guessing that the pthread calls wouldn't be portable to Win32? Which is ok if there are similar calls for Win threads. > > > > > > On 13/09/2010, at 9:57 PM, Dragi?a Duri? wrote: > > > > > Only "better" would be using same storage as for MyId... Access time > > > would be same as for that value, and if you use MyId access time is > > > access to TLS (thread local storage) plus your structure manipulation. > > > IMO, some IntRefTbl is better idea than list. > > > > > > If you decide to use same storage, then it's pthread.getspecific and > > > pthread.setspecific you are looking for. > > > > > > On Mon, 2010-09-13 at 21:14 -0700, Darko wrote: > > >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > >> > > >> Cheers, > > >> Darko. > > >> > > > > > > -- > > > Dragi?a Duri? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Sep 14 14:31:48 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 05:31:48 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <4D57FCA0-0636-4BE3-91FB-79D23FAFC209@darko.org> What I'm not clear about in that case is how I get back to the allocated references. Any particular object doesn't know what thread it's running in but needs access to the currently running thread's copy of the objects. If I could subclass Thread.T and have that allocated when creating new threads that would be perfect. I could store a reference in each object pointing to it's per-thread data but that seems wasteful. On 14/09/2010, at 5:07 AM, Tony Hosking wrote: > Why not just allocate in the heap and hold a reference in the thread closure? > > On 14 Sep 2010, at 00:14, Darko wrote: > >> I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? >> >> Cheers, >> Darko. >> > From darko at darko.org Tue Sep 14 14:34:59 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 05:34:59 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> <20100914045504.A62281A209C@async.async.caltech.edu> <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org> Message-ID: That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > On 14 Sep 2010, at 01:08, Darko wrote: > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. >> >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: >> >>> Darko writes: >>>> I need to have certain data structures allocated on a per thread basis. = >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >>>> index a list. Is there a better, more portable way of allocating on a = >>>> per-thread basis? >>>> >>>> Cheers, >>>> Darko. >>> >>> In my experience what you suggest works just fine (remember to lock the >>> doors, though!) But you can get disappointing performance on some thread >>> implementations (ones that involve switching into supervisor mode more >>> than necessary when accessing pthread structures). >>> >>> Generally speaking I avoid needing per-thread structures as much as possible >>> and instead put what you need in the Closure and then pass pointers around. >>> Of course you can mix the methods for a compromise between speed and >>> cluttered code... >>> >>> I think what you want is also not a list but a Table. >>> >>> Mika >> > From jay.krell at cornell.edu Tue Sep 14 14:59:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 12:59:18 +0000 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , Message-ID: Tony -- then why does pthread_get/setspecific and Win32 TLS exist? What language doesn't support heap allocation were they designed to support? It is because code often fails to pass all the parameters through all functions. Again the best current answer is: #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. As well, you'd get very very far with merely: #ifdef _WIN32 __declspec(thread) #else __thread #endif Those work adequately for many many purposes, are more efficient, much more convenient, and very portable. I believe there is even an "official" C++ proposal along these lines. We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well. Can anyone propose something? It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use. - Jay > From: darko at darko.org > Date: Tue, 14 Sep 2010 05:34:59 -0700 > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > >> > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > >> > >>> Darko writes: > >>>> I need to have certain data structures allocated on a per thread basis. = > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > >>>> index a list. Is there a better, more portable way of allocating on a = > >>>> per-thread basis? > >>>> > >>>> Cheers, > >>>> Darko. > >>> > >>> In my experience what you suggest works just fine (remember to lock the > >>> doors, though!) But you can get disappointing performance on some thread > >>> implementations (ones that involve switching into supervisor mode more > >>> than necessary when accessing pthread structures). > >>> > >>> Generally speaking I avoid needing per-thread structures as much as possible > >>> and instead put what you need in the Closure and then pass pointers around. > >>> Of course you can mix the methods for a compromise between speed and > >>> cluttered code... > >>> > >>> I think what you want is also not a list but a Table. > >>> > >>> Mika > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Tue Sep 14 15:13:26 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 06:13:26 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , Message-ID: <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> I think a minimalist approach where you get to store and retrieve one traced reference per thread would do the trick. If people want more they can design their own abstraction on top of that. Maybe just add the following to the Thread interface: PROCEDURE GetPrivate(): REFANY; PROCEDURE SetPrivate(ref: REFANY); On 14/09/2010, at 5:59 AM, Jay K wrote: > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much as possible > > >>> and instead put what you need in the Closure and then pass pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Tue Sep 14 15:50:02 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 14 Sep 2010 06:50:02 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <20100914135002.72B6A1A2097@async.async.caltech.edu> If you have control over all the code you can (probably?) always do that, perhaps at the cost of some extra code. But there are times---such as when writing an interpreter that interfaces with "any" Modula-3 code---that you may want to have thread-private data accessible without necessarily being able to access the thread closure. In these cases, you don't know how many threads you have but yet want to have "global" variables. It would be really nice to have some interface for doing this without going all the way through pthreads primitives (or something equivalent)... Mika Tony Hosking writes: >Why not just allocate in the heap and hold a reference in the thread = >closure? > >On 14 Sep 2010, at 00:14, Darko wrote: > >> I need to have certain data structures allocated on a per thread = >basis. Right now I'm thinking of using the thread id from ThreadF.MyId() = >to index a list. Is there a better, more portable way of allocating on a = >per-thread basis? >>=20 >> Cheers, >> Darko. >>=20 From jay.krell at cornell.edu Tue Sep 14 16:05:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 14:05:12 +0000 Subject: [M3devel] Per thread data In-Reply-To: <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, , <20100914045504.A62281A209C@async.async.caltech.edu>, , <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> Message-ID: Eh? Just one thread local for the entire process? I think not. More like: PROCEDURE AllocateThreadLocal(): INTEGER; PROCEDURE GetThreadLocal(INTEGER):REFANY; PROCEDURE SetThreadLocal(INTEGER;REFANY); or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. The first set of names sounds better, the second "scales" better. This seems like a constant dilemna. btw, important point I just remembered: unless you do extra work, thread locals are hidden from the garbage collector. This is why the thread implementations seemingly store extra data. The traced data is in globals, so the garbage collector can see them. ?- Jay ________________________________ > From: darko at darko.org > Date: Tue, 14 Sep 2010 06:13:26 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > I think a minimalist approach where you get to store and retrieve one > traced reference per thread would do the trick. If people want more > they can design their own abstraction on top of that. Maybe just add > the following to the Thread interface: > > PROCEDURE GetPrivate(): REFANY; > PROCEDURE SetPrivate(ref: REFANY); > > > On 14/09/2010, at 5:59 AM, Jay K wrote: > > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all > functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 > TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much > more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then > support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) > know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object > allocated for the same thread, so it needs to find the currently > running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in > the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no > calls on them can be re-entered, which also avoids the need for locking > them in a threaded environment, which is impractical. The result is > that I need one copy of each object in each thread. There is > approximately one allocated object per object type so space is not a > big issue. I'm looking at a small number of threads, probably maximum > two per processor core. With modern processors I'm assuming that a > linear search through a small array is actually quicker that a hash > table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread > basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating > on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some > thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much > as possible > > >>> and instead put what you need in the Closure and then pass > pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > > From jay.krell at cornell.edu Tue Sep 14 16:09:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 14:09:28 +0000 Subject: [M3devel] m3cc/m3gdb mangled names Message-ID: Two part proposal: if targeting a platform that m3gdb doesn't currently support, don't mangle the names ? I understand this set is subject to change, and therefore that's a flaw in the suggestion. if I can determine that neither -gstabs nor -gstabs+ are on the command line, ? and I think I can, then don't mangle the names. and then, along with the goal of making all optimizations work I want all the other -g options, like plain -g, to not crash. I expect these goals have somewhat coincident fixes. I expect to do this shortly. This is a brief period to object, and maybe for me to explain myself better than in the commit message, perhaps. ?- Jay From rodney_bates at lcwb.coop Tue Sep 14 17:17:47 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Tue, 14 Sep 2010 10:17:47 -0500 Subject: [M3devel] Per thread data In-Reply-To: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org> Message-ID: <4C8F921B.6040005@lcwb.coop> Another way: Put your thread-specific data in local variables of the topmost procedure of your thread, i.e., the procedure that you override Thread.Closure.apply with. Then you can access it in either of two ways, or a mixture: 1) Nest other procedures inside the topmost procedure and use nonlocal references to the thread-specific data. 2) Pass it (probably by reference) to/thru any non-nested procedures you really must have. Any code you don't have control over would not have any way of knowing about your thread-specific data, except if you passed it as parameter(s). Darko wrote: > I need to have certain data structures allocated on a per thread basis. Right now I'm thinking of using the thread id from ThreadF.MyId() to index a list. Is there a better, more portable way of allocating on a per-thread basis? > > Cheers, > Darko. > > From hosking at cs.purdue.edu Tue Sep 14 18:48:22 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 12:48:22 -0400 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , Message-ID: Ah, sorry. I misunderstood. Sounds like we need a thread-local pragma <*LOCAL*>? On 14 Sep 2010, at 08:59, Jay K wrote: > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object allocated for the same thread, so it needs to find the currently running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no calls on them can be re-entered, which also avoids the need for locking them in a threaded environment, which is impractical. The result is that I need one copy of each object in each thread. There is approximately one allocated object per object type so space is not a big issue. I'm looking at a small number of threads, probably maximum two per processor core. With modern processors I'm assuming that a linear search through a small array is actually quicker that a hash table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much as possible > > >>> and instead put what you need in the Closure and then pass pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Sep 14 22:08:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 20:08:21 +0000 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , Message-ID: Sure. <* ThreadLocal *> or such, be sure it mentions "thread". ?- Jay ________________________________ > Subject: Re: [M3devel] Per thread data > From: hosking at cs.purdue.edu > Date: Tue, 14 Sep 2010 12:48:22 -0400 > CC: darko at darko.org; m3devel at elegosoft.com > To: jay.krell at cornell.edu > > Ah, sorry. I misunderstood. Sounds like we need a thread-local pragma > <*LOCAL*>? > > On 14 Sep 2010, at 08:59, Jay K wrote: > > Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > What language doesn't support heap allocation were they designed to support? > It is because code often fails to pass all the parameters through all > functions. > > Again the best current answer is: > #ifdefed C that uses pthread_get/setspecific / Win32 > TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > As well, you'd get very very far with merely: > #ifdef _WIN32 > __declspec(thread) > #else > __thread > #endif > > Those work adequately for many many purposes, are more efficient, much > more convenient, and very portable. > I believe there is even an "official" C++ proposal along these lines. > > We could easily abstract this -- the first -- into Modula-3 and then > support it on user threads as well. > Can anyone propose something? > It has to go in m3core, as that is the only code that (is supposed to) > know which thread implementation is in use. > > - Jay > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 05:34:59 -0700 > > To: hosking at cs.purdue.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > That's the idea but each object can only call another object > allocated for the same thread, so it needs to find the currently > running thread's copy of the desired object. > > > > On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > > > > If they are truly private to each thread, then allocating them in > the heap while still not locking them would be adequate. Why not? > > > > > > On 14 Sep 2010, at 01:08, Darko wrote: > > > > > >> I have lots of objects that are implemented on the basis that no > calls on them can be re-entered, which also avoids the need for locking > them in a threaded environment, which is impractical. The result is > that I need one copy of each object in each thread. There is > approximately one allocated object per object type so space is not a > big issue. I'm looking at a small number of threads, probably maximum > two per processor core. With modern processors I'm assuming that a > linear search through a small array is actually quicker that a hash > table. > > >> > > >> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >> > > >>> Darko writes: > > >>>> I need to have certain data structures allocated on a per thread > basis. = > > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>> index a list. Is there a better, more portable way of allocating > on a = > > >>>> per-thread basis? > > >>>> > > >>>> Cheers, > > >>>> Darko. > > >>> > > >>> In my experience what you suggest works just fine (remember to lock the > > >>> doors, though!) But you can get disappointing performance on some > thread > > >>> implementations (ones that involve switching into supervisor mode more > > >>> than necessary when accessing pthread structures). > > >>> > > >>> Generally speaking I avoid needing per-thread structures as much > as possible > > >>> and instead put what you need in the Closure and then pass > pointers around. > > >>> Of course you can mix the methods for a compromise between speed and > > >>> cluttered code... > > >>> > > >>> I think what you want is also not a list but a Table. > > >>> > > >>> Mika > > >> > > > > > > From mika at async.async.caltech.edu Tue Sep 14 22:28:13 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 14 Sep 2010 13:28:13 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , Message-ID: <20100914202813.1CCF81A20A2@async.async.caltech.edu> Something that changes the meaning of the language in such a fundamental way I think ought to be implemented as a library so that we can simulate the behavior in other releases... not as a compiler pragma. Yes I know there's an efficiency and expressibility price for this. Mika Jay K writes: > >Sure. <* ThreadLocal *> or such=2C be sure it mentions "thread". > >=A0- Jay > > > >________________________________ >> Subject: Re: [M3devel] Per thread data >> From: hosking at cs.purdue.edu >> Date: Tue=2C 14 Sep 2010 12:48:22 -0400 >> CC: darko at darko.org=3B m3devel at elegosoft.com >> To: jay.krell at cornell.edu >> >> Ah=2C sorry. I misunderstood. Sounds like we need a thread-local pragma >> <*LOCAL*>? >> >> On 14 Sep 2010=2C at 08:59=2C Jay K wrote: >> >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? >> What language doesn't support heap allocation were they designed to suppo= >rt? >> It is because code often fails to pass all the parameters through all >> functions. >> >> Again the best current answer is: >> #ifdefed C that uses pthread_get/setspecific / Win32 >> TlsAlloc/GetValue/SetValue=2C ignoring user threads/OpenBSD. >> >> As well=2C you'd get very very far with merely: >> #ifdef _WIN32 >> __declspec(thread) >> #else >> __thread >> #endif >> >> Those work adequately for many many purposes=2C are more efficient=2C muc= >h >> more convenient=2C and very portable. >> I believe there is even an "official" C++ proposal along these lines. >> >> We could easily abstract this -- the first -- into Modula-3 and then >> support it on user threads as well. >> Can anyone propose something? >> It has to go in m3core=2C as that is the only code that (is supposed to) >> know which thread implementation is in use. >> >> - Jay >> >> >> > From: darko at darko.org >> > Date: Tue=2C 14 Sep 2010 05:34:59 -0700 >> > To: hosking at cs.purdue.edu >> > CC: m3devel at elegosoft.com >> > Subject: Re: [M3devel] Per thread data >> > >> > That's the idea but each object can only call another object >> allocated for the same thread=2C so it needs to find the currently >> running thread's copy of the desired object. >> > >> > On 14/09/2010=2C at 5:08 AM=2C Tony Hosking wrote: >> > >> > > If they are truly private to each thread=2C then allocating them in >> the heap while still not locking them would be adequate. Why not? >> > > >> > > On 14 Sep 2010=2C at 01:08=2C Darko wrote: >> > > >> > >> I have lots of objects that are implemented on the basis that no >> calls on them can be re-entered=2C which also avoids the need for locking >> them in a threaded environment=2C which is impractical. The result is >> that I need one copy of each object in each thread. There is >> approximately one allocated object per object type so space is not a >> big issue. I'm looking at a small number of threads=2C probably maximum >> two per processor core. With modern processors I'm assuming that a >> linear search through a small array is actually quicker that a hash >> table. >> > >> >> > >> On 13/09/2010=2C at 9:55 PM=2C Mika Nystrom wrote: >> > >> >> > >>> Darko writes: >> > >>>> I need to have certain data structures allocated on a per thread >> basis. =3D >> > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() = >to =3D >> > >>>> index a list. Is there a better=2C more portable way of allocating >> on a =3D >> > >>>> per-thread basis? >> > >>>> >> > >>>> Cheers=2C >> > >>>> Darko. >> > >>> >> > >>> In my experience what you suggest works just fine (remember to lock= > the >> > >>> doors=2C though!) But you can get disappointing performance on some >> thread >> > >>> implementations (ones that involve switching into supervisor mode m= >ore >> > >>> than necessary when accessing pthread structures). >> > >>> >> > >>> Generally speaking I avoid needing per-thread structures as much >> as possible >> > >>> and instead put what you need in the Closure and then pass >> pointers around. >> > >>> Of course you can mix the methods for a compromise between speed an= >d >> > >>> cluttered code... >> > >>> >> > >>> I think what you want is also not a list but a Table. >> > >>> >> > >>> Mika >> > >> >> > > >> > >> > = From hosking at cs.purdue.edu Tue Sep 14 22:37:59 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Tue, 14 Sep 2010 16:37:59 -0400 Subject: [M3devel] Per thread data In-Reply-To: <20100914202813.1CCF81A20A2@async.async.caltech.edu> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , <20100914202813.1CCF81A20A2@async.async.caltech.edu> Message-ID: <5F561977-1C70-4060-9605-F4B834953799@cs.purdue.edu> Yeah, I thought of that afterwards. Probably need a ThreadLocal generic interface like Atomic. On 14 Sep 2010, at 16:28, Mika Nystrom wrote: > Something that changes the meaning of the language in such a fundamental > way I think ought to be implemented as a library so that we can simulate > the behavior in other releases... not as a compiler pragma. Yes I know > there's an efficiency and expressibility price for this. > > Mika > > Jay K writes: >> >> Sure. <* ThreadLocal *> or such=2C be sure it mentions "thread". >> >> =A0- Jay >> >> >> >> ________________________________ >>> Subject: Re: [M3devel] Per thread data >>> From: hosking at cs.purdue.edu >>> Date: Tue=2C 14 Sep 2010 12:48:22 -0400 >>> CC: darko at darko.org=3B m3devel at elegosoft.com >>> To: jay.krell at cornell.edu >>> >>> Ah=2C sorry. I misunderstood. Sounds like we need a thread-local pragma >>> <*LOCAL*>? >>> >>> On 14 Sep 2010=2C at 08:59=2C Jay K wrote: >>> >>> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? >>> What language doesn't support heap allocation were they designed to suppo= >> rt? >>> It is because code often fails to pass all the parameters through all >>> functions. >>> >>> Again the best current answer is: >>> #ifdefed C that uses pthread_get/setspecific / Win32 >>> TlsAlloc/GetValue/SetValue=2C ignoring user threads/OpenBSD. >>> >>> As well=2C you'd get very very far with merely: >>> #ifdef _WIN32 >>> __declspec(thread) >>> #else >>> __thread >>> #endif >>> >>> Those work adequately for many many purposes=2C are more efficient=2C muc= >> h >>> more convenient=2C and very portable. >>> I believe there is even an "official" C++ proposal along these lines. >>> >>> We could easily abstract this -- the first -- into Modula-3 and then >>> support it on user threads as well. >>> Can anyone propose something? >>> It has to go in m3core=2C as that is the only code that (is supposed to) >>> know which thread implementation is in use. >>> >>> - Jay >>> >>> >>>> From: darko at darko.org >>>> Date: Tue=2C 14 Sep 2010 05:34:59 -0700 >>>> To: hosking at cs.purdue.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] Per thread data >>>> >>>> That's the idea but each object can only call another object >>> allocated for the same thread=2C so it needs to find the currently >>> running thread's copy of the desired object. >>>> >>>> On 14/09/2010=2C at 5:08 AM=2C Tony Hosking wrote: >>>> >>>>> If they are truly private to each thread=2C then allocating them in >>> the heap while still not locking them would be adequate. Why not? >>>>> >>>>> On 14 Sep 2010=2C at 01:08=2C Darko wrote: >>>>> >>>>>> I have lots of objects that are implemented on the basis that no >>> calls on them can be re-entered=2C which also avoids the need for locking >>> them in a threaded environment=2C which is impractical. The result is >>> that I need one copy of each object in each thread. There is >>> approximately one allocated object per object type so space is not a >>> big issue. I'm looking at a small number of threads=2C probably maximum >>> two per processor core. With modern processors I'm assuming that a >>> linear search through a small array is actually quicker that a hash >>> table. >>>>>> >>>>>> On 13/09/2010=2C at 9:55 PM=2C Mika Nystrom wrote: >>>>>> >>>>>>> Darko writes: >>>>>>>> I need to have certain data structures allocated on a per thread >>> basis. =3D >>>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() = >> to =3D >>>>>>>> index a list. Is there a better=2C more portable way of allocating >>> on a =3D >>>>>>>> per-thread basis? >>>>>>>> >>>>>>>> Cheers=2C >>>>>>>> Darko. >>>>>>> >>>>>>> In my experience what you suggest works just fine (remember to lock= >> the >>>>>>> doors=2C though!) But you can get disappointing performance on some >>> thread >>>>>>> implementations (ones that involve switching into supervisor mode m= >> ore >>>>>>> than necessary when accessing pthread structures). >>>>>>> >>>>>>> Generally speaking I avoid needing per-thread structures as much >>> as possible >>>>>>> and instead put what you need in the Closure and then pass >>> pointers around. >>>>>>> Of course you can mix the methods for a compromise between speed an= >> d >>>>>>> cluttered code... >>>>>>> >>>>>>> I think what you want is also not a list but a Table. >>>>>>> >>>>>>> Mika >>>>>> >>>>> >>>> >>> >> = From jay.krell at cornell.edu Tue Sep 14 22:38:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 14 Sep 2010 20:38:24 +0000 Subject: [M3devel] Per thread data In-Reply-To: <20100914202813.1CCF81A20A2@async.async.caltech.edu> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, <20100914045504.A62281A209C@async.async.caltech.edu>, <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , <20100914202813.1CCF81A20A2@async.async.caltech.edu> Message-ID: Thread.Local ? Also, if you are doing this, can you add NoInline? We are letting gcc be more aggressive lately. I want NoInline for the toplevel function in the thread implementations. I could probably fake it by making a call to <*EXTERN*> setjmp. It might also be nice to parallel more of C/gcc's features. <*volatile*> ? And if you are really aggressive, since these involve m3cg changes, move any typeids that mangle names to be immediately after the name they mangle?? Maybe that is overkill though. It's just for tracing of mangled names via infrastructure. Also, load/store should take some notion of a field. A name or a uid perhaps. But now I'm being greedy. I'm willing to first prototype field access via linear search. Mika I see your point. We could consider both. I can maybe do the library soon. Or someone else can. It's pretty easy. ? It really should be mostly #ifdefed C, plus either ?? 1) using UNTRACED ROOT or INTEGER instead of REFANY for the data ???? You could loophole between untraced root and integer. ????? Safety would imply providing integer and float/real options to safe code. ????? Possibly double/longreal (which would take two slots on 32bit targets). ????? I think the functions could be exposed to safe code. They'd raise ???? exceptions for invalid tls indeices ?? 2) some way to reveal the REFANYs to the garbage collector ???? 2a) possibly by stashing them all in globals as well ? ???? 2b) or by having the garbage collector use the per thread data functions, ? with the caveat that they can't be use across threads, which might ?? be a problem; a thread could perhaps fetch all of its per thread ?? data into locals before acknowleding suspension ? ? Many approaches would require the runtime to ???? know all the per thread data keys/indices, which I suspect is easy enough. I'd appreciate a fairly firm commit it will actually be used. Thanks. Maybe we can switch m3core to use itself. Maybe. ? (It'd have to not raise exceptions or use try, to avoid circular dependency.) Maybe just use an array and linear search, in m3core or your code.. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > Date: Tue, 14 Sep 2010 13:28:13 -0700 > From: mika at async.async.caltech.edu > > Something that changes the meaning of the language in such a fundamental > way I think ought to be implemented as a library so that we can simulate > the behavior in other releases... not as a compiler pragma. Yes I know > there's an efficiency and expressibility price for this. > > Mika > > Jay K writes: > > > >Sure. <* ThreadLocal *> or such=2C be sure it mentions "thread". > > > >=A0- Jay > > > > > > > >________________________________ > >> Subject: Re: [M3devel] Per thread data > >> From: hosking at cs.purdue.edu > >> Date: Tue=2C 14 Sep 2010 12:48:22 -0400 > >> CC: darko at darko.org=3B m3devel at elegosoft.com > >> To: jay.krell at cornell.edu > >> > >> Ah=2C sorry. I misunderstood. Sounds like we need a thread-local pragma > >> <*LOCAL*>? > >> > >> On 14 Sep 2010=2C at 08:59=2C Jay K wrote: > >> > >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > >> What language doesn't support heap allocation were they designed to suppo= > >rt? > >> It is because code often fails to pass all the parameters through all > >> functions. > >> > >> Again the best current answer is: > >> #ifdefed C that uses pthread_get/setspecific / Win32 > >> TlsAlloc/GetValue/SetValue=2C ignoring user threads/OpenBSD. > >> > >> As well=2C you'd get very very far with merely: > >> #ifdef _WIN32 > >> __declspec(thread) > >> #else > >> __thread > >> #endif > >> > >> Those work adequately for many many purposes=2C are more efficient=2C muc= > >h > >> more convenient=2C and very portable. > >> I believe there is even an "official" C++ proposal along these lines. > >> > >> We could easily abstract this -- the first -- into Modula-3 and then > >> support it on user threads as well. > >> Can anyone propose something? > >> It has to go in m3core=2C as that is the only code that (is supposed to) > >> know which thread implementation is in use. > >> > >> - Jay > >> > >> > >> > From: darko at darko.org > >> > Date: Tue=2C 14 Sep 2010 05:34:59 -0700 > >> > To: hosking at cs.purdue.edu > >> > CC: m3devel at elegosoft.com > >> > Subject: Re: [M3devel] Per thread data > >> > > >> > That's the idea but each object can only call another object > >> allocated for the same thread=2C so it needs to find the currently > >> running thread's copy of the desired object. > >> > > >> > On 14/09/2010=2C at 5:08 AM=2C Tony Hosking wrote: > >> > > >> > > If they are truly private to each thread=2C then allocating them in > >> the heap while still not locking them would be adequate. Why not? > >> > > > >> > > On 14 Sep 2010=2C at 01:08=2C Darko wrote: > >> > > > >> > >> I have lots of objects that are implemented on the basis that no > >> calls on them can be re-entered=2C which also avoids the need for locking > >> them in a threaded environment=2C which is impractical. The result is > >> that I need one copy of each object in each thread. There is > >> approximately one allocated object per object type so space is not a > >> big issue. I'm looking at a small number of threads=2C probably maximum > >> two per processor core. With modern processors I'm assuming that a > >> linear search through a small array is actually quicker that a hash > >> table. > >> > >> > >> > >> On 13/09/2010=2C at 9:55 PM=2C Mika Nystrom wrote: > >> > >> > >> > >>> Darko writes: > >> > >>>> I need to have certain data structures allocated on a per thread > >> basis. =3D > >> > >>>> Right now I'm thinking of using the thread id from ThreadF.MyId() = > >to =3D > >> > >>>> index a list. Is there a better=2C more portable way of allocating > >> on a =3D > >> > >>>> per-thread basis? > >> > >>>> > >> > >>>> Cheers=2C > >> > >>>> Darko. > >> > >>> > >> > >>> In my experience what you suggest works just fine (remember to lock= > > the > >> > >>> doors=2C though!) But you can get disappointing performance on some > >> thread > >> > >>> implementations (ones that involve switching into supervisor mode m= > >ore > >> > >>> than necessary when accessing pthread structures). > >> > >>> > >> > >>> Generally speaking I avoid needing per-thread structures as much > >> as possible > >> > >>> and instead put what you need in the Closure and then pass > >> pointers around. > >> > >>> Of course you can mix the methods for a compromise between speed an= > >d > >> > >>> cluttered code... > >> > >>> > >> > >>> I think what you want is also not a list but a Table. > >> > >>> > >> > >>> Mika > >> > >> > >> > > > >> > > >> > > = From darko at darko.org Wed Sep 15 02:38:20 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 17:38:20 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, , <20100914045504.A62281A209C@async.async.caltech.edu>, , <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org> Message-ID: <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable. I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that? On 14/09/2010, at 7:05 AM, Jay K wrote: > > Eh? Just one thread local for the entire process? I think not. > > More like: > > PROCEDURE AllocateThreadLocal(): INTEGER; > PROCEDURE GetThreadLocal(INTEGER):REFANY; > > PROCEDURE SetThreadLocal(INTEGER;REFANY); > > > or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. > The first set of names sounds better, the second "scales" better. > This seems like a constant dilemna. > > btw, important point I just remembered: unless you do extra work, > thread locals are hidden from the garbage collector. > > This is why the thread implementations seemingly store extra data. > The traced data is in globals, so the garbage collector can see them. > > - Jay > > ________________________________ >> From: darko at darko.org >> Date: Tue, 14 Sep 2010 06:13:26 -0700 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] Per thread data >> >> I think a minimalist approach where you get to store and retrieve one >> traced reference per thread would do the trick. If people want more >> they can design their own abstraction on top of that. Maybe just add >> the following to the Thread interface: >> >> PROCEDURE GetPrivate(): REFANY; >> PROCEDURE SetPrivate(ref: REFANY); >> >> >> On 14/09/2010, at 5:59 AM, Jay K wrote: >> >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? >> What language doesn't support heap allocation were they designed to support? >> It is because code often fails to pass all the parameters through all >> functions. >> >> Again the best current answer is: >> #ifdefed C that uses pthread_get/setspecific / Win32 >> TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. >> >> As well, you'd get very very far with merely: >> #ifdef _WIN32 >> __declspec(thread) >> #else >> __thread >> #endif >> >> Those work adequately for many many purposes, are more efficient, much >> more convenient, and very portable. >> I believe there is even an "official" C++ proposal along these lines. >> >> We could easily abstract this -- the first -- into Modula-3 and then >> support it on user threads as well. >> Can anyone propose something? >> It has to go in m3core, as that is the only code that (is supposed to) >> know which thread implementation is in use. >> >> - Jay >> >> >>> From: darko at darko.org >>> Date: Tue, 14 Sep 2010 05:34:59 -0700 >>> To: hosking at cs.purdue.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: [M3devel] Per thread data >>> >>> That's the idea but each object can only call another object >> allocated for the same thread, so it needs to find the currently >> running thread's copy of the desired object. >>> >>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote: >>> >>>> If they are truly private to each thread, then allocating them in >> the heap while still not locking them would be adequate. Why not? >>>> >>>> On 14 Sep 2010, at 01:08, Darko wrote: >>>> >>>>> I have lots of objects that are implemented on the basis that no >> calls on them can be re-entered, which also avoids the need for locking >> them in a threaded environment, which is impractical. The result is >> that I need one copy of each object in each thread. There is >> approximately one allocated object per object type so space is not a >> big issue. I'm looking at a small number of threads, probably maximum >> two per processor core. With modern processors I'm assuming that a >> linear search through a small array is actually quicker that a hash >> table. >>>>> >>>>> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: >>>>> >>>>>> Darko writes: >>>>>>> I need to have certain data structures allocated on a per thread >> basis. = >>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = >>>>>>> index a list. Is there a better, more portable way of allocating >> on a = >>>>>>> per-thread basis? >>>>>>> >>>>>>> Cheers, >>>>>>> Darko. >>>>>> >>>>>> In my experience what you suggest works just fine (remember to lock the >>>>>> doors, though!) But you can get disappointing performance on some >> thread >>>>>> implementations (ones that involve switching into supervisor mode more >>>>>> than necessary when accessing pthread structures). >>>>>> >>>>>> Generally speaking I avoid needing per-thread structures as much >> as possible >>>>>> and instead put what you need in the Closure and then pass >> pointers around. >>>>>> Of course you can mix the methods for a compromise between speed and >>>>>> cluttered code... >>>>>> >>>>>> I think what you want is also not a list but a Table. >>>>>> >>>>>> Mika >>>>> >>>> >>> >> > From jay.krell at cornell.edu Wed Sep 15 04:23:04 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Sep 2010 02:23:04 +0000 Subject: [M3devel] Per thread data In-Reply-To: <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, ,,<20100914045504.A62281A209C@async.async.caltech.edu>, ,,<458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, ,,, , , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org>, , <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> Message-ID: It's not a hash lookup. It is a direct array index. Disassemble kernel32!TlsGetValue. It's much cheaper than a hash lookup, much more expensive than reading a global or local. on Windows 7 x86: \bin\x86\cdb cmd 0:000> u kernel32!TlsGetValue kernel32!TlsGetValue: 750111cd ff2510080175 jmp dword ptr [kernel32!_imp__TlsGetValue (75010810)] 0:000> u poi(75010810) KERNELBASE!TlsGetValue: 76532c95 8bff mov edi,edi 76532c97 55 push ebp 76532c98 8bec mov ebp,esp 76532c9a 64a118000000 mov eax,dword ptr fs:[00000018h] ; get per thread data base 76532ca0 8b4d08 mov ecx,dword ptr [ebp+8] 76532ca3 83603400 and dword ptr [eax+34h],0 76532ca7 83f940 cmp ecx,40h ; compare index to 64 76532caa 7309 jae KERNELBASE!TlsGetValue+0x20 (76532cb5) ; if above, goto 76532cb5 76532cac 8b8488100e0000 mov eax,dword ptr [eax+ecx*4+0E10h] ; get the actual value 76532cb3 eb14 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end 76532cb5 81f940040000 cmp ecx,440h ; compare to 1088 76532cbb 7210 jb KERNELBASE!TlsGetValue+0x38 (76532ccd) if below, goto 76532ccd 76532cbd 680d0000c0 push 0C000000Dh ; invalid parameter 76532cc2 e86b390200 call KERNELBASE!BaseSetLastNTError (76556632) 76532cc7 33c0 xor eax,eax ; return 0 for failure or for TlsSetValue not called 76532cc9 5d pop ebp 76532cca c20400 ret 4 76532ccd 8b80940f0000 mov eax,dword ptr [eax+0F94h] ; get data base for values > 64 76532cd3 85c0 test eax,eax ; compare to null 76532cd5 74f0 je KERNELBASE!TlsGetValue+0x32 (76532cc7) ; if null, goto 76532cc7, which returns 0, this is if you have calls TlsAlloc but not TlsSetValue 76532cd7 8b848800ffffff mov eax,dword ptr [eax+ecx*4-100h] ; get the value for index > 64 (subtracting 64*4) 76532cde ebe9 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end But your proposal might be reasonable anyway. Except, wouldn't Thread.T have to be revealed in an .i3 file? - Jay > From: darko at darko.org > Date: Tue, 14 Sep 2010 17:38:20 -0700 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] Per thread data > > The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable. > > I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that? > > > On 14/09/2010, at 7:05 AM, Jay K wrote: > > > > > Eh? Just one thread local for the entire process? I think not. > > > > More like: > > > > PROCEDURE AllocateThreadLocal(): INTEGER; > > PROCEDURE GetThreadLocal(INTEGER):REFANY; > > > > PROCEDURE SetThreadLocal(INTEGER;REFANY); > > > > > > or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. > > The first set of names sounds better, the second "scales" better. > > This seems like a constant dilemna. > > > > btw, important point I just remembered: unless you do extra work, > > thread locals are hidden from the garbage collector. > > > > This is why the thread implementations seemingly store extra data. > > The traced data is in globals, so the garbage collector can see them. > > > > - Jay > > > > ________________________________ > >> From: darko at darko.org > >> Date: Tue, 14 Sep 2010 06:13:26 -0700 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] Per thread data > >> > >> I think a minimalist approach where you get to store and retrieve one > >> traced reference per thread would do the trick. If people want more > >> they can design their own abstraction on top of that. Maybe just add > >> the following to the Thread interface: > >> > >> PROCEDURE GetPrivate(): REFANY; > >> PROCEDURE SetPrivate(ref: REFANY); > >> > >> > >> On 14/09/2010, at 5:59 AM, Jay K wrote: > >> > >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > >> What language doesn't support heap allocation were they designed to support? > >> It is because code often fails to pass all the parameters through all > >> functions. > >> > >> Again the best current answer is: > >> #ifdefed C that uses pthread_get/setspecific / Win32 > >> TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > >> > >> As well, you'd get very very far with merely: > >> #ifdef _WIN32 > >> __declspec(thread) > >> #else > >> __thread > >> #endif > >> > >> Those work adequately for many many purposes, are more efficient, much > >> more convenient, and very portable. > >> I believe there is even an "official" C++ proposal along these lines. > >> > >> We could easily abstract this -- the first -- into Modula-3 and then > >> support it on user threads as well. > >> Can anyone propose something? > >> It has to go in m3core, as that is the only code that (is supposed to) > >> know which thread implementation is in use. > >> > >> - Jay > >> > >> > >>> From: darko at darko.org > >>> Date: Tue, 14 Sep 2010 05:34:59 -0700 > >>> To: hosking at cs.purdue.edu > >>> CC: m3devel at elegosoft.com > >>> Subject: Re: [M3devel] Per thread data > >>> > >>> That's the idea but each object can only call another object > >> allocated for the same thread, so it needs to find the currently > >> running thread's copy of the desired object. > >>> > >>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > >>> > >>>> If they are truly private to each thread, then allocating them in > >> the heap while still not locking them would be adequate. Why not? > >>>> > >>>> On 14 Sep 2010, at 01:08, Darko wrote: > >>>> > >>>>> I have lots of objects that are implemented on the basis that no > >> calls on them can be re-entered, which also avoids the need for locking > >> them in a threaded environment, which is impractical. The result is > >> that I need one copy of each object in each thread. There is > >> approximately one allocated object per object type so space is not a > >> big issue. I'm looking at a small number of threads, probably maximum > >> two per processor core. With modern processors I'm assuming that a > >> linear search through a small array is actually quicker that a hash > >> table. > >>>>> > >>>>> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > >>>>> > >>>>>> Darko writes: > >>>>>>> I need to have certain data structures allocated on a per thread > >> basis. = > >>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > >>>>>>> index a list. Is there a better, more portable way of allocating > >> on a = > >>>>>>> per-thread basis? > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Darko. > >>>>>> > >>>>>> In my experience what you suggest works just fine (remember to lock the > >>>>>> doors, though!) But you can get disappointing performance on some > >> thread > >>>>>> implementations (ones that involve switching into supervisor mode more > >>>>>> than necessary when accessing pthread structures). > >>>>>> > >>>>>> Generally speaking I avoid needing per-thread structures as much > >> as possible > >>>>>> and instead put what you need in the Closure and then pass > >> pointers around. > >>>>>> Of course you can mix the methods for a compromise between speed and > >>>>>> cluttered code... > >>>>>> > >>>>>> I think what you want is also not a list but a Table. > >>>>>> > >>>>>> Mika > >>>>> > >>>> > >>> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darko at darko.org Wed Sep 15 05:00:34 2010 From: darko at darko.org (Darko) Date: Tue, 14 Sep 2010 20:00:34 -0700 Subject: [M3devel] Per thread data In-Reply-To: References: <475F3FB4-8194-486F-BE14-F84FF91563AE@darko.org>, , , <20100914045504.A62281A209C@async.async.caltech.edu>, , , <458A13AF-162B-482D-AEED-1F52B48FC0CE@darko.org>, , , , , , , , , , <5BD30F98-1BA4-4DF0-9AB8-30F068F7EFAB@darko.org>, , <0731C8A4-8C5C-43E0-90F4-F931274C251B@darko.org> Message-ID: No, only the subtype has to be revealed. I think both approaches have their usefulness, the Get/Set is useful for libraries. On 14/09/2010, at 7:23 PM, Jay K wrote: > It's not a hash lookup. It is a direct array index. > Disassemble kernel32!TlsGetValue. > It's much cheaper than a hash lookup, much more expensive than reading a global or local. > > > on Windows 7 x86: > > \bin\x86\cdb cmd > 0:000> u kernel32!TlsGetValue > kernel32!TlsGetValue: > 750111cd ff2510080175 jmp dword ptr [kernel32!_imp__TlsGetValue (75010810)] > > 0:000> u poi(75010810) > KERNELBASE!TlsGetValue: > 76532c95 8bff mov edi,edi > 76532c97 55 push ebp > 76532c98 8bec mov ebp,esp > 76532c9a 64a118000000 mov eax,dword ptr fs:[00000018h] ; get per thread data base > 76532ca0 8b4d08 mov ecx,dword ptr [ebp+8] > 76532ca3 83603400 and dword ptr [eax+34h],0 > 76532ca7 83f940 cmp ecx,40h ; compare index to 64 > 76532caa 7309 jae KERNELBASE!TlsGetValue+0x20 (76532cb5) ; if above, goto 76532cb5 > 76532cac 8b8488100e0000 mov eax,dword ptr [eax+ecx*4+0E10h] ; get the actual value > 76532cb3 eb14 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end > 76532cb5 81f940040000 cmp ecx,440h ; compare to 1088 > 76532cbb 7210 jb KERNELBASE!TlsGetValue+0x38 (76532ccd) if below, goto 76532ccd > 76532cbd 680d0000c0 push 0C000000Dh ; invalid parameter > 76532cc2 e86b390200 call KERNELBASE!BaseSetLastNTError (76556632) > 76532cc7 33c0 xor eax,eax ; return 0 for failure or for TlsSetValue not called > 76532cc9 5d pop ebp > 76532cca c20400 ret 4 > 76532ccd 8b80940f0000 mov eax,dword ptr [eax+0F94h] ; get data base for values > 64 > 76532cd3 85c0 test eax,eax ; compare to null > 76532cd5 74f0 je KERNELBASE!TlsGetValue+0x32 (76532cc7) ; if null, goto 76532cc7, which returns 0, this is if you have calls TlsAlloc but not TlsSetValue > 76532cd7 8b848800ffffff mov eax,dword ptr [eax+ecx*4-100h] ; get the value for index > 64 (subtracting 64*4) > 76532cde ebe9 jmp KERNELBASE!TlsGetValue+0x34 (76532cc9) ; goto end > > > > But your proposal might be reasonable anyway. > Except, wouldn't Thread.T have to be revealed in an .i3 file? > > > - Jay > > > > > From: darko at darko.org > > Date: Tue, 14 Sep 2010 17:38:20 -0700 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] Per thread data > > > > The issue I see is performance. That requires at least a hash lookup and will have performance nothing like a global variable. > > > > I'd like to change the Thread interface so that Fork takes a parameter of a typecode which must be a subtype of Thread.T and allocates that if specified. Assuming Thread.Self() is not slow that should perform much better. Anyone see any problems with that? > > > > > > On 14/09/2010, at 7:05 AM, Jay K wrote: > > > > > > > > Eh? Just one thread local for the entire process? I think not. > > > > > > More like: > > > > > > PROCEDURE AllocateThreadLocal(): INTEGER; > > > PROCEDURE GetThreadLocal(INTEGER):REFANY; > > > > > > PROCEDURE SetThreadLocal(INTEGER;REFANY); > > > > > > > > > or ThreadLocalAllocate, ThreadLocalGet, ThreadLocalSet. > > > The first set of names sounds better, the second "scales" better. > > > This seems like a constant dilemna. > > > > > > btw, important point I just remembered: unless you do extra work, > > > thread locals are hidden from the garbage collector. > > > > > > This is why the thread implementations seemingly store extra data. > > > The traced data is in globals, so the garbage collector can see them. > > > > > > - Jay > > > > > > ________________________________ > > >> From: darko at darko.org > > >> Date: Tue, 14 Sep 2010 06:13:26 -0700 > > >> To: jay.krell at cornell.edu > > >> CC: m3devel at elegosoft.com > > >> Subject: Re: [M3devel] Per thread data > > >> > > >> I think a minimalist approach where you get to store and retrieve one > > >> traced reference per thread would do the trick. If people want more > > >> they can design their own abstraction on top of that. Maybe just add > > >> the following to the Thread interface: > > >> > > >> PROCEDURE GetPrivate(): REFANY; > > >> PROCEDURE SetPrivate(ref: REFANY); > > >> > > >> > > >> On 14/09/2010, at 5:59 AM, Jay K wrote: > > >> > > >> Tony -- then why does pthread_get/setspecific and Win32 TLS exist? > > >> What language doesn't support heap allocation were they designed to support? > > >> It is because code often fails to pass all the parameters through all > > >> functions. > > >> > > >> Again the best current answer is: > > >> #ifdefed C that uses pthread_get/setspecific / Win32 > > >> TlsAlloc/GetValue/SetValue, ignoring user threads/OpenBSD. > > >> > > >> As well, you'd get very very far with merely: > > >> #ifdef _WIN32 > > >> __declspec(thread) > > >> #else > > >> __thread > > >> #endif > > >> > > >> Those work adequately for many many purposes, are more efficient, much > > >> more convenient, and very portable. > > >> I believe there is even an "official" C++ proposal along these lines. > > >> > > >> We could easily abstract this -- the first -- into Modula-3 and then > > >> support it on user threads as well. > > >> Can anyone propose something? > > >> It has to go in m3core, as that is the only code that (is supposed to) > > >> know which thread implementation is in use. > > >> > > >> - Jay > > >> > > >> > > >>> From: darko at darko.org > > >>> Date: Tue, 14 Sep 2010 05:34:59 -0700 > > >>> To: hosking at cs.purdue.edu > > >>> CC: m3devel at elegosoft.com > > >>> Subject: Re: [M3devel] Per thread data > > >>> > > >>> That's the idea but each object can only call another object > > >> allocated for the same thread, so it needs to find the currently > > >> running thread's copy of the desired object. > > >>> > > >>> On 14/09/2010, at 5:08 AM, Tony Hosking wrote: > > >>> > > >>>> If they are truly private to each thread, then allocating them in > > >> the heap while still not locking them would be adequate. Why not? > > >>>> > > >>>> On 14 Sep 2010, at 01:08, Darko wrote: > > >>>> > > >>>>> I have lots of objects that are implemented on the basis that no > > >> calls on them can be re-entered, which also avoids the need for locking > > >> them in a threaded environment, which is impractical. The result is > > >> that I need one copy of each object in each thread. There is > > >> approximately one allocated object per object type so space is not a > > >> big issue. I'm looking at a small number of threads, probably maximum > > >> two per processor core. With modern processors I'm assuming that a > > >> linear search through a small array is actually quicker that a hash > > >> table. > > >>>>> > > >>>>> On 13/09/2010, at 9:55 PM, Mika Nystrom wrote: > > >>>>> > > >>>>>> Darko writes: > > >>>>>>> I need to have certain data structures allocated on a per thread > > >> basis. = > > >>>>>>> Right now I'm thinking of using the thread id from ThreadF.MyId() to = > > >>>>>>> index a list. Is there a better, more portable way of allocating > > >> on a = > > >>>>>>> per-thread basis? > > >>>>>>> > > >>>>>>> Cheers, > > >>>>>>> Darko. > > >>>>>> > > >>>>>> In my experience what you suggest works just fine (remember to lock the > > >>>>>> doors, though!) But you can get disappointing performance on some > > >> thread > > >>>>>> implementations (ones that involve switching into supervisor mode more > > >>>>>> than necessary when accessing pthread structures). > > >>>>>> > > >>>>>> Generally speaking I avoid needing per-thread structures as much > > >> as possible > > >>>>>> and instead put what you need in the Closure and then pass > > >> pointers around. > > >>>>>> Of course you can mix the methods for a compromise between speed and > > >>>>>> cluttered code... > > >>>>>> > > >>>>>> I think what you want is also not a list but a Table. > > >>>>>> > > >>>>>> Mika > > >>>>> > > >>>> > > >>> > > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Sep 15 14:59:17 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Sep 2010 12:59:17 +0000 Subject: [M3devel] uid == 0? Message-ID: It'd be super convenient if uid == 0 was invalid. But then, whey is NO_UID = 0xFFFFFFFF? You know, I recently introduced: typedef struct GTY(()) m3type { ? unsigned long id; ? tree GTY(()) t; } m3type_t; I think it might be useful to flesh this out a bunch, like: typedef struct GTY(()) m3type { ? unsigned long id; ? tree GTY(()) t; ? /* conceptually a union */ ? unsigned is_packed : 1; ? unsigned is_record : 1; ? unsigned is_enum : 1; ? unsigned is_object : 1; ? struct ? { ??? unsigned size; ??? unsigned long target_id; ? } packed; } m3type_t; or: typedef struct GTY(()) m3type { ? unsigned long id; ? tree GTY(()) t; ? /* conceptually a union */ ??? unsigned packed_size; (* or zero *) ??? unsigned long packed_target_id; (* or zero *) } m3type_t; ?- I think t will often have this information, but not always, like how to discern object from record? ?? Maybe it doesn't matter? ?- the gcc garbage collector might require more annotations for unions and I'd rather defer that ?- but there will be many of these (thousands?) ?- I'm lately a non-fan of bitfields in C, because I can't predict the layout easily. ?- Jay From jay.krell at cornell.edu Tue Sep 21 16:19:34 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 21 Sep 2010 14:19:34 +0000 Subject: [M3devel] Hudson seems down. Message-ID: http://hudson.modula3.com:8080 ? Not that I doing much lately.. ?- Jay From kay.haeusler at elego.de Tue Sep 21 16:31:15 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Tue, 21 Sep 2010 16:31:15 +0200 Subject: [M3devel] Hudson seems down. In-Reply-To: References: Message-ID: <20100921163115.1722aba8@linden.elego.de> Hello Jay Jay K wrote: > http://hudson.modula3.com:8080 > > ? > > Not that I doing much lately.. I've restarted hudson -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From kay.haeusler at elego.de Tue Sep 21 16:38:27 2010 From: kay.haeusler at elego.de (Kay =?UTF-8?B?SMOkdXNsZXI=?=) Date: Tue, 21 Sep 2010 16:38:27 +0200 Subject: [M3devel] Hudson seems down. In-Reply-To: <20100921163115.1722aba8@linden.elego.de> References: <20100921163115.1722aba8@linden.elego.de> Message-ID: <20100921163827.5acb0e65@linden.elego.de> Kay H?usler wrote: > > http://hudson.modula3.com:8080 > > > > ? > > > > Not that I doing much lately.. > > I've restarted hudson Hudson is back -- Mit freundlichen Gr??en Kay H?usler mailto:kay.haeusler at elego.de elego Software Solutions GmbH http://www.elego.de Gustav-Meyer-Allee 25, Geb?ude 12 HRB 77719 13355 Berlin, Germany Amtsgericht Charlottenburg Tel.: +49 30 23458696 Sitz der Gesellschaft: Berlin Fax: +49 30 23458695 Gesch?ftsf?hrer: Olaf Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: not available URL: From jay.krell at cornell.edu Sat Sep 25 11:35:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Sep 2010 09:35:12 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix Message-ID: PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = ? (* LL = m *) ? VAR self := GetActivation(); ? BEGIN ??? IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; ??? IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; ??? XWait(m, c, self, alertable := TRUE); ? END AlertWait; The pthread code doesn't have the check for NIL and call to Die. Nor for that matter, the uses of ThreadDebug -- which I added. I think these should be more similar. What I was really wondering about, again, is more common code between Win32 and Posix in the thread code... ?- Jay From jay.krell at cornell.edu Sat Sep 25 12:47:56 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Sep 2010 10:47:56 +0000 Subject: [M3devel] uid to string conversion? (probably answered my own question) Message-ID: static void fmt_uid (unsigned long x, char *buf) { ? unsigned i = UID_SIZE; ? static const char alphabet[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"; ? gcc_assert (sizeof(alphabet) == 63); ? if (x == NO_UID) ? { ??? static const char zzzzzz[] = "zzzzzz"; ??? memcpy (buf, zzzzzz, sizeof(zzzzzz)); ??? return; ? } ? buf[i] = 0; ? while (i) ? { ??? buf[--i] = alphabet[x % 62]; ??? x /= 62; ? } ? if (x || buf[0] < 'A' || buf[0] > 'Z') ??? fatal_error (" *** bad uid -> identifier conversion!!"); } 1) what guarantees buf[0] is valid, in that last chunk? Is it because uids have a limited range and they'd have to be too large to fail there? Because 62^6 is larger than 2^32? 2) The check is too tight anyway? It should allow also lowercase a-z? 1) I guess so: #include #include unsigned multu32(unsigned a, unsigned b) { ? unsigned long long c = (a * (unsigned long long)b); ? if (c != (unsigned)c) /* or ? if (c > ~(unsigned)0) */ ? { ??? printf("overflow %u * %u; %x * %x\n", a, b, a, b); ??? exit(0); ? } ? return c; } int main() { unsigned a = 1; unsigned i = { 0 }; for (; i < 20; ++i) { ? printf("%u: %u %x\n", i, a, a); ? a = multu32(a, 62); } return 0; } jbook2:p248 jay$ gcc 1.c jbook2:p248 jay$ ./a.out 0: 1 1 1: 62 3e 2: 3844 f04 3: 238328 3a2f8 4: 14776336 e17810 5: 916132832 369b13e0 overflow 916132832 * 62; 369b13e0 * 3e ?- Jay From dragisha at m3w.org Sat Sep 25 13:41:19 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Sep 2010 13:41:19 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? Message-ID: <1285414879.3024.0.camel@boromir.m3w.org> Anybody working UI's with Trestle? It is mapped no native widgets on Windows? What about Mac? -- Dragi?a Duri? From jay.krell at cornell.edu Sat Sep 25 14:31:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Sep 2010 12:31:18 +0000 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: <1285414879.3024.0.camel@boromir.m3w.org> References: <1285414879.3024.0.camel@boromir.m3w.org> Message-ID: It draws all the controls itself. The Mac version is the X Windows version. ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sat, 25 Sep 2010 13:41:19 +0200 > Subject: [M3devel] UI, Trestle, native... Cocoa?? > > Anybody working UI's with Trestle? It is mapped no native widgets on > Windows? What about Mac? > -- > Dragi?a Duri? > From hosking at cs.purdue.edu Sat Sep 25 16:32:21 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 25 Sep 2010 10:32:21 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: Message-ID: <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> Is it ok in the WIn32 implementation for the thread to be native. I think it is ok for pthread. On 25 Sep 2010, at 05:35, Jay K wrote: > > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > (* LL = m *) > VAR self := GetActivation(); > BEGIN > IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > XWait(m, c, self, alertable := TRUE); > END AlertWait; > > > The pthread code doesn't have the check for NIL and call to Die. > Nor for that matter, the uses of ThreadDebug -- which I added. > > I think these should be more similar. > > What I was really wondering about, again, is more common code between Win32 and Posix > in the thread code... > > - Jay > From dragisha at m3w.org Sat Sep 25 22:42:07 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Sep 2010 22:42:07 +0200 Subject: [M3devel] UI, Trestle, native... Cocoa?? In-Reply-To: References: <1285414879.3024.0.camel@boromir.m3w.org> Message-ID: <1285447327.3009.0.camel@boromir.m3w.org> Is it feasible to make it mora native to Mac? Interesting? On Sat, 2010-09-25 at 12:31 +0000, Jay K wrote: > It draws all the controls itself. > The Mac version is the X Windows version. > > - Jay > > ---------------------------------------- > > From: dragisha at m3w.org > > To: m3devel at elegosoft.com > > Date: Sat, 25 Sep 2010 13:41:19 +0200 > > Subject: [M3devel] UI, Trestle, native... Cocoa?? > > > > Anybody working UI's with Trestle? It is mapped no native widgets on > > Windows? What about Mac? > > -- > > Dragi?a Duri? > > > -- Dragi?a Duri? From dragisha at m3w.org Sun Sep 26 13:45:53 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sun, 26 Sep 2010 13:45:53 +0200 Subject: [M3devel] windows devel, howto? Message-ID: <1285501553.3009.2.camel@boromir.m3w.org> I see msvc 9.0 is requirement, but MS offers only latest and greatest 2010? Can someone spare few moments to coach me to Win Modula-3? :) TIA -- Dragi?a Duri? From jay.krell at cornell.edu Sun Sep 26 14:11:49 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 12:11:49 +0000 Subject: [M3devel] windows devel, howto? In-Reply-To: <1285501553.3009.2.camel@boromir.m3w.org> References: <1285501553.3009.2.camel@boromir.m3w.org> Message-ID: We don't require any particular version. I have tested with many, almost every single version from 2.0 though 9.0. 2008 is still available. http://www.microsoft.com/express/Downloads/ ?besides www.ebay.com And ./boot1.py has "special" support for Windows -- you can build a useful cross archive from Posix or whatever and then compiler the C and link on Windows. It even produces a nice little Makefile for Windows. ?- Jay ---------------------------------------- > From: dragisha at m3w.org > To: m3devel at elegosoft.com > Date: Sun, 26 Sep 2010 13:45:53 +0200 > Subject: [M3devel] windows devel, howto? > > I see msvc 9.0 is requirement, but MS offers only latest and greatest > 2010? > > Can someone spare few moments to coach me to Win Modula-3? :) > > TIA > -- > Dragi?a Duri? > From jay.krell at cornell.edu Sun Sep 26 14:21:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 12:21:51 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> References: , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> Message-ID: I think it is problematic in both. If I understand you. The thread locals could be allocated on-demand which might address some situations. Though that can also fail. A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). ? That even allows you to fail (due to low memory). However that doesn't work as well as one might hope. In particular, any number of threads can be created before a particular .dll is loaded. And a .dll can be unloaded while the threads still exist -- making also thread detach not so ideal for freeing. What you have to do is: ? - be willing to allocate on demand? ? - have some story for failure ? - track all the thread locals through a global (!) and free them in thread/process detach ?? (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; ?? there is a parameter that distinguishes them; best to do nothing, quickly in ?? the ExitProcess). Best really really really really best to avoid thread locals. But that is probably impossible. Cygwin does wacky stuff where it puts its thread locals at the top of the stack. Which doesn't solve the problems. ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sat, 25 Sep 2010 10:32:21 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > Is it ok in the WIn32 implementation for the thread to be native. > I think it is ok for pthread. > > On 25 Sep 2010, at 05:35, Jay K wrote: > > > > > PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > > (* LL = m *) > > VAR self := GetActivation(); > > BEGIN > > IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > > IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > > XWait(m, c, self, alertable := TRUE); > > END AlertWait; > > > > > > The pthread code doesn't have the check for NIL and call to Die. > > Nor for that matter, the uses of ThreadDebug -- which I added. > > > > I think these should be more similar. > > > > What I was really wondering about, again, is more common code between Win32 and Posix > > in the thread code... > > > > - Jay > > > From hosking at cs.purdue.edu Sun Sep 26 15:13:09 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Sep 2010 09:13:09 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu> Message-ID: <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? On 26 Sep 2010, at 08:21, Jay K wrote: > > I think it is problematic in both. > If I understand you. > > > The thread locals could be allocated on-demand which might > address some situations. Though that can also fail. > > > A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > That even allows you to fail (due to low memory). > However that doesn't work as well as one might hope. > In particular, any number of threads can be created before a particular .dll is loaded. > And a .dll can be unloaded while the threads still exist -- making also thread detach > not so ideal for freeing. What you have to do is: > - be willing to allocate on demand > - have some story for failure > - track all the thread locals through a global (!) and free them in thread/process detach > (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > there is a parameter that distinguishes them; best to do nothing, quickly in > the ExitProcess). > > > Best really really really really best to avoid thread locals. > But that is probably impossible. > > > Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > Which doesn't solve the problems. > > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sat, 25 Sep 2010 10:32:21 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >> >> Is it ok in the WIn32 implementation for the thread to be native. >> I think it is ok for pthread. >> >> On 25 Sep 2010, at 05:35, Jay K wrote: >> >>> >>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = >>> (* LL = m *) >>> VAR self := GetActivation(); >>> BEGIN >>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; >>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; >>> XWait(m, c, self, alertable := TRUE); >>> END AlertWait; >>> >>> >>> The pthread code doesn't have the check for NIL and call to Die. >>> Nor for that matter, the uses of ThreadDebug -- which I added. >>> >>> I think these should be more similar. >>> >>> What I was really wondering about, again, is more common code between Win32 and Posix >>> in the thread code... >>> >>> - Jay >>> >> > From jay.krell at cornell.edu Sun Sep 26 15:51:22 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Sep 2010 13:51:22 +0000 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> References: , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> Message-ID: What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? ?- Jay ---------------------------------------- > From: hosking at cs.purdue.edu > Date: Sun, 26 Sep 2010 09:13:09 -0400 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > > Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? > > On 26 Sep 2010, at 08:21, Jay K wrote: > > > > > I think it is problematic in both. > > If I understand you. > > > > > > The thread locals could be allocated on-demand which might > > address some situations. Though that can also fail. > > > > > > A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). > > That even allows you to fail (due to low memory). > > However that doesn't work as well as one might hope. > > In particular, any number of threads can be created before a particular .dll is loaded. > > And a .dll can be unloaded while the threads still exist -- making also thread detach > > not so ideal for freeing. What you have to do is: > > - be willing to allocate on demand > > - have some story for failure > > - track all the thread locals through a global (!) and free them in thread/process detach > > (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; > > there is a parameter that distinguishes them; best to do nothing, quickly in > > the ExitProcess). > > > > > > Best really really really really best to avoid thread locals. > > But that is probably impossible. > > > > > > Cygwin does wacky stuff where it puts its thread locals at the top of the stack. > > Which doesn't solve the problems. > > > > > > - Jay > > > > ---------------------------------------- > >> From: hosking at cs.purdue.edu > >> Date: Sat, 25 Sep 2010 10:32:21 -0400 > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix > >> > >> Is it ok in the WIn32 implementation for the thread to be native. > >> I think it is ok for pthread. > >> > >> On 25 Sep 2010, at 05:35, Jay K wrote: > >> > >>> > >>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = > >>> (* LL = m *) > >>> VAR self := GetActivation(); > >>> BEGIN > >>> IF DEBUG THEN ThreadDebug.AlertWait(m, c); END; > >>> IF self = NIL THEN Die(ThisLine(), "AlertWait called from non-Modula-3 thread") END; > >>> XWait(m, c, self, alertable := TRUE); > >>> END AlertWait; > >>> > >>> > >>> The pthread code doesn't have the check for NIL and call to Die. > >>> Nor for that matter, the uses of ThreadDebug -- which I added. > >>> > >>> I think these should be more similar. > >>> > >>> What I was really wondering about, again, is more common code between Win32 and Posix > >>> in the thread code... > >>> > >>> - Jay > >>> > >> > > > From hosking at cs.purdue.edu Sun Sep 26 15:56:29 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Sep 2010 09:56:29 -0400 Subject: [M3devel] thread calls on non-modula3 threads, win32 vs. posix In-Reply-To: References: , , <2D10BE95-A5A3-46CD-ABE0-71EBEC1678C9@cs.purdue.edu>, , <75D42A60-DD6A-4499-AC01-83A01ADD61BB@cs.purdue.edu> Message-ID: <8EFC2130-1893-4F1D-BC73-C42EB57CE89C@cs.purdue.edu> In general that would be dangerous. If it is a thread not created by Modula-3 Thread.Fork then how will we have the machinery to stop it for GC so its roots can be scanned. In principle, native threads are untraced, whereas M3 threads are traced. Untraced things are not allowed to refer to traced things. On 26 Sep 2010, at 09:51, Jay K wrote: > > What is supposed to happen if you call into Modula-3 code on a non-Modula-3 thread? > > - Jay > > ---------------------------------------- >> From: hosking at cs.purdue.edu >> Date: Sun, 26 Sep 2010 09:13:09 -0400 >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >> >> Why does a native thread need M3-supported thread locals? The idea is to keep native and M3 threads separate, right? >> >> On 26 Sep 2010, at 08:21, Jay K wrote: >> >>> >>> I think it is problematic in both. >>> If I understand you. >>> >>> >>> The thread locals could be allocated on-demand which might >>> address some situations. Though that can also fail. >>> >>> >>> A reasonable seeming place to allocate thread locals is m3core.DllMain(thread attach). >>> That even allows you to fail (due to low memory). >>> However that doesn't work as well as one might hope. >>> In particular, any number of threads can be created before a particular .dll is loaded. >>> And a .dll can be unloaded while the threads still exist -- making also thread detach >>> not so ideal for freeing. What you have to do is: >>> - be willing to allocate on demand >>> - have some story for failure >>> - track all the thread locals through a global (!) and free them in thread/process detach >>> (but note that there are two .dll unload scenarios: FreeLibrary and ExitProcess; >>> there is a parameter that distinguishes them; best to do nothing, quickly in >>> the ExitProcess). >>> >>> >>> Best really really really really best to avoid thread locals. >>> But that is probably impossible. >>> >>> >>> Cygwin does wacky stuff where it puts its thread locals at the top of the stack. >>> Which doesn't solve the problems. >>> >>> >>> - Jay >>> >>> ---------------------------------------- >>>> From: hosking at cs.purdue.edu >>>> Date: Sat, 25 Sep 2010 10:32:21 -0400 >>>> To: jay.krell at cornell.edu >>>> CC: m3devel at elegosoft.com >>>> Subject: Re: [M3devel] thread calls on non-modula3 threads, win32 vs. posix >>>> >>>> Is it ok in the WIn32 implementation for the thread to be native. >>>> I think it is ok for pthread. >>>> >>>> On 25 Sep 2010, at 05:35, Jay K wrote: >>>> >>>>> >>>>> PROCEDURE AlertWait (m: Mutex; c: Condition) RAISES {Alerted} = >>>>> (* LL = m *) >>>>> VAR self := GetActivation(); >>>>> BEGIN >>>>>