<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>BinRd/BinWr "redesign".<br><br><br>How about BinRd/BinWr is "redesigned" with the following in mind:<br><br><br>instead of most compact encoding, instead use least-decoding-needed<br>encoding, which is also least compact<br><br><br>in particular, store all integers as native-endian 8 byte integers<br><br><br>include at the start of the stream, like:<br><br><br> UINT8 file_endian;<br> UINT64 integer_map_offset;<br> UINT64 integer_map_size;<br><br><br>reader would mmap the file (mmap has its pluses and minuses).<br>The data would be presumed to fit in address space -- even if<br>it tends to be accessed sequentially, random access would be possible.<br><br><br>if file_endian != host_endian, it would jump ahead to the<br>positions indicated by integer_map_offset and swap them.<br><br><br>writer would note all these offsets while writing<br><br><br><br>If I made this change, then I'd be much more likely to just<br>use this "pre-"existing" format as an in-memory format that<br>I loop over multiple times.<br><br><br>Given that these are temporary files that don't usually make it to disk,<br>optimizing for size isn't clearly valuable.<br><br><br>Given this change, walking the m3cg data multiple times would <br>end up just being bumping a pointer through an array of variably-sized<br>records, the sizes of which would be trivially looked up based<br>on the first byte (with the exception of case_jump).<br>This would likely obvious my ongoing little M3CG_MultiPass tedious work.<br>Something I believe is desired/needed here for M3C.m3. This isn't meant<br>to be a pointless excercise (though it is *somewhat* speculative).<br><br><br>m3front/m3cg/m3cg_ops would be unchanged.<br>The change would be in M3CG_BinRd.m3/M3CG_BinWr.m3/parse.c.<br><br><br>Thoughts?<br><br><br>I've omitted the obvious detail -- floats/doubles.<br>There'd actually be an array of MultiByteValueMaps.<br>They'd include a size. There'd be "4" for floats, and "8"<br>for INTEGERs and doubles. And hypothetically 10 or 16 for "extended",<br>but those don't really exist.<br><br><br><br> - Jay<br><br> </div></body>
</html>