From dragisha at m3w.org Wed Jan 18 15:10:31 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 18 Jan 2012 15:10:31 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= Message-ID: As per subject? I would like to pack this: TSPacketHeader = RECORD sync: BITS 8 FOR File.Byte; (* Always 0x47 *) tErrInd, (* Transport Error Indicator *) pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) transPrio: BITS 1 FOR [0..1]; pid: BITS 13 FOR PID; transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) cc: BITS 4 FOR Nibble; END; My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. What I get is: 0000 1010 1000 0001 0101 0100 last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; first eight bits of pid four bits of cc; two bits of abc; two bits for transScramControl a mess. with pid being most special sort of it :). Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? TIA, dd From rodney_bates at lcwb.coop Wed Jan 18 20:54:03 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 18 Jan 2012 13:54:03 -0600 Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: <4F17235B.2000808@lcwb.coop> On 01/18/2012 08:10 AM, Dragi?a Duri? wrote: > As per subject? I would like to pack this: > > TSPacketHeader = RECORD > sync: BITS 8 FOR File.Byte; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > > My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. > > What I get is: > > 0000 1010 1000 0001 0101 0100 > > last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; > first eight bits of pid > four bits of cc; two bits of abc; two bits for transScramControl > > a mess. with pid being most special sort of it :). > > Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? > > TIA, > dd > > Hmm, this smells very strongly of a little-endian problem. You didn't say how you got the actual bit contents you give. It has only 24 bits, though the record has 32. Here is a possible explanation. 1) The packed record is laid out in little-endian, i.e. right-to-left. 2) The value you give is byte 1, byte 2, byte 3 of the word, numbering bytes right-to-left, as in little endian. This interpretation correctly predicts your actual value. The language doesn't say anything about endianness or order of field layout in a record with packed fields, in the section on packed types. However, I think I recall there are other places where the language specifically calls for little-endian numbering, regardless of the actual target machine. I don't remember where right off hand. It may be that the actual rule is to do it the way the target machine numbers things. The apparent assumption is that packed records are unavoidably target-dependent in other ways anyway. I agree this example is a mess, but I think the mess is mostly inherited from the mess that so-called "little endian" is. It's inconsistent. R2L within the bits of a native machine word, L2R between words of an array or record, L2R when there are arrays of bytes, L2R in machine code, L2R in byte-oriented I/O operations. Then we have deeper mixups, e.g. an array of 16-bit elements. I guess we at least need to document what the compiler actually does. From jay.krell at cornell.edu Thu Jan 19 05:28:30 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Jan 2012 04:28:30 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: > packing data into record about packing bits left-right-until-spent? It is not portable. In particular, there is endianness variation. The C spec leaves things up to implementation. If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. (Maybe still a few, like struct linger). - Jay > From: dragisha at m3w.org > Date: Wed, 18 Jan 2012 15:10:31 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] packing problem? how exactly does modula-3 pack data into records?? > > As per subject? I would like to pack this: > > TSPacketHeader = RECORD > sync: BITS 8 FOR File.Byte; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > > My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. > > What I get is: > > 0000 1010 1000 0001 0101 0100 > > last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; > first eight bits of pid > four bits of cc; two bits of abc; two bits for transScramControl > > a mess. with pid being most special sort of it :). > > Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Jan 19 18:47:39 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Jan 2012 18:47:39 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Why wouldn't it be portable? What endiannes has to do with bit strings? I don't think it is wrong to make it left-to-right-until-spent? As it's implementation dependent? ok? Why would not our implementation be left-to-?.? :) I think it's totally reasonable to expect from implementation exactly what I am expecting here and now. As for C? I know several ways to implement this? And good ones. What I would like is to have cm3 doing it in obvious, intuitive way. TIA On Jan 19, 2012, at 5:28 AM, Jay K wrote: > > packing data into record about packing bits left-right-until-spent? > > It is not portable. > In particular, there is endianness variation. > The C spec leaves things up to implementation. > > If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. > Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. > (Maybe still a few, like struct linger). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 19 23:42:47 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Jan 2012 22:42:47 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Message-ID: I believe our layout endeavors to be C compatible. For some supposedly typical C behavior. It is, I am pretty certain, endian-dependent. I would like to remove that actually -- the frontend at this point knows very little about each target, and I'd like to see if it can know even less. It knows: word size endianness jmpbuf size not much more. jmpbuf size I know we can remove, but I had trouble when tried to fix that, about a year ago. I've had much less time to work on Modula-3 the past year or so. :( (then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) I know it's a little wierd what I say -- C is impelementation-dependent and we try to be C compatible. And m3core/libm3 used to have some dependency on this C compatibility, e.g. the waitpid stuff. But I believe I removed all such dependency. - Jay From: dragisha at m3w.org Date: Thu, 19 Jan 2012 18:47:39 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? Why wouldn't it be portable? What endiannes has to do with bit strings? I don't think it is wrong to make it left-to-right-until-spent? As it's implementation dependent? ok? Why would not our implementation be left-to-?.? :) I think it's totally reasonable to expect from implementation exactly what I am expecting here and now. As for C? I know several ways to implement this? And good ones. What I would like is to have cm3 doing it in obvious, intuitive way. TIA On Jan 19, 2012, at 5:28 AM, Jay K wrote: > packing data into record about packing bits left-right-until-spent? It is not portable. In particular, there is endianness variation. The C spec leaves things up to implementation. If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. (Maybe still a few, like struct linger). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Jan 19 23:51:34 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Jan 2012 23:51:34 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Message-ID: back in 1997-8 I did an LINUXALPHA port of pm3. All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine). So, speaking about C and portability... No such thing. Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :) On Jan 19, 2012, at 11:42 PM, Jay K wrote: > (then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) > > > I know it's a little wierd what I say -- C is impelementation-dependent and we try > to be C compatible. And m3core/libm3 used to have some dependency > on this C compatibility, e.g. the waitpid stuff. But I believe I removed all > such dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 20 02:18:26 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Jan 2012 01:18:26 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , Message-ID: The cross-wordsize problem of gcc was indeed lame, but it is long since gone. Gcc has an almost-great cross-build story. Ld has a good cross-build story. Though it doesn't support as many systems as gcc. The problem is getting headers and libraries. I've been trying to a build ia64-linux toolset from source but I haven't gotten glibc/linux-headers to work out. Producing .S and .o from .c (w/o #include) is easy enough. On Windows, cross-compilers are now also common, a lot of the tools are x86-hosted despite targeting AMD64, IA64, and more (Windows CE: PowerPC, MIPS, ARM, SH.) Though I think NT/MIPS, NT/PowerPC, NT/Alpha had only native compilers released -- presumably there were cross compilers at least for bootstrapping. Anyway, if you just conserving space, then "BITS FOR" should work fine. If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific. I think besides endianness, there is another factor, where cm3 tries to be C-compatible. Like, how aligned bitfields need to be. I only recently learned the rules for NT bitfields. First, aside, in C, bitfields can only be int or unsigned. In Microsoft C however, they can be any integer type. The layout rules are affected by the type. I think the rules are that the type of the bitfield determines the alignment of the loads/stores to access it. That is: struct { unsigned char a; unsigned char b:1; } vs. struct { unsigned char a; unsigned int b:1 } In the first case, b is at byte offset 1. In the second case, it is at byte offset 4. I don't remember what order the bits are allocated within bytes. Anyway, it isn't portable stuff. I used to like bitfields for compactness. Lately I disfavor them, because I like to be able to predict the layout of a struct. Still, they can be useful: 1) again, compactness 2) lining up with some external definition, esp. hardware (e.g. page tables) 3) ability to do stuff like: union { unsigned AsInt; struct { unsigned a : 1; unsigned b : 1; unsigned c : 1; } s; } u; You can test AsInt for non-zeroness to see if any of a/b/c are set. That can be useful. Though, if layout-predictability is important, I'd just do one of: struct { unsigned char a, b, c; unsigned char any; } and require setters of a/b/c to set any, or struct { unsigned char a,b,c; } require checking a || b || c. Problem is -- when d is added, have to update all the uses. Then again..C++ struct { unsigned char a,b,c; bool Any() { return a || b || c; } } only one place to update. Anyway... - Jay From: dragisha at m3w.org Date: Thu, 19 Jan 2012 23:51:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? back in 1997-8 I did an LINUXALPHA port of pm3. All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine). So, speaking about C and portability... No such thing. Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :) On Jan 19, 2012, at 11:42 PM, Jay K wrote:(then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) I know it's a little wierd what I say -- C is impelementation-dependent and we try to be C compatible. And m3core/libm3 used to have some dependency on this C compatibility, e.g. the waitpid stuff. But I believe I removed all such dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 08:29:47 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 08:29:47 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , Message-ID: <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> I am not using packing to interface with C or to be compact. My code is directly producing packets for some network protocol. No C in sight :). And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? On Jan 20, 2012, at 2:18 AM, Jay K wrote: > Anyway, if you just conserving space, then "BITS FOR" should work fine. > If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific. > I think besides endianness, there is another factor, where cm3 tries to be C-compatible. > Like, how aligned bitfields need to be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 13:02:51 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 13:02:51 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> Message-ID: <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> TYPE (* This is how it should be written... If only cm3 packed left-to-right-until-spent. todo for me. TSPacketHeader = RECORD sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) tErrInd, (* Transport Error Indicator *) pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) transPrio: BITS 1 FOR [0..1]; pid: BITS 13 FOR PID; transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) cc: BITS 4 FOR Nibble; END; *) TSPacketHeader = RECORD sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) pidHi: BITS 5 FOR [16_00..16_1f]; transPrio: BITS 1 FOR [0..1]; pusi, tErrInd: BITS 1 FOR BOOLEAN; pidLo: BITS 8 FOR [16_00..16_ff]; cc: BITS 4 FOR Nibble; afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) END; With additional methods for getPid() and setPid(), this works as expected. But I _really_ think we should have continuous bit fields in cases where it spans byte boundary and combined with how other pieces of this work now - it means we need left to right packing of bit strings into bytes, not right to left as it is done now on my x86_64 box. This is probably some endianess relict, but I also think endiannes has nothing to do with us once we decide to go bit strings. I don't see a big problem to implement this in such a way right now. Especially since at this moment nobody is having any expectations from implementation (except me O:) ) - we won't break anything. TIA, dd On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > I am not using packing to interface with C or to be compact. > > My code is directly producing packets for some network protocol. No C in sight :). > > And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. > > I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? From wagner at elegosoft.com Fri Jan 20 14:28:42 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Jan 2012 14:28:42 +0100 Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? Message-ID: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> Ups, this has almost been lost in my email folders... I'm just forwarding now to m3devel. ----- Forwarded message from estellnb at gmail.com ----- Date: Sat, 17 Dec 2011 17:50:42 +0100 From: Elmar Stellnberger Reply-To: Elmar Stellnberger Subject: m3gcc: RTL or GIMPLE based? To: m3-support at elego.de How does m3gcc base on the GCC? Does it base on RTL or on GIMPLE-trees? ----- 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 jay.krell at cornell.edu Fri Jan 20 19:11:07 2012 From: jay.krell at cornell.edu (Jay) Date: Fri, 20 Jan 2012 10:11:07 -0800 Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> References: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> Message-ID: As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) On Jan 20, 2012, at 4:02 AM, Dragi?a Duri? wrote: > TYPE > (* This is how it should be written... If only cm3 packed left-to-right-until-spent. todo for me. > > TSPacketHeader = RECORD > sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > *) > > TSPacketHeader = RECORD > sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) > > pidHi: BITS 5 FOR [16_00..16_1f]; > transPrio: BITS 1 FOR [0..1]; > pusi, > tErrInd: BITS 1 FOR BOOLEAN; > > pidLo: BITS 8 FOR [16_00..16_ff]; > > cc: BITS 4 FOR Nibble; > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > END; > > With additional methods for getPid() and setPid(), this works as expected. > > But I _really_ think we should have continuous bit fields in cases where it spans byte boundary and combined with how other pieces of this work now - it means we need left to right packing of bit strings into bytes, not right to left as it is done now on my x86_64 box. This is probably some endianess relict, but I also think endiannes has nothing to do with us once we decide to go bit strings. > > I don't see a big problem to implement this in such a way right now. Especially since at this moment nobody is having any expectations from implementation (except me O:) ) - we won't break anything. > > TIA, > dd > > On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > >> I am not using packing to interface with C or to be compact. >> >> My code is directly producing packets for some network protocol. No C in sight :). >> >> And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. >> >> I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? > From dabenavidesd at yahoo.es Fri Jan 20 19:43:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Jan 2012 18:43:25 +0000 (GMT) Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: Message-ID: <1327085005.94940.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: in fact I think the main issue is the Assumption that everywhere there is C, which is just as wrong, as their claim "C is portable", what we need is but with other Wirth languages, more than the Outside world claims C is the best language ever I'm convinced this is to say "whether C is not better than others we don't care as we don't know neither". Is just outside ignorance. If hackers were rather worried about their safety they wouldn't be using C as an application programming language is clear. That said, look what is done in Linux since there isn't much security in its driver base, which is the "most precious treasure of Gnu/Linux hackers" they just don't know when a driver will just bring the system absolutely down. (And yet they criticize Modula-3 RT exception of bringing down the system, yet SPIN changed that) That said, Gnu/Linux has been proposed a real API of safe drivers, but basically it means all drivers should be written in a type safe language. My problem is not against C, as many others I don't hate it, I really like it, but for real systems programming I do much prefer Modula-3. C isn't the issue here, if you can prove the system is well typed, there isn't much to discuss, but if not, what are we doing with that (we don't what this programs can do BTW). I do prefer Gnu/Linux platform of development but "I can't trusty this machines" some dear Friend of this community said. Thanks in advance --- El vie, 20/1/12, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" > Para: "Dragi?a Duri?" > CC: "m3devel" , "Jay K" > Fecha: viernes, 20 de enero, 2012 13:11 > As in C, if you need portability and > predictability, just don't use bitfields. Use integer types > of size 8, 16, 32, or possibly 64 bits, and do the > appropriate shifting and masking, possibly > endian-dependent. > > > Actually, to avoid endian and packing/alignment concerns, > use only 8 bit integers and optionally pack/unpack into more > convenient types. > > > - Jay (phone) > > On Jan 20, 2012, at 4:02 AM, Dragi?a Duri? > wrote: > > > TYPE > > (* This is how it should be written... If only > cm3 packed left-to-right-until-spent. todo for me. > > > > TSPacketHeader = RECORD > > sync: BITS 8 FOR > [16_0..16_ff]; (* Always 0x47 *) > > tErrInd, > (* > Transport Error Indicator *) > > pusi: BITS 1 FOR BOOLEAN; > (* Payload Unit Start Indicator *) > > transPrio: BITS 1 FOR [0..1]; > > pid: BITS 13 FOR PID; > > transScramControl: BITS 2 FOR [0..3]; (* > 00 means no scrambling *) > > afc: BITS 2 FOR [0..3]; (* 01 - no > adaptation field, payload only *) > > cc: BITS 4 FOR Nibble; > > END; > > *) > > > > TSPacketHeader = RECORD > > sync: BITS 8 FOR > [16_0..16_ff]; (* Always 0x47 *) > > > > pidHi: BITS 5 FOR [16_00..16_1f]; > > transPrio: BITS 1 FOR [0..1]; > > pusi, > > tErrInd: BITS 1 FOR BOOLEAN; > > > > pidLo: BITS 8 FOR [16_00..16_ff]; > > > > cc: BITS 4 FOR Nibble; > > afc: BITS 2 FOR [0..3]; (* 01 - no > adaptation field, payload only *) > > transScramControl: BITS 2 FOR [0..3]; (* > 00 means no scrambling *) > > END; > > > > With additional methods for getPid() and setPid(), > this works as expected. > > > > But I _really_ think we should have continuous bit > fields in cases where it spans byte boundary and combined > with how other pieces of this work now - it means we need > left to right packing of bit strings into bytes, not right > to left as it is done now on my x86_64 box. This is probably > some endianess relict, but I also think endiannes has > nothing to do with us once we decide to go bit strings. > > > > I don't see a big problem to implement this in such a > way right now. Especially since at this moment nobody is > having any expectations from implementation (except me O:) ) > - we won't break anything. > > > > TIA, > > dd > > > > On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > > > >> I am not using packing to interface with C or to > be compact. > >> > >> My code is directly producing packets for some > network protocol. No C in sight :). > >> > >> And, as probably all those pesky :) network > protocols around? Order of bytes and (expected) order of > bits is - left to right. > >> > >> I really do not understand why this is something > hard to accept as standard (or at least cm3) way for > bit packing? > > > From jay.krell at cornell.edu Sat Jan 21 00:05:46 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Jan 2012 23:05:46 +0000 Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? In-Reply-To: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> References: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> Message-ID: Neither. "tree" is the answer. It is obvious from the code. See: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c - Jay > Date: Fri, 20 Jan 2012 14:28:42 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? > > Ups, this has almost been lost in my email folders... > I'm just forwarding now to m3devel. > > ----- Forwarded message from estellnb at gmail.com ----- > Date: Sat, 17 Dec 2011 17:50:42 +0100 > From: Elmar Stellnberger > Reply-To: Elmar Stellnberger > Subject: m3gcc: RTL or GIMPLE based? > To: m3-support at elego.de > > How does m3gcc base on the GCC? > Does it base on RTL or on GIMPLE-trees? > > > ----- 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 22:59:34 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 22:59:34 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: References: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> Message-ID: <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> Ok, it is your standpoint. I don't share it. Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote: > As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. > > > Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. > > > - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 22 10:31:53 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Jan 2012 10:31:53 +0100 Subject: [M3devel] m3front does not compile Message-ID: <20120122103153.0rxpt4dee8goco40@mail.elegosoft.com> The current m3front package is not compilable, see for example http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/571/console The reason seems to be a mix between the latest release code, where a traced parameter has been added, and fixes that have been merged to the main line. It would be great if somebody could fix that. 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 Thu Jan 26 06:46:08 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Jan 2012 05:46:08 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , , , <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org>, <14CC8397-2A21-438E-953D-E0788511E717@m3w.org>, , <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> Message-ID: Let's say we have something defined by hardware, I'm making this up, and we have a C header already for it: typedef struct x86_pte /* fictional page table entry */ { unsigned valid : 1; unsigned execute : 1; unsigned writable : 1; unsigned physical_page : 29; } x86_pte; and I want to interface with this hardware from Modula-3. What do I do? ?Find the documenation, let's say it goes like: ? x86_pte_valid 0x80000000 x86_pte_executable 0x40000000 x86_pte_writable 0x20000000 ?Translate that into Modula-3. Do I write: x86_pte = BITS 32 FOR RECORD valid: BITS 1 FOR BOOLEAN; executable: BITS 1 FOR BOOLEAN; writable: BITS 1 FOR BOOLEAN; physical_page: BITS 29 FOR [0...16_1FFFFFFF]; END; or do I write: x86_pte = BITS 32 FOR RECORD physical_page: BITS 29 FOR [0...16_1FFFFFFF]; writable: BITS 1 FOR BOOLEAN; executable: BITS 1 FOR BOOLEAN; valid: BITS 1 FOR BOOLEAN; END; ?or do I write something else (maybe physical_page isn't unpacked properly) ?or do I write something unambiguous but possibly slow: x86_pte_opaque = RECORD: opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255]; END; PROCEDURE Valid(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_80) # 0; END Valid; PROCEDURE Writable(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_40) # 0; END Writable; PROCEDURE Executable(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_20) # 0; END Executable; PROCEDURE PhysicalPage(pte: x86_pte): CARDINAL = BEGIN RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8), pte.opaque[3]); (* approx *) END PhysicalPage; Or maybe: RECORD UnpackedPTE = RECORD Valid, Executable, Writable: BOOLEAN; Page: CARDINAL; END; filled in by the above functions and then accessed directly? But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system. I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above. This allows for easier transliteration of /usr/include into m3core/unix. However it does not allow for the "simulator scenario" -- where the host's C compiler is different than the one that interprets the C struct I showed. Nor does it allow well for what you want to do -- portability across machines. C programmers face the same dilemna. Know that their compiler is somehow sane and predictable and use nice/convenient bitfields, or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually. Where C programmers depend on bitfields, and where Modula-3 transliterates C headers, it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior. I have gone and removed m3core's dependency on this. Again, I believe that was the original authors' intent. Clearly there are pluses and minuses to the various approaches. If you look at the GNU binutils, I think they do stuff like: struct packed_foo { unsigned char foo[2]; unsigned char bar[4]; unsigned char abc[8]; |; struct unpacked_foo { unsigned short foo; unsigned long bar; unsigned long long abc; }; void unpack_foo(packed_foo* packed, unpacked_foo* unpacked) { unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo)); } void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size) { unsigned long long value = { 0 }; size_t i = { 0 }; assert(unpacked_size >= packed_size); for (i = 0; < packed_size) value = (value << 8) | packed[i]; if (unpacked_size == 1) *(unsigned char*)unpacked = (unsigned char)value; else if (unpacked_size == sizeof(unsigned short)) *(unsigned short*)unpacked = (unsigned short)value; else if (unpacked_size == sizeof(unsigned long)) *(unsigned long*)unpacked = (unsigned long)value; else if (unpacked_size == sizeof(unsigned long long)) *(unsigned long long*)unpacked = (unsigned long long)value; else assert(false); } This has the cost/tedium of copying, but it is very portable, while still letting the compiler do a little of the layout for you. If you are defining your own protocol, I think the opaque/unpacking strategy is safest, albeit slowest and most tedious. You could also be wasteful and not use bitfields in your protocol. - Jay From: dragisha at m3w.org Date: Fri, 20 Jan 2012 22:59:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Ok, it is your standpoint. I don't share it. Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote:As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Jan 26 15:38:45 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Jan 2012 14:38:45 +0000 (GMT) Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: Message-ID: <1327588725.26977.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi Jay: Pretty much is good question that you are asking. I believe mostly the guys in SPIN did pretty much what you suggest, using the Multiflow C compiler for dynamic event dispatching optimization: http://oldwww.cs.pitt.edu/~mock/papers/wcsss96.pdf and AVOCA x-kernel subsystem using C but with Modula-3 keywords (so there was an abstract specification, e.g INTERFACE) and its implementation in C with Modula-3 idiom, p.77 with a Graph Description Language: http://arizona.openrepository.com/arizona/bitstream/10150/185158/1/azu_td_9103022_sip1_m.pdf Hope it helps. Thanks in advance. --- El jue, 26/1/12, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Para: dragisha at m3w.org CC: "m3devel" Fecha: jueves, 26 de enero, 2012 00:46 Let's say we have something defined by hardware, I'm making this up, and we have a C header already for it: ? typedef struct x86_pte /* fictional page table entry */? ? {? ??? unsigned valid : 1;? ??? unsigned execute : 1;? ??? unsigned writable : 1;? ??? unsigned physical_page : 29;? ? } x86_pte;? ? ? ? and I want to interface with this hardware from Modula-3.? ? What do I do?? ? ?Find the documenation, let's say it goes like:? ? ? ???? x86_pte_valid 0x80000000??? ??? x86_pte_executable 0x40000000? ??? x86_pte_writable 0x20000000? ? ?Translate that into Modula-3.? ? Do I write:? ? x86_pte = BITS 32 FOR RECORD? ??? valid: BITS 1 FOR BOOLEAN;? ??? executable: BITS 1 FOR BOOLEAN;? ??? writable: BITS 1 FOR BOOLEAN;? ??? physical_page: BITS 29 FOR [0...16_1FFFFFFF];? ? END; or do I write: ? x86_pte = BITS 32 FOR RECORD??? ??? physical_page: BITS 29 FOR [0...16_1FFFFFFF];? ??? writable: BITS 1 FOR BOOLEAN;? ??? executable: BITS 1 FOR BOOLEAN;? ??? valid: BITS 1 FOR BOOLEAN;? ? END;? ?or do I write something else (maybe physical_page isn't unpacked properly) ??or do I write something unambiguous but possibly slow:? ? x86_pte_opaque = RECORD:? ??? opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255]; ? END; ? PROCEDURE Valid(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_80) # 0;? ? END Valid;? ? PROCEDURE Writable(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_40) # 0;? ? END Writable;? ? PROCEDURE Executable(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_20) # 0;? ? END Executable;? ?PROCEDURE PhysicalPage(pte: x86_pte):? CARDINAL =? ? BEGIN? ??? RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8),???? pte.opaque[3]); (* approx *)?? ? END PhysicalPage;? Or maybe: RECORD UnpackedPTE = RECORD ? Valid, Executable, Writable: BOOLEAN; ? Page: CARDINAL; END; filled in by the above functions and then accessed directly? ? But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system.? I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above. This allows for easier transliteration of /usr/include into m3core/unix. ? However it does not allow for the "simulator scenario" -- where the host's C compiler is ? different than the one that interprets the C struct I showed. ? Nor does it allow well for what you want to do -- portability across machines.? C programmers face the same dilemna. Know that their compiler is somehow sane and predictable and use nice/convenient bitfields, or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually. Where C programmers depend on bitfields, and where Modula-3 transliterates C headers, it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior. I have gone and removed m3core's dependency on this. Again, I believe that was the original authors' intent. Clearly there are pluses and minuses to the various approaches. If you look at the GNU binutils, I think they do stuff like: struct packed_foo { ? unsigned char foo[2]; ? unsigned char bar[4]; ? unsigned char abc[8]; |; struct unpacked_foo { ? unsigned short foo; ? unsigned long bar; ? unsigned long long abc; }; void unpack_foo(packed_foo* packed, unpacked_foo* unpacked) { ? unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo)); } void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size) { ? unsigned long long value = { 0 };? ? size_t i = { 0 };? ? assert(unpacked_size >= packed_size);?? ? for (i = 0; < packed_size)? ??? value = (value << 8) | packed[i];? ? if (unpacked_size == 1)? ?? ? *(unsigned char*)unpacked = (unsigned char)value;??? ? else if (unpacked_size == sizeof(unsigned short))?? ?? ? *(unsigned short*)unpacked = (unsigned short)value;??? ? else if (unpacked_size == sizeof(unsigned long))??? ?? ? *(unsigned long*)unpacked = (unsigned long)value;??? ? else if (unpacked_size == sizeof(unsigned long long))??? ?? ? *(unsigned long long*)unpacked = (unsigned long long)value;??? ? else ??? assert(false);? } This has the cost/tedium of copying, but it is very portable, while still letting the compiler do a little of the layout for you. ? If you are defining your own protocol, I think the opaque/unpacking strategy is safest, albeit slowest and most tedious. You could also be wasteful and not use bitfields in your protocol. ?- Jay From: dragisha at m3w.org Date: Fri, 20 Jan 2012 22:59:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Ok, it is your standpoint. I don't share it.? Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote: As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jan 30 12:14:19 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 30 Jan 2012 12:14:19 +0100 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Message-ID: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An embedded message was scrubbed... From: Dariusz =?UTF-8?B?S25vY2nFhHNraQ==?= Subject: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Date: Fri, 27 Jan 2012 18:57:29 +0100 Size: 3937 URL: From wagner at elegosoft.com Mon Jan 30 12:15:44 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 30 Jan 2012 12:15:44 +0100 Subject: [M3devel] Fwd: Quick Access to someone who knows the CM3 and Reactor environments ... Message-ID: <20120130121544.36996wl0ovel5yow@mail.elegosoft.com> Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An embedded message was scrubbed... From: Louis Jordaan Subject: Quick Access to someone who knows the CM3 and Reactor environments ... Date: Mon, 30 Jan 2012 12:24:11 +0200 Size: 17769 URL: From dabenavidesd at yahoo.es Mon Jan 30 13:32:13 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 30 Jan 2012 12:32:13 +0000 (GMT) Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: <1327926733.93585.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi Dariusz: Would you mind just try to void to build cm3 from the bootstrap image and make it with the rpm package for your distro (assuming it's FC16 AMD64, right?), please: http://pkgs.org/download/cm3 There is anything wrong with your installation attempt, just that is better try to build a first bootstrap image of your own and then proceed as you might prefer. Thanks in advance --- El lun, 30/1/12, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem > Para: m3devel at elegosoft.com > Fecha: lunes, 30 de enero, 2012 06:14 > Sorry, I'm busy with private matters > currently, so I'm forwarding > your request to m3devel. > > 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 > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging > Program. > From jay.krell at cornell.edu Tue Jan 31 03:21:56 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Jan 2012 02:21:56 +0000 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: > $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > *** cannot find package import-libs / m3-win/import-libs You don't have the full source tree.Among m3-sys, m3-tools, m3-ui, etc., you are missing m3-win.If there is an "all" archive, try it? - Jay Date: Mon, 30 Jan 2012 12:14:19 +0100 From: wagner at elegosoft.com To: m3devel at elegosoft.com Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --Forwarded Message Attachment-- Date: Fri, 27 Jan 2012 18:57:29 +0100 From: dknoto at gmail.com To: m3-support at elego.de Subject: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Dears, I have tried compile latest CM3 snapshot d5.9.0-2011-11-19-02-40-49 on my system "Linux wenus.*.pl 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux". I have installed CM3 compiler version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-08-09 02:51:03 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX. I unpacked the source in directory cm3 by commands (I found it on yours website): $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz and then i did it: $ cd scripts $ ./do-cm3-core.sh buildship /home/dknoto/Projekty/CM3-5.9.0-devel-1/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel-1' $RARGS && cm3 -ship $RARGS -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel-1' " import-libs m3cc m3core libm3 windowsResources parseparams patternmatching sysutils unittest m3middle m3cggen m3objfile m3linker m3back m3front m3quake cm3 m3scanner m3tools m3bundle mklib tempfiles bitvector digraph realgeometry set slisp sortedtableextras table-list tcp cm3ide mtex m3sleep *** cannot find package import-libs / m3-win/import-libs Have you any idea? Best regards -- Dariusz Knoci?ski -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Jan 18 15:10:31 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 18 Jan 2012 15:10:31 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= Message-ID: As per subject? I would like to pack this: TSPacketHeader = RECORD sync: BITS 8 FOR File.Byte; (* Always 0x47 *) tErrInd, (* Transport Error Indicator *) pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) transPrio: BITS 1 FOR [0..1]; pid: BITS 13 FOR PID; transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) cc: BITS 4 FOR Nibble; END; My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. What I get is: 0000 1010 1000 0001 0101 0100 last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; first eight bits of pid four bits of cc; two bits of abc; two bits for transScramControl a mess. with pid being most special sort of it :). Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? TIA, dd From rodney_bates at lcwb.coop Wed Jan 18 20:54:03 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 18 Jan 2012 13:54:03 -0600 Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: <4F17235B.2000808@lcwb.coop> On 01/18/2012 08:10 AM, Dragi?a Duri? wrote: > As per subject? I would like to pack this: > > TSPacketHeader = RECORD > sync: BITS 8 FOR File.Byte; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > > My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. > > What I get is: > > 0000 1010 1000 0001 0101 0100 > > last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; > first eight bits of pid > four bits of cc; two bits of abc; two bits for transScramControl > > a mess. with pid being most special sort of it :). > > Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? > > TIA, > dd > > Hmm, this smells very strongly of a little-endian problem. You didn't say how you got the actual bit contents you give. It has only 24 bits, though the record has 32. Here is a possible explanation. 1) The packed record is laid out in little-endian, i.e. right-to-left. 2) The value you give is byte 1, byte 2, byte 3 of the word, numbering bytes right-to-left, as in little endian. This interpretation correctly predicts your actual value. The language doesn't say anything about endianness or order of field layout in a record with packed fields, in the section on packed types. However, I think I recall there are other places where the language specifically calls for little-endian numbering, regardless of the actual target machine. I don't remember where right off hand. It may be that the actual rule is to do it the way the target machine numbers things. The apparent assumption is that packed records are unavoidably target-dependent in other ways anyway. I agree this example is a mess, but I think the mess is mostly inherited from the mess that so-called "little endian" is. It's inconsistent. R2L within the bits of a native machine word, L2R between words of an array or record, L2R when there are arrays of bytes, L2R in machine code, L2R in byte-oriented I/O operations. Then we have deeper mixups, e.g. an array of 16-bit elements. I guess we at least need to document what the compiler actually does. From jay.krell at cornell.edu Thu Jan 19 05:28:30 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Jan 2012 04:28:30 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: > packing data into record about packing bits left-right-until-spent? It is not portable. In particular, there is endianness variation. The C spec leaves things up to implementation. If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. (Maybe still a few, like struct linger). - Jay > From: dragisha at m3w.org > Date: Wed, 18 Jan 2012 15:10:31 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] packing problem? how exactly does modula-3 pack data into records?? > > As per subject? I would like to pack this: > > TSPacketHeader = RECORD > sync: BITS 8 FOR File.Byte; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > > My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. > > What I get is: > > 0000 1010 1000 0001 0101 0100 > > last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; > first eight bits of pid > four bits of cc; two bits of abc; two bits for transScramControl > > a mess. with pid being most special sort of it :). > > Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Jan 19 18:47:39 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Jan 2012 18:47:39 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Why wouldn't it be portable? What endiannes has to do with bit strings? I don't think it is wrong to make it left-to-right-until-spent? As it's implementation dependent? ok? Why would not our implementation be left-to-?.? :) I think it's totally reasonable to expect from implementation exactly what I am expecting here and now. As for C? I know several ways to implement this? And good ones. What I would like is to have cm3 doing it in obvious, intuitive way. TIA On Jan 19, 2012, at 5:28 AM, Jay K wrote: > > packing data into record about packing bits left-right-until-spent? > > It is not portable. > In particular, there is endianness variation. > The C spec leaves things up to implementation. > > If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. > Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. > (Maybe still a few, like struct linger). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 19 23:42:47 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Jan 2012 22:42:47 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Message-ID: I believe our layout endeavors to be C compatible. For some supposedly typical C behavior. It is, I am pretty certain, endian-dependent. I would like to remove that actually -- the frontend at this point knows very little about each target, and I'd like to see if it can know even less. It knows: word size endianness jmpbuf size not much more. jmpbuf size I know we can remove, but I had trouble when tried to fix that, about a year ago. I've had much less time to work on Modula-3 the past year or so. :( (then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) I know it's a little wierd what I say -- C is impelementation-dependent and we try to be C compatible. And m3core/libm3 used to have some dependency on this C compatibility, e.g. the waitpid stuff. But I believe I removed all such dependency. - Jay From: dragisha at m3w.org Date: Thu, 19 Jan 2012 18:47:39 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? Why wouldn't it be portable? What endiannes has to do with bit strings? I don't think it is wrong to make it left-to-right-until-spent? As it's implementation dependent? ok? Why would not our implementation be left-to-?.? :) I think it's totally reasonable to expect from implementation exactly what I am expecting here and now. As for C? I know several ways to implement this? And good ones. What I would like is to have cm3 doing it in obvious, intuitive way. TIA On Jan 19, 2012, at 5:28 AM, Jay K wrote: > packing data into record about packing bits left-right-until-spent? It is not portable. In particular, there is endianness variation. The C spec leaves things up to implementation. If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. (Maybe still a few, like struct linger). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Jan 19 23:51:34 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Jan 2012 23:51:34 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Message-ID: back in 1997-8 I did an LINUXALPHA port of pm3. All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine). So, speaking about C and portability... No such thing. Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :) On Jan 19, 2012, at 11:42 PM, Jay K wrote: > (then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) > > > I know it's a little wierd what I say -- C is impelementation-dependent and we try > to be C compatible. And m3core/libm3 used to have some dependency > on this C compatibility, e.g. the waitpid stuff. But I believe I removed all > such dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 20 02:18:26 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Jan 2012 01:18:26 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , Message-ID: The cross-wordsize problem of gcc was indeed lame, but it is long since gone. Gcc has an almost-great cross-build story. Ld has a good cross-build story. Though it doesn't support as many systems as gcc. The problem is getting headers and libraries. I've been trying to a build ia64-linux toolset from source but I haven't gotten glibc/linux-headers to work out. Producing .S and .o from .c (w/o #include) is easy enough. On Windows, cross-compilers are now also common, a lot of the tools are x86-hosted despite targeting AMD64, IA64, and more (Windows CE: PowerPC, MIPS, ARM, SH.) Though I think NT/MIPS, NT/PowerPC, NT/Alpha had only native compilers released -- presumably there were cross compilers at least for bootstrapping. Anyway, if you just conserving space, then "BITS FOR" should work fine. If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific. I think besides endianness, there is another factor, where cm3 tries to be C-compatible. Like, how aligned bitfields need to be. I only recently learned the rules for NT bitfields. First, aside, in C, bitfields can only be int or unsigned. In Microsoft C however, they can be any integer type. The layout rules are affected by the type. I think the rules are that the type of the bitfield determines the alignment of the loads/stores to access it. That is: struct { unsigned char a; unsigned char b:1; } vs. struct { unsigned char a; unsigned int b:1 } In the first case, b is at byte offset 1. In the second case, it is at byte offset 4. I don't remember what order the bits are allocated within bytes. Anyway, it isn't portable stuff. I used to like bitfields for compactness. Lately I disfavor them, because I like to be able to predict the layout of a struct. Still, they can be useful: 1) again, compactness 2) lining up with some external definition, esp. hardware (e.g. page tables) 3) ability to do stuff like: union { unsigned AsInt; struct { unsigned a : 1; unsigned b : 1; unsigned c : 1; } s; } u; You can test AsInt for non-zeroness to see if any of a/b/c are set. That can be useful. Though, if layout-predictability is important, I'd just do one of: struct { unsigned char a, b, c; unsigned char any; } and require setters of a/b/c to set any, or struct { unsigned char a,b,c; } require checking a || b || c. Problem is -- when d is added, have to update all the uses. Then again..C++ struct { unsigned char a,b,c; bool Any() { return a || b || c; } } only one place to update. Anyway... - Jay From: dragisha at m3w.org Date: Thu, 19 Jan 2012 23:51:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? back in 1997-8 I did an LINUXALPHA port of pm3. All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine). So, speaking about C and portability... No such thing. Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :) On Jan 19, 2012, at 11:42 PM, Jay K wrote:(then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) I know it's a little wierd what I say -- C is impelementation-dependent and we try to be C compatible. And m3core/libm3 used to have some dependency on this C compatibility, e.g. the waitpid stuff. But I believe I removed all such dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 08:29:47 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 08:29:47 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , Message-ID: <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> I am not using packing to interface with C or to be compact. My code is directly producing packets for some network protocol. No C in sight :). And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? On Jan 20, 2012, at 2:18 AM, Jay K wrote: > Anyway, if you just conserving space, then "BITS FOR" should work fine. > If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific. > I think besides endianness, there is another factor, where cm3 tries to be C-compatible. > Like, how aligned bitfields need to be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 13:02:51 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 13:02:51 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> Message-ID: <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> TYPE (* This is how it should be written... If only cm3 packed left-to-right-until-spent. todo for me. TSPacketHeader = RECORD sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) tErrInd, (* Transport Error Indicator *) pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) transPrio: BITS 1 FOR [0..1]; pid: BITS 13 FOR PID; transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) cc: BITS 4 FOR Nibble; END; *) TSPacketHeader = RECORD sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) pidHi: BITS 5 FOR [16_00..16_1f]; transPrio: BITS 1 FOR [0..1]; pusi, tErrInd: BITS 1 FOR BOOLEAN; pidLo: BITS 8 FOR [16_00..16_ff]; cc: BITS 4 FOR Nibble; afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) END; With additional methods for getPid() and setPid(), this works as expected. But I _really_ think we should have continuous bit fields in cases where it spans byte boundary and combined with how other pieces of this work now - it means we need left to right packing of bit strings into bytes, not right to left as it is done now on my x86_64 box. This is probably some endianess relict, but I also think endiannes has nothing to do with us once we decide to go bit strings. I don't see a big problem to implement this in such a way right now. Especially since at this moment nobody is having any expectations from implementation (except me O:) ) - we won't break anything. TIA, dd On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > I am not using packing to interface with C or to be compact. > > My code is directly producing packets for some network protocol. No C in sight :). > > And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. > > I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? From wagner at elegosoft.com Fri Jan 20 14:28:42 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Jan 2012 14:28:42 +0100 Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? Message-ID: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> Ups, this has almost been lost in my email folders... I'm just forwarding now to m3devel. ----- Forwarded message from estellnb at gmail.com ----- Date: Sat, 17 Dec 2011 17:50:42 +0100 From: Elmar Stellnberger Reply-To: Elmar Stellnberger Subject: m3gcc: RTL or GIMPLE based? To: m3-support at elego.de How does m3gcc base on the GCC? Does it base on RTL or on GIMPLE-trees? ----- 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 jay.krell at cornell.edu Fri Jan 20 19:11:07 2012 From: jay.krell at cornell.edu (Jay) Date: Fri, 20 Jan 2012 10:11:07 -0800 Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> References: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> Message-ID: As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) On Jan 20, 2012, at 4:02 AM, Dragi?a Duri? wrote: > TYPE > (* This is how it should be written... If only cm3 packed left-to-right-until-spent. todo for me. > > TSPacketHeader = RECORD > sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > *) > > TSPacketHeader = RECORD > sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) > > pidHi: BITS 5 FOR [16_00..16_1f]; > transPrio: BITS 1 FOR [0..1]; > pusi, > tErrInd: BITS 1 FOR BOOLEAN; > > pidLo: BITS 8 FOR [16_00..16_ff]; > > cc: BITS 4 FOR Nibble; > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > END; > > With additional methods for getPid() and setPid(), this works as expected. > > But I _really_ think we should have continuous bit fields in cases where it spans byte boundary and combined with how other pieces of this work now - it means we need left to right packing of bit strings into bytes, not right to left as it is done now on my x86_64 box. This is probably some endianess relict, but I also think endiannes has nothing to do with us once we decide to go bit strings. > > I don't see a big problem to implement this in such a way right now. Especially since at this moment nobody is having any expectations from implementation (except me O:) ) - we won't break anything. > > TIA, > dd > > On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > >> I am not using packing to interface with C or to be compact. >> >> My code is directly producing packets for some network protocol. No C in sight :). >> >> And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. >> >> I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? > From dabenavidesd at yahoo.es Fri Jan 20 19:43:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Jan 2012 18:43:25 +0000 (GMT) Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: Message-ID: <1327085005.94940.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: in fact I think the main issue is the Assumption that everywhere there is C, which is just as wrong, as their claim "C is portable", what we need is but with other Wirth languages, more than the Outside world claims C is the best language ever I'm convinced this is to say "whether C is not better than others we don't care as we don't know neither". Is just outside ignorance. If hackers were rather worried about their safety they wouldn't be using C as an application programming language is clear. That said, look what is done in Linux since there isn't much security in its driver base, which is the "most precious treasure of Gnu/Linux hackers" they just don't know when a driver will just bring the system absolutely down. (And yet they criticize Modula-3 RT exception of bringing down the system, yet SPIN changed that) That said, Gnu/Linux has been proposed a real API of safe drivers, but basically it means all drivers should be written in a type safe language. My problem is not against C, as many others I don't hate it, I really like it, but for real systems programming I do much prefer Modula-3. C isn't the issue here, if you can prove the system is well typed, there isn't much to discuss, but if not, what are we doing with that (we don't what this programs can do BTW). I do prefer Gnu/Linux platform of development but "I can't trusty this machines" some dear Friend of this community said. Thanks in advance --- El vie, 20/1/12, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" > Para: "Dragi?a Duri?" > CC: "m3devel" , "Jay K" > Fecha: viernes, 20 de enero, 2012 13:11 > As in C, if you need portability and > predictability, just don't use bitfields. Use integer types > of size 8, 16, 32, or possibly 64 bits, and do the > appropriate shifting and masking, possibly > endian-dependent. > > > Actually, to avoid endian and packing/alignment concerns, > use only 8 bit integers and optionally pack/unpack into more > convenient types. > > > - Jay (phone) > > On Jan 20, 2012, at 4:02 AM, Dragi?a Duri? > wrote: > > > TYPE > > (* This is how it should be written... If only > cm3 packed left-to-right-until-spent. todo for me. > > > > TSPacketHeader = RECORD > > sync: BITS 8 FOR > [16_0..16_ff]; (* Always 0x47 *) > > tErrInd, > (* > Transport Error Indicator *) > > pusi: BITS 1 FOR BOOLEAN; > (* Payload Unit Start Indicator *) > > transPrio: BITS 1 FOR [0..1]; > > pid: BITS 13 FOR PID; > > transScramControl: BITS 2 FOR [0..3]; (* > 00 means no scrambling *) > > afc: BITS 2 FOR [0..3]; (* 01 - no > adaptation field, payload only *) > > cc: BITS 4 FOR Nibble; > > END; > > *) > > > > TSPacketHeader = RECORD > > sync: BITS 8 FOR > [16_0..16_ff]; (* Always 0x47 *) > > > > pidHi: BITS 5 FOR [16_00..16_1f]; > > transPrio: BITS 1 FOR [0..1]; > > pusi, > > tErrInd: BITS 1 FOR BOOLEAN; > > > > pidLo: BITS 8 FOR [16_00..16_ff]; > > > > cc: BITS 4 FOR Nibble; > > afc: BITS 2 FOR [0..3]; (* 01 - no > adaptation field, payload only *) > > transScramControl: BITS 2 FOR [0..3]; (* > 00 means no scrambling *) > > END; > > > > With additional methods for getPid() and setPid(), > this works as expected. > > > > But I _really_ think we should have continuous bit > fields in cases where it spans byte boundary and combined > with how other pieces of this work now - it means we need > left to right packing of bit strings into bytes, not right > to left as it is done now on my x86_64 box. This is probably > some endianess relict, but I also think endiannes has > nothing to do with us once we decide to go bit strings. > > > > I don't see a big problem to implement this in such a > way right now. Especially since at this moment nobody is > having any expectations from implementation (except me O:) ) > - we won't break anything. > > > > TIA, > > dd > > > > On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > > > >> I am not using packing to interface with C or to > be compact. > >> > >> My code is directly producing packets for some > network protocol. No C in sight :). > >> > >> And, as probably all those pesky :) network > protocols around? Order of bytes and (expected) order of > bits is - left to right. > >> > >> I really do not understand why this is something > hard to accept as standard (or at least cm3) way for > bit packing? > > > From jay.krell at cornell.edu Sat Jan 21 00:05:46 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Jan 2012 23:05:46 +0000 Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? In-Reply-To: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> References: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> Message-ID: Neither. "tree" is the answer. It is obvious from the code. See: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c - Jay > Date: Fri, 20 Jan 2012 14:28:42 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? > > Ups, this has almost been lost in my email folders... > I'm just forwarding now to m3devel. > > ----- Forwarded message from estellnb at gmail.com ----- > Date: Sat, 17 Dec 2011 17:50:42 +0100 > From: Elmar Stellnberger > Reply-To: Elmar Stellnberger > Subject: m3gcc: RTL or GIMPLE based? > To: m3-support at elego.de > > How does m3gcc base on the GCC? > Does it base on RTL or on GIMPLE-trees? > > > ----- 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 22:59:34 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 22:59:34 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: References: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> Message-ID: <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> Ok, it is your standpoint. I don't share it. Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote: > As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. > > > Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. > > > - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 22 10:31:53 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Jan 2012 10:31:53 +0100 Subject: [M3devel] m3front does not compile Message-ID: <20120122103153.0rxpt4dee8goco40@mail.elegosoft.com> The current m3front package is not compilable, see for example http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/571/console The reason seems to be a mix between the latest release code, where a traced parameter has been added, and fixes that have been merged to the main line. It would be great if somebody could fix that. 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 Thu Jan 26 06:46:08 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Jan 2012 05:46:08 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , , , <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org>, <14CC8397-2A21-438E-953D-E0788511E717@m3w.org>, , <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> Message-ID: Let's say we have something defined by hardware, I'm making this up, and we have a C header already for it: typedef struct x86_pte /* fictional page table entry */ { unsigned valid : 1; unsigned execute : 1; unsigned writable : 1; unsigned physical_page : 29; } x86_pte; and I want to interface with this hardware from Modula-3. What do I do? ?Find the documenation, let's say it goes like: ? x86_pte_valid 0x80000000 x86_pte_executable 0x40000000 x86_pte_writable 0x20000000 ?Translate that into Modula-3. Do I write: x86_pte = BITS 32 FOR RECORD valid: BITS 1 FOR BOOLEAN; executable: BITS 1 FOR BOOLEAN; writable: BITS 1 FOR BOOLEAN; physical_page: BITS 29 FOR [0...16_1FFFFFFF]; END; or do I write: x86_pte = BITS 32 FOR RECORD physical_page: BITS 29 FOR [0...16_1FFFFFFF]; writable: BITS 1 FOR BOOLEAN; executable: BITS 1 FOR BOOLEAN; valid: BITS 1 FOR BOOLEAN; END; ?or do I write something else (maybe physical_page isn't unpacked properly) ?or do I write something unambiguous but possibly slow: x86_pte_opaque = RECORD: opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255]; END; PROCEDURE Valid(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_80) # 0; END Valid; PROCEDURE Writable(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_40) # 0; END Writable; PROCEDURE Executable(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_20) # 0; END Executable; PROCEDURE PhysicalPage(pte: x86_pte): CARDINAL = BEGIN RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8), pte.opaque[3]); (* approx *) END PhysicalPage; Or maybe: RECORD UnpackedPTE = RECORD Valid, Executable, Writable: BOOLEAN; Page: CARDINAL; END; filled in by the above functions and then accessed directly? But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system. I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above. This allows for easier transliteration of /usr/include into m3core/unix. However it does not allow for the "simulator scenario" -- where the host's C compiler is different than the one that interprets the C struct I showed. Nor does it allow well for what you want to do -- portability across machines. C programmers face the same dilemna. Know that their compiler is somehow sane and predictable and use nice/convenient bitfields, or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually. Where C programmers depend on bitfields, and where Modula-3 transliterates C headers, it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior. I have gone and removed m3core's dependency on this. Again, I believe that was the original authors' intent. Clearly there are pluses and minuses to the various approaches. If you look at the GNU binutils, I think they do stuff like: struct packed_foo { unsigned char foo[2]; unsigned char bar[4]; unsigned char abc[8]; |; struct unpacked_foo { unsigned short foo; unsigned long bar; unsigned long long abc; }; void unpack_foo(packed_foo* packed, unpacked_foo* unpacked) { unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo)); } void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size) { unsigned long long value = { 0 }; size_t i = { 0 }; assert(unpacked_size >= packed_size); for (i = 0; < packed_size) value = (value << 8) | packed[i]; if (unpacked_size == 1) *(unsigned char*)unpacked = (unsigned char)value; else if (unpacked_size == sizeof(unsigned short)) *(unsigned short*)unpacked = (unsigned short)value; else if (unpacked_size == sizeof(unsigned long)) *(unsigned long*)unpacked = (unsigned long)value; else if (unpacked_size == sizeof(unsigned long long)) *(unsigned long long*)unpacked = (unsigned long long)value; else assert(false); } This has the cost/tedium of copying, but it is very portable, while still letting the compiler do a little of the layout for you. If you are defining your own protocol, I think the opaque/unpacking strategy is safest, albeit slowest and most tedious. You could also be wasteful and not use bitfields in your protocol. - Jay From: dragisha at m3w.org Date: Fri, 20 Jan 2012 22:59:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Ok, it is your standpoint. I don't share it. Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote:As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Jan 26 15:38:45 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Jan 2012 14:38:45 +0000 (GMT) Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: Message-ID: <1327588725.26977.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi Jay: Pretty much is good question that you are asking. I believe mostly the guys in SPIN did pretty much what you suggest, using the Multiflow C compiler for dynamic event dispatching optimization: http://oldwww.cs.pitt.edu/~mock/papers/wcsss96.pdf and AVOCA x-kernel subsystem using C but with Modula-3 keywords (so there was an abstract specification, e.g INTERFACE) and its implementation in C with Modula-3 idiom, p.77 with a Graph Description Language: http://arizona.openrepository.com/arizona/bitstream/10150/185158/1/azu_td_9103022_sip1_m.pdf Hope it helps. Thanks in advance. --- El jue, 26/1/12, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Para: dragisha at m3w.org CC: "m3devel" Fecha: jueves, 26 de enero, 2012 00:46 Let's say we have something defined by hardware, I'm making this up, and we have a C header already for it: ? typedef struct x86_pte /* fictional page table entry */? ? {? ??? unsigned valid : 1;? ??? unsigned execute : 1;? ??? unsigned writable : 1;? ??? unsigned physical_page : 29;? ? } x86_pte;? ? ? ? and I want to interface with this hardware from Modula-3.? ? What do I do?? ? ?Find the documenation, let's say it goes like:? ? ? ???? x86_pte_valid 0x80000000??? ??? x86_pte_executable 0x40000000? ??? x86_pte_writable 0x20000000? ? ?Translate that into Modula-3.? ? Do I write:? ? x86_pte = BITS 32 FOR RECORD? ??? valid: BITS 1 FOR BOOLEAN;? ??? executable: BITS 1 FOR BOOLEAN;? ??? writable: BITS 1 FOR BOOLEAN;? ??? physical_page: BITS 29 FOR [0...16_1FFFFFFF];? ? END; or do I write: ? x86_pte = BITS 32 FOR RECORD??? ??? physical_page: BITS 29 FOR [0...16_1FFFFFFF];? ??? writable: BITS 1 FOR BOOLEAN;? ??? executable: BITS 1 FOR BOOLEAN;? ??? valid: BITS 1 FOR BOOLEAN;? ? END;? ?or do I write something else (maybe physical_page isn't unpacked properly) ??or do I write something unambiguous but possibly slow:? ? x86_pte_opaque = RECORD:? ??? opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255]; ? END; ? PROCEDURE Valid(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_80) # 0;? ? END Valid;? ? PROCEDURE Writable(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_40) # 0;? ? END Writable;? ? PROCEDURE Executable(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_20) # 0;? ? END Executable;? ?PROCEDURE PhysicalPage(pte: x86_pte):? CARDINAL =? ? BEGIN? ??? RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8),???? pte.opaque[3]); (* approx *)?? ? END PhysicalPage;? Or maybe: RECORD UnpackedPTE = RECORD ? Valid, Executable, Writable: BOOLEAN; ? Page: CARDINAL; END; filled in by the above functions and then accessed directly? ? But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system.? I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above. This allows for easier transliteration of /usr/include into m3core/unix. ? However it does not allow for the "simulator scenario" -- where the host's C compiler is ? different than the one that interprets the C struct I showed. ? Nor does it allow well for what you want to do -- portability across machines.? C programmers face the same dilemna. Know that their compiler is somehow sane and predictable and use nice/convenient bitfields, or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually. Where C programmers depend on bitfields, and where Modula-3 transliterates C headers, it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior. I have gone and removed m3core's dependency on this. Again, I believe that was the original authors' intent. Clearly there are pluses and minuses to the various approaches. If you look at the GNU binutils, I think they do stuff like: struct packed_foo { ? unsigned char foo[2]; ? unsigned char bar[4]; ? unsigned char abc[8]; |; struct unpacked_foo { ? unsigned short foo; ? unsigned long bar; ? unsigned long long abc; }; void unpack_foo(packed_foo* packed, unpacked_foo* unpacked) { ? unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo)); } void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size) { ? unsigned long long value = { 0 };? ? size_t i = { 0 };? ? assert(unpacked_size >= packed_size);?? ? for (i = 0; < packed_size)? ??? value = (value << 8) | packed[i];? ? if (unpacked_size == 1)? ?? ? *(unsigned char*)unpacked = (unsigned char)value;??? ? else if (unpacked_size == sizeof(unsigned short))?? ?? ? *(unsigned short*)unpacked = (unsigned short)value;??? ? else if (unpacked_size == sizeof(unsigned long))??? ?? ? *(unsigned long*)unpacked = (unsigned long)value;??? ? else if (unpacked_size == sizeof(unsigned long long))??? ?? ? *(unsigned long long*)unpacked = (unsigned long long)value;??? ? else ??? assert(false);? } This has the cost/tedium of copying, but it is very portable, while still letting the compiler do a little of the layout for you. ? If you are defining your own protocol, I think the opaque/unpacking strategy is safest, albeit slowest and most tedious. You could also be wasteful and not use bitfields in your protocol. ?- Jay From: dragisha at m3w.org Date: Fri, 20 Jan 2012 22:59:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Ok, it is your standpoint. I don't share it.? Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote: As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jan 30 12:14:19 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 30 Jan 2012 12:14:19 +0100 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Message-ID: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An embedded message was scrubbed... From: Dariusz =?UTF-8?B?S25vY2nFhHNraQ==?= Subject: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Date: Fri, 27 Jan 2012 18:57:29 +0100 Size: 3937 URL: From wagner at elegosoft.com Mon Jan 30 12:15:44 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 30 Jan 2012 12:15:44 +0100 Subject: [M3devel] Fwd: Quick Access to someone who knows the CM3 and Reactor environments ... Message-ID: <20120130121544.36996wl0ovel5yow@mail.elegosoft.com> Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An embedded message was scrubbed... From: Louis Jordaan Subject: Quick Access to someone who knows the CM3 and Reactor environments ... Date: Mon, 30 Jan 2012 12:24:11 +0200 Size: 17769 URL: From dabenavidesd at yahoo.es Mon Jan 30 13:32:13 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 30 Jan 2012 12:32:13 +0000 (GMT) Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: <1327926733.93585.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi Dariusz: Would you mind just try to void to build cm3 from the bootstrap image and make it with the rpm package for your distro (assuming it's FC16 AMD64, right?), please: http://pkgs.org/download/cm3 There is anything wrong with your installation attempt, just that is better try to build a first bootstrap image of your own and then proceed as you might prefer. Thanks in advance --- El lun, 30/1/12, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem > Para: m3devel at elegosoft.com > Fecha: lunes, 30 de enero, 2012 06:14 > Sorry, I'm busy with private matters > currently, so I'm forwarding > your request to m3devel. > > 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 > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging > Program. > From jay.krell at cornell.edu Tue Jan 31 03:21:56 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Jan 2012 02:21:56 +0000 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: > $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > *** cannot find package import-libs / m3-win/import-libs You don't have the full source tree.Among m3-sys, m3-tools, m3-ui, etc., you are missing m3-win.If there is an "all" archive, try it? - Jay Date: Mon, 30 Jan 2012 12:14:19 +0100 From: wagner at elegosoft.com To: m3devel at elegosoft.com Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --Forwarded Message Attachment-- Date: Fri, 27 Jan 2012 18:57:29 +0100 From: dknoto at gmail.com To: m3-support at elego.de Subject: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Dears, I have tried compile latest CM3 snapshot d5.9.0-2011-11-19-02-40-49 on my system "Linux wenus.*.pl 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux". I have installed CM3 compiler version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-08-09 02:51:03 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX. I unpacked the source in directory cm3 by commands (I found it on yours website): $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz and then i did it: $ cd scripts $ ./do-cm3-core.sh buildship /home/dknoto/Projekty/CM3-5.9.0-devel-1/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel-1' $RARGS && cm3 -ship $RARGS -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel-1' " import-libs m3cc m3core libm3 windowsResources parseparams patternmatching sysutils unittest m3middle m3cggen m3objfile m3linker m3back m3front m3quake cm3 m3scanner m3tools m3bundle mklib tempfiles bitvector digraph realgeometry set slisp sortedtableextras table-list tcp cm3ide mtex m3sleep *** cannot find package import-libs / m3-win/import-libs Have you any idea? Best regards -- Dariusz Knoci?ski -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Wed Jan 18 15:10:31 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 18 Jan 2012 15:10:31 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= Message-ID: As per subject? I would like to pack this: TSPacketHeader = RECORD sync: BITS 8 FOR File.Byte; (* Always 0x47 *) tErrInd, (* Transport Error Indicator *) pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) transPrio: BITS 1 FOR [0..1]; pid: BITS 13 FOR PID; transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) cc: BITS 4 FOR Nibble; END; My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. What I get is: 0000 1010 1000 0001 0101 0100 last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; first eight bits of pid four bits of cc; two bits of abc; two bits for transScramControl a mess. with pid being most special sort of it :). Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? TIA, dd From rodney_bates at lcwb.coop Wed Jan 18 20:54:03 2012 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 18 Jan 2012 13:54:03 -0600 Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: <4F17235B.2000808@lcwb.coop> On 01/18/2012 08:10 AM, Dragi?a Duri? wrote: > As per subject? I would like to pack this: > > TSPacketHeader = RECORD > sync: BITS 8 FOR File.Byte; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > > My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. > > What I get is: > > 0000 1010 1000 0001 0101 0100 > > last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; > first eight bits of pid > four bits of cc; two bits of abc; two bits for transScramControl > > a mess. with pid being most special sort of it :). > > Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? > > TIA, > dd > > Hmm, this smells very strongly of a little-endian problem. You didn't say how you got the actual bit contents you give. It has only 24 bits, though the record has 32. Here is a possible explanation. 1) The packed record is laid out in little-endian, i.e. right-to-left. 2) The value you give is byte 1, byte 2, byte 3 of the word, numbering bytes right-to-left, as in little endian. This interpretation correctly predicts your actual value. The language doesn't say anything about endianness or order of field layout in a record with packed fields, in the section on packed types. However, I think I recall there are other places where the language specifically calls for little-endian numbering, regardless of the actual target machine. I don't remember where right off hand. It may be that the actual rule is to do it the way the target machine numbers things. The apparent assumption is that packed records are unavoidably target-dependent in other ways anyway. I agree this example is a mess, but I think the mess is mostly inherited from the mess that so-called "little endian" is. It's inconsistent. R2L within the bits of a native machine word, L2R between words of an array or record, L2R when there are arrays of bytes, L2R in machine code, L2R in byte-oriented I/O operations. Then we have deeper mixups, e.g. an array of 16-bit elements. I guess we at least need to document what the compiler actually does. From jay.krell at cornell.edu Thu Jan 19 05:28:30 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Jan 2012 04:28:30 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: > packing data into record about packing bits left-right-until-spent? It is not portable. In particular, there is endianness variation. The C spec leaves things up to implementation. If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. (Maybe still a few, like struct linger). - Jay > From: dragisha at m3w.org > Date: Wed, 18 Jan 2012 15:10:31 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] packing problem? how exactly does modula-3 pack data into records?? > > As per subject? I would like to pack this: > > TSPacketHeader = RECORD > sync: BITS 8 FOR File.Byte; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > > My data, pusi is TRUE, sync is 0x47, pid is 4129 (0x1021), cc is 5 and afc is 0x1.Rest is zeros. > > What I get is: > > 0000 1010 1000 0001 0101 0100 > > last five bits of pid; one bit for transPrio, one bit for pusi (TRUE), one bit for tErrInd; > first eight bits of pid > four bits of cc; two bits of abc; two bits for transScramControl > > a mess. with pid being most special sort of it :). > > Is this excected/normal? Wasn't whole idea os packing data into record about packing bits left-right-until-spent? > > TIA, > dd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Jan 19 18:47:39 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Jan 2012 18:47:39 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: Message-ID: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Why wouldn't it be portable? What endiannes has to do with bit strings? I don't think it is wrong to make it left-to-right-until-spent? As it's implementation dependent? ok? Why would not our implementation be left-to-?.? :) I think it's totally reasonable to expect from implementation exactly what I am expecting here and now. As for C? I know several ways to implement this? And good ones. What I would like is to have cm3 doing it in obvious, intuitive way. TIA On Jan 19, 2012, at 5:28 AM, Jay K wrote: > > packing data into record about packing bits left-right-until-spent? > > It is not portable. > In particular, there is endianness variation. > The C spec leaves things up to implementation. > > If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. > Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. > (Maybe still a few, like struct linger). -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Jan 19 23:42:47 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 19 Jan 2012 22:42:47 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Message-ID: I believe our layout endeavors to be C compatible. For some supposedly typical C behavior. It is, I am pretty certain, endian-dependent. I would like to remove that actually -- the frontend at this point knows very little about each target, and I'd like to see if it can know even less. It knows: word size endianness jmpbuf size not much more. jmpbuf size I know we can remove, but I had trouble when tried to fix that, about a year ago. I've had much less time to work on Modula-3 the past year or so. :( (then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) I know it's a little wierd what I say -- C is impelementation-dependent and we try to be C compatible. And m3core/libm3 used to have some dependency on this C compatibility, e.g. the waitpid stuff. But I believe I removed all such dependency. - Jay From: dragisha at m3w.org Date: Thu, 19 Jan 2012 18:47:39 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? Why wouldn't it be portable? What endiannes has to do with bit strings? I don't think it is wrong to make it left-to-right-until-spent? As it's implementation dependent? ok? Why would not our implementation be left-to-?.? :) I think it's totally reasonable to expect from implementation exactly what I am expecting here and now. As for C? I know several ways to implement this? And good ones. What I would like is to have cm3 doing it in obvious, intuitive way. TIA On Jan 19, 2012, at 5:28 AM, Jay K wrote: > packing data into record about packing bits left-right-until-spent? It is not portable. In particular, there is endianness variation. The C spec leaves things up to implementation. If you can, I recommend copying the data from C to a more portable less dense Modula-3 representation. Like what is now done throughout m3core/libm3 -- i.e. we don't interface with C at all through bitfields, nor do we try to line up with struct stat or any other struct, roughly speaking. (Maybe still a few, like struct linger). -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Jan 19 23:51:34 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 19 Jan 2012 23:51:34 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> Message-ID: back in 1997-8 I did an LINUXALPHA port of pm3. All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine). So, speaking about C and portability... No such thing. Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :) On Jan 19, 2012, at 11:42 PM, Jay K wrote: > (then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) > > > I know it's a little wierd what I say -- C is impelementation-dependent and we try > to be C compatible. And m3core/libm3 used to have some dependency > on this C compatibility, e.g. the waitpid stuff. But I believe I removed all > such dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Jan 20 02:18:26 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Jan 2012 01:18:26 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , Message-ID: The cross-wordsize problem of gcc was indeed lame, but it is long since gone. Gcc has an almost-great cross-build story. Ld has a good cross-build story. Though it doesn't support as many systems as gcc. The problem is getting headers and libraries. I've been trying to a build ia64-linux toolset from source but I haven't gotten glibc/linux-headers to work out. Producing .S and .o from .c (w/o #include) is easy enough. On Windows, cross-compilers are now also common, a lot of the tools are x86-hosted despite targeting AMD64, IA64, and more (Windows CE: PowerPC, MIPS, ARM, SH.) Though I think NT/MIPS, NT/PowerPC, NT/Alpha had only native compilers released -- presumably there were cross compilers at least for bootstrapping. Anyway, if you just conserving space, then "BITS FOR" should work fine. If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific. I think besides endianness, there is another factor, where cm3 tries to be C-compatible. Like, how aligned bitfields need to be. I only recently learned the rules for NT bitfields. First, aside, in C, bitfields can only be int or unsigned. In Microsoft C however, they can be any integer type. The layout rules are affected by the type. I think the rules are that the type of the bitfield determines the alignment of the loads/stores to access it. That is: struct { unsigned char a; unsigned char b:1; } vs. struct { unsigned char a; unsigned int b:1 } In the first case, b is at byte offset 1. In the second case, it is at byte offset 4. I don't remember what order the bits are allocated within bytes. Anyway, it isn't portable stuff. I used to like bitfields for compactness. Lately I disfavor them, because I like to be able to predict the layout of a struct. Still, they can be useful: 1) again, compactness 2) lining up with some external definition, esp. hardware (e.g. page tables) 3) ability to do stuff like: union { unsigned AsInt; struct { unsigned a : 1; unsigned b : 1; unsigned c : 1; } s; } u; You can test AsInt for non-zeroness to see if any of a/b/c are set. That can be useful. Though, if layout-predictability is important, I'd just do one of: struct { unsigned char a, b, c; unsigned char any; } and require setters of a/b/c to set any, or struct { unsigned char a,b,c; } require checking a || b || c. Problem is -- when d is added, have to update all the uses. Then again..C++ struct { unsigned char a,b,c; bool Any() { return a || b || c; } } only one place to update. Anyway... - Jay From: dragisha at m3w.org Date: Thu, 19 Jan 2012 23:51:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? back in 1997-8 I did an LINUXALPHA port of pm3. All portability problems I met were in C. And biggie was with gcc and its inability (at the moment) to cross compile on 32bit platform for 64bit RISC (lots and lots of registers on target machine). So, speaking about C and portability... No such thing. Your m3core.h work is great, by the way. I do a lot of low level stuff and it helps a lot. Thanks! :) On Jan 19, 2012, at 11:42 PM, Jay K wrote:(then again -- endian-knowledge can be used to make ntohl/htonl highly optimized.) I know it's a little wierd what I say -- C is impelementation-dependent and we try to be C compatible. And m3core/libm3 used to have some dependency on this C compatibility, e.g. the waitpid stuff. But I believe I removed all such dependency. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 08:29:47 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 08:29:47 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F?= In-Reply-To: References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , Message-ID: <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> I am not using packing to interface with C or to be compact. My code is directly producing packets for some network protocol. No C in sight :). And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? On Jan 20, 2012, at 2:18 AM, Jay K wrote: > Anyway, if you just conserving space, then "BITS FOR" should work fine. > If you need to interface with C, and you can't change the C, you should be able to get something to work, but it will possibly be somewhat non-portable, esp. endian-specific. > I think besides endianness, there is another factor, where cm3 tries to be C-compatible. > Like, how aligned bitfields need to be. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 13:02:51 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 13:02:51 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> References: , , , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> Message-ID: <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> TYPE (* This is how it should be written... If only cm3 packed left-to-right-until-spent. todo for me. TSPacketHeader = RECORD sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) tErrInd, (* Transport Error Indicator *) pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) transPrio: BITS 1 FOR [0..1]; pid: BITS 13 FOR PID; transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) cc: BITS 4 FOR Nibble; END; *) TSPacketHeader = RECORD sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) pidHi: BITS 5 FOR [16_00..16_1f]; transPrio: BITS 1 FOR [0..1]; pusi, tErrInd: BITS 1 FOR BOOLEAN; pidLo: BITS 8 FOR [16_00..16_ff]; cc: BITS 4 FOR Nibble; afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) END; With additional methods for getPid() and setPid(), this works as expected. But I _really_ think we should have continuous bit fields in cases where it spans byte boundary and combined with how other pieces of this work now - it means we need left to right packing of bit strings into bytes, not right to left as it is done now on my x86_64 box. This is probably some endianess relict, but I also think endiannes has nothing to do with us once we decide to go bit strings. I don't see a big problem to implement this in such a way right now. Especially since at this moment nobody is having any expectations from implementation (except me O:) ) - we won't break anything. TIA, dd On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > I am not using packing to interface with C or to be compact. > > My code is directly producing packets for some network protocol. No C in sight :). > > And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. > > I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? From wagner at elegosoft.com Fri Jan 20 14:28:42 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Fri, 20 Jan 2012 14:28:42 +0100 Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? Message-ID: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> Ups, this has almost been lost in my email folders... I'm just forwarding now to m3devel. ----- Forwarded message from estellnb at gmail.com ----- Date: Sat, 17 Dec 2011 17:50:42 +0100 From: Elmar Stellnberger Reply-To: Elmar Stellnberger Subject: m3gcc: RTL or GIMPLE based? To: m3-support at elego.de How does m3gcc base on the GCC? Does it base on RTL or on GIMPLE-trees? ----- 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 jay.krell at cornell.edu Fri Jan 20 19:11:07 2012 From: jay.krell at cornell.edu (Jay) Date: Fri, 20 Jan 2012 10:11:07 -0800 Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> References: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> Message-ID: As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) On Jan 20, 2012, at 4:02 AM, Dragi?a Duri? wrote: > TYPE > (* This is how it should be written... If only cm3 packed left-to-right-until-spent. todo for me. > > TSPacketHeader = RECORD > sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) > tErrInd, (* Transport Error Indicator *) > pusi: BITS 1 FOR BOOLEAN; (* Payload Unit Start Indicator *) > transPrio: BITS 1 FOR [0..1]; > pid: BITS 13 FOR PID; > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > cc: BITS 4 FOR Nibble; > END; > *) > > TSPacketHeader = RECORD > sync: BITS 8 FOR [16_0..16_ff]; (* Always 0x47 *) > > pidHi: BITS 5 FOR [16_00..16_1f]; > transPrio: BITS 1 FOR [0..1]; > pusi, > tErrInd: BITS 1 FOR BOOLEAN; > > pidLo: BITS 8 FOR [16_00..16_ff]; > > cc: BITS 4 FOR Nibble; > afc: BITS 2 FOR [0..3]; (* 01 - no adaptation field, payload only *) > transScramControl: BITS 2 FOR [0..3]; (* 00 means no scrambling *) > END; > > With additional methods for getPid() and setPid(), this works as expected. > > But I _really_ think we should have continuous bit fields in cases where it spans byte boundary and combined with how other pieces of this work now - it means we need left to right packing of bit strings into bytes, not right to left as it is done now on my x86_64 box. This is probably some endianess relict, but I also think endiannes has nothing to do with us once we decide to go bit strings. > > I don't see a big problem to implement this in such a way right now. Especially since at this moment nobody is having any expectations from implementation (except me O:) ) - we won't break anything. > > TIA, > dd > > On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > >> I am not using packing to interface with C or to be compact. >> >> My code is directly producing packets for some network protocol. No C in sight :). >> >> And, as probably all those pesky :) network protocols around? Order of bytes and (expected) order of bits is - left to right. >> >> I really do not understand why this is something hard to accept as standard (or at least cm3) way for bit packing? > From dabenavidesd at yahoo.es Fri Jan 20 19:43:25 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 20 Jan 2012 18:43:25 +0000 (GMT) Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: Message-ID: <1327085005.94940.YahooMailClassic@web29703.mail.ird.yahoo.com> Hi all: in fact I think the main issue is the Assumption that everywhere there is C, which is just as wrong, as their claim "C is portable", what we need is but with other Wirth languages, more than the Outside world claims C is the best language ever I'm convinced this is to say "whether C is not better than others we don't care as we don't know neither". Is just outside ignorance. If hackers were rather worried about their safety they wouldn't be using C as an application programming language is clear. That said, look what is done in Linux since there isn't much security in its driver base, which is the "most precious treasure of Gnu/Linux hackers" they just don't know when a driver will just bring the system absolutely down. (And yet they criticize Modula-3 RT exception of bringing down the system, yet SPIN changed that) That said, Gnu/Linux has been proposed a real API of safe drivers, but basically it means all drivers should be written in a type safe language. My problem is not against C, as many others I don't hate it, I really like it, but for real systems programming I do much prefer Modula-3. C isn't the issue here, if you can prove the system is well typed, there isn't much to discuss, but if not, what are we doing with that (we don't what this programs can do BTW). I do prefer Gnu/Linux platform of development but "I can't trusty this machines" some dear Friend of this community said. Thanks in advance --- El vie, 20/1/12, Jay escribi?: > De: Jay > Asunto: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" > Para: "Dragi?a Duri?" > CC: "m3devel" , "Jay K" > Fecha: viernes, 20 de enero, 2012 13:11 > As in C, if you need portability and > predictability, just don't use bitfields. Use integer types > of size 8, 16, 32, or possibly 64 bits, and do the > appropriate shifting and masking, possibly > endian-dependent. > > > Actually, to avoid endian and packing/alignment concerns, > use only 8 bit integers and optionally pack/unpack into more > convenient types. > > > - Jay (phone) > > On Jan 20, 2012, at 4:02 AM, Dragi?a Duri? > wrote: > > > TYPE > > (* This is how it should be written... If only > cm3 packed left-to-right-until-spent. todo for me. > > > > TSPacketHeader = RECORD > > sync: BITS 8 FOR > [16_0..16_ff]; (* Always 0x47 *) > > tErrInd, > (* > Transport Error Indicator *) > > pusi: BITS 1 FOR BOOLEAN; > (* Payload Unit Start Indicator *) > > transPrio: BITS 1 FOR [0..1]; > > pid: BITS 13 FOR PID; > > transScramControl: BITS 2 FOR [0..3]; (* > 00 means no scrambling *) > > afc: BITS 2 FOR [0..3]; (* 01 - no > adaptation field, payload only *) > > cc: BITS 4 FOR Nibble; > > END; > > *) > > > > TSPacketHeader = RECORD > > sync: BITS 8 FOR > [16_0..16_ff]; (* Always 0x47 *) > > > > pidHi: BITS 5 FOR [16_00..16_1f]; > > transPrio: BITS 1 FOR [0..1]; > > pusi, > > tErrInd: BITS 1 FOR BOOLEAN; > > > > pidLo: BITS 8 FOR [16_00..16_ff]; > > > > cc: BITS 4 FOR Nibble; > > afc: BITS 2 FOR [0..3]; (* 01 - no > adaptation field, payload only *) > > transScramControl: BITS 2 FOR [0..3]; (* > 00 means no scrambling *) > > END; > > > > With additional methods for getPid() and setPid(), > this works as expected. > > > > But I _really_ think we should have continuous bit > fields in cases where it spans byte boundary and combined > with how other pieces of this work now - it means we need > left to right packing of bit strings into bytes, not right > to left as it is done now on my x86_64 box. This is probably > some endianess relict, but I also think endiannes has > nothing to do with us once we decide to go bit strings. > > > > I don't see a big problem to implement this in such a > way right now. Especially since at this moment nobody is > having any expectations from implementation (except me O:) ) > - we won't break anything. > > > > TIA, > > dd > > > > On Jan 20, 2012, at 8:29 AM, Dragi?a Duri? wrote: > > > >> I am not using packing to interface with C or to > be compact. > >> > >> My code is directly producing packets for some > network protocol. No C in sight :). > >> > >> And, as probably all those pesky :) network > protocols around? Order of bytes and (expected) order of > bits is - left to right. > >> > >> I really do not understand why this is something > hard to accept as standard (or at least cm3) way for > bit packing? > > > From jay.krell at cornell.edu Sat Jan 21 00:05:46 2012 From: jay.krell at cornell.edu (Jay K) Date: Fri, 20 Jan 2012 23:05:46 +0000 Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? In-Reply-To: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> References: <20120120142842.9e3o4wq4gwgs40ww@mail.elegosoft.com> Message-ID: Neither. "tree" is the answer. It is obvious from the code. See: http://dcvs.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c - Jay > Date: Fri, 20 Jan 2012 14:28:42 +0100 > From: wagner at elegosoft.com > To: m3devel at elegosoft.com > Subject: [M3devel] Fwd: m3gcc: RTL or GIMPLE based? > > Ups, this has almost been lost in my email folders... > I'm just forwarding now to m3devel. > > ----- Forwarded message from estellnb at gmail.com ----- > Date: Sat, 17 Dec 2011 17:50:42 +0100 > From: Elmar Stellnberger > Reply-To: Elmar Stellnberger > Subject: m3gcc: RTL or GIMPLE based? > To: m3-support at elego.de > > How does m3gcc base on the GCC? > Does it base on RTL or on GIMPLE-trees? > > > ----- 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Fri Jan 20 22:59:34 2012 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 20 Jan 2012 22:59:34 +0100 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: References: <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org> <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org> <14CC8397-2A21-438E-953D-E0788511E717@m3w.org> Message-ID: <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> Ok, it is your standpoint. I don't share it. Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote: > As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. > > > Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. > > > - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Sun Jan 22 10:31:53 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Sun, 22 Jan 2012 10:31:53 +0100 Subject: [M3devel] m3front does not compile Message-ID: <20120122103153.0rxpt4dee8goco40@mail.elegosoft.com> The current m3front package is not compilable, see for example http://hudson.modula3.com:8080/job/cm3-current-build-AMD64_FREEBSD/571/console The reason seems to be a mix between the latest release code, where a traced parameter has been added, and fixes that have been merged to the main line. It would be great if somebody could fix that. 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 Thu Jan 26 06:46:08 2012 From: jay.krell at cornell.edu (Jay K) Date: Thu, 26 Jan 2012 05:46:08 +0000 Subject: [M3devel] =?windows-1252?q?packing_problem=85_how_exactly_does_mo?= =?windows-1252?q?dula-3_pack_data_into_records=3F=3F_=85_=22solved=22?= In-Reply-To: <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> References: , , <8A006898-DF0D-42A7-9731-FF164A22CFD1@m3w.org>, , , , <074AF47C-F14D-476D-8756-1197F2D82C9C@m3w.org>, <14CC8397-2A21-438E-953D-E0788511E717@m3w.org>, , <5DA40F77-111B-4781-98A9-CAF5EE7ACD07@m3w.org> Message-ID: Let's say we have something defined by hardware, I'm making this up, and we have a C header already for it: typedef struct x86_pte /* fictional page table entry */ { unsigned valid : 1; unsigned execute : 1; unsigned writable : 1; unsigned physical_page : 29; } x86_pte; and I want to interface with this hardware from Modula-3. What do I do? ?Find the documenation, let's say it goes like: ? x86_pte_valid 0x80000000 x86_pte_executable 0x40000000 x86_pte_writable 0x20000000 ?Translate that into Modula-3. Do I write: x86_pte = BITS 32 FOR RECORD valid: BITS 1 FOR BOOLEAN; executable: BITS 1 FOR BOOLEAN; writable: BITS 1 FOR BOOLEAN; physical_page: BITS 29 FOR [0...16_1FFFFFFF]; END; or do I write: x86_pte = BITS 32 FOR RECORD physical_page: BITS 29 FOR [0...16_1FFFFFFF]; writable: BITS 1 FOR BOOLEAN; executable: BITS 1 FOR BOOLEAN; valid: BITS 1 FOR BOOLEAN; END; ?or do I write something else (maybe physical_page isn't unpacked properly) ?or do I write something unambiguous but possibly slow: x86_pte_opaque = RECORD: opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255]; END; PROCEDURE Valid(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_80) # 0; END Valid; PROCEDURE Writable(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_40) # 0; END Writable; PROCEDURE Executable(pte: x86_pte): BOOLEAN = BEGIN RETURN Word.And(pte.opaque[0], 16_20) # 0; END Executable; PROCEDURE PhysicalPage(pte: x86_pte): CARDINAL = BEGIN RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8), pte.opaque[3]); (* approx *) END PhysicalPage; Or maybe: RECORD UnpackedPTE = RECORD Valid, Executable, Writable: BOOLEAN; Page: CARDINAL; END; filled in by the above functions and then accessed directly? But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system. I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above. This allows for easier transliteration of /usr/include into m3core/unix. However it does not allow for the "simulator scenario" -- where the host's C compiler is different than the one that interprets the C struct I showed. Nor does it allow well for what you want to do -- portability across machines. C programmers face the same dilemna. Know that their compiler is somehow sane and predictable and use nice/convenient bitfields, or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually. Where C programmers depend on bitfields, and where Modula-3 transliterates C headers, it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior. I have gone and removed m3core's dependency on this. Again, I believe that was the original authors' intent. Clearly there are pluses and minuses to the various approaches. If you look at the GNU binutils, I think they do stuff like: struct packed_foo { unsigned char foo[2]; unsigned char bar[4]; unsigned char abc[8]; |; struct unpacked_foo { unsigned short foo; unsigned long bar; unsigned long long abc; }; void unpack_foo(packed_foo* packed, unpacked_foo* unpacked) { unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo)); } void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size) { unsigned long long value = { 0 }; size_t i = { 0 }; assert(unpacked_size >= packed_size); for (i = 0; < packed_size) value = (value << 8) | packed[i]; if (unpacked_size == 1) *(unsigned char*)unpacked = (unsigned char)value; else if (unpacked_size == sizeof(unsigned short)) *(unsigned short*)unpacked = (unsigned short)value; else if (unpacked_size == sizeof(unsigned long)) *(unsigned long*)unpacked = (unsigned long)value; else if (unpacked_size == sizeof(unsigned long long)) *(unsigned long long*)unpacked = (unsigned long long)value; else assert(false); } This has the cost/tedium of copying, but it is very portable, while still letting the compiler do a little of the layout for you. If you are defining your own protocol, I think the opaque/unpacking strategy is safest, albeit slowest and most tedious. You could also be wasteful and not use bitfields in your protocol. - Jay From: dragisha at m3w.org Date: Fri, 20 Jan 2012 22:59:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Ok, it is your standpoint. I don't share it. Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote:As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Jan 26 15:38:45 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 26 Jan 2012 14:38:45 +0000 (GMT) Subject: [M3devel] =?utf-8?q?packing_problem=E2=80=A6_how_exactly_does_mod?= =?utf-8?q?ula-3_pack_data_into_records=3F=3F_=E2=80=A6_=22solved=22?= In-Reply-To: Message-ID: <1327588725.26977.YahooMailClassic@web29702.mail.ird.yahoo.com> Hi Jay: Pretty much is good question that you are asking. I believe mostly the guys in SPIN did pretty much what you suggest, using the Multiflow C compiler for dynamic event dispatching optimization: http://oldwww.cs.pitt.edu/~mock/papers/wcsss96.pdf and AVOCA x-kernel subsystem using C but with Modula-3 keywords (so there was an abstract specification, e.g INTERFACE) and its implementation in C with Modula-3 idiom, p.77 with a Graph Description Language: http://arizona.openrepository.com/arizona/bitstream/10150/185158/1/azu_td_9103022_sip1_m.pdf Hope it helps. Thanks in advance. --- El jue, 26/1/12, Jay K escribi?: De: Jay K Asunto: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Para: dragisha at m3w.org CC: "m3devel" Fecha: jueves, 26 de enero, 2012 00:46 Let's say we have something defined by hardware, I'm making this up, and we have a C header already for it: ? typedef struct x86_pte /* fictional page table entry */? ? {? ??? unsigned valid : 1;? ??? unsigned execute : 1;? ??? unsigned writable : 1;? ??? unsigned physical_page : 29;? ? } x86_pte;? ? ? ? and I want to interface with this hardware from Modula-3.? ? What do I do?? ? ?Find the documenation, let's say it goes like:? ? ? ???? x86_pte_valid 0x80000000??? ??? x86_pte_executable 0x40000000? ??? x86_pte_writable 0x20000000? ? ?Translate that into Modula-3.? ? Do I write:? ? x86_pte = BITS 32 FOR RECORD? ??? valid: BITS 1 FOR BOOLEAN;? ??? executable: BITS 1 FOR BOOLEAN;? ??? writable: BITS 1 FOR BOOLEAN;? ??? physical_page: BITS 29 FOR [0...16_1FFFFFFF];? ? END; or do I write: ? x86_pte = BITS 32 FOR RECORD??? ??? physical_page: BITS 29 FOR [0...16_1FFFFFFF];? ??? writable: BITS 1 FOR BOOLEAN;? ??? executable: BITS 1 FOR BOOLEAN;? ??? valid: BITS 1 FOR BOOLEAN;? ? END;? ?or do I write something else (maybe physical_page isn't unpacked properly) ??or do I write something unambiguous but possibly slow:? ? x86_pte_opaque = RECORD:? ??? opaque: BITS 32 FOR ARRAY OF BITS 8 FOR [0..255]; ? END; ? PROCEDURE Valid(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_80) # 0;? ? END Valid;? ? PROCEDURE Writable(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_40) # 0;? ? END Writable;? ? PROCEDURE Executable(pte: x86_pte):? BOOLEAN =? ? BEGIN? ??? RETURN Word.And(pte.opaque[0], 16_20) # 0;? ? END Executable;? ?PROCEDURE PhysicalPage(pte: x86_pte):? CARDINAL =? ? BEGIN? ??? RETURN Word.Or(Word.Or(Word.Or(Word.LeftShift(Word.And(pte.opaque[0], 16_1F), 24), Word.LeftShift(pte.opaque[1], 16)), Word.LeftShift(pte.opaque[2], 8),???? pte.opaque[3]); (* approx *)?? ? END PhysicalPage;? Or maybe: RECORD UnpackedPTE = RECORD ? Valid, Executable, Writable: BOOLEAN; ? Page: CARDINAL; END; filled in by the above functions and then accessed directly? ? But I also want to write some sort of simulator -- i.e. I'm not necessarily running on a little endian system.? I believe the original authors desired a "straight" translation from C headers -- the first Modula-3 version above. This allows for easier transliteration of /usr/include into m3core/unix. ? However it does not allow for the "simulator scenario" -- where the host's C compiler is ? different than the one that interprets the C struct I showed. ? Nor does it allow well for what you want to do -- portability across machines.? C programmers face the same dilemna. Know that their compiler is somehow sane and predictable and use nice/convenient bitfields, or take no dependency on the unspecified bitfield behavior and unpack bits/bytes manually. Where C programmers depend on bitfields, and where Modula-3 transliterates C headers, it is profitable for Modula-3 to try to emulate the platform's C compiler's behavior. I have gone and removed m3core's dependency on this. Again, I believe that was the original authors' intent. Clearly there are pluses and minuses to the various approaches. If you look at the GNU binutils, I think they do stuff like: struct packed_foo { ? unsigned char foo[2]; ? unsigned char bar[4]; ? unsigned char abc[8]; |; struct unpacked_foo { ? unsigned short foo; ? unsigned long bar; ? unsigned long long abc; }; void unpack_foo(packed_foo* packed, unpacked_foo* unpacked) { ? unpack_little_endian(packed->foo, sizeof(packed->foo), &unpacked->foo, sizeof(&unpacked->foo)); } void unpack_little_endian(unsigned char* packed, size_t packed_size, void* unpacked, size_t unpacked_size) { ? unsigned long long value = { 0 };? ? size_t i = { 0 };? ? assert(unpacked_size >= packed_size);?? ? for (i = 0; < packed_size)? ??? value = (value << 8) | packed[i];? ? if (unpacked_size == 1)? ?? ? *(unsigned char*)unpacked = (unsigned char)value;??? ? else if (unpacked_size == sizeof(unsigned short))?? ?? ? *(unsigned short*)unpacked = (unsigned short)value;??? ? else if (unpacked_size == sizeof(unsigned long))??? ?? ? *(unsigned long*)unpacked = (unsigned long)value;??? ? else if (unpacked_size == sizeof(unsigned long long))??? ?? ? *(unsigned long long*)unpacked = (unsigned long long)value;??? ? else ??? assert(false);? } This has the cost/tedium of copying, but it is very portable, while still letting the compiler do a little of the layout for you. ? If you are defining your own protocol, I think the opaque/unpacking strategy is safest, albeit slowest and most tedious. You could also be wasteful and not use bitfields in your protocol. ?- Jay From: dragisha at m3w.org Date: Fri, 20 Jan 2012 22:59:34 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] packing problem? how exactly does modula-3 pack data into records?? ? "solved" Ok, it is your standpoint. I don't share it.? Right now my problem is solved. If I encounter its variation again, I'l fix it for myself. Excuse "C does it too" does not ring too Modulee for me :). dd On Jan 20, 2012, at 7:11 PM, Jay wrote: As in C, if you need portability and predictability, just don't use bitfields. Use integer types of size 8, 16, 32, or possibly 64 bits, and do the appropriate shifting and masking, possibly endian-dependent. Actually, to avoid endian and packing/alignment concerns, use only 8 bit integers and optionally pack/unpack into more convenient types. - Jay (phone) -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Mon Jan 30 12:14:19 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 30 Jan 2012 12:14:19 +0100 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Message-ID: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An embedded message was scrubbed... From: Dariusz =?UTF-8?B?S25vY2nFhHNraQ==?= Subject: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Date: Fri, 27 Jan 2012 18:57:29 +0100 Size: 3937 URL: From wagner at elegosoft.com Mon Jan 30 12:15:44 2012 From: wagner at elegosoft.com (Olaf Wagner) Date: Mon, 30 Jan 2012 12:15:44 +0100 Subject: [M3devel] Fwd: Quick Access to someone who knows the CM3 and Reactor environments ... Message-ID: <20120130121544.36996wl0ovel5yow@mail.elegosoft.com> Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------- next part -------------- An embedded message was scrubbed... From: Louis Jordaan Subject: Quick Access to someone who knows the CM3 and Reactor environments ... Date: Mon, 30 Jan 2012 12:24:11 +0200 Size: 17769 URL: From dabenavidesd at yahoo.es Mon Jan 30 13:32:13 2012 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Mon, 30 Jan 2012 12:32:13 +0000 (GMT) Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: <1327926733.93585.YahooMailClassic@web29705.mail.ird.yahoo.com> Hi Dariusz: Would you mind just try to void to build cm3 from the bootstrap image and make it with the rpm package for your distro (assuming it's FC16 AMD64, right?), please: http://pkgs.org/download/cm3 There is anything wrong with your installation attempt, just that is better try to build a first bootstrap image of your own and then proceed as you might prefer. Thanks in advance --- El lun, 30/1/12, Olaf Wagner escribi?: > De: Olaf Wagner > Asunto: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem > Para: m3devel at elegosoft.com > Fecha: lunes, 30 de enero, 2012 06:14 > Sorry, I'm busy with private matters > currently, so I'm forwarding > your request to m3devel. > > 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 > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging > Program. > From jay.krell at cornell.edu Tue Jan 31 03:21:56 2012 From: jay.krell at cornell.edu (Jay K) Date: Tue, 31 Jan 2012 02:21:56 +0000 Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem In-Reply-To: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> References: <20120130121419.98572pur8h0x4pl7@mail.elegosoft.com> Message-ID: > $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz > *** cannot find package import-libs / m3-win/import-libs You don't have the full source tree.Among m3-sys, m3-tools, m3-ui, etc., you are missing m3-win.If there is an "all" archive, try it? - Jay Date: Mon, 30 Jan 2012 12:14:19 +0100 From: wagner at elegosoft.com To: m3devel at elegosoft.com Subject: [M3devel] Fwd: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Sorry, I'm busy with private matters currently, so I'm forwarding your request to m3devel. 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 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --Forwarded Message Attachment-- Date: Fri, 27 Jan 2012 18:57:29 +0100 From: dknoto at gmail.com To: m3-support at elego.de Subject: CM3 d 5.9.0 2011-11-19-02-40-49 compilling problem Dears, I have tried compile latest CM3 snapshot d5.9.0-2011-11-19-02-40-49 on my system "Linux wenus.*.pl 3.1.9-1.fc16.x86_64 #1 SMP Fri Jan 13 16:37:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux". I have installed CM3 compiler version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-08-09 02:51:03 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX. I unpacked the source in directory cm3 by commands (I found it on yours website): $ tar -zxf /path/to/cm3-src-{sys,gnu,std}-CM3VERSION.tgz and then i did it: $ cd scripts $ ./do-cm3-core.sh buildship /home/dknoto/Projekty/CM3-5.9.0-devel-1/scripts/pkgmap.sh -c "cm3 -build -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel-1' $RARGS && cm3 -ship $RARGS -DROOT='/home/dknoto/Projekty/CM3-5.9.0-devel-1' " import-libs m3cc m3core libm3 windowsResources parseparams patternmatching sysutils unittest m3middle m3cggen m3objfile m3linker m3back m3front m3quake cm3 m3scanner m3tools m3bundle mklib tempfiles bitvector digraph realgeometry set slisp sortedtableextras table-list tcp cm3ide mtex m3sleep *** cannot find package import-libs / m3-win/import-libs Have you any idea? Best regards -- Dariusz Knoci?ski -------------- next part -------------- An HTML attachment was scrubbed... URL: