A Literate Assembly Language

A recent edition of [Babbage’s] The Chip Letter discusses the obscurity of assembly language. He points out, and I think correctly, that assembly language is more often read than written, yet nearly all of them are hampered by obscurity left over from the days when punched cards had 80 columns and a six-letter symbol was all you could manage in the limited memory space of the computer. For example,  without looking it up, what does the ARM instruction FJCVTZS do? The instruction’s full name is Floating-point Javascript Convert to Signed Fixed-point Rounding Towards Zero. Not super helpful.

But it did occur to me that nothing is stopping you from writing a literate assembler that is made to be easier to read. First, most C compilers will accept some sort of asm statement, and you could probably manage that with compile-time string construction and macros. However, I think there is a better possibility.

Reuse, Recycle

Since I sometimes develop new CPU architectures, I have a universal cross assembler that is, honestly, an ugly hack, but it works quite well. I’ve talked about it before, but if you don’t want to read the whole post about it, it uses some simple tricks to convert standard-looking assembly language formats into C code that is then compiled. Executing the resulting program outputs the desired machine language into a desired file format. It is very easy to set up, and in the middle, there’s a nice C program that emits machine code. It is not much more readable than the raw assembly, but you shouldn’t have to see it. But what if we started the process there and made the format readable?

At the heart of the system is a C program that lives in soloasm.c. It handles command line options and output file generation. It calls an external function, genasm with a single integer argument. When that argument is set to 1, it indicates the assembler is in its first pass, and you only need to fill in label values with real numbers. If the pass is a 2, it means actually fill in the array that holds the code.

That array is defined in the __solo_info instruction (soloasm.h). It includes the size of the memory, a pointer to the code, the processor’s word size, the beginning and end addresses, and an error flag. Normally, the system converts your assembly language input into a bunch of function calls it writes inside the genasm function. But in this case, I want to reuse soloasm.c to create a literate assembly language. Continue reading “A Literate Assembly Language”

Hackaday Links Column Banner

Hackaday Links: May 7, 2023

More fallout for SpaceX this week after their Starship launch attempt, but of the legal kind rather than concrete and rebar. A handful of environmental groups filed the suit, alleging that the launch generated “intense heat, noise, and light that adversely affects surrounding habitat areas and communities, which included designated critical habitat for federally protected species as well as National Wildlife Refuge and State Park lands,” in addition to “scatter[ing] debris and ash over a large area.”

Specifics of this energetic launch aside, we always wondered about the choice of Boca Chica for a launch facility. Yes, it has all the obvious advantages, like a large body of water directly to the east and being at a relatively low latitude. But the whole area is a wildlife sanctuary, and from what we understand there are still people living pretty close to the launch facility. Then again, you could pretty much say the same thing about the Cape Canaveral and Cape Kennedy complex, which probably couldn’t be built today. Amazing how a Space Race will grease the wheels of progress.

Continue reading “Hackaday Links: May 7, 2023”

The New Hotness

If there’s one good thing to be said about the chip shortage of 2020-2023 (and counting!) it’s that a number of us were forced out of our ruts, and pushed to explore parts that we never would have otherwise. Or maybe it’s just me.

Back in the old times, I used to be a die-hard Atmel AVR fan for small projects, and an STM32 fan for anything larger. And I’ll freely admit, I got stuck in my ways. The incredible abundance of dev boards in the $2 range also helped keep me lazy. I had my thing, and I was fine sticking with it, admittedly due to the low price of those little blue pills.

An IN-12B Nixie tube on a compact driver PCBAnd then came the drought, and like everyone else, my stockpile of microcontrollers started to dwindle. Replacements at $9 just weren’t an option, so I started looking around. And it’s with no small bit of shame that I’ll admit that I hadn’t been keeping up with the changes as much as I should have. Nowadays, it’s all ESP32s and RP2040s over here, and granted there’s a bit of a price bump, but the performance is there in abundance. But I can’t help feeling like I’m a few years back of the cutting edge.

So when I see work like what [CNLohr] and [Bitluni] are doing with the ultra-cheap CH32V003 microcontrollers, it makes me think that I need to start filling in gaps in my comfortable working-set of chips again. But how the heck am I supposed to keep up? And how do you? It took a global pandemic and silicon drought to force me out of my comfort zone last time. Can the simple allure of dirt-cheap chips get me out? We’ll see!

Hackaday Podcast 217: The Unintentional Space And 3D Printing Episode

Hackaday Editors Elliot Williams and Tom Nardi definitely didn’t plan on devoting most of this episode to 3D printing and space stories, but let’s be honest, it was bound to happen sooner or later. After an update on the Hackaday Prize, the discussion moves on to a pair of troubled spacecraft and the challenges of exploring the final frontier. From there you’ll hear about a chocolate 3D printer we’ve had our eyes on for years, the tools you should have next to your own (non-chocolate) 3D printer, and a bit of contemplation of what it really means to design for 3D printing versus traditional manufacturing methods. But it’s not all plastic fantastic — by the end of the episode you’ll also hear about some particularly bold high-altitude aviators and the surprisingly short time we have left with the humble barcode.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Going to be stranded on a desert island? Download the podcast now!

Continue reading “Hackaday Podcast 217: The Unintentional Space And 3D Printing Episode”

This Week In Security: Oracle Opera, Passkeys, And AirTag RFC

There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.

It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.

The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.

The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to. Continue reading “This Week In Security: Oracle Opera, Passkeys, And AirTag RFC”

Metallurgist working by the blast furnaces in Třinec Iron and Steel Works. (Credit: Třinecké železárny)

We Already Live In A Hydrogen Economy: Steel Production, Generator Cooling, And Welding Gas

Although generally hydrogen is only mentioned within the context of transportation and energy storage, by far the most useful applications are found in industrial applications, including for the chemical industry, the manufacturing of steel, as well as that of methanol and fertilizer. This is illustrated by how today most of all hydrogen produced today is used for these industrial applications, as well as for applications such as cooling turbo generators, with demand for hydrogen in these applications rapidly increasing.

Currently virtually all hydrogen produced today comes from natural gas, via steam methane reformation (SMR), with potentially methane pyrolysis making natural gas-derived hydrogen a low-carbon source. The remainder of hydrogen comes from coal gasification and a small fraction from electrolysis of water. The hydrogen is often produced on-site, especially at industrial plants and thermal power plants. So aside from any decarbonization efforts, there are many uses for hydrogen which the public appears to be generally unaware of.

This leads us to the somewhat controversial hydrogen ladder.

Continue reading “We Already Live In A Hydrogen Economy: Steel Production, Generator Cooling, And Welding Gas”

NASA’s Voyager Space Probe’s Reserve Power, And The Intricacies Of RTG-Based Power Systems

Launched in 1977, the Voyager 1 and 2 space probes have been operating non-stop for over 45 years, making their way from Earth to our solar system’s outer planets and beyond. Courtesy of the radioisotope thermoelectric generators (RTGs) which provided 470 W at launch, they are able to function in the darkness of Deep Space as well as they did within the confines of our Sun-lit solar system. Yet as nothing in the Universe is really infinite, so too do these RTGs wear out over time, both from natural decay of their radioactive source and from the degradation of the thermocouples.

Despite this gradual drop in power, NASA recently announced that Voyager 2 has a hitherto seemingly unknown source of reserve power that will postpone the shutdown of more science instruments for a few more years. The change essentially bypasses a voltage regulator circuit and associated backup power system, freeing up the power consumed by this for the scientific instruments which would otherwise have begun to shut down years sooner.

While this is good news in itself, it’s also noteworthy because the Voyager’s 45+ year old Multi-Hundred Watt (MHW) RTGs are the predecessor to the RTGs that are still powering the New Horizons probe after 17 years, and the Mars Science Laboratory (Curiosity) for over 10 years, showing the value of RTGs in long-term exploration missions.

Although the basic principle behind an RTG is quite simple, their design has changed significantly since the US put a SNAP-3 RTG on the Transit 4B satellite in 1961.

Continue reading “NASA’s Voyager Space Probe’s Reserve Power, And The Intricacies Of RTG-Based Power Systems”