[M3devel] I know, I know...

[Jay]

Look at the code in m3core or libm3 that picks apart floats? The unsafe/loophole part isn't relevant.

 - Jay (briefly/pocket-sized-computer-aka-phone)

On Aug 23, 2012, at 12:42 PM, Dragiša Durić <dragisha at m3w.org> wrote:

> I have a friend, working for large software company and he just recently ported some message router from SPARC to Linux/Intel… 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… 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. 
> 
> TIA
> --
> Divided by a common language
> 
> Dragiša Durić
> dragisha at m3w.org
> 
> 
> 
> 
> On Aug 23, 2012, at 9:29 PM, Dragiša Durić wrote:
> 
>> You mean, for system programming I have to use C?
>> 
>> --
>> Divided by a common language
>> 
>> Dragiša Durić
>> dragisha at m3w.org
>> 
>> 
>> 
>> 
>> On Aug 23, 2012, at 9:26 PM, Jay K wrote:
>> 
>>> How about you just use "bytes" or integers and helper functions like this:
>>>  
>>>  
>>> typedef struct _BIT_FIELD {
>>>     UINT8 ByteOffset;
>>>     UINT8 BitOffset;
>>>     UINT8 BitCount;
>>> } BIT_FIELD;
>>> 
>>>  
>>> HRESULT
>>> ExtractBitField(__in const BIT_FIELD* BitField,
>>>                 __in const UINT8* Bytes,
>>>                 __in size_t Size,
>>>                 __out_opt UINT8* Value)
>>> /*++
>>> Extract a bitfield from an array of bytes, as specified
>>>     by a byte offset, a bit offset within the first byte, and a bit count.
>>> The bitfield is presumed to be no more than 8 bits -- however that could be easily fixed.
>>> The bitfield can definitely cross byte boundaries.
>>> --*/
>>> {
>>>     UINT8 const bitCount = BitField->BitCount;
>>>     UINT8 const bitOffset = BitField->BitOffset;
>>>     UINT8 const byteOffset = BitField->ByteOffset;
>>>     UINT8 const FF = (UINT8)~(UINT8)0;
>>>     BOOL8 const twoBytes = ((bitOffset + bitCount) > 8);
>>>     UINT8 const secondBitOffset = (8 - bitOffset);
>>>     UINT8 localValue = { 0 };
>>>     HRESULT error = { 0 };
>>>     if (Value)
>>>         *Value = 0;
>>>     if ((bitCount > 8) || (bitOffset > 7) || (bitCount == 0))
>>>     {
>>>         error = E_INVALIDARG;
>>>         goto Exit;
>>>     }
>>>     if ((byteOffset + twoBytes) >= Size)
>>>     {
>>>         error = HRESULT_FROM_WIN32(ERROR_BUFFER_OVERFLOW);
>>>         goto Exit;
>>>     }
>>>     localValue = (Bytes[byteOffset] >> bitOffset);
>>>     if (twoBytes)
>>>     {
>>>         localValue &= ~(FF << secondBitOffset);
>>>         localValue |= (Bytes[byteOffset + 1] << secondBitOffset);
>>>     }
>>>     localValue &= ~(FF << bitCount);
>>>     error = 0;
>>>     if (Value)
>>>         *Value = localValue;
>>> Exit:
>>>     return error;
>>> }
>>> 
>>>  
>>> arrays of bytes are really the only way to control the layout.
>>> Look at how GNU binutils works, for example...
>>> Bitfields in C don't yield predictable/portable layout either.
>>>  
>>>  
>>>  - Jay
>>>  
>>> > From: hosking at cs.purdue.edu
>>> > Date: Thu, 23 Aug 2012 09:30:57 -0400
>>> > To: dragisha at m3w.org
>>> > CC: m3devel at elegosoft.com
>>> > Subject: Re: [M3devel] I know, I know...
>>> > 
>>> > PACKED?
>>> > 
>>> > Sent from my iPad
>>> > 
>>> > On Aug 23, 2012, at 3:24 AM, Dragiša Durić <dragisha at m3w.org> wrote:
>>> > 
>>> > > I know this will probably be very dense subject, but. What about:
>>> > > 
>>> > > TSPacketHeader = <* ENDIAN = BIG*>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;
>>> > > 
>>> > > Meaning: bit data is packed from left to right, and all multi-byte data is packed MSB first.
>>> > > 
>>> > > Right now I am doing this, based on knowledge of my platform (little endian, x86_64), like this:
>>> > > 
>>> > > 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;
>>> > > 
>>> > > And please don't tell me "write in C", because then I will just "offload" this problem to C preprocessor and still only hope for the best. Modula-3 is provably very adept to systems programming and I hope it can be more so.
>>> > > 
>>> > > Thanks in advance..
>>> > > --
>>> > > Divided by a common language
>>> > > 
>>> > > Dragiša Durić
>>> > > dragisha at m3w.org
>>> > > 
>>> > > 
>>> > > 
>>> > >
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120823/8b8d58a1/attachment-0002.html>