In 1999 I used Modula-2 for my first computer science/programming languages exam at university. The environment was a bit like Turbo Pascal 3.0, though with a more complete language (TP3 had no modules/units) and library, comparable perhaps to TP5.

Units were introduced in Turbo Pascal 4, then TP 5.5 added OOP based on Apple's Object Pascal, further improvements were then based on the Object Pasca / C++ relationship on Borland's compilers.

I do something similar with build trees, naming them +build, +cross-arm etc.

This convention was suggested by the GNU Arch version control system years ago (maybe 20??), but it's really useful for the same tab completion reason and I have kept it for almost two decades, even when I switched to git.

It was suggested by Tom Lord (RIP), who used it heavily long before he wrote GNU Arch.

File names or directories starting with a comma where considered “junk”, and ones with a plus sign I think where considered “precious”.

> because that client wasn't planning to pay them

Wait, you mean they used your little ruse as a means to be paid themselves??

Yes they did, and it worked!

That only works if you are sure to have a 64-bit result. If you can have divisor < multiplier and need to detect overflow, it's more complicated.

I think so, "whatever you boast it's not overstating" -> cannot be overstated.

How so? A guitar doesn't go past a few kHz (the highest string is IIRC 660 Hz, and the top fret is 660*4) and AM long wave radio—which is almost dead—starts around 120 kHz.

As someone who did assembly coding on the 8086/286/386 in the 90s, the xH and xL registers were quite useful to write efficient code. Maybe 64-bit mode should have gotten rid of them completely though, rather than only when REX.W=1.

AAA/AAS/DAA/DAS were used quite a lot by COBOL compilers. These days ASCII and BCD processing doesn't use them, but it takes very fast data paths (the microcode sequencer in the 8086 was pretty slow), large ALUs, and very fast multipliers (to divide by constant powers of 10) to write efficient routines.

I/O ports have always been weird though. :)

To be honest, validating bibliographies does not cost valuable time. Every research group will have their own bibtex file to which every paper the group ever cited is added.

Typically when you add it you get the info from another paper or copy the bibtex entry from Google scholar, but it's really at most 10 minutes work, more likely 2-5. Every paper might have 5-10 new entries in the bibliography, so that's 1 hour or less of work?

The complaint here is about this being an insufficient amount of effort because the bibtex entry from Google Scholar is wrong sometimes.

Yes, I wish this was this simple. :) There are many other complications:

* Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L.

* Different bits of the EVEX prefix are valid depending on the opcode byte.

* Some encodings (called groups) produce different instructions depending on bits 3-5 of the modrm byte (the second byte after all prefixes). Some encodings further produce different groups depending on whether bits 6-7 (mod) of the modrm byte identifies a register or not.

* Some instructions read a whole vector register but only a scalar if the same instruction has a memory operand. Sometimes this is clear in the manual, sometimes it is not, sometimes the manual is downright wrong.

* Some instructions do not allow using the legacy high-8-bits registers even though they don't do anything with bits 8 and above of the operand: they only want a 32- or 64-bit register as their operand.

* APX (EVEX map 4) looks a lot like legacy map 0, but actually a few instructions were moved there from other maps for good reasons, a few more were moved there for no apparent reason (SHLD/SHRD iirc), and a few more are new.

* REX2 does not extend SSE and AVX instructions to 32 registers even though REX does extend them to 16.

* Intel defines a thing called VEX instruction classes, which makes sense except for a dozen or two instructions where it doesn't. For these, sometimes AMD uses a different class, sometimes doesn't; sometimes AMD's choice makes sense, sometimes it doesn't.

And many more that I found out while writing QEMU's current x86 decoder (which tries to be table based but sometimes that's just impossible).

> Some instructions require VEX.L or VEX.W to be 0 or 1, and some encodings result in completely different instructions if you change VEX.L.

There is even an instruction where AMD got this wrong! VPERMQ requires VEX.W=1, but some AMD CPUs also happily execute it when VEX.W=0 even though that is supposed to raise an exception.

> There's no need to get full EVSE for most people,

It's a lot more comfortable though. It's been a great addition to the home to get an EVSE, even a small single-phase one.