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

121–129 of 129 posts

Re: X86 assembly doesn’t have to be scary

#121

Post by badminton1 »

zshrdlu wrote: post #115
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/

Neatly organized. The "man" command also has documentation on syscalls.

A good introduction to syscalls, with some explanation is "The Linux Programming Interface", http://man7.org/tlpi/ (book)

Re: X86 assembly doesn’t have to be scary

#122

Post by Jupe »

gpderetta wrote: post #105
user5454 wrote: post #102

Earlier quoted context omitted.

But with AGA chipset the Amiga got chunky pixels (e.g. write palette index to the framebuffer as in VGA).

That was supposed to be a feature of AAA. I do not think AGA supported chunky pixels.

Yep, but for complexity, nothing matched HAM (hold and modify) mode, except maybe the aftermarket DCTV, the details of which escapes me, but I recall it having separate chroma and luminense.

Edit: found some info on DCTV: https://retrocomputing.stackexchange.com/questions/2201/how-...

Re: X86 assembly doesn’t have to be scary

#123

Post by tawayway »

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…

Another old chestnut - learning some assembly allows you to read it, even if you don't ever need to write any. There is real value in understanding which instructions your compiler is emitting.

Beating the compiler is made easier if you can look at the compiler's answers.

Re: X86 assembly doesn’t have to be scary

#124

Post by gpderetta »

blattimwind wrote: post #120
bogomipz wrote: post #77

Earlier quoted context omitted.

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

also DSP code has a decent amount of instruction level parallelism.

Re: X86 assembly doesn’t have to be scary

#125

Post by gpderetta »

inferiorhuman wrote: post #81
BeeOnRope wrote: post #79

Earlier quoted context omitted.

Not really, those use a microscopic amount of area on a modern die and shouldn't have much power impact at all when they aren't being used. You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them.

> You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them. I've got no idea (obviously) but it seems that maintaining compatibility with legacy hardware shouldn't be all that cheap. If it is, kudos to Intel.

What I heard is that, by far, the biggest cost is validating the final hardware. Intel and AMD have very large experience and test tools so the incremental cost for a new CPU is not huge, but it is a big barrier for a new competitor in the x86 space (but then again, patents are probably an even bigger barrier).

Newer/Simpler architectures should be easier to validate.

Re: X86 assembly doesn’t have to be scary

#126

Post by lmm »

ksk wrote: post #116
lmm wrote: post #114

Earlier quoted context omitted.

> 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 instea…

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

Indeed. Better that than CPU Upgrade -> silently leak your private keys, which is what we currently get.

> OK, please propose a solution then.

I've been proposing a solution this whole thread: publish enough information about exact CPU behaviour to allow a (specialised) compiler to produce reliably constant-time code, even if only for a single CPU model at a time.

Re: X86 assembly doesn’t have to be scary

#127

Post by bogomipz »

blattimwind wrote: post #120
bogomipz wrote: post #77

Earlier quoted context omitted.

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

>"typical DSP code does calculations using predictable memory access patterns and usually contains very little logic."

Thanks, that's what I was missing - the access patterns of signal processing is what makes VLIW a good fit.

Is there any other use case where VLIW architectures are prevalent or are DSPs the primary use case?

Re: X86 assembly doesn’t have to be scary

#128

Post by prirun »

tvmalsv wrote: post #20

When I was about 14 I was enthralled with programming my new Commodore 64, first in BASIC, then 6510 assembly. I had the opportunity to accompany my mother to a one-day class on programming. Being just an intro on the subject, I was well ahead of what they would be discussing, but thought it would interesting to talk to some adults that were also into programming. I was talking to a couple of guys about what I had be…

I worked at Prime Computer (a minicomputer company) in Detroit when I was 19. Ford was converting their car design program, PDGS (Product Design Graphic System) to Prime. It ran on 16-bit 32K CDC computers. The program was huge and used overlays to swap different features in and out from disk as the user clicked on menu options on a vector display. For the young tikes here, a vector display is like a traffic control display: it draws perfectly straight lines, perfect circles, by moving an electron beam over a continuous phosphor-coated screen. No pixels.

By contrast, the Prime minis had a Multics architecture with virtual memory (no overlay swapping!), something like 8MB of memory, a 32MB disk drive (16MB fixed, 16MB removable cartridge) and could support 2 vector displays on 1 computer. Happy days!

So yeah, for us oldsters (I'm 58), modern software often seems very bloated.

Re: X86 assembly doesn’t have to be scary

#129

Post by ksk »

lmm wrote: post #126
ksk wrote: post #116

Earlier quoted context omitted.

>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 instea…

> 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. Indeed. Better that than C…

That is not a solution though. Its your personal wish list. Neither Intel nor AMD is going to publish their CPU design. No consumer is going to purchase/use software that arbitrarily breaks. Its as unrealistic as someone saying don't release any software with bugs. A solution recognizes the reality of the current situation. You'll have to figure out how to get all parties on-board your agenda. I don't expect you to come up with one right this moment, but I did want to challenge your position.
Post reply on HN