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

91–100 of 106 posts

Re: Assembly Hall of Shame

#91

Post by inigyou »

thyristan wrote: post #89

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…

Page tables are physically addressed, so can't recurse. I assume this thing actually works by causing a page fault on the first instruction of the page fault handler, which is a new instruction.

Re: Assembly Hall of Shame

#93

Post by inigyou »

userbinator wrote: post #76

PCIe is more like a packet-switched network than a bus, which is incidentally why things like Thunderbolt (effectively external PCIe) and sillier demonstrations like https://www.youtube.com/watch?v=q5xvwPa3r7M work. ...and with things like https://en.wikipedia.org/wiki/ExpEther , you can get even higher latencies.

Pretty dumb right? When latency gets this high, you need a more asynchronous design to get any reasonable performance. PCIe is clearly designed with the assumption of latencies a few hundred cycles at most (or usually) - this MMIO register is an extreme outlier. It might be unmapped, and timing out on the hardware side, or it might be converted to an access on some really slow configuration bus.

Re: Assembly Hall of Shame

#94

Post by inigyou »

achierius wrote: post #9

It'd be really interesting to see whether the winning (losing?) instructions/strategies would be different on other architectures. At least right now the top spot (`fxrstor64` on MMIO, starve PCIe) seems relatively architecture-independent, but maybe something about MMIO ordering rules on e.g. POWER would be different enough to change that -- or perhaps open up new avenues? I wonder what the actual limit on this `fxr…

I think the idea was to find a long instruction on an ordinary PC. Of course by adding special hardware you can stall things.

Re: Assembly Hall of Shame

#95

Post by thyristan »

inigyou wrote: post #91
thyristan wrote: post #89

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…

Page tables are physically addressed, so can't recurse. I assume this thing actually works by causing a page fault on the first instruction of the page fault handler, which is a new instruction.

> Page tables are physically addressed

Nope. Not on x86. You can use either physical or virtual addresses at your choosing. Consumer OSes use virtual ones, so you can swap out page tables (yes, really!). See https://wiki.osdev.org/X86_Paging "Page directory".

Re: Assembly Hall of Shame

#97

Post by inigyou »

thyristan wrote: post #95
inigyou wrote: post #91

Earlier quoted context omitted.

Page tables are physically addressed, so can't recurse. I assume this thing actually works by causing a page fault on the first instruction of the page fault handler, which is a new instruction.

> Page tables are physically addressed Nope. Not on x86. You can use either physical or virtual addresses at your choosing. Consumer OSes use virtual ones, so you can swap out page tables (yes, really!). See https://wiki.osdev.org/X86_Paging "Page directory".

Nothing in this section mentions them containing virtual addresses. In fact the word "physical" is written in bold. Are you a hallucinating LLM?

Re: Assembly Hall of Shame

#99

Post by LoganDark »

sitzkrieg wrote: post #47
Xirdus wrote: post #28

Earlier quoted context omitted.

It is literally impossible to respond to input in 10ms on most platforms, for various reasons. The USB input lag of 12-30ms and the 60Hz refresh rate of most monitors being just the first two.

this is also why 60 hz refresh rate is all but dead outside of console gaming (not to mention 1000hz poll rate devices being the norm)

absolutely not, try finding a 15" 4K OLED with a refresh rate other than 60Hz

Re: Assembly Hall of Shame

#100

Post by thyristan »

inigyou wrote: post #97
thyristan wrote: post #95

Earlier quoted context omitted.

> Page tables are physically addressed Nope. Not on x86. You can use either physical or virtual addresses at your choosing. Consumer OSes use virtual ones, so you can swap out page tables (yes, really!). See https://wiki.osdev.org/X86_Paging "Page directory".

Nothing in this section mentions them containing virtual addresses. In fact the word "physical" is written in bold. Are you a hallucinating LLM?

You are right.

Not an LLM problem, just an undecaffeinated meat brain and some faulty memories. I've misread 'When PS=0, the page table address field represents the physical address of the page table that manages the four megabytes at that point.' to mean that when PS=1, the address isn't physical. But PS is page size... And I somehow remembered that you could induce pagefaults when walking the page tables...

Sorry.

Post reply on HN