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

111–118 of 118 posts

Re: Assembly Hall of Shame

#111

Post by Xirdus »

Dylan16807 wrote: post #106
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.

> The USB input lag of 12-30ms How'd you get that number? USB defaults to polling at 125Hz and a lot of devices go at 1000Hz (or higher). The rest of the pipeline should be a fraction of a millisecond. I guess bad debouncing hardware can add a lot more, but that's far from USB's fault.

It's mostly due to OS-level USB stacks being quite terrible for latency for the most part, especially on Windows. Though I might've misremembered the exact numbers.

Re: Assembly Hall of Shame

#112

Post by Xirdus »

xboxnolifes wrote: post #33
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.

60Hz monitors definitely prevent it, but I'm pretty sure USB lag is far less than 12-30ms. My USB mouse can make a round-trip to a remote server faster than that.

Out of curiosity, how did you measure mouse roundtrip with sub-12ms precision?

Re: Assembly Hall of Shame

#113

Post by Xirdus »

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)

"Most" includes standard issue corporate hardware for office drones, bottom of the barrel laptops bought as gifts to children, and ultra cheap Android phones in developing countries.

Re: Assembly Hall of Shame

#114

Post by Gibbon1 »

TomatoCo wrote: post #5

This author also has other things like: A compiler that emits only `mov` instructions and another compiler that deliberately messes with the control flow so that, if disassembled, common debuggers will draw symbols like skulls or threats. https://github.com/xoreaxeaxeax/repsych

I saw a string of emoji that supposedly when copied to a file and renamed .exe prints out hello when run.

Re: Assembly Hall of Shame

#115

Post by nxobject »

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…

> 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.

IIRC, early 68k Macs had processor upgrades hooked onto the 68k bus and did exactly this - an early boot driver run by the “actual” CPU coordinated handoff with the expansion CPU’s bootstrap ROM.

Re: Assembly Hall of Shame

#116

Post by egberts1 »

My favorite is having an XOR opcode modifying the operand of its next IMUL operand.

Fools QEMU and makes for a good "am I on a VM" logic test.

A function of precalculating XOR operand inadvertly twice at QeMU TLB compute time AFTER retrieval of and toward its cached IMUL operand value.

In short, emulation doing preparation of registers twice (negating XOR)

Now you have a logic test revealing QEMU thru minute differential of IMUL operand value and its different multiplication results.

ROT13, anyone?

Disclaimer: works only on RXW memory page. It is literally a self-modifying code.

Re: Assembly Hall of Shame

#117

Post by summarybot »

RiverCrochet wrote: post #48
summarybot wrote: post #19

Earlier quoted context omitted.

The OS should do less not more

vi should be a kernel-level system call, tunable with sysctls. For agentic management.

that sort of rearrangement makes sense. and the likely downstream effect is the OS can ... do less [at higher levels of userspace]

Re: Assembly Hall of Shame

#118

Post by adamrezich »

fluoridation wrote: post #43
adamrezich wrote: post #32

Earlier quoted context omitted.

The new mspaint fucked, then unfucked, then refucked my decades-old muscle memory of Win+R mspaint Enter Ctrl+E 1 Tab 1 Enter Ctrl+V to open Paint, resize canvas to minimum, then paste from clipboard. When you press Ctrl+E now, the Units control is selected by default, for some completely asinine reason!!!

That's pretty cool. I've never needed to do that because Paint remembers the last canvas size set manually.

Yeah but sometimes I save images using Paint and then the default canvas size will be something else!

If I were designing an OS shell I would simply give the user the ability to easily make temporary text or image buffers and copy and paste content to/from them, rather than using a Notepad or a Paint.

Post reply on HN