Category: ARM

the future isn’t built on arm

whbeebe
Get this book now

I have been working with Arm (or ARM) processors for decades, going back to the 1990s. Arm used to be an acronym for Acorn RISC Machines because it was the BBC Acorn Computers that developed the initial instruction set architecture (ISA) for a processor that would be better than what was available at the time, which was Intel’s 16-bit 80286. Two engineers on staff designed the first ARM processor. Just two. Their first silicon release was ARM1 in 1985. The ARM processors themselves would go into many computers of the late 1980s to 1990s, not the least of which was the Apple Newton. The ARM portion of Acorn Computers would eventually be spun off in 1999 as Advanced RISC Machines. Thus would begin the long uphill marketplace climb to mobile marketplace dominance today.

So here we are with Arm getting ready for its initial public offering as a publicly traded company. And Arm has amassed an army of lawyers to go out and do what only lawyers can do, which is to stomp anything that smells like it might be a threat to Arm’s hegemony in this space, or possibly using their “mark.” And thus we come to Maria Markstedter and what used to be her web site, arm-assembly[dot], but which has been renamed due to said Arm lawyers to https://leg-assembly.com/ . That site has been available for years, with the full knowledge of earlier Arm. Ms. Markstedter has been one of many supporting resources for Arm, providing a needed teaching resource, especially when it comes to deep security issues which reverse engineering (especially of malware) can provide.

I have my own copy of the book Arm Assembly, and I’m glad I serendipitously purchased mine when I did, because the lawyers are threatening to have the book reprinted if they find anything they don’t like it in. If you want the first copy of that book I suggest you grab a copy before they’re all gone. I got mine at Amazon.

So what can we do against Arm? The same thing we did against Intel back in the late 1990s and early 2000s. Promote an alternative. In this case it should be RISC-V (pronounced RISC FIVE). RISC-V is a ten-year-old ISA that was developed at Berkeley, the same university complex that gave us the first RISC chips that led directly to MIPS, SPARC, and yes, even the first ARM chips. Except this time RISC-V is an open ISA, meaning anyone can create silicon using it and not have to pay for the privilege. And more importantly not get bullied and threatened by any controlling organization or business, which is what Arm has evolved into.

So here I am again doing my small part to advance a new way of computing. I am but one of very many. From what I can tell the use of RISC-V processors are rising, starting with the low end in embedded projects — just like it did with Arm. If I can spec a RISC-V processor in a design, I will. If I can’t, I won’t. But over time RISC-V processors will only get better, and those design wins that go to another processor today will go to RISC-V tomorrow — just like it did with Arm. Frankly, as with Intel, Arm has only itself to blame.

Links

RISC-V International — https://riscv.org/

RISC-V Technical Wiki — https://wiki.riscv.org/

RISC-V 32 & 64-Bit MCUs and MPUs — https://www.renesas.com/us/en/products/microcontrollers-microprocessors/risc-v

SiFive — https://www.sifive.com/technology/risc-v

Arm’s lawyers want to check assembly expert’s book for trademark missteps — https://www.theregister.com/2023/09/12/arm_markstedter_domain/

 

building and running deno 1.8 on a jetson xavier nx

whbeebe

I’ve been wrestling with building Deno on my Jetson Xavier NX running Nvidia’s version of Ubuntu 18.04.2 as part of L4T, or Linux For Tegra (although I tend to think of ‘T’ for Tensorflow). Deno is a reimplementation, if you will, of NodeJS in Rust, attempting to correct many of the bad design decisions that went into Node over time. Deno was created by Ryan Dahl, the original creator of NodeJS, so he should know where the skeletons of Node are buried.

The problem with installing and working with Deno on the Xavier is that it’s Arm-based, whereas all the other environments are x86-based. You can thus download and update (deno upgrade) Deno natively, whereas on the Xavier you need to install a native distribution of Rust, then build deno on the platform with cargo build deno. This worked for all of deno versions up to 1.6.7, then 1.7 was released and building deno on Arm failed repeatedly due to a failure to build librusty_v8. I filed a bug report over two weeks ago, and then, three days ago, I got a response from one of the devs telling me that there was “no pre-built 0.17.0 static library for aarch64 but there is one if you upgrade to 0.20.0.” Sure enough, when I re-ran cargo build deno and watched the task pull and build all the libraries, it pulled librusty_v8 version 0.20.0, which successfully built along with everything else. I have since closed the bug (see https://github.com/denoland/rusty_v8/issues/630 ).

The big draw for me is Deno’s experimental support for WebGPU API. I ran the example given in the release notes ( https://deno.land/posts/v1.8 ) and copied the results into the top of this post. I doubt that JavaScript running on Deno will replace Python as the front-end for ML running on the Jetson Xavier, but I can see it supporting Python, especially with web-based development. I am no fan of Python’s web frameworks, and I’ve lost my disdain for JavaScript over the past 12 months due to another task that showed I could use minimal JavaScript to cleanly solve a knotty problem. Deno also gives me plenty of powerful examples of programming in Rust, so there’s that angle.

Since retirement I’ve explored more interesting languages and their uses than I ever did in the last five years of my regular employment. It wasn’t so much ageism as it was my employer’s adamant insistence that development was their way or the highway. I’m now free to follow my own path(s) and finding what I’m learning to be new, interesting, and challenging in a good way.