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

Beating the Compiler

mattkeeter.com

Post reply on HN
Print view View original

11–20 of 78 posts

Re: Beating the Compiler

#11

Post by duskwuff »

duped wrote: post #7
mkeeter wrote: post #5

Earlier quoted context omitted.

This is an interesting idea, but gets tricky if someone writes self-modifying code! There are Uxn instructions which write to RAM; normally , this is used for storing data, but nothing prevents programs from editing their own code as they're running.

> but nothing prevents programs from editing their own code as they're running On some platforms writing to memory mapped in with PROT_EXEC will trigger a page fault and the process will be killed. In other words, self modifying executables are effectively forbidden by design (the workaround is to unmap the memory, map it as PROT_WRITE, modify, unmap, map it in as PROT_EXEC, and resume execution - which is what JITs…

There's a better workaround, incidentally, which is to map the same memory to two different address ranges with different access permissions. This allows code in the JIT region to be updated while threads may be running in it.

Re: Beating the Compiler

#12

Post by mkeeter »

projektfu wrote: post #8

Good article, brings the data to back it up. Unfortunately, it was hard to read with the monokai.css theme because comments were nearly invisible, and a lot of your information was in comments. Changing the color from #75715e to #95917e did the trick. I guess Monokai is for programmers who never read comments.

Thanks for the feedback; I tweaked the brightness and pushed the change.

Re: Beating the Compiler

#13

Post by 201984 »

Very cool! I enjoy seeing people writing asm, and letting us get the most out of our CPUs.

I see you already tried what I thought of, which is getting rid of the jump table and making each instruction handler the same size. Do you think that could still work if you limited each instruction handler to 64 or 32 bytes instead of 256, and then for longer handlers jumped to a larger body of code somewhere else?

Re: Beating the Compiler

#16

Post by gpm »

ajbt200128 wrote: post #10

> // SAFETY: do you trust me? No. Have you seen the safer-ffi crate? Then you won't have to commit the deadly sin of writing unsafe Rust

> safer-ffi crate

It looks to me like that crate is supposed to help with exposing rust functions to C safely, not calling foreign functions in foreign code safely. Am I missing something?

Re: Beating the Compiler

#18

Post by albinahlback »

gumby wrote: post #3

IMHO the best way to think of it (well, it's how I have long thought of it) is two lemmas: 1 - The compiler has more "fingers" than a human does. Back when I wrote programs in assembly I would use printout to keep track of what I was doing and for debugging, and so would often put a finger on the paper to mark where a jump was and then go to the destination to see if it matched up, etc. This process isn't at all scal…

While I do think there are a lot of reasons to why one should not write in assembly, time-critical base routines can often benefit a lot from being written in assembly (take GMP's mpn-module for instance). However, this puts some constraint on how the code should be formatted (in GMP's case, this means that everything the mpz-module does is derived from the mpn-module), which cannot be said for all applications.

Re: Beating the Compiler

#20

Post by Hemospectrum »

duped wrote: post #7
mkeeter wrote: post #5

Earlier quoted context omitted.

This is an interesting idea, but gets tricky if someone writes self-modifying code! There are Uxn instructions which write to RAM; normally , this is used for storing data, but nothing prevents programs from editing their own code as they're running.

> but nothing prevents programs from editing their own code as they're running On some platforms writing to memory mapped in with PROT_EXEC will trigger a page fault and the process will be killed. In other words, self modifying executables are effectively forbidden by design (the workaround is to unmap the memory, map it as PROT_WRITE, modify, unmap, map it in as PROT_EXEC, and resume execution - which is what JITs…

The parent comment was referring to programs running inside the UXN virtual machine, which explicitly supports and endorses self-modifying code. Many of the creators' own programs take advantage of this capability, so any conforming implementation has to find a way to make it work.
Post reply on HN