#asciilifeform | 2022-06-04

Say, asciilifeform, how is Endianness handled for the Interfaces.Unsigned_N types, such as here?

00:16

Does Unsigned_16'Write write big or little endian?

00:29

I've checked the ARM and found naught so far.

~ 37 minutes ~

01:06

It's implementation-defined.

~ 3 hours 56 minutes ~

05:03

http://logs.nosuchlabs.com/log/asciilifeform/2022-06-03#1104667 << by default, goes with the endianness of the local machine. arguably oughta nail it down there. could be bothered, if bigendians weren't extinct...

05:03

Logged on 2022-06-03 20:14:05 verisimilitude: Does Unsigned_16'Write write big or little endian?

05:04

( well, e.g. 'm' has a bigendian mode, but even there off by default... )

05:04

*

asciilifeform hasn't a bigendian iron in torture room or in dc, to try on, sadly

05:06

ftr ffa is 100% endianism-free, by design.

05:19

So, as soon as the input must be described exactly, this Ada feature is on the same level as ``look, I named the function which writes it, and call that instead''.

05:19

I'll be stuck reading individual octets to get what I need.

05:20

s/writes/reads/

05:26

I like Ada, but sometimes the chastity cage really itches.

05:33

verisimilitude: what's the problem w/ specifying bit order when the latter actually matters ?

05:34

Well, take that earlier code; the Interfaces.Unsigned_N Write attributes can't be changed, so now either subtypes must be made, or every call changed.

05:34

so make a subtype. e.g. ffa doesn't use naked unsigned_xyz

05:34

By not allowing one to just specify endianness, they're almost useless.

05:34

verisimilitude: in most cases there's 0 reason to giveafuck re endianism

05:35

Common Lisp is actually a little better, because with that I've LDB and DPB.

05:35

when there aint any external wholesale swallowings of unsigned_x for x>8

05:35

( and when yer only eating what you've previously shat yerself )

05:36

Just disregard me; this sucks in general anyway. Damn near every time I need to get data into a program from a format, it's the most complicated and fragile part of the program.

05:36

in general this is to be blamed on the ctard side

05:37

Yes; there should be no need to do any of this.

05:37

It should be done in the underlying system, but that would actually be useful, so no.

05:37

the obv solution finally, could say, implemented -- the extermination of 'wrong'-endian irons

05:37

Little endian delenda est.

05:37

sure, but will need time machine.

05:39

It's not too late to change Pest to use the proper endian, the network order.

05:39

inherited from extinct sparc ? why ?

05:39

( see also... )

05:39

(trilema) 2015-04-07 mircea_popescu: which reminds me of a joke : when they entered the eu, the romanians starting bidding on all sorts of contracts. like for instance, a 1947 british rfq to move the country to european style driving.

05:40

Well, we agree on the extermination of wrong endianness.

05:40

erryone, lol, agrees...

05:41

Either big endian or, better, no endian.

05:42

on sane iron -- no endianism (cuz no unaligned access)

05:42

nao where to get any..

05:44

*

asciilifeform bbl

05:44

We're back at the start of the circle, again.

~ 1 hours 42 minutes ~

07:27

crtdaydreams

billymg: new comment re: Gentoo Tut. I think it might've been butchered, the lower half of the comment seems to have disappeared.

07:28

crtdaydreams

had a <a href=""></a> tag there, I thought I did, but may not have closed it correctly.

~ 1 hours 13 minutes ~

08:42

http://logs.nosuchlabs.com/log/asciilifeform/2022-06-03#1104619 This was an interesting day.

08:42

Logged on 2022-06-03 12:36:52 asciilifeform: 's 'official position' to this day -- if somehow suddenly appears a replacement for ada which actually meets asciilifeform's reqs -- would use !

~ 8 hours 14 minutes ~

16:56

i think the question of endianness is inherently c-ism-- you always have to have a reader and a writer for your data, to use lisp terminology, if you're going to serialize, and your reader should take octets and convert them to internal presentation accordingly. so e.g. read-number -> (logand (ash (read-byte s) 0) (ash (read-byte s) 8) ...)

16:57

rob pike maked similar point, and i think his is a solid treatment of subject https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html

17:02

billymg

crtdaydreams: the comment indeed cuts off, even in what i can see in the admin panel. would you like me to delete the comment so that you can resubmit? otherwise you're free to add the chopped off bit in a subsequent comment, up to you

17:02

so your reader is built of smaller functions, that are format specific, e.g. you have read-number, read-text, read-array or whatever, which you then combine into larger blocks (defun read-header (s) (let ((version (read-number s)) ...)) (make-%header :version version ...))

17:03

which makes endianness or really serialization concerns to be entirely irrelevant. format author might choose to pack his numbers in whatever hairbrained way

17:05

i'm a fan of network byte order, which is bigendian, which is that way for historic reasons, and is pretty much all through the rfcs and early specs, but only like it because "it's always been done that way" etc.

17:05

...when specifying network standards

17:08

lisp machines including genera had clear dileation of boundaries: if you wanted to read a serialized format you'd have a reader and write for it, but then you store the result in fasl, which is a way to dump any internal representation to disc. so e.g. you read-jpeg -> which gives you image object, which is some struct wrapped arrays, which you then can "save" to a genera fasl if you need to (or keep it in state)

17:10

and to further clarify read number: png:read-number would be different from bitcoin-serializer:read-number because the underlying storage formats are different, whether endianness or whatever other concerns

17:11

(i prefer to treat everything as a "reader" but "serialize-" or "parse-" are also acceptable terms)

17:20

http://logs.nosuchlabs.com/log/asciilifeform/2022-06-04#1104714 << asciilifeform historically has 'positive associations' with bigendianism -- from assoc. with 'serious irons', salivated over '90s 'workstations' etc. which at one time were 'what one connects to net', vs 'toy' comps where littleendianism was ~exclusively found. but today is rather 'dead hand' imho, the 'serious irons' extinct, and the massaging of endi

17:20

anism is simply waste of kilowattage and a largely pointless mine for n00bs to step on, imho

17:20

Logged on 2022-06-04 13:03:02 phf: i'm a fan of network byte order, which is bigendian, which is that way for historic reasons, and is pretty much all through the rfcs and early specs, but only like it because "it's always been done that way" etc.

17:21

and yes as pike et al point out, and as demonstrated in e.g. ffa, if you serialize bytewise, endianism is irrelevant

17:21

sadly not erryone serializes bytewise

17:23

imho the ada way is civilized -- can explicitly mark the expected endianness of a word, and machine will do Right Thing (incl. for bit positions in bitmasks, from which ultimately no escape if yer twiddling bits for 'electric' reasons)

17:26

*

asciilifeform erry time asks bigendian aficionados 'what'd be gained, for the burned cpu cycles, from making a ~new~ protocol 'network-endian' ?' -- gets blank stare

17:29

imho is a (relatively light) symptom of a serious disease, where 'other people's cpu cycles' are considered 'free'

17:29

https://archive.ph/20220603185518/https://asia.nikkei.com/Politics/International-relations/Indo-Pacific/China-nears-launch-of-third-carrier-turning-up-pressure-on-Taiwan

they aint phree.

17:33

*

asciilifeform must bbl

~ 25 minutes ~

17:58

mats

~ 1 hours 47 minutes ~

19:45

http://logs.nosuchlabs.com/log/asciilifeform/2022-06-04#1104725 This is similar to the argument C language idiots use to ignore necessary checks, although the solution really is to just use better hardware, we agree.

19:45

Logged on 2022-06-04 13:23:57 asciilifeform: erry time asks bigendian aficionados 'what'd be gained, for the burned cpu cycles, from making a ~new~ protocol 'network-endian' ?' -- gets blank stare

19:49

http://logs.nosuchlabs.com/log/asciilifeform/2022-06-04#1104726 I meant to reference the next message.

19:49