Netch

From a bystanderʼs POV it is excessively hard to memorize all the mess with multiple different extensions. The naming style doesnʼt alleviate the task. But this is a typical issue in the whole RISC-V ecosystem.

What Iʼm slightly confused for is that all these extensions, useful for a minor part of applications, arenʼt moved to longer instructions (6-byte).

A normal situation in my tasks is when the working copy contains lots of changes that are used for debug (mainly prints) but these changes shall not be committed to the proposed change. For this, even interactive adding (`git add -i`) does not satisfy; I need `git add -e` which allows editing in a patch form, and remove the temporary local changes.

Slightly side note - I donʼt understand why C++ invents new stdio based functions like std::print but rejects to import funopen() or fopencookie() which make stdio flexible similar to iostreams. As for me it should have been done ≈20 years ago.

With the manner exposed by the most feature-full DEs, Iʼd expect setting default to ~/Cache (not ~/cache, the latter is for the userʼs discretion).

But, I tend to agree with the main articleʼs premise that without a special teaching for the issue most newcomers will lose the issue.

Nice work! Perseverance to find the root cause in such an unfriendly environment as any bootstrap is what saves all us from the civilization crash...

RISC-V designers explicitly declare in their base specification: "The AMOs were designed to implement the C11 and C++11 memory models efficiently." So at least one example is present.

> Python might have used array[~0] instead

This is what was once added to C#: arr[^idx], when this ^idx is mapped to a special object, typically optimized then out. arr[^0] means the last element.

> In Europe, we typically mark the ground-floor as floor-zero,

_Western_ Europe. Eastern Europe prefers 1-based numbering. The reason, typically assumed, is that thermal isolation, required due to colder winters, causes at least one stair segment between entrance and the sequentially first floor.

> find the convention used in many countries of numbering building floors starting with zero to be more logical.

Ukrainian here. Multi-floor buildings always have at least one stair section to first floor due to need of thermal basement isolation. (I guess this is not pertaining to Western Europe due to more clement winters.) And, yep, it is called "first" floor. Using zero number is rare but possible (in this case it is called "tsokolny" floor) if a real "basement floor" is present, but in this case still 1-based numbering is preferred.

This division, using SRT loop with 2 bit output per iteration, perhaps would have already been microcoded - but using the lookup table as an accelerator. An alternative could use a simpler approach (e.g. 1-bit-iteration "non-restoring" division). Longer but still fitting into normal range.

But if they had understood possible aftermath of non-tested block they would have implemented two blocks, and switch to older one if misworking was detected.

Filename character set and its interpretation shall be controlled per directory or, at least, per FS. This pertains not only to permitted set like with or without LF, but to collation rules as well (including case insensitivity with cases like Turkish/Crimean/etc. I/ı and İ/i). Also this shall include workarounds for already existing problems: if a directory already contains files I1 and ı1, there shall be a technique to deal with them separately ever with Turkish locale.

But restricting this at syscall level is definite insanity, among with excuses.

OK let them add an explicit check to standard tools, and/or to open(), mkdir(), etc. with O_PORTABLECHARS. And an environment option to disable this check.

Why they force the restriction at syscall level?

> it seems that glibc does not support it

`iconv` does, and this is enough in common. Among with tons of eerie EBCDIC/whatever...

> That can only be a bug - UTF-32/UCS-4 never saw external use

I regularly use `iconv -t utf-32be | hd` to look what a bizarre sequence is denoting yet another weird symbol like an itchy hedgehog.

And what is a real reason to disallow this?

But at least a programmer shall be aware to call it (whatever API is used).

> You're not limited to 650MB provided you use UDF rather than ISO 9660.

You donʼt take into account case of booting real ISO on an old hardware. If it doesnʼt know DVD, chance of UDF support in BIOS is vague. More so, itʼs possible to barge in to a system without "no-emulation" support so the real boot part will be limited to 2880M due to floppy emulation.

Yep, all this is very old. UDF and no-emulation support appeared circa 2000. Bootable USB sticks appeared appoximately the same couple of years. En mass, these systems had been gone circa 2010. (Iʼm even slightly confused I still remember all these barriers, among with CHS addressing, geometry translation, etc.) So each boot media creator has to select what part of this legacy is to be supported... or drop it at all and orient only to a common base for last ~10 years.

> Makes you wonder why this isn't part of the C++ standard library itself.

Plainly no need if there is a separate easily attachable library (and with permissible license). What C++ had to do - provide character (char{8,16,32}_t) and string types - it has done.

> There’s no excuse.

Until mid-2000s there was no certainty Unicode will eventually defeat competitors. In real it havenʼt fully yet - GB2312 and Tron are still locally prevailing, and IBM still jogs with EBCDIC. But at its early times nobody was reasonably sure, and Java attempt could have failed as well. (More so Java approach for UCS-2 was wrong - already commented nearby.)

> In C# I can simply do this: "hello world".ToUpper();

Hmm still actual: https://www.moserware.com/2008/02/does-your-code-pass-turkey...

All the code which is not in hot path may conform to any rules, and typically is designed according to something like SOLID, to make understanding and maintenance as simple as possible (and suitable to any average coder).

All the code which performance, memory cost, etc. is critical, should be adjusted to fit into required confine even if it will violate all other tenets. This often results in combination of opposite approaches - anything that does well.

Finally, one just profiles the code and fixes all most spending paths. This is what now any average programmer can do. What it canʼt do - and what Carmack has been doing for decades - is to predict such places and fixes them proactively at architectural level; and to find tricky solutions that average joe-the-programmer hasnʼt heard ever.

Really I would have concur with the author if dealing again and again with a need to fit the media contents into 650MB (if it is intended to be put at real ISO) or to guarantee how combination of 1) realmode bootloader + 2) UEFI bootloader + 3) ISO-only thunk + 4) UDF volume bizarrely interlace in a single byte stream.

Bootloaders are dodgy even without such a complication. Freeing oneself from all this may give just a moral sense of deliverance...

Live CD is mainly replaced with live USB, even if it is called the same nickname.

> QEMU running Windows for x86 on an M1 isn't very fast either.

It seems the main obstacle is in paging where x86 4KB clashes with Apple 16KB (ARM/64 supports multiple sizes), so, 2-level paging canʼt aid and an emulator has to shadow-paging which is, definitely, much slower.

> Apple does it with Rosetta and Microsoft with whatever their thing is called, you don't even notice that an app is running under emulation.

But they still use a vendor-specific TSO support in hardware.

> You're saying you can't think of one context where a trade of between largest supported int value vs total bytes of the message is a reasonable one?

Seems you have pretty misread me. Well, "any system" (where systemd is useful in principle) "context" and not "any" "system context", if I correctly guessed where is your point.

As the whole protocol shall be supporting Linux, in a fully universal manner, support of 64-bit values for pointers (even in crash reports), file offsets (including 32-bit systems), etc. is a must.

> I would encourage you to work with either data at scale or embedded hardware for a fresh perspective.

Thanks, I got used to, different platforms (like ARM) including 32- and 64-bit ones. Also ancient beasts like 6502, PDP-11, and even S/360 (Soviet clones) at good old school times. Beg your pardon, no experience with 8051, 8042, ESP8266 and so on, but they arenʼt in question here. Again, the very topic is full-scale Unix context - more so, closer to desktop/laptop/server, which are nearly always 64-bit now (mainstream distribution vendors deliberately abandoned 32-bit versions for these domains a few years ago), so I donʼt expect much digression.

Most cases an initial estimate of change cost is utterly overstated because emotional and reluctant to change.

(And, well, this fact is also abused by wreckers who explain any reasonable objection with this factor;))

All this suggests the insane Windows time (64 bits of 100ns periods since 01.01.1601 00:00 GMT as it would have been Gregorian) sometimes has it small advantages - both an excellent discretion and will work even the whole galaxy will be conquerred... ;))

FreeBSD was also more radical in dealing with off_t which became 64 bits since 2.0. Linux still has rudiments of old size in its 32-bit versions.

> One of which was the automatic cast of 32 bit function arguments to 64 bit during the function call.

AFAIU this works only for unsigned arguments (as loading to %edi clears upper part of %rdi). SysV ABI spec for x86-64 says nothing about extending all values in registers or stack to full 64-bit value, and comment on boolean (only LS byte contains something significant) suggests this is a common rule.

> Code that assumes time_t is the same width as int is already broken

You missed the point. It is meant that code _built for the same target_ "assumes" all instances use the same definition of time_t, and not about such a guarantee across different targets. That's why Gentoo solution to redefine target is cumbersome but finally working - as radical as axe.

> SCTP

> It also has multiplexing built right in.

It is not. You canʼt stop, for example, receiving from stream 0 during getting high-priority data from stream 9. No userlevel API allows to specify "now receive a message exactly from stream 9". Data packet TSNs are the same number sequence for all streams. You canʼt normally ignore a single data TSN for a stream payload: you have to issue SACK and brook constant retransmissions from other side. You canʼt specify receive window separately for each stream, to calm the sender down while the streamʼs receive buffer is full.

I donʼt know who and why spreads the myth it is really multiplexing, but now these stream numbers are merely another type of per-message external tag. All other is merely scam. It seems that initial design was moving toward this possibility but then something unfortunate happened.

> This means you don’t have to devise message length communication into your application layer protocol and can rely on your transport.

This is, well, tasty from it.

> If you really want real numbers passing them as decimal string is actually sensible.

Hexadecimal, if so. Nearly any decent modern language and runtime can it.

    $ python
    >>> import math
    >>> math.pi.hex()
    '0x1.921fb54442d18p+1'

This gives exact value without any rounding effects and conversion cost.

(I donʼt count decimal floating-point as it is quite rare and its application is faint. In overwhelming most of cases, fixed point is better.)