Live data from Hacker News

X86 assembly doesn’t have to be scary

blog.benjojo.co.uk

91–100 of 129 posts

Re: X86 assembly doesn’t have to be scary

#91

Earlier quoted context omitted.

there was at least one non-realized research project where the cache was exposed as part of the architecture to be managed by the compiler (ppc lets you do some of that). i think thats a potentially very fruitful approach, but would it have helped the spectre situation in any way? oh, what you're suggesting in an analog for compiler driven speculation? that may have helped, and is also probably worth thinking about

Every single CPU architecture that has decided to lean on "smart compilers" has failed. Intel flushed billions down the drain on Itanium. They lit $100 bills on fire trying to make a smart compiler. It never paid off. Think about that for a minute. No matter how good your compiler I'll put my money on using hardware to solve Spectre. In the future I'd expect caches to gain some kind of exclusive tagging or set-aside…

I just read Microsoft is having their own go at it.

https://www.theregister.co.uk/2018/06/18/microsoft_e2_edge_w...

Re: X86 assembly doesn’t have to be scary

#92

The problem I keep running into is that everybody's asm is different looking, and not even internally consistent. Trying to parse all of this stuff: [BITS 16] ;tell the assembler that its a 16 bit code Okay, so this is an instruction to the assembler saying that we're only working with 16 bit registers and to emit 16 bit code. Straightforwards enough here. [ORG 0x7C00];Origin, tell the assembler that where the code w…

As for your confusion, you brought uneasy example here. This is a boot sector, which requires some knowledge on the process, flat binary addressing by convention, and tricks that must fit in 510 bytes, if any. That seems hard (not really) because all you’ve got is a first disk sector and 64kB of BIOS. Once you boot up into OS by reading more sectors and executing these, things slowly begin to ease. Your regular DOS-based program will look like any other example on the internet.

Edit: oh, this code is from the article. Bad habit of reading comments first, sorry!

Re: X86 assembly doesn’t have to be scary

#93
post #6

Loved the article. Then one can follow up with some MS-DOS classics. https://www.amazon.com/Peter-Nortons-Assembly-Language-Book/... https://www.amazon.com/Advanced-S-DOS-Programming-Microsoft-... https://www.amazon.com/Peter-Norton-Programmers-Bible-progra... https://www.amazon.de/PC-Intern-Programming-Encyclopedia-Dev...

Peter Norton's Assembly Language book is also online: https://openlibrary.org/works/OL65474W/Assembly_language_boo... but crazily, there's a waitlist to "check out" the eBook.

Sigh.

I did once contact the current copyright owners (DK or Penguin, I think) to see if it could be re-released or released for free, but the paperwork scared me off. Hopefully someone has more luck one day.

Re: X86 assembly doesn’t have to be scary

#94
post #3

If your intention is to avoid scaring newbies off, I'm not sure if 16bit real mode, PC boot process, BIOS services and all that arcana that follows is the best place to begin.

It seems like a better introduction would have the aim of helping the newbie learn assembly that would be useful in debugging or working around bugs in code that you don't have source to.

Re: X86 assembly doesn’t have to be scary

#95
post #39

What would be more interesting is the UEFI boot process. I don't think any new computer comes booting into 16bit real mode anymore. I would love to see a "Write your own UEFI bootable kernel" I'm sure going straight to a semi sane 32bit environment is much easier to deal with than starting at 16 and working your way up.

>32bit environment is much easier to deal with than starting at 16 and working your way up.

How much bytes do you think one requires for an OS loader? The complex part is loading all the code into memory from a file on disk partition without having a MB-sized fs driver, stdlib and loader in it yet. 16, 32 or 64 it doesn’t really matter.

Re: X86 assembly doesn’t have to be scary

#96
post #11

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. And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to keep in cache, which code paths are most likely, etc?

> 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 if the parts that are impossible to handle statically were instead handled in software by a JIT compiler that could speculate and deoptimize when necessary? Could that be a more efficient model for executing high-level languages like Java etc.?

Re: X86 assembly doesn’t have to be scary

#97
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…

It's funny how you can just adapt and work with whatever is available, and that becomes your norm. Especially when you don't even realize there are other options out there. Another example of this, also quite relevant to the article, is the 64K address space of a 16-bit segment; to anyone who is used to HLLs, 64-bit address spaces, and gigabytes of RAM, it seems impossibly small. Even more so when you take a modern C…

And that's why I love D. I can get fairly small binaries and still use powerful language constructs so that I can focus on the logic and not on the language.

Re: X86 assembly doesn’t have to be scary

#98
post #96

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 if the parts that are impossible to handle statically were instead handled in software by a JIT compiler that could speculate and deoptimize when necessary? Could that be a more efficient model for executing high-level languages like Java etc.?

> Could that be a more efficient model

No, because what the CPUs have is the advantage of being able to have specialized circuits with the new answers in each clock, every instruction in every pipelne stage and so fast adaptation to the use in run time.

Re: X86 assembly doesn’t have to be scary

#100
Sometimes its necessary to return to the past to remember the things we've abandoned in the rush to modernity.

I'm speaking, of course, of the wonderful Prince of Persia and its delights. So many treasures to be discovered for anyone interested in even a little bit of assembly-language programming.. it definitely sharpens my chops, anyway:

http://fabiensanglard.net/prince_of_persia/index.php

PRINCE OF PERSIA CODE REVIEW.

Post reply on HN