pm215

If you think Arm is a "nice RISC encoding" then I think you've mostly been looking at the older integer bits of it :-) As you get into FP and SIMD there are just a lot more useful operations that need to fit into the strictly limited encoding space, and new features that need to be tucked into previously unused corners of the space, and it all gets noticeably less regular (e.g. "these two bits encode the operand size which is 0b00/0b01/0b10 for 8/16/32 bits, but 64 bit operands aren't supported and 0b11 means it's part of an entirely different set of instructions").

I haven't looked at them, partly because I'm sceptical about how much use they are. In my experience the hard part of emulating new instructions is the semantics, the "what does this instruction actually do?" bit. The line in the decode file that specifies the 1s and 0s and fields is trivial and takes no time. Plus, the way the architecture splits things up often doesn't match the way that makes the emulation simpler: for instance "same operation, but comes in signed and unsigned flavours" is often encoded with a sign bit but appears in the architecture as two separate instructions, one with an S in the name and one with a U. It's often simpler to have one decode line which covers both and passes signedness as an argument, where something auto-generated from the architectual data would give you two distinct functions.

For cases where everything you need is really in the datafiles (e.g. a simple disassembler) or where you're providing a user facing API that you want to have match the architecture documentation closely, the tradeoffs are different.

Also for QEMU I tend to value "works the same regardless of target architecture" over "we can do a clever thing for this one case but all the others will be different".

For a learning project like this one, this would probably be overkill, but my personal suggestion for instruction decoding is that it really pays in the long term to use a data driven decoder. It's fairly easy to do a handcoded "if bits A..B are 0b1000 and..." decoder for the basic integer parts of the instruction set, but especially as you get into complexities like SIMD and if you need your decoder to be easy to modify to add new instructions later this gets very unwieldy.

QEMU switched to a data driven representation with a python program to autogenerate the "check bit patterns and extract fields" code, and it's one of the better design overhauls we've done: we started using it mostly for new code but went back and converted some of the old handwritten decoders too. It's much easier to add a new instruction when you only need to add a line like

  USADA8           ---- 0111 1000 rd:4 ra:4 rm:4 0001 rn:4

and add a function trans_USADA8() that gets called with the field values, compared to trying to find the right place in a big existing set of handcoded switch and if statements to add the extra checks for the insn.

The others don't seem to have the MIT license pullreq added, so they are not open source; the source code is merely available. The repos have a note:

"This collection is meant for education, discussion, and historical work, allowing researchers and students to study how code was made for these interactive fiction games and how the system dealt with input and processing. It is not considered to be under an open license."

This github repo has been up for some years now (this old blog post has some back story: https://blog.zarfhome.com/2019/04/all-of-infocoms-game-sourc... ) -- AFAIK it's the source contents from an old hard drive image from back when Infocom was a company.

(I only checked hitchhikers and starcross, because github is giving a lot of error pages for these right now.)

This is partly because of the UK's ticketing system, which (like airline prices) heavily discounts for people who can book ahead and travel at off-peak hours. If you're able to do that, then for instance, right now you can get a ticket from Euston to Manchester on Weds 10th December mid-morning for 35 quid. If you're really price sensitive you can get there for just 14 quid (you have to change at Crewe and take an extra hour and a half of journey time).

The downside of this pricing system is (a) everybody complains about its complexity (b) if you really do need to travel at peak time or at very short notice you're going to pay a lot (c) it's really easy to make it look like it's a terrible rip-off by quoting the anytime walkup fare for an intercity journey :-)

Mmm, presumably big infrastructure projects like HS2 don't count as "operational" expenses. (Personally I put the huge costs of HS2 down to our complete inability to build anything in a reasonable timeframe and budget, rather than to privatisation in particular. The usual ludicrously long and extended consultation/legal objection/appeal process plus political meddling in the specification plus other stuff all factor in here.)

I think there's a couple of things about typical foreign experiences of UK public transport to note (some of this may not apply to you in particular, of course):

(1) Most tourists visit largely London and its near surroundings. Public transport in (and to) London is generally much better than other parts of the country.

(2) A lot of the downsides don't manifest if you're a relatively infrequent user and you're largely travelling at off-peak times. As a UK resident who doesn't commute on the railway, this also includes me -- my experience of trains is generally good because I travel at quieter times and I don't travel so often that unreliability is a regular experience.

(3) If you ignore the costs (by not being a taxpayer or because you're less price sensitive for infrequent travel and especially for holiday travel), then you're ignoring the large part of the argument which is "this privatization had massive inefficiencies and costs".

FWIW, the UK government pays about half of the 25 billion/year cost of the "operational rail industry" (source: https://dataportal.orr.gov.uk/statistics/finance/rail-indust...). I couldn't find the equivalent stats for Portugal with a quick search, so I don't know how that compares.

They're a consultancy: ultimately they do things because either some company paid them to do it, or because they think it will help bring in future business.

There are definitely companies out there who want to run "wrong endian" configs -- traditionally this was "I have a big endian embedded networking device and I want to move away from a dying architecture (e.g. MIPS or PPC) but I really don't want to try to find all the places in my enormous legacy codebase where we accidentally or deliberately assumed big endian".

Personally I'm not in favour of having the niche usecase tail wag the general toolchain dog, and I think that's the sentiment behind Linus's remarks.

Oh hey, a 9000/340 in the Cambridge area. Almost certainly that originated with the university's Engineering department, who back in the 1990s got rid of a lot of these machines that they had been using as X terminals. My notes say they had six diskless workstations to each server, and kept the monitors to use with the replacement machines, which would explain why this person's 9000/340 has no disk or monitor.

Some truly terrible quality pictures of the one I used to own are at https://www.chiark.greenend.org.uk/~pmaydell/hardware/tiroth... (I have long since disposed of it). Some of the people who got the machines had a play around with getting Linux booting on them. Amazingly some of that code is still in the kernel, eg drivers/net/ethernet/amd/hplance.c so it might even still work ;-)

I suspect Dijkstra would have disagreed with you about "and" and "or", judging from his criticism of the technical report which had the line "even the standard symbols used for logical connectives have been avoided for the sake of clarity".

Personally I think one advantage of '&&' and '||' is that it's clear they're a notation that you need to know the syntax and semantics of. For instance typically '&&' is "short-circuiting" and will not evaluate its RHS if the LHS is true; a natural-language "if a and b then ..." doesn't suggest that critical detail or necessarily nudge you to go and check. (Not that Dijkstra was in favour of short-circuiting logical operators, to judge by https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD100... point 4...)

More generally, I'm not sure of the benefit of tailoring the language syntax for beginners rather than experienced practitioners; the advantage of '&&', '||' and the rest of the "C-like" syntax stuff in a new language is that it's familiar to a wide base of existing experienced programmers.

My guess would be that it's a split between employees in support (where being helpful to the customer is the aim and suggesting workarounds is part of the job) vs development (where it was almost certainly acknowledged as a bug but had to be weighed up against every other bug and feature for priority). Bugs with known workarounds which only affect a small slice of users are often not fixed very quickly.

Broadly speaking I think the instruction set doesn't make much difference (assuming it rises above a baseline level of capability). What did for all the workstation and minicomputer class vendors with non-x86 architectures was that x86 got good enough and was much much cheaper because of the volume of the PC market. At the lower end the business model (sell your CPU core to go into other companies' SoCs) was a lot more important than the architecture in Arm's eventual success I think (and the rise of riscv is absolutely down to its business model too).

Some of the things listed in that article are definitely architecture design mistakes (especially the lack of interlocks in MIPS I), but they're not deal breakers and some of them are fixable (later MIPS versions put in the interlocks so you didn't need to care unless you were targeting the older CPUs). In the end not that many programmers write assembly or compilers.

Personally I strongly do not want to get better at remembering dreams. At the moment I very rarely remember anything about dreaming, and on the very rare occasion that some fragment of memory from a dream pops into my head it is super confusing until I identify "oh, that must have been from a dream". I prefer to keep my memory uncontaminated with random garbage :)

You could definitely do better than x32 did (IIRC it is a bit of an outlier even among "32-bit compat ABI" setups). But even if the kernel changes were done more cleanly that still leaves the whole software stack with the ongoing maintenance burden. The fact that approximately nobody has taken up x32 suggests that the performance gain is not worth it in practice for most people and codebases.

Defining yet another 32-bit-on-64-bit x86 ABI would be even worse, because now everybody would have to support x32 for the niche users who are still using that, plus your new 32-bit ABI as well.

In practice it seems like it's not as simple as that; see this lkml post from a few years back pointing out some of the weird x32 specific syscall stuff they ended up with: https://lkml.org/lkml/2018/12/10/1145

But my main point is that the complexity is not in the one-off "here's a patch to the kernel/compiler to add this", but in the way you now have an entire extra config that needs to be maintained and tested all the way through the software stack by the kernel, toolchain, distros and potentially random other software with inline asm or target specific ifdefs. That's ongoing work for decades for many groups of people.

The problem is that it's relatively easy to add "supports both endiannesses" in hardware and architecture but the ongoing effect on the software stack is massive. You need a separate toolchain for it; you need support in the kernel for it; you need distros to build all their stuff two different ways; everybody has to add a load of extra test cases and setups. That's a lot of ongoing maintenance work for a very niche use case, and the other problem is that typically almost nobody actually uses the nonstandard endianness config and so it's very prone to bitrotting, because nobody has the hardware to run it.

Architectures with only one supported endianness are less painful. "Supports both and both are widely used" would also be OK (I think mips was here for a while?) but I think that has a tendency to collapse into "one is popular and the other is niche" over time.

Relatedly, "x32" style "32 bit pointers on a 64 bit architecture" ABIs are not difficult to define but they also add a lot of extra complexity in the software stack for something niche. And they demonstrate how hard it is to get rid of something once it's nominally supported: x32 is still in Linux because last time they tried to dump it a handful of people said they still used it. Luckily the Arm ILP32 handling never got accepted upstream in the first place, or it would probably also still be there sucking up maintenance effort for almost no users.

The unexpected thing in that particular case is that even if you were well aware and avoided the flag when building your numeric code, the way some other non-numeric-computing person compiled some unrelated non-numeric module like "gevent" could result in the fast-math behaviour being applied to your code too. (Happily gcc has now fixed this.)

That isn't what I want, though. I don't see any point in the index as a construct -- I am happy with changes being either (a) not in any commit, just in the working directory or (b) in the most recent commit. Somewhere lurking in the middle is just confusing.

What I mean is that I do not want a single "swiss army knife" rebase command that does everything with lots of options to remember. It's fine to have that in the toolbox for the once in six months weird requirement. But for the simple cases I do every day I want simple commands that each do one thing and have memorable names.

On that first point, there's a use case I sometimes have where stgit feels very clunky:

* I have a branch foo with a stack of patches which are the thing I'm working on, based on a master branch

* I have a separate stack of patches on a branch bar (let's say this is a feature that interacts with foo but it's not ready to upstream yet or maybe at all)

* I want to test and work on the combination of foo and bar and make changes that might need to be updates to some patch in foo, or to some patch in bar

At the moment I pick all the patches in foo onto bar in order to do the work and updates in this combined branch, squashing fixes and changes into appropriate patches. Then once I'm happy I go back to the foo branch, blow away the old patches and re-pick them off my combined branch.

This works but feels super clunky -- does jj do better here? That would be a real incentive to try it out.

For the rest, they don't sound like they're strong enough to beat "I've used stgit for 10 years and have a solid workflow with it".

And I just scanned the jj rebase docs and it looks awful, everything I moved to stgit to get away from. I do not want to think about managing a patch stack in terms of "move a bunch of revisions to a different parent". I like having a straightforward stack of patches that I can push, pop and reorder and list. Don't make me think about graphs of commits and multiple rebase suboptions and all that for something that I do all the time in my main workflow, please.

Yeah, I get the impression jj is good for this, and if I were using raw git then it would be a massive upgrade. Luckily for me stgit already does what I want in this area so I have no strong need to investigate alternatives, but if stgit ever bitrots then jj might be a useful next thing.

I find myself from time to time with stuff in the index (merge conflicts in particular I think can result in this). I never put anything there explicitly. I would love to be able to configure git such that the index didn't exist, but I can't.

I would love the git index to not be a thing you had to care about unless you deliberately wanted to use that feature, but in my experience this is not the case...it feels to me like an implementation detail that surfaces into the UI more than it ought to.

As an stgit user, this seems like a weird workflow to me. I never want to have that many uncommitted changes just floating around that will eventually belong to multiple commits. If I'm halfway through something and realise "oh, it would be good to do xyz first" I don't want to have xyz's changes and my half-way-through changes all mixed up -- I want to pop the half-way-through stuff, do the xyz stuff and commit it, then re-push the half-way-through stuff to keep working. If I'm looking at a diff and picking out parts of it then I've done something wrong -- I have a tool for doing it but I only need to use it every couple of months...

I end up with "neatly separated does-one-thing commits" but I get there by building them up as I go along, not by writing a ton of code and then trying to split it up afterwards.

Yeah, we do try to maintain at least some back compat. Some things go through a deprecate-and-drop cycle, but that is more often driven by "the old thing is a pain to maintain internally" than by "the new thing is more user friendly".

New top level command line options are rare these days, and magic "do what I mean" options also rare: we tend to prefer "tell us specifically what you want".

The countervailing force here is the desire for command line backwards compatibility. Every time you change a default to be something that makes more sense today, you break the existing working setups of some unknown number of people...

The approach the project has settled on is to say that providing user friendly defaults should be the job of a "management layer" piece of software like libvirt, and QEMU proper should concentrate on providing flexible and orthogonal options which that other software can use to tell it what to do.

For a counterexample in the other direction, the 8-track system uses "cartridge" for its enclosure-with-audio-on-magnetic-tape object.

Though English, French, etc sharing the same unicode codepoints is not as far as I'm aware problematic, whereas Chinese and Japanese characters sharing codepoints does cause wrong behaviour (wrong shape of character used in text because renderer has to guess whether to use a Chinese or Japanese font) and has to be worked around by marking up text as "this is Japanese"...

It might also have a different atmosphere on a dark evening lit only by candlelight, compared to "lit as brightly as possible for photography".

There are, but you have to run enough of the javascript on the page and from the cdn for them to to show up.