Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Assembly Hall of Shame

github.com

Post reply on HN
Print view View original

81–90 of 104 posts

Re: Assembly Hall of Shame

#81

Post by kazinator »

Joel_Mckay wrote: post #74
kazinator wrote: post #69

Bus cycles can be arbitrarily long on any processor that has memory cycles with a hand shake requiring an ack, with no timeout. E.g. we can build a board around a MC68000 where we make it lock up forever in a bus cycle, waiting for a DTACK that doesn't arrive. Some early microprocessors had clocked bus cycles without handshaking. They would put out an address on some address lines and signal some line together with a…

In general, more complex processors have latency issues, and in some ways modern chips have actually become worse with each design iteration. https://en.wikipedia.org/wiki/Metastability_(electronics) Ultimately... failure modes must arise because naive gate design simulation models can't determine issues in a computationally feasible time frame. The consequences of "fixing" CDC prone design flaws makes a processor ma…

I smell Buridan's ass. :)

Re: Assembly Hall of Shame

#82

Post by inigyou »

citelao wrote: post #40
m463 wrote: post #37

Earlier quoted context omitted.

I stand corrected. I looked it up and it is .1 seconds (100ms) The basic advice regarding response times has been about the same for thirty years [Miller 1968; Card et al. 1991]: - 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result. - 1.0 second is about the limit for the user's flow of thought…

That’s the prevailing statistic, but your original number isn’t that wrong either: Humans can perceive much smaller latencies. If you look at the Card & Miller reference, at least some humans can perceive differences in ~50ms vs 100ms latencies when typing (in my limited testing, it’s likely you can!). There’s some newer research I don’t have handy that I believe found error rates decreased and NSAT improved until ar…

"The human eye can see 39620Hz": https://youtu.be/Sb_7uN7sfTw

Re: Assembly Hall of Shame

#84

Post by phire »

pbsd wrote: post #36
michalsustr wrote: post #17

Very cool! Also, huh interesting. I’ve used rdtsc to measure cycle diffs but had no idea its execution takes that long. Is that common across architectures?

The cycle count for RDTSC is ~25 cycles on Skylake-era microarchitectures. The 49 number shown in the OP seems off.

It's actually benchmarking 1000 repetitions of the RDTSC instruction running in parallel.

My guess... On Skylake, multiple in-flight RDTSC instructions slow each other down for some reason?

Possibly because it's attempting to provide a strict monotonic guarantee, that no two RSTSC instructions will return the same timestamp. Intel's manual only claims monotonic, which theoretically allows for two RSTSC instructions to return the same timestamp.

Re: Assembly Hall of Shame

#85

Post by jonathrg »

benmmurphy wrote: post #79
Brian_K_White wrote: post #60

Earlier quoted context omitted.

I looked at both links and don't see anything weird or annoying, and I hate overblown styles myself.

‘The counters tell the story’ might be something they consider odd. But I’m not familiar with the author’s style so they could have had these tics pre-LLM or they picked up these tics from reading a lot of LLM content.

Yes, that's the point where I was like "wait a second" and started counting em dashes. A third alternative, perhaps the LLMs were trained hard on his prior work? :-)

Re: Assembly Hall of Shame

#86

Post by phire »

baddash wrote: post #45

just curious, how much do these actually discover useful practices or pitfalls, on top of just being for fun?

The repo page says exactly why these long running instructions were researched.

A very long-running instruction can be used to break SMI: https://github.com/xoreaxeaxeax/smiiiiiiiiiiiiiiii

Re: Assembly Hall of Shame

#88

Post by fluoridation »

dxdm wrote: post #77
fluoridation wrote: post #68

Earlier quoted context omitted.

I'm not disputing the total effect. I'm asking if you'd rather describe ADD and JMP in this manner, in order to say that NOP does not in fact do nothing.

Love the pedantry here. I'm currently at: no op code does anything, it's all fancy effects in the hardware that can be described in arbitrary detail, which somehow allows me to cause these letters to appear on your screen.

Insightful and compelling. Tell me another one.

Re: Assembly Hall of Shame

#89

Post by thyristan »

Depending on his interpretation of the rules about trapped instructions, one could just build a loop in the x86 page tables. Those are usually a tree linked by pointers, and any page table lookup can create another page fault that creates another lookup that...

Leads to x86 page table MMU magic being turing complete: https://github.com/jbangert/trapcc

And the simplest thing you can do on such a system is just to loop indefinitely, thus creating a simple instruction with a memory access (mov or anything, doesn't really matter, even the instruction fetch for a nop would work) to take infinite time.

Re: Assembly Hall of Shame

#90

Post by dxdm »

fluoridation wrote: post #88
dxdm wrote: post #77

Earlier quoted context omitted.

Love the pedantry here. I'm currently at: no op code does anything, it's all fancy effects in the hardware that can be described in arbitrary detail, which somehow allows me to cause these letters to appear on your screen.

Insightful and compelling. Tell me another one.

With pleasure.

There was a boy A very strange, enchanted boy They say he wandered very far Very far, over land and sea A little shy and sad of eye But very wise was he.

And then one day A magic day he passed my way And while we spoke of many things Fools and kings This he said to me: "The greatest thing you'll ever learn Is just to love and be loved in return."

Post reply on HN