Scan32bit

If anybody’s interested, I’ve updated my little scanner that examines code looking for 32 bit unsafe instructions.

In addition to the usuals (MOVS, LDM ^), it now adds support for things that don’t work or are marked as unpredictable on ARMv7+ or bogus instructions that now raise an exception, namely:

• SWP/SWPB
• LDR/STR with both registers being the same and writeback.
• LDM with the base register in the register list and writeback.
• LDRB with the destination being R15 ¹.
• Any data processing instruction with a register-shifted register, and any register being R15.
• Any LDM that uses writeback and contains only one register in the list.

That last one may be a potential lurking issue for us, as quite a bit of code uses stuff like LDMFD R13!,{R0} instead of LDR R0,[R13],#4, probably because it’s simpler to remember and on the old machines it probably didn’t make any notable speed difference.

However, the ARM ARM DDI 0406C.c ² notes, on page A8-398 (for LDMFD, elsewhere for other LDMs) that on ARMv7 or later, writeback and only one register should be considered unpredictable.
Um.

http://heyrick.ddns.net/files/scan32bit_0-03.zip

It’s written in BASIC, it isn’t crunched, and this one has had most of it rewritten to be a lot more readable and clear than the previous one(s).

¹ I’ve actually seen it. I’m guessing it was a typo. Thankfully that code path was never executed…

² This document is a mess. ARM, Thumb, and VFP are all listed together instead of in separate sections. The description of the instruction set thus spans 809 pages (p300-p1109), and is then followed by information on the ThumbEE instruction set, for some reason.
Kind of wish this was available printed; a PDF containing 2736 pages is ridiculous – PDFs are great for text searching, but awful for dipping into and/or cross-referencing. I did most of the instruction decoding referring to the printed ARM ARM second edition.

However, the ARM ARM DDI 0406C.c 2 notes, on page A8-398 (for LDMFD, elsewhere for other LDMs) that on ARMv7 or later, writeback and only one register should be considered unpredictable.

You might want to check the latest version (C.d); I’m not seeing the warning you mention.

Finally found it.

It’s there. P399. The bit in monotype at the bottom:

if wback && registers<n> == ‘1’ && ArchVersion() >=  7 then UNPREDICTABLE;

That’s not checking if there’s one register. It’s checking if the base register is in the list.

Well, thank God for that.

Of course, if the three billion pages defined what “registers<n>” meant….

That said, when has “load a register that’s the same as the base register with writeback” ever worked? What’s the register supposed to be on exit?

Of course, if the three billion pages defined what “registers<n>” meant….

Extract bit ‘n’ of the bitstring ‘registers’. They have an entire chapter devoted to defining the pseudocode language :-) (Philosophical question: If your pseudocode language has a detailed specification, doesn’t that mean it’s not proper pseudocode?)

That said, when has “load a register that’s the same as the base register with writeback” ever worked? What’s the register supposed to be on exit?

Prior to ARMv7: The instruction will ‘work’, but the base register will be left with an unknown value.

ARMv7+: The entire instruction is considered unpredictable and may cause an abort or some other malfunction.

They have an entire chapter devoted to defining the pseudocode language :-)

Easy to miss in an electronic document of ~3000 pages. I did a search for “registers<n>” and “<n>” and it showed up nothing other than the times it was used in the definition.

If your pseudocode language has a detailed specification

Just think, we could have a processor that can execute microcode written in that pseudocode. ;-)

Prior to ARMv7:

Ah, so basically “it’s bollocks and you’re an idiot” and the only difference is now ARMv7 will tell you so. ;-)

It’s easy enough to remove this check from the scanner (it’s just plain BASIC), though I probably ought to change it to look for LDMFD/STMFD with only one register and warn that this is inefficient these days.

though I probably ought to change it to look for LDMFD/STMFD with only one register and warn that this is inefficient these days.

That should get you an interesting number of results from various parts of the OS, as for various apps out there…

from various parts of the OS,

Hmm, aren’t there PUSH and POP macros, or somesuch, for exactly that purpose?

(aside: BASIC supports them! In Zap’s disassembly mode, pressing Enter on a line will allow one to edit it; try PUSH {R0} and PUSH {R0-R3}@. ;-)

as for various apps out there…

Oh, I know. That’s why 😱 at thinking that this was soon to be an instruction that the processors wouldn’t like.

Hmm, aren’t there PUSH and POP macros, or somesuch, for exactly that purpose?

I don’t have the current DDE but the version I do have has, IIRC, an interesting instruction in the POP and PUSH. Can but hope the latest avoids the deprecated¹ use.

¹ The spellcheck saw a missing letter/typo and suggested “defecated” :)

IIRC, an interesting instruction in the POP and PUSH.

HCF?

ARM ARM DDI 0406C.c … This document is a mess.

I had to check that I didn’t write that…thank goodness, no, I didn’t. 0406A is the last one I was responsible for… 8~)

Mind you, that was probably quite a mess too. Written under horrendous time pressure, and trying to do the Assembler Guide at the same time. And the debug & memory architecture chapters weren’t mine at all, I make no comment on them…

I understand that such a thing as a processor architecture is a constantly changing target, but really I think it suffers most from not being squashed bits of dead tree.

By contrast, I find the 2nd edition quite pleasing. Sadly it predates UAL. One of these days I’ll have to dig up a translation chart been UAL and old nomenclature, and write it in in pencil.

I have another ARM ARM that’s half as thick. Don’t recall if that’s 1st edition or 3rd…?

I think it suffers most from not being squashed bits of dead tree.

And we’re back here again. While I don’t disagree¹, does anyone much beyond a few doddering geriatric enthusiasts around these parts care? More importantly, does any of ARM’s target market care?

As a student of the late 90s, I remember the shock of coming from a university department where all computers had internet access, to a work placement where if you needed web access you had to put in a formal request through your manager in order to borrow the company modem (and you had to have a desk phone line or a friendly desk neighbour, too). Datasheets lived in the datasheet library: a fair-sized room with those rolling bookshelves, from which you could borrow the books published by the semiconductor companies. If you needed details of a new chip, you phoned your area sales rep up and asked if they could post you a copy.

By the time I went back full time after graduating, desk PCs had internet access², but datasheets were still mostly printed out and filed in the library.

By the time I’d changed jobs in the mid noughties, I printed and filed interesting datasheets for my own use.

By 2010, I’d stopped even that, aside from a few rare exceptions. Printing any interesting datasheets could easily run to most of a ream of paper, which wasn’t really a good use of resources. I just collected stuff in an organised hierarchy of folders.

Amongst the engineers that I know now, printed stuff is the exception and not the rule. In the era of dual monitors, it’s not a big deal.

¹ I’ve been getting compliments for my bookshelf-based Zoom backdrop during lockdown, but I suspect that’s mainly because those who seem impressed can’t see the titles.

² Using the company-preferred DogPile search engine, which is apparently still a thing.

Oh, I’ll happily admit to being a doddering geriatric who prefers paper.

What the new world brings is easy and rapid access to information. What it takes away is the rapidity of understanding that information.

My personal vision of hell is a place where all the information I could ever need is available in a little handheld device, but that’s the only and sole way of accessing this information. And I have all of eternity to understand such things as quantum physics and what the universe is made of…
…by reading PDFs on a five inch screen. Forever.
I actually have nightmares with this sort of plotline. And, since I’m a geek I think to rummage around for a USB to HDMI dongle to plug in a proper sized monitor, but since it’s a nightmare the text on the monitor shows up the exact same size. Aaaaargh!

In the era of dual monitors, it’s not a big deal.

I had two 1600×1200 22" monitors on my desk at ARM fifteen years ago, and thought it was great. Far better now with a single 3840×2160 43" monitor – that cost a tenth of what those two monitors cost. (Not to mention of course that it weighs half what one of them did, and needs 15" less depth of desk.)

Amongst the engineers that I know now, printed stuff is the exception and not the rule. In the era of dual monitors, it’s not a big deal.

Hmm, squashed and reconstituted tree – back when the main labs system stopped using dot matrix listing printers(about 2003) I rescued a box of the fan fold A4 paper to use as scribbly-note paper.
I’ve been off work since April 27th but I’m assuming it’s still under my desk and 95% complete. At this rate of use I’m definitely going to retire before I finish the box.

I actually have nightmares with this sort of plotline. And, since I’m a geek I think to rummage around for a USB to HDMI dongle to plug in a proper sized monitor, but since it’s a nightmare the text on the monitor shows up the exact same size.

Covid 19 fever/delusions: Laptop with screen full of important text (of course) all out of focus. In the end I got rid of it in the logical way – pressed the delusional power button on the delusional laptop.
—> Aldershot

back when the main labs system stopped using dot matrix listing printers(about 2003) I rescued a box of the fan fold A4 paper to use as scribbly-note paper

Snap! I’ve got a couple of boxes, one still unstarted, from about that time (actually 1991). Rescued from a skip outside the offices next door to SSERC where I was working then. (Got a dud monitor out of the same skip, fixed it, and used it for several years.)