X86 assembly doesn’t have to be scary • Hacker News Board

Re: X86 assembly doesn’t have to be scary

#101

Post by mmjaa » Tue, Jun 19, 2018, 9:19 AM UTC

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…

The answer is, of course, that the 0-page is a full set of 255 registers.. you just have to know how to use the X/Y/Accumulator to access them properly ... ;)

Re: X86 assembly doesn’t have to be scary

#102

Post by user5454 » Tue, Jun 19, 2018, 10:13 AM UTC

Jupe wrote: post #63

Narishma wrote: post #50

Earlier quoted context omitted.

Didn't the Amiga's graphics system also use bitplanes?

Yep, sure did.

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

Re: X86 assembly doesn’t have to be scary

#103

Post by eadmund » Tue, Jun 19, 2018, 10:26 AM UTC

dcomp wrote: 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.

I would love to see a 'write your own UEFI kernel in assembly,' but every resource seems to assume that one is writing in C. I want my system to be in assembly, and to grow it from there.

Re: X86 assembly doesn’t have to be scary

#104

Post by lmm » Tue, Jun 19, 2018, 10:31 AM UTC

ksk wrote: post #34

ChrisSD wrote: 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?

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

Re: X86 assembly doesn’t have to be scary

#105

Post by gpderetta » Tue, Jun 19, 2018, 10:54 AM UTC

user5454 wrote: post #102

Jupe wrote: post #63

Earlier quoted context omitted.

Yep, sure did.

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.

Re: X86 assembly doesn’t have to be scary

#106

Post by gpderetta » Tue, Jun 19, 2018, 10:57 AM UTC

brandmeyer wrote: post #72

thechao wrote: post #51

Earlier quoted context omitted.

Even 15 decoders are a pinprick on the core’s area—at least when I saw die area for LRB. Fetch & schedule we’re a bit larger. Most of the core area was register files & floating-vector logic.

In fairness, Larrabee was originally an in-order design.

It was also a simpler core, which means that for a complex OoO monster, the decoder would be an even smaller area. The OoO instruction scheduler would be a significant chunk, but that has nothing to do with being x86.

Re: X86 assembly doesn’t have to be scary

#107

Post by CrankyCanuck » Tue, Jun 19, 2018, 12:26 PM UTC

Back in the late 80's, when I was in University, we had second year course where we had to do x86 assembly on PC XT or AT clones. Assignment #1 was messing with keyboard interrupts...easy peasy. Assignment #2? Write a video game...basically we had to do the "snake game" with a never ending line you could steer as it grew. Anyhow, I have to admit pretty much the whole class figured it out...assembly was not nearly as insane as we thought. By the end of that course, I was almost as comfy writing x86 assembly as Pascal. Fun times.

Re: X86 assembly doesn’t have to be scary

#108

Post by messe » Tue, Jun 19, 2018, 12:32 PM UTC

barrkel wrote: post #85

userbinator wrote: post #75

Earlier quoted context omitted.

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…

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 @f
            stosw
            jmp @b
    ;; Halt and wait for interrupt
    @@:     hlt
            jmp @b

    hello:  db 'Hello, World!', 00h

That's a total of 37 byes including the string.

Re: X86 assembly doesn’t have to be scary

#109

Post by buzzier » Tue, Jun 19, 2018, 12:47 PM UTC

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…

+ "Reverse Engineering for Beginners" free book https://beginners.re/

Re: X86 assembly doesn’t have to be scary

#110

Post by AnnoyingSwede » Tue, Jun 19, 2018, 1:51 PM UTC

The key to x86 assembler/machine code was avoiding the software interupts as they were painfully slow. Sure, when you are dealing with a 512byte boot sector you are better of offloading as much code as you can to software interupts, but for everything else the battle was to come up with something faster than the software interupts.

In many cases some basic routines used in qbasic was actually faster than their counterparty interupts in asm. A grand example of this would be using mode 13h (320x200) and interupt 10 to set all pixels on a screen to a single color, which could take up to 2 seconds using machine code and bios interupts (as it verifies vertical and horizontal refresh prior to setting the pixel). Using interupts however is relativly painfree as the author pointed out.