[M3devel] I know, I know...

Jay K jay.krell at cornell.edu
Fri Aug 24 00:12:48 CEST 2012


I don't doubt that Modula-3 can handle it.
And I don't doubt that C can handle it.
But in both cases I find 1) the details beyond my attention span 2) definitely in the C case and very possibly in the Modula-3 case, not portable. You could learn the rules on one platform/compiler, only to produce code that doesn't work on others. Why bother learning them therefore? If you just want efficient storage in memory and don't care about the layout, then bitfields are ok. If you need to control the layout to interoperate with another system..even though bitfields are supposedly designed for this..I'm not sure I'd bother.
 
 
C bitfields don't have portable layout.
Do you suppose that Modula-3 ones do?
 Maybe there are in fact an obvious set of rules that all compilers follow? I don't know.
 
 
Arrays of bytes have predictable layout.
Look at how binutils reads/writes object files. It does like this:
 
 
typedef struct elf_header_packed {
  char signature[4];
  char architecture[4];
  char offset_to_foo[4];
} elf_header_packed;
 
typedef struct elf_header {
  long signature;
  long architecture;
  long offset_to_foo;
} elf_header;
 
 
and uses some pack/unpack functions to convert.
 
 
They are solving a slightly different problem.
They don't have bitfields necessarily to contend with, but just packing/size of integers that have a number of bits that are power of 2 (8, 16, 32, 64). 
 
 
 - Jay
 



From: dragisha at m3w.org
Date: Thu, 23 Aug 2012 21:59:46 +0200
To: mika at async.caltech.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] I know, I know...

I have RTInfo module we developed years ago to parse .M3WEB. Good enough? :) But, not a solution, it is easier to write as I wrote in example I used to illustrate problem. 



GCC not obeying packing instructions is like. GCC not working in lot of cases. For some reason, I don't believe in it.


Hint, gm2 is GCC based compiler. And supports very precise packing/aligning rules.




--
Divided by a common language


Dragiša Durić
dragisha at m3w.org




On Aug 23, 2012, at 9:51 PM, Mika Nystrom wrote:


Well I don't think Jay said that bytes couldn't be unpacked in Modula-3
(you can just use Word for that).

But I think the point was that a compiler back-end might not necessarily
obey your packing instructions?

Here's what I think you should do... it would be super useful, both to
you and other people in the future.  And completely independent of
compilers.

Write a something-or-other that uses m3tk to read your RECORD type
spec, plus pragmas of your own choice (or comments, or auxiliary data
from somewhere) and then generates code using Word.T that can process
byte streams and return the RECORD you declared, in portable Modula-3.
I doubt it's very difficult.  m3tk is cool!

   Mika

=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes:



--Apple-Mail=_8871A9FB-3130-4B36-8524-F6549A5CEC9E

Content-Type: multipart/alternative;

boundary="Apple-Mail=_2314A877-555E-4BDE-8112-C875A2AE5122"





--Apple-Mail=_2314A877-555E-4BDE-8112-C875A2AE5122

Content-Transfer-Encoding: quoted-printable

Content-Type: text/plain;

charset=windows-1250



I have a friend, working for large software company and he just recently =

ported some message router from SPARC to Linux/Intel=85 Lots of "network =

order" data, same as with my current projects. Network, communication in =

general, network order is everywhere.



Insisting on some god-given data ordering is a bit=85 What is nice word =

here? :) Outlandish? Outimeish?



This is not first time I started discussion like this here. Every single =

time Jay explains to me how Modula-3 cannot handle it. I am handling it, =

as I have shown in my example, with Modula-3 code. With a bit of effort =

I can make it almost-transparent (subfolder/platform) over various =

platforms. Of course, as I am developing a full product (not software to =

be run on arbitrary platform) I don't have to worry about too many =

platforms. One is enough here, but I still think Modula-3 can benefit, =

and a lot, if it supported explicit byte/bit ordering/packing/aligning =

pragmas.



Also, unlike GCC, pointer alignment in Modula-3 is 64bit on x86_64. It =

is 32bit in GCC, and x86_64 is totally happy with it. Wr have 64bit so =

we must write piece of software in C to be what? Compatible with API's =

all systems are compatible with without any hassle.=20



TIA

--

Divided by a common language



Dragi=9Aa Duri=E6

dragisha at m3w.org



 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120823/42cb16dd/attachment-0002.html>


More information about the M3devel mailing list