[M3devel] I know, I know...

[Jay K]

Modula-3 has bit-mapping.
Encoding it in functions that takes offsets and sizes is not hard.
Using the language features gives you a choice of either
 - portable layout that doesn't likely match C
 - unportable layout that might match C
 At least unportable in terms of endianness -- again, for better and worse, see how we pick apart floats.
 It works, but the declarations are duplicated for little endian vs. big endian.
 Such knowledge does traditionally live in a compiler and its "core" libraries/runtime, but I'd still like to minimize it, maybe eliminate it.


Neither is a ggeat choice I think.
The compiler had tried to match target-specific layout/alignment rules.
Whether it got them correct, I don't know.
I relaxed the code because it was hard to know if it was right or wrong and
just didn't seem worth maintaining -- i.e. porting to new systems.

 - Jay



> Date: Fri, 24 Aug 2012 10:00:52 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] I know, I know...
> 
> On Thu, Aug 23, 2012 at 12:51:15PM -0700, 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 
> 
> Pragmas are definitely the wrong choice.  If they are ignored on an 
> implementation that  doesn't recognise them, this will be the wrong 
> semantics.
> 
> Coding all the extraction and insertion functions is obscure, picky, and 
> error-prone.  Bit-mapping is one of the reasons people use systems 
> languages, and the lack of it is a deficiency in Modula 3.
> 
> Not that I'm advocating rewriting the compiler right away.  It may be a 
> deficiency we can live with.
> 
> -- hendrik
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120824/86221280/attachment-0002.html>