Almost a decade ago, I wrote about how the venerable and elegant but third-tier programming language Scheme had no way to access the program arguments that would work across different implementations, and pointed out that type of large stumbling block tends to hinder the adoption of a language. The last time I worked on a serious project in Scheme was only a little later. So not much news from the Schemeoverse has reached me since then. Which is why I just learned that four years after that post, five years previous to the present day, the Scheme community decided to fix that and standardized on option (c) from that post: (command-line) gets you your program’s arguments. Progress marches on! In the case of Scheme, that march is just veerrryyyy slow.

Lookee, lookee, seems like the Europeans have figured out how crazy DST is and are likely to drop it soon (by the standards of these things, so maybe in a couple years). Keep pushing for DST abolishment, everyone — progress is being made.

There’s this video going around “An Open Source CPU!?” about SiFive’s implementation of RISC-V being “an open source CPU”, but it’s so duplicitous that I wanted to tear out my hair as I watched it. RISC-V is an interesting and worthy project, but the video is misleading in so many ways it’s hard to know where to begin.

For one thing, the x86-16 ISA wasn’t just hacked up in a few weeks from nothing. Intel’s architects spent months on it, and it was based on Intel’s 8-bit 8080 ISA, which was in turn informed by the experience of their earlier 8008 ISA. It had also already been on the market for a few years by the time IBM got around to the PC. For another thing, the x86-32 ISA was hardly lacking competition during its era of desktop dominance, with Motorola’s 68000, IBM’s Power Architecture, and DEC’s Alpha all big-name-backed ISAs trying to displace it. When the time came for 64-bit PCs, even Intel itself failed in its attempt to push a new kind of ISA for the PC market with its Itanium architecture.

Regarding the RISC/CISC divide, it is true that CISC processors don’t execute their ISA instructions directly in hardware now, but instead run RISC microcode (because RISC instruction-handling circuitry executes faster and is easier to design) for a CISC ISA interpreter. But that doesn’t mean RISC is best for application or system code, because microcode has no instruction cache! In the embedded systems and mobile-device markets, ARM had to abandon the “elegant” simplicity of their RISC ISA and supplement it with non-RISC “Thumb” and then “Thumb-2” extensions to raise its code density (important on small processors with small instruction caches) to keep x86 ISA microcontrollers, with their dense CISC code and ever-decreasing prices, at bay. As is often the case when competing technologies butt heads, the best solution is to find a way to use the advantages of both!

The video’s title is “An Open Source CPU!?” — and this is its biggest lie, because SiFive’s CPU being open is presented as something new, which is very much not true. Even if you dismiss all CISC designs as unworthy, there are open RISC specs with open source implementations that predate RISC-V, both grassroots and of commercial origin. Furthermore, SiFive’s CPU not only isn’t the first open source RISC processor, it’s not even the first open source RISC-V processor! You can get open source implementations of RISC-V here (VexRiscv) or here (ORCA) or here (Sodor).

This video is just an advertisement of SiFive’s pretending to be an independent informational video, spreading misinformation about the history and present state of microprocessors. (For your amusement, go and pause the video around 6m12s — the presenter is stating the inferiority of other open ISAs compared to RISC-V while showing a changelog on GitHub. But the changelog shown is not that of anything to do with another ISA, but the opposite: it’s actually the changelog for the port of gdb to RISC-V! The presenter could have grabbed a screenshot from the GitHub pages of the ZPU project with insignificant additional effort and shown something that was actually applicable to his claim, but once you’ve stepped off the straight-and-narrow path of honesty onto the wide highway of dishonesty, why bother?)

In short, that video is complete and utter BS, the presenter should be downvoted into YouTube oblivion, you should never pay one red cent for anything from SiFive, and RISC-V deserves better. It’s strong enough that it should be able to fight honestly, and having its proponents descend to dishonest shilling for one corporation is disgraceful.

Today most of the United States switches from Standard Time to Daylight Savings Time. But it looks like in the fall Florida won’t be switching back to Standard Time like the rest of us. And good on them! As I’ve said before, staying with this tradition of changing our clocks twice a year is ridiculous in this age.

CNN spends some digital ink talking about a world-wide survey of countries’ reputations in this article here. It’s an interesting read, even though (or partly because?) it’s a short article.

But look at the final three sentences:

Canada and Japan tied for fourth place. The rest of the Top 10 is Italy at No. 7, Switzerland at No. 8, Australia at No. 9 and Sweden at No. 10. No non-Western countries managed to crack the Top 10.

“No non-Western countries”, eh? Australia is #9 on the list, and they’re in the eastern hemisphere. But Australia, while geographically closer to Asia than Europe, is culturally closer to Europe than Asia, so maybe that’s what they mean. But look at who’s #4 on the list: Japan. The Land of the Rising Sun is as east as Eastern gets. What they mean is that no developing nations are on the list, only those with advanced economies. But nobody wants to be part of an undeveloped economy, so of course the list is going to be exclusively advanced economies.

The “non-Western country” observation is either simply wrong (geographically or culturally “Western”) or meaningless (“Western” as a synonym for advanced economy). It’s not that Asia is undeveloped, it’s that undeveloped economies are undeveloped. The non-Western country quip is meaningless except to the extent that Western ≡ advanced is a racist presentation of the banal equivalence advanced ≡ advanced.

Exactly how one goes about building .so files^* isn’t widely understood, and the documentation on it is overcomplicated IMHO. So, I figure the web needs a tutorial demonstrating how to build an extremely simple .so file. Et voilà, here’s a step by step guide for building a .so file on Linux or a similarly flavored Unix using a GNU-compatible toolchain.

We’re going to make two .o files, “call_me.o” and “die.o”, and combine them into a single “call_me_and_die” shared library. Making a library is very much like making an executable, just with some tweaks to the build commands and some extra steps at the end. To make our “call_me_and_die” library, we start the way we would with a “call_me_and_die” executable: writing a .h file for the common function signatures. File so_tut.h:

extern void call_me(void);
extern void die_die_die(void);

(more…)

Today’s xkcd riffs a common frustration about busy files: programs that can’t do their intended operations on them rarely (if ever) specify the file that’s busy or tell the user which programs are using the file — and without that knowledge, the user can’t fix the problem.

There are tools that can help you discover those things, as I describe using ten years ago, but I’d already been running into EBUSY problems for ten years by then, and the old guard before me for another ten years beyond that. Why haven’t things improved?

Sometimes file_operation(filename) fails — hey, this happens, busy files are a thing, ain’t nothing your program can do about that. But report to the user that file_operation on filename failed for reason strerror(errno)! Not reporting the filename is just sloppy programming.

It’s not like the tools have gotten any better. What, you think it’s acceptable to make the user trace your program, looking through a haystack of every system call to find the needle which is the program’s critical failure? Is that work you’re putting on the user’s shoulders less than sticking the filename in the error message? This has sucked for two generations now. Please help making it suck less.

… because you might get it.

Look at things right now: James Comey deserved to be fired. Specifically, he deserved to be fired because of his interference in the election. Wish granted! He’s been sacked for (so writes the Sacker in Chief) that reason in particular. But now, seemingly nearly everybody (yours truly included) thinks the act of terminating Comey was wrong. We live in interesting times. May you not come to the attention of important people.

Mercurial’s  hg diff  command supports a  --reverse  option which shows the regular diff output except it reverses the sense of the comparison — i.e., it goes from the “destination” to the “source” (git diff  supports this action too, but as the flag “-R”). Most of the time you want the ordinary “forward” sense, but occasionally the reverse sense comes in handy, and that’s why that option’s there. On rare occasion, I’ll even want to do this to files not under version control, but the regular system diff doesn’t support this feature.

So, after hitting this deficiency again recently, I decided to write up my own reverse-diff command which would swap its last two arguments and call diff. I started with the shell, as dealing with command arguments and calling programs is its forte. But it turned out to be surprisingly difficult to do stuff like copy the argument list or mess around with the end and near-end of the argument list, which I thought would be dead-simple operations. After futzing around with shell variables and parameters and the various options for variable/parameter expansion for something like 25 minutes, I came to my senses and did it in something like two minutes using C, where nothing’s going to interpret any kind of data as anything unless you explicitly request it to, and array manipulation is built in with clean syntax. All I had to do was swap argv[argc-1] and argv[argc-2] then execvp("diff", argv), easy peasy.

And if I golf argc and argv into c and v, then it fits in 130 chars [source]:
#include <unistd.h>
int main(int c, char**v) {
 if (c>2) { char*t=v[c-2]; v[c-2]=v[c-1]; v[c-1]=t; }
 return execvp("diff", v);
}

I could probably omit the check for ≥2 arguments, as the system diff doesn’t support the convention that a missing file argument means to use stdin (instead, it treats a filename of - (single hyphen) as representing stdin), but perhaps it’ll be used by somebody who’s installed an enhanced diff program.

I’m also amused that each of my “twitcodes” has been in a different language: shell, perl, python, and now C.

I found the C puzzles webpage by Gowri Kumar to be a very interesting collection of oddities of the C language and some of its basic libraries. If you work with C for fun or profit, I encourage you to go and give them a try. I found very few of them to produce behavior I hadn’t expected, which could be a symptom of overfamiliarity with C. I did find a few surprises though, which I felt warranted further investigation. (more…)