string.pack with bit resolution

[bil til <flyer31@...>]

Hi,
one further question from me newbie:

I discoverd this string.pack in 5.3 lua.

A further bottleneck for controller applications, where we have to live
with, can be "field-proof" communications. Often this runs with low
data-rates. CAN e. g. max. 1Mbaud, and KNX even only 9.6kBaud. The advantage
of KNX is, that it allows "relatively chaotic cabling", as you typically
find in houses... .

If you want to transfer data over such lines, it is very important to pack
numbers very efficiently into communication buffers, and "very" here
ultimately requires "bit-efficiently".

For such bit and byte packing, we could do our own formatting, but it would
be very nice, if the format string could be interchanged with other devices
/ other people, and then would describe the buffer contents unique, at least
in "lua world".

Therefore could you please consider to allow the following extensions to the
Ref manual spec "6.4.2-Format strings for pack":
a: bit
S0: a null-terminated String
S: a string, where the number field before specifies the string length (so
that the string length can be specified also by a short number, e. g. 1 byte
or so)
S$: string until end of the buffer
...and one VERY important point: The letters a,b,h,l are used for specific
bit sizes. If a number is directly appended to those (maybe limit to 1...32
or 1...64), then this gives the number of bits/bytes etc. Like this then I
can specify the following:
a3 3-bit number (signed, A3 would be unsigned)
b3 24-bit number (signed, B3 would be unsigned)
h3 48-bit number (signed, H3 would be unsigned)
You can also allow a[3], b[3], h[3], but I would allow both notations (also
for in,sn,!n I would allow to skip the brackets)
And !0 must also be also allowed (for numbers): This means STRICLTY NO
alignment, not even on bit level (so allowing to concat such numbers in
bit-mode, without loosing any bits). Exception: strings and chars - these by
default can always align to 1 byte at minimum, I am fine with this.
(or should I better use X0 .. I do not really understand the difference
between Xop and !)


Further a "half precision float" also should get a number (e. g. "r" like
good old "real" from Fortan  - maybe only operating systemw with "hardware
support" for half-precision (16bit-floats) - Cortex M3/M4 can convert in one
cycle to half-precision... this can be useful data compression ... of course
in lua for Linux or Windows such "r" support might be awkward to program of
course, I would not support this there possibly).


A number before such letter still is used for repeats. So you could then
write:
!0 10a 3A4 b3  (=10 bit-numbers 0/1, 3 unsigned 4bit numbers, one 24bit
signed)

... For those who complain that this "bloats up" the "500 line pack" code
even more: This really is used by VERY many people... . And anybody with ROM
problems I think in the lua C code can easily strip the format specifiers to
some smaller set (e. g. allow only a,b,h,l,f,d)



--
Sent from: http://lua.2524044.n2.nabble.com/Lua-l-f2524044.html