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.
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.
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.
> 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.
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.
If you want more than 1-second precision, 64 bits are not enough. (Hmm does all C++ std::chrono implementation utilize 128-bit integers for nanosecond precision?)
> The tooling? There's open source tooling that generates code like any XDR tooling and like PB tooling and like MSFT RPC tooling.
There is no open source tooling that combines really used scheme understanding - in 5G this includes parameterized specifications by X.683 - and decoder able to show partially decoded message before an error, with per-bit explanation of rules led to its encoding.
> E.g., PKI uses DER, so a TLV encoding, thus it's inefficient.
When it is used, ~5% space economy is never worth people efforts to diagnose any problem. I strictly vote for this "inefficiency".
It seems you posit taglessness to be a universal crucial merit of any encoding scheme. This is good in an ideal world, heh.
I have had a misfortune to work for 5G which is full of PER-encoded protocols. Dealing with discrepancies in them - incompatible changes in 3GPP standard versions, different vendorsʼ errors, combined with usually low level of developers and managers in a typical corporation - was an utter nightmare.
IETF, in general, provides a good policy combining truly fixed binary protocols when they are unavoidable (IP/TCP/UDP levels) and flexible, often text, protocols where there is no substantial overhead from their use. Their early moves, well, suffered from over-grammaticalization (as RFC822). CBOR is nice here because it combines tagness and compactness. 3-bit basic tag combined with value (if fit) or length, it is commensurable with OER in efficiency but is decodable without scheme - and it is extremely useful in practice.
> I genuinely dislike CBOR. Formats which require me to calculate the length of the message before sending it
CBOR is not. No full message length. Only primitive type values. Compound type values require length _in items_ (not bytes) but indefinite encoding is possible if allowed ("deterministic" constraint to message forbids it).
So technically this doesnʼt differ from e.g. JSON where you have to wait until final "}" or "]" for a long compound item, and have to install an artificial limit.
> Add in an "indefinite length" option and you've got potentially unbounded client memory usage to watch out for.
> As if that wasn't enough you get extensible tags so the meaning of any message is entirely dependent on the context it was sent in.
So does any such a protocol. JSON, XML, any ASN.1, CBOR, whatever. If there are no extensible tags, there are field names - or they will be added by customer using what is allowed. Iʼve seen this in ASN.1 sequence-of pairs of name+value, directly emulating JSON-like dictionary. To limit it is not how security issues are handled.
If you mention tab-completing, if starting with the detailest component it wonʼt work at all because of context search problems. If you press something like "alice<Tab>", in deepest-first order it will have to search the whole tree which could contain millions of entities. Worse than, some subtrees may be dynamically loaded during the completion request.
To mitigate senseless tree top listing, IDEs propose a bunch of means like context-related hints or unpacking forms like "o.e.t" to "org.example.test".
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).