From Newsgroup: comp.arch

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 08/08/2026 5:36 AM, Thomas Koenig wrote:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

This feels like cheating. You can also just implement hardware
that has something in MMIO space that never replies. I don't know
how the rest of the hardware deals with that situation, but I don't
see how that's impossible.

You can also just unplug the CPU mid-instruction, and then define
yourself as having /won/ by infinity.


Happy assembly coding!
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> schrieb:

On 08/08/2026 5:36 AM, Thomas Koenig wrote:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

This feels like cheating.

Arguably yes, but still is fun.

And number 9, wbindv, does not need to do any fancy I/O searching.

You can also just implement hardware
that has something in MMIO space that never replies. I don't know
how the rest of the hardware deals with that situation, but I don't
see how that's impossible.

You can also just unplug the CPU mid-instruction, and then define
yourself as having /won/ by infinity.

Both would require hardware modification, and that is excluded by
the rules.

Happy assembly coding!

Yep :-)
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig wrote:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

I'm a bit worried by all the FPU denormal microtraps, this really isn't optimal today!

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

Thomas Koenig <tkoenig@netcologne.de> schrieb:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

Having clicked one link further, it seems that this can be used
to break SMM, the ring-2 (or whatever) mode on x86 CPUs which is
supposed to be secured by ensuring that if it runs on one core,
it runs on all cores.

Ooops.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch


Thomas Koenig <tkoenig@netcologne.de> posted:

Just how long can an assembly instruction take on x86?

A number of these <arguably> should not be in ISA at least in the
form they are. For example, instead of writing-back and invalidating
each line in all caches, why not a simpler instruction that touches
exactly 1 line and use it in a loop.

MSR registers are especially slow to access.

But I see no particular reason that denormals should be so slow.

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

Should be used as a guide as to what "not to do".
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 8/8/2026 11:11 AM, Terje Mathisen wrote:

Thomas Koenig wrote:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work
for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

I'm a bit worried by all the FPU denormal microtraps, this really isn't optimal today!

Seemingly, despite the claims, Intel and AMD still haven't found them cost-justified to deal with entirely in the native HW...


Decided not to go into it too much, but I am not entirely convinced
desktop PC FPUs are not also corner-cutting in a few of these same areas
(they exhibit a lot of the same "subtle-yet-detectable" quirks, and
incur performance penalties in a lot of the same scenarios, etc).

Like, they too were like:
Yeah, do a crappier version in hardware, and silently fix up the results
when it fails;
Then add a faster DAZ/FTZ mode, and maybe/maybe-not have the user notice
that now the ULP rounding is now also occasionally (but still
infrequently) off-by-1 (from what an actual strict 0.5 ULP rounding
would have given).

...

Terje

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Fri, 7 Aug 2026 21:36:16 -0000 (UTC), Thomas Koenig wrote:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

Not really a rCLhall of shamerCY, more a rCLhall of how far can you screw around with an x86-family processorrCY.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 8/8/2026 4:44 PM, Lawrence DrCOOliveiro wrote:

On Fri, 7 Aug 2026 21:36:16 -0000 (UTC), Thomas Koenig wrote:

Just how long can an assembly instruction take on x86?

Hint: MUCH longer than you think, but you have to work for it.

Details at https://github.com/xoreaxeaxeax/asm-hall-of-shame .

Not really a rCLhall of shamerCY, more a rCLhall of how far can you screw around with an x86-family processorrCY.

Execute a RMW, aka LOCKED on a point in memory that happens to straddle
two l2 cache lines... Buckle up! Oh my.
--- Synchronet 3.22a-Linux NewsLink 1.2