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

X86 assembly doesn’t have to be scary

blog.benjojo.co.uk

Post reply on HN
Print view View original

111–120 of 129 posts

Re: X86 assembly doesn’t have to be scary

#111

Post by gecko »

messe wrote: post #108
barrkel wrote: post #85

Earlier quoted context omitted.

Hello world in real mode is leveraging a bunch of code and data from the BIOS, so it's not quite as small as you're suggesting, but yes, bloat is the cost in general purpose abstractions. Smart linking is related to GC. Not all the conditional and indirect edges in the control flow graph can be skipped by the linker's graph traversal, so you usually end up with lots and lots of unused code. And then there's all the s…

Not important, I just thought it'd be fun to write but: > Hello world in real mode is leveraging a bunch of code and data from the BIOS Not necessarily, you can avoid the BIOS calls by just copying the string directly to video memory: mov ax, 0xB800 mov es, ax xor di, di mov ah, 0x07 mov si, hello ;; Load character, if zero, jump to end otherwise store ;; character and color in video memory @@: lodsb test al, al jz @…

I might be missing something, but you're still relying on the BIOS to have the graphical representation of those letters. Right?

Re: X86 assembly doesn’t have to be scary

#112

Post by messe »

gecko wrote: post #111
messe wrote: post #108

Earlier quoted context omitted.

Not important, I just thought it'd be fun to write but: > Hello world in real mode is leveraging a bunch of code and data from the BIOS Not necessarily, you can avoid the BIOS calls by just copying the string directly to video memory: mov ax, 0xB800 mov es, ax xor di, di mov ah, 0x07 mov si, hello ;; Load character, if zero, jump to end otherwise store ;; character and color in video memory @@: lodsb test al, al jz @…

I might be missing something, but you're still relying on the BIOS to have the graphical representation of those letters. Right?

As far as I remember, the default VGA font is stored on the graphics card ROM and copied into the video memory by that same onboard ROM, not the motherboard BIOS, so no I don't believe so. I may be mistaken.

Re: X86 assembly doesn’t have to be scary

#113

Post by ksk »

lmm wrote: post #104
ksk wrote: post #34

Earlier quoted context omitted.

>It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! >And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to kee…

Branch prediction is great except in the rare cases where it isn't. I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it.

>Branch prediction is great except in the rare cases where it isn't.

Sure, is there any CPU feature that this does not apply to?

>I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it.

Its hard to parse what your exact request is here. Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Or do you want to just disable it? But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.

Re: X86 assembly doesn’t have to be scary

#114

Post by lmm »

ksk wrote: post #113
lmm wrote: post #104

Earlier quoted context omitted.

Branch prediction is great except in the rare cases where it isn't. I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it.

>Branch prediction is great except in the rare cases where it isn't. Sure, is there any CPU feature that this does not apply to? >I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it. Its hard to parse what your exact request is here. Branch predictors o…

> Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation.

Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly.

> But then there are other places where bugs can hide. DMA Controller bugs, side channel attacks on caches, or basic DRAM attacks like Row Hammer,etc. Letting external programmers access CPU internals is only going to open another HUGE can of worms.

There are other holes, sure. That's not a reason not to fix the biggest hole. We'll fix the smaller holes in turn.

Re: X86 assembly doesn’t have to be scary

#115

Post by zshrdlu »

badminton1 wrote: post #65

Some free quality resources, ready to use: - Intel CPU programming guide https://www.intel.com/content/dam/www/public/us/en/documents... - Calling conventions https://en.wikipedia.org/wiki/X86_calling_conventions https://en.wikibooks.org/wiki/X86_Disassembly/Calling_Conven... - Web compiler output viewer https://godbolt.org/ - Operation code (opcode) reference http://ref.x86asm.net/ - Disassembler/debugger https://gi…

Probably also need some syscall references: https://fresh.flatassembler.net/lscr/

Re: X86 assembly doesn’t have to be scary

#116

Post by ksk »

lmm wrote: post #114
ksk wrote: post #113

Earlier quoted context omitted.

>Branch prediction is great except in the rare cases where it isn't. Sure, is there any CPU feature that this does not apply to? >I wouldn't want to see it removed but I would like to see better documentation and a more transparent interface onto it, so that those rare programs that do need precise control over it (e.g. security code) can have it. Its hard to parse what your exact request is here. Branch predictors o…

> Branch predictors on various Intel/AMD/etc CPUs work slightly differently from each other, and so even if you had access to the design documents, you would have to write programs specific to each CPU instead of targeting x86/x86-64. Not to mention that microcode updates could alter the implementation. Sure, though hopefully that's something a compiler could do. What I'd like is to be able to write a compiler that c…

>What I'd like is to be able to write a compiler that could understand the difference between as-fast-as-possible code (most code) and constant-time code, and build the latter correctly.

If you want your compiled code to rely on the internal design of the CPU then its going to be tightly coupled to one particular CPU. CPU Upgrade -> code no longer works. Oh you ran the software on your laptop which has Core i5 instead of Core i7 -> Code no longer works. Oh your S/W Vendor went out of business and you purchased a new machine with a different CPU -> No working code for you.

>There are other holes, sure. That's not a reason not to fix the biggest hole.

OK, please propose a solution then. Or are we merely arguing over hypotheticals and lamenting the fact that stuff isn't secure? If so, yeah, stuff isn't as secure as any of us would like it to be! That doesn't get us anywhere though.

Re: X86 assembly doesn’t have to be scary

#117

Post by krylon »

jecel wrote: post #31
krylon wrote: post #14

Earlier quoted context omitted.

Well, Intel has tried repeatedly to replace x86 (AXP32, i860/i960, Itanium), but in a way, they were a victim of their own success.

Actually, the iAPX432 came first in 1976. When it became obvious that this project was going to take longer than expected (it was only launched in 1981) Intel did a quick extension to the 8080 to keep customers from going to the competition while they waited.

Thank you for pointing that out!

Re: X86 assembly doesn’t have to be scary

#118

Post by krylon »

scottlamb wrote: post #66
krylon wrote: post #10

I think to many programmers assembly is the "GOTO" of programming languanges: From the day you start learning to program, you are told that all this fancy high-level-language stuff is there so you do not have to deal with assembly. So most people never go there. I did go there, briefly, about ten years ago. It was wicked fun. But all in all, I may have written maybe 20 or 30 instructions of assembly in total. I did t…

> At that point I figured that the people who told me that "you can't beat the compiler" were probably right and called it a day On that subject...my understanding [0] is: These days, the best bet for beating the compiler is to use vendor intrinsics (for SIMD, encryption, bit-twiddling, etc). Shaving an instruction off the inner loop might give you a few percent; using SIMD lets you operate on 256 or 512 bits per ins…

> These days, the best bet for beating the compiler is to use vendor intrinsics (for SIMD, encryption, bit-twiddling, etc)

Well, I would not count that as "beating" the compiler so much, but as "using it", "helping it", or something like that. ;-)

Anyway, when I still wrote C code for a living, we were using the OpenWatcom compiler, and as far as I could figure out at the time, it made no effort whatsoever to support SIMD, and the only way to use them was to drop to assembly. (OpenWatcom's support for inline assembly and even inline binary code was very nice, though.)

Re: X86 assembly doesn’t have to be scary

#119

Post by krylon »

Veedrac wrote: post #71
krylon wrote: post #10

I think to many programmers assembly is the "GOTO" of programming languanges: From the day you start learning to program, you are told that all this fancy high-level-language stuff is there so you do not have to deal with assembly. So most people never go there. I did go there, briefly, about ten years ago. It was wicked fun. But all in all, I may have written maybe 20 or 30 instructions of assembly in total. I did t…

You got 20-30 instructions in, drew, and decided it was impossible to do better? That's calling it quits a bit early.

Like I said, my motivation was not very strong.

During my programming socialization, assembly was always characterized as this terrible thing they did back in the 1960s, so I was reluctant to even try to begin with. Secondly, I had read quite a bit about how nowadays, compilers were so good, it was not worth the effort.

My initial motivation to even give assembly a try was not performance, but accessing CPU-specific features (RDTSC).

Re: X86 assembly doesn’t have to be scary

#120

Post by blattimwind »

bogomipz wrote: post #77
blattimwind wrote: post #47

Earlier quoted context omitted.

> I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same,…

>"What we do know is outside some niches (like DSPs, where VLIW reigns king)" Interesting, why is VLIW is so predominant in DPS chips?

Because typical DSP code does calculations using predictable memory access patterns and usually contains very little logic. This makes it possible to largely statically schedule the code. It's fairly similar in that regard to e.g. GPU shaders (and indeed GPUs have used VLIW-like designs in the past) and scientific data crunching code.
Post reply on HN