Re: [Cbor] Self Described CBOR - Little Endian

[Laurence Lundblade <[e-mail]>]

For native implementation, the amount of extra object code for endian conversion seems pretty small. My guess is 100 or 200 bytes. My encoding function that does endian conversion, and preferred encoding and deals with alignment is 150 bytes of object code. When you start encoding and decoding complicated structures like nested maps with optional items and you add in duplicate label detection, the percentage of the overall implementation saved is small.

It might have been better for CBOR to choose little endian because most CPUs are, but at this point any unnecessary divergence would create interoperability issues.

LL

> On Mar 24, 2021, at 1:06 PM, Joe Hildebrand <[e-mail]> wrote:
> 
> Coincidentally, I just got a very small generic WASM decoder working:
> 
> https://github.com/hildjj/cbor-wasm
> 
> Inspired by https://github.com/quartzjer/cb0r/, but works synchronously in streaming mode, like expat.
> 
> — 
> Joe Hildebrand
> 
>> On Mar 22, 2021, at 10:50 PM, alex thompson <[e-mail]> wrote:
>> 
>> ​Given the prevalence of little endian hardware and the existence of the LE typed array tags it would be useful to opt-in to LE encoding of the additional information bytes as well. This would simplify decoders that are specific to LE platforms, particularly WebAssembly which is all LE and hasn’t defined a swap instruction.
>> 
>> The opt-in could be self described with tag 55798 (has the same non-unicode magic number characteristic as 55799). The beginning of a stream would default to BE so tag 55798 itself would appear as 0xd9d9f6. Then any following tags and descendant items would be LE.
>> 
>> For completeness, 55798 and 55799 could be nested within one another, switching the endianness as the decoder traverses a tree of items. Nested tags 24 and 63 would pass on their endianness to their embedded items. No effect on typed array tags 64-87.
>> 
>> It would be a breaking change for generic decoders since ignoring 55798 wouldn’t work as expected but I think the impact is very manageable and fits with CBOR’s stated goals of small code size and extensibility.
>> 
>> Alex
>> _______________________________________________
>> CBOR mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cbor
> 
> _______________________________________________
> CBOR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cbor