Netch

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?)

> if you do what the various specs on the internet suggest you do if you have an integer > 2^53: you encode it as decimal value as a string.

Hexadecimal is better - more compact, much less encoding/decoding effort. Alternatively, array of two integers does as well.

Text forms for any error, not NaN, are also useful.

But issues with non-UTF-8 encodings - as in CJK world - may spoil the picture pretty more.

> 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".

> Are these required or useful in this context?

At least 64-bit numbers are crucial in any system context.

If you show your code to unlimited public, there is plenty of sites for this like GitHub or Bitbucket, but itʼs your problem to attract enough reviewers (both in quantity and quality) to attend your project. You donʼt directly need an open license for this publication type, but interest to your project would be otherwise utterly weak.

If you donʼt show your code, this falls back to the trivial case of proprietary resource.

So I donʼt understand the very idea of the question unless it is rechecked or extended.

Some programmer forums allow posting code to discuss any aspect of it, I participate in a few. But in that case you wonʼt be able to control discussion, and you have to find out how to make your request interesting.

A similar idea was tested in an experimental BSD clone in Berkeley in mid-1980s. (Great sorry I havenʼt kept link to the description, so rephrase with my own words. Maybe this was in the McKusickʼs book?)

No suid or sgid was allowed. A daemon started from init and listening on a socket listened for connections, checked permissions and run the specified binary with requested permissions. A caller had to interact with the started program using pipes.

It seems the complexity of passing all to pipes was why the approach was rejected. Instead, the checking of inherited environment was strengthened. "Everything new is well forgotten old."

> Which, ten years down the line, should free up a bit more opcode space when they decide to no longer support CS/DS/ES/SS segment prefixes. The space could be used for instructions that are the same in 32-bit and 64-bit modes.

The document explicitly says that segment prefixes are _ignored_.

> Removing all ring 3 I/O instructions (also part of the plan) will free up 8 further bytes in the primary opcode map for user space code.

It does not unless the same codes are removed in ring 0 as well. But if ring 0 IO commands are converted to multibyte, why ring 3 IO commands can't get the same?

> And then there is the 67h byte being freed as well due to removing address size overrides.

Again, not ignored - unsupported styles get GP instead.

> Free space in the primary opcode map => better encoding density...

Won't happen. More so, most encodings are shared with 32-bit mode and still developed this way.

> Getting rid of 16-bit data will make the data flow engine in future CPUs simpler (no more partial register stalls).

This is missed as well. 16-bit data are still handlable. Only addressing is disallowed.

> So what are the benefits?

Seems pretty none among what you listed:(

1. Reading the current spec I'm most wondering with mandatory paging enable. This requires prefilled paging catalogs in RAM. Does it mean CPU can't start until ME (or another external agent) generates these catalogs?

It also looks really weird compared to other ISAs as System/Z or SPARC which really benefit of not using page translation in kernel mode. I'd expect alleviation of switching paging on and off...

2. Looks it's a good moment to relax memory ordering from TSO, with easy control using Flags. (Using it will gradually soar in years, yep.)

The design of current x86s is that multiple regions under 4GB boundary are occupied by I/O regions, some of them tied to processor (as APIC, HPET, etc.) and some to extension cards which reject working in 64-bit mode.

3.2GB is an example figure - it could be 3.5GB, 3.6GB... - but reflects that RAM can't be mapped at all of lower 4GB. Memory controllers typically remap part of it to a range upper than 4GB boundary, so 32-bit PAE-capable or 64-bit OS can still use it.

OTOH using 64-bit OS is recommended with RAM >=1.5GB because if OS can't map all RAM _twice_ and all device memory to virtual address space, tricks with memory banking (frequent page remapping) are getting needed to deal with data move.

While the _engineers_ of Intel are definitely not idiots - otherwise they couldn't have been getting enough success - the quasi-engineer layer over it, which makes the real technical decisions, showed a truly summit of folly, multiple times.

- Foolhardy snatch 1: iAPX 432. - Degradation in first half of 1990s, concluded with FDIV bug, and marvellous savior "ASCI Red" which paid all OoO development (PPro and following). - Foolhardy snatch 2: RAMBUS + Itanium. Nearly collapse with P4 and miracle #2 with Israel team, Core, and stealing AMD64.

I can't imagine that a person adopted EPIC-based Itanium had had a real engineering competence. (Not sure for iAPX 432, this is a complicated issue.)

On a lower layes, as ISA details, every Intel move looks like using prediction less than for 1 move forward! Maybe 1/2 move sounds more veracious. Loads of examples. And, this also seems a guy that just remembered he was an "engineer" 30-40 years ago is now a decision maker.

> Those modes and microcode need to be validated, tested and add bloat to the boot software stack.

Just allowing booting directly in 64-bit mode and making 64-bit SMM mode would be enough to avoid boot software stack problems. Riddance of "legacy mode" doesn't require all it.

Every time I see a yet next inventor designs its own configuration language and foolhardily crosses a rake field of syntax conflicts, design errors, and subtle logic bugs, I recall LISP with its S-expressions. The two last cases were CMake and BitBake.

Being a kind of divergent multiverse base is not bad, provided a common spirit is still shared and abidden between implementations. For LISP, having e.g. Scheme and Guile as a minimal working base, and Common LISP as an "all batteries included", it not that bad even despite their miscompatibility.

As any unlimitedly editable documents this one has been vandalized :( there is no more point to visit it.

> The code already has that problem.

Only in untyped or dynamically-typed languages. But even in JavaScript one may write +obj.version instead of obj.version to make it numeric. Evading this is a straight way to hell.

In a statically typed one, conversion is typically generated from description and type checking applies just at reading.

The problem with vaguely specified format is in more simplex cases. Shall we accept 45x as number (and what it value will be, 45 or 0)? 045? 045x? What date is 1/2/3, 1-2-3? And so on.

> You don't end up in a situation like this contrived example:

Modern languages repair this with mandatory block braces: {C style} (Rust, Go, Swift...) or Modula/Ada style (if x then foo else bar end). C style is easier for editors.

> What's your issue with significant whitespace?

1. Many cases when leading whitespace is still spoiled, including editors (which use can't be avoided due to corporate tool limiting), web formatters, etc. Last decade spreading of mobile-aware tools made this worse.

2. With grouping by indentation, it's hard to determine block start if multiple blocks are ended at the same line, like:

    a:
        b
        c
        d:
            e
            f
    p

and let's imagine the most nested block occupies 2-3 screens (not rare for configs or code, even if it is against good coding rules). You have no means to decide what block start is to be matched when you ask editor to find match.

I code in Python continuously since 2004 and I deem grouping by indentation is bad idea. Not fatally bad, of course, but with explicit grouping it would be a bit better.

> We had that a decade ago. It was called XML and XML Schema.

It would be true if XML was not full of all this SGML debris like "entities" (really, uncontroller macros), if real schema formats was flexible enough (I needed <c> inside <a> and <c> inside <b> when they totally different), etc.

But when a config reader tool has to deal with 40+-year legacy of enterprise guys wanting to embrace the universe, but all this doesn't allow to control contents without external measures like regexp checking... that simply shuts up facing real world.

I am from Kiev, Ukraine, initially studied English at classic Soviet school with explicit orientation to British style. Nevertheless, it suggests 93% American. Initially I guessed this is due to r-coloring, but words like "plastic bags" have no R ;)

There isn't Chrome for FreeBSD. When I access google.com/chrome from Firefox under it, it says I needn't download it because my Chromebook does it by own means :) Shall I retry later on?