2017 May 01 14:00

I’ve written a tutorial on threaded code implementations and also an exploration of the difference between call and branch-and-link instructions, and how that difference relates to threaded code.

Enjoy reading!

2017 April 11 00:17

Why am I excited about RISC-V?

I just posted a response on GitHub to the question “Is RISC-V the bee’s knees?” and thought I should re-post it here.

I kinda feel the way I felt back in the 80s and early 90s when ARM was the underdog. They had a new, fresh design, a small-is-beautiful approach, and a sense of openness. (I have an ARM Assembler Cookbook that has some amazing ideas and code in it – circa 1993 or so.) Since then ARM have become much more closed and proprietary. Their clean, tiny core has grown an instruction set that rivals x86 in its complexity. And it’s only getting worse with their move to 64 bits.

RISC-V appeals to me in the same way that ARM did in those early days, and that Lua always has. I’m on record celebrating Lua’s parsimony in an era of profligacy. RISC-V has the same sense of parsimony.

Having written a bunch of assemblers and disassemblers (and simple compilers too), I care about instruction sets. RISC-V really hits a sweet spot. The design is impeccable; and the encoding rather clever. I especially appreciate that the Compressed instructions are disjoint from the “standard” set – not some tacked-on after-thought that requires a new mode (Thumb, anyone?) and lots of annoyance and complexity for the compiler and OS people.

I also think it has legs. I really hope that SiFive make a big splash, and I’m trying to help out in my small way by making tools that might be useful to people on this new cutting edge – people who are exploring the architecture and bringing up new systems.

I knew ARM was going to succeed. I should have bought their stock! But success has ruined them, in a way. Yes, their CoreSight Debug stuff is cool and well-designed, but Thumb2 is so hairy that I never finished my disassembler, and never even started the assembler. I didn’t mean to, but I kind of gave up on Cortex-M.

And I totally buy the RISC-V propaganda about having a single instruction set for an entire SoC. Right now there might two or more for the core, another for the DSP, another for an “embedded controller”, etc. You have to have knowledge of each, toolchains for each, etc. It’s a nightmare.

Having “one instruction set” to rule them all is a great idea. And one with built-in support for co-processors and instruction-set extensions! (Well, ARM had that too. The co-processor bit at least.)

Having a truly free instruction set that can be meaningfully used for both teaching and research is, frankly, amazing. And it’s a nice one, too! An inspiration, even!

So, yes – I think RISC-V is the bee’s knees. ;-)

As a side note: I was pretty excited about the MSP430 before I got excited about RISC-V. The MSP430 was probably the easiest instruction set to write an assembler and disassembler for, and because it’s almost a PDP-11 – with the perfect mix of post-increment instructions and PC-as-a-general-register – writing an ITC Forth was not only totally trivial, but rivals native code in speed. (ITC NEXT is on par with doing a call and return, if not faster.)

Oddly, even though MSP430 is totally CISC, I was able to take the MSP430 kernel and meta-compiler and rewrite them for RISC-V in no time – a day or two maybe.

2017 April 06 14:43

Big news today!

Two things:

What this really means is that muforth can now do all of the following:

See the full instructions for getting started with RISC-V. I’ll also keep up-to-date a page with the status of RISC-V support in muforth.

2017 February 20 12:51

Welcome to 2017!

I won’t say “happy 2017” because we now live in a strange time of hacked elections and dire futures. With luck the year will improve as it goes along – but events continue to suggest otherwise. I’m going to try to stay busy working on muforth, regardless of the fraught political situation.

MSP430 updates

I’ve been working steadily on tweaks and fixes to the MSP430 target compiler. It is complete enough now to target compile Forth code, and do pretty featureful remote (tethered) execution on the target. There are a few things missing from the MSP430 Forth kernel – multiply and divide for example – so there is work to be done there.

And there is little to no documentation – other than the Git commit log (where I often wax prolix) – so getting started can be a challenge. Maybe I need a forum? But perhaps I should wait until there are more than two users... ;-)

RISC-V arrives in silicon!

If you haven’t been following the story, RISC-V (say “risk five”), a new computer architecture developed at UC Berkeley, aims to turn the world of computer architecture – and hopefully computing – on its head.

Originally developed for teaching and research, RISC-V is now taking on the world of commercial silicon. The founders of the project – Krste Asanović, Yunsup Lee, and Andrew Waterman – have spun off a company – SiFive – that aims to make developing custom RISC-V silicon easy and (relatively) inexpensive. (One neat thing about the architecture is its built-in support for instruction set extensions and custom co-processors.)

This talk by Krste Asanović is a great introduction to RISC-V:

In order to get the ecosystem growing, SiFive have developed the first silicon – the FE310 – and a development board to exercise it – HiFive1.

hifive1-board.jpg

Previously it was possible to run RISC-V only in simulation (slow) or on an FGPA (somewhat faster). Now we can get an idea of what is possible in real silicon: the HiFive1 board sports a 32-bit RISC-V chip running at 320 MHz! (This is a 180nm design. They have another design in the pipeline with a more sophisticated core and targeting a much smaller process that will compete with ARM-based application processors.)

The HiFive1 is available from Crowd Supply. Go grab one! Or five! I’m going to get one, and I plan to get some kind of meta-compiled Forth running on it – with the help of muforth, of course. ;-) So I should be, in short order, committing an assembler and prototype meta-compiler for RISC-V!

And props to Crowd Supply for their Proclamation of User Rights, which specifies that Creators can not trample on the rights of Users to explore, change, combine, criticize, and otherwise truly own the product, and further requires Creators to take care with respect to Users’ privacy and security.

Digital products are hugely problematic, thanks to the DMCA. Given the current state of law here in the USA, you don’t truly own any product that you purchase (not license, but purchase) that contains software (or firmware). That software is the property of the manufacturer, and any efforts on your part to understand, modify, or fix it can mean breaking the law! Talk about a chilling effect!!

Forcing Creators (who use the Crowd Supply platform) to guarantee the freedom of Users to truly own the products they purchase is a huge win for Users. Bravo.

The Electronic Frontier Foundation (EFF) is also working hard on this issue.

Web site update

This site started out as a clone of Nimble Machines and inherited all of its problems – chiefly, the lack of readability. Try as I might to choose attractive and interesting fonts, the sites remained difficult to read on-screen.

I recently spent several hours digging through Google Fonts – and what a load of dreck to search through! I almost gave up in despair. I kept finding fonts I liked, but somehow every combination I tried looked terrible.

The chief obstacle was finding a readable body font. I used the Guardian newspaper as my model. A big part of the personality of the Guardian is the custom typeface, which is also supremely readable. I wanted to find something similar. Merriweather seemed like a possibility, but it looked terrible when I tried using it. The available weights were either too light or dark, and it didn’t resonate with any of the sans-serif fonts I wanted to use for headings.

I finally settled on a trio of fonts that seem to work well together. The body font is Droid Serif; the title and heading font is Fira Sans (commissioned by Mozilla for Firefox OS); and the monospace font used for code and Forth word names is Fira Mono (also from Firefox OS).

I’m going to leave the fonts alone, for now, though I may still tweak the (mostly non-existent) color scheme.

This minor “redesign” may show up on Nimble Machines as well... ;-)

I’ve also removed pages that were essentially copies of content from Nimble Machines. I want the pages here to be truly muforth-specific, and I plan to “cross-link” to pages on NM rather than have copies here. I feel like that is a cleaner solution.

Read the 2016 journal.