A RISC-V LISP Compiler…Written In Lisp

Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!

The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.

The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.

We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.

Time’s Up For Mbed

In a forum post has come the announcement that mBed, ARM’s accessible microcontroller development platform, is to reach end-of-life in July 2026. This means that the online platform and OS will no longer be supported by ARM, though the latter will remain an open source project. The website will be shuttered, and no new projects can be created after that date using ARM infrastructure.

mBed was originally launched back in 2009, as a competitor to the Arduino IDE for ARM’s chips. Its easy development made it attractive and there were soon an array of boards from different manufacturers supporting it, but perhaps due to its support for only the one architecture, it failed to find success. It’s certainly not the first time a single-architecture microcontroller development platform has been discontinued, we need only look to the Intel Edison for that, but given the success of ARM platforms in general it’s still something of a surprise. Perhaps it’s time to take the press release explanation that other platforms such as Arduino have simply been much more popular.

Will a community form around an open source mBed? Given that it’s been a definite minority among Hackaday projects over the years, while we hope it does, we’re not so sure.

mBed board image: Viswesr, CC BY-SA 3.0.

M1 Development Board From Scraps

Apple is fairly notorious for building devices that are difficult to repair, but with the right tools it’s often not completely impossible to circumvent some of their barriers. As they say, every lock has a key. [dosdude1] has wanted a specific M1 development board for a while now and has been slowly piecing together everything he needs to cobble one together, and finally got this unit running despite many roadblocks put in his way by Apple.

The development kit is a Developer Transition Kit  or “DTK” meant for developers during Apple’s transition from Intel chips to their own in-house ARM-based M1 platform. This particular version is in a Mac Mini form factor but it has a few hurdles to clear before it powers on. First, the board was cut in a critical location that shorted out many of the PCB layers, so this had to be carefully filed down to remove the shorts. It was also missing a few tiny surface mount components and a NAND chip, but these were scavenged from other scrapped parts and assembled into a fully working machine.

There are a number of other non-physical problems to solve here as well, too. Apple coded their NAND chips to work with specific WiFi modules so if these aren’t programmed to work together the computer will get stuck in a boot loop. But with that and a few other details out of the way [dosdude1] finally has his DTK up and running in a 2018 Mac Mini chassis, right down to the working power LEDs. We’ve seen all kinds of PCB damage before (although not often quite this intricate) and even PCBs repaired that were snapped in half.

Thanks to [CodeAsm] for the tip!

Continue reading “M1 Development Board From Scraps”

RISC OS Gets An Update

There should be rejoicing among fans of the original ARM operating system this week, as the venerable RISC OS received its version 5.30 update. It contains up-to-date versions of the bundled software as well as for the first time, out-of-the-box WiFi support, and best of all, it can run on all Raspberry Pi models except the Pi 5. If you’ve not encountered RISC OS before, it’s the continuing development of the OS supplied with the first ARM product, the Acorn Archimedes. As such it’s a up-to-date OS but with an interface that feels like those of the early 1990s.

We like RISC OS here, indeed we reviewed the previous version this year, so naturally out came the Hackaday Pi 3 and an SD card to run it on. It’s as smooth and quick as it ever was, but sadly try as we might, we couldn’t get the Pi’s wireless interface to appear in the list of available network cards. This almost certainly has more to do with us than it does the OS, but it would have been nice to break free from the tether of the network cable. The included Netsurf 3.11 browser is nippy but a little limited, and just as it was during our review, sadly not capable of editing a Hackaday piece or we’d be using it to write this.

It’s great to see this operating system still under active development, and we can see that it so nearly fulfills our requirement here for a lightweight OS on the road. For those of us who used the original version, then called Arthur, it’s a glimpse of how desktop computing could, or perhaps even should, have been.

Why X86 Needs To Die

As I’m sure many of you know, x86 architecture has been around for quite some time. It has its roots in Intel’s early 8086 processor, the first in the family. Indeed, even the original 8086 inherits a small amount of architectural structure from Intel’s 8-bit predecessors, dating all the way back to the 8008. But the 8086 evolved into the 186, 286, 386, 486, and then they got names: Pentium would have been the 586.

Along the way, new instructions were added, but the core of the x86 instruction set was retained. And a lot of effort was spent making the same instructions faster and faster. This has become so extreme that, even though the 8086 and modern Xeon processors can both run a common subset of code, the two CPUs architecturally look about as far apart as they possibly could.

So here we are today, with even the highest-end x86 CPUs still supporting the archaic 8086 real mode, where the CPU can address memory directly, without any redirection. Having this level of backwards compatibility can cause problems, especially with respect to multitasking and memory protection, but it was a feature of previous chips, so it’s a feature of current x86 designs. And there’s more!

I think it’s time to put a lot of the legacy of the 8086 to rest, and let the modern processors run free. Continue reading “Why X86 Needs To Die”

Is This 3D Printed Third Arm Useful? Maybe?

Humans have two arms, and we do pretty good things with them. More is surely better, though, right? With that in mind, [Emily The Engineer] set out to make a third arm for popular YouTuber [This Old Tony], and our primary question is this: is it actually useful?

The basic design is based around a strapped-on arm brace, which mounts the additional appendage to the wearer’s forearm. It uses a motor-driven geared mechanism to open and close a gripper, but the first revision was incredibly slow to open and close, to the point of being almost useless. Changing out the threaded rod that drives the mechanism massively sped up the gripper, much to [Emily]’s satisfaction. Strength and mounting upgrades got it to the point where it could actually be used to lift objects like spray cans and bricks. Ultimately, though, the arm mount and controls do kind of prevent the user from using their left hand when they have the third hand fitted.

It’s a fun project, if not exactly a useful one, even if [Emily] does use it to carry extra grocery bags . It does have us wondering if some kind of shoulder or backpack-mounted arms could be useful, though. It’s certainly not up to the standards of modern prosthetic, but we do love the idea of human augmentation with additional robot limbs. Here’s hoping technology advances further to make builds like this more capable in future!

Continue reading “Is This 3D Printed Third Arm Useful? Maybe?”

The Nintendo Switch CPU Exposed

Ever wonder what’s inside a Nintendo Switch? Well, the chip is an Nvidia Tegra X1. However, if you peel back a layer, there are four ARM CPU cores inside — specifically Cortex A57 cores, which take up about two square millimeters of space on the die. The whole cluster, including some cache memory, takes up just over 13 square millimeters. [ClamChowder] takes us inside the Cortex A57 inside the Nintendo Switch in a recent post.

Interestingly, the X1 also has four A53 cores, which are more power efficient, but according to the post, Nintendo doesn’t use them. The 4 GB of DRAM is LPDDR4 memory with a theoretical bandwidth of 25.6 GB/s.

The post details the out-of-order execution and branch prediction used to improve performance. We can’t help but marvel that in our lifetime, we’ve seen computers go from giant, expensive machines to the point where a game console has 8 CPU cores and advanced things like out-of-order execution. Still, [ClamChowder] makes the point that the Switch’s processor is anemic by today’s standards, and can’t even compare with an outdated desktop CPU.

Want to program the ARM in assembly language? We can help you get started. You can even do it on a breadboard, though the LPC1114 is a pretty far cry from what even the Switch is packing under the hood.