If you don’t catch that, don’t worry. Hopefully by the end of the post you’ll have an intuitive understanding on the operation of all the other logic gates as well.

Logical operations such as AND, OR, XOR have weird and non-intuitive names. “Do you want apple or banana?” means you can either take either just the apple or just the banana (but not both). Yet on boolean logic, this would be written as apple XOR banana. Could we do better?

This question has been boiling in my head (and probably others). It’s been a running joke, how logical “A OR B” means “true if A is true or B is true”. But I find the naming breaks horribly when we step further. What’s the output of A XOR B XOR C?

I “discovered” that there’s actually an intuitive way of understanding all of these operation. It’s just that we need to rethink the name of all of the operations. I said “discovered” because I’m probably not the first one, there may be a literature about this, but this is how I was taught at school, and I presume many others as well, so I would like to build on this.

Let’s start simple. AND gate outputs true if all the inputs to it are true. On the other hand, OR gate will output true if some of the inputs are true. So let’s just call them that, all gate and some gate. This is also true for any number of inputs, so that all(true, false, true) = false because one of them is not true, whereas some(true, false, true) = true because some of them are true!

Next comes the negation gates. What’s a NAND gate? Well, it’s a gate that turns on when not-all of the inputs are true. So not-all(true, false, true) = true because not all of them are true. In contrast, not-all(true, true, true) = false because all of them are true. By the same logic, A NOR gate is not-some, which is technically correct but awkward to say. In some programming languages with Option type, the two variants are Some and None, so let’s just call NOR as the none gate: none(true, false, true) = false because it is only true if none of them are true: none(false, false, false) = true.

Lastly, let’s talk about the exclusive gates. XOR is commonly taught as checking if only one of the input is true, so for 2-input XOR, the output is true when A is true or B is true, but not both. It is also commonly taught that XOR outputs true if A is different from B. However, none of these explanations generalize. What about 3-input XOR? XOR(A,B,C) is the same as (A XOR (B XOR C)). Actually all of the logic gates can be chained associatively this way. If A is true, then in order to output true, B XOR C must be false by setting B=false, C=false or by setting B=true, C=true. A, B, and C here are actually interchangable (commutative) and this generalize to larger input XOR. In a sense, XOR is true when the number of true input is odd, letting me call XOR as odd gate. So odd(true, false, true, true, false) = true because the number of true is 3 (odd). Similarly, an XNOR gate is just a negation of odd gate, unsurprisingly called the even gate. It returns true when the number of true inputs are even. For 2-input XNOR, it outputs true when both A and B are false or true.

So to summarize: we now have all, some, not-all, none, odd, and even gates. Hopefully that makes more sense over the traditional namings!

The project allows the upstream Arch Linux PKGBUILDs to be compiled and ran on ARM devices. This contrasts to fork projects which maintain their own modifications.

For years, ArchLinuxARM (alarm) has been the go-to distribution for running the project on ARM devices. While it has served the community well, it operates as a separate project and requires significant number of modifications compared to upstream Archlinux project. These differences may even manifested as packages being out-of-date or even broken packages, such as the infamous chromium package not building on alarm project.

On the other hand, the ongoing effort has been to run mostly unmodified Archlinux PKGBUILD files with minimal modifications. This is supported as part of a recent effort RFC!32 which allows non x86_64 architecture to also be targeted by the Archlinux packages.

The project is currently usable with around 99% projects able to be built from upstream Arch Linux project, because a lot of the ARM-specific modifications have been merged to upstream PKGBUILD, so at least there’s a “legitimacy” aspect of the project. That said, the binary distribution is still entirely community-maintained.

Discussions are being done to know which ARM architecture to (eventually) officially support. The concensus between the community maintainers is to support at least ARMv8-a architecture with no interest in ARMv7 or lower because of the need of aarch64 instruction set. One of the member and myself are working on ARMv8-a itself, but the main efforts are currently targetting ARMv8.2-a, mainly because of package build failure that happened in the past. That issue has been resolved and there doesn’t seem to be any blocker in targetting ARMv8-a, other than the fact that significant efforts have been made on ARMv8.2-a.

More information on the project can be found on #archlinux-ports on liberachat IRC with documents written on Arch Linux Ports: AArch64.

I’ll try to write down the projects I’ve been working on here, so I can practice writing down things. I’m not sure how often I’ll write but this blog has an RSS if you want to keep in touch.