Hacker News Reader

Comment by Alupis | Hacker News Reader

Smidge simpler and uses only kernel routines

    #   as hello.S -o hello.o
    #   ld hello -o hello
    #   ./hello
    
    .data                         # .data section starts
    msg: .ascii "Hello, World!\n" # msg is ASCII chars (.ascii or .byte)
    len: .int 14                  # msg length is 14 chars, an integer
                                  # .int 32 bits, .word 16 bits, .byte 8 bits
    .text                         # text (instruction code) section starts
    .global _start                # _start is like main(), .global means public
                                  # public symbols are for linker to link into runtime
    _start:                       # _start starts here
       movl len,  %edx            # value 14 copied to CPU register edx
       movl $msg, %ecx            # memory addr of msg copied to CPU register ecx
       movl $1,   %ebx            # file descriptor 1 is computer display
       movl $4,   %eax            # system call 4 is sys_write (output)
       int  $128                  # interrupt 128 is entry to OS services
    
       movl $1,   %eax            # system call 1 is sys_exit (prog exits)
       movl $77,  %ebx            # status return (shell command: "echo $?" to see it)
       int  $128                  # call OS to do it via interrupt #128

View on HN

ARM version:

    .data                                                                                       
    msg: .ascii "Hello, World!\n"                                                               
    len = . - msg                                                                               
                                                                                    
    .text                                                                                       
    .global _start                                                                              
                                                                                            
    _start:                                                                                     
      mov     r0, #1                /* fd 1 = stdout */                                         
      ldr     r1, =msg              /* message */                                               
      ldr     r2, =len              /* length of message */                                     
      mov     r7, $4                /* write */                                                 
      swi     #0                    /* syscall */                                               
                                                                                            
      mov     r0, $0                /* status */                                                
      mov     r7, $1                /* exit */                                                  
      swi     #0                    /* syscall */

I couldn't get the # style comments to work, so had to resort to /* */ instead. It's very similar because the code is quite simple, but could be a good starting point if you are interested in ARM assembly. You can use the same commands as above to build and run.

To use syscalls x86_64 assembly (at least on linux), you'll want to use the syscall instruction, and set up the registers according to the linux 64 bit syscall calling convention (which is different than the 32-bit convention).

Well.. to be fair as a tutorial on assembly language the linked article (which does nothing but make a C-linkage function (main) to call another function (printf)) is going to be a better choice.

Things like system calls and program startup are more advanced topics you'd introduce later, even if they make for shorter code.

And to nit even further: your example is "lower level" but still relies on a metric ton of magic being executed by the linker. If you're allowed to "just invoke ld" the OP's "just call and return from main" trick doesn't sound so bad.

There is no magic in what the linker is doing. It just needs to create an ELF file with two sections and set the start address.

Check this out http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

Sigh... "just". Find me 100 programmers capable of writing a C function to call another and tell me how many of them understand the ELF format, or even know that it exists. It's a subject worthy of its own tutorial (which you conveniently linked to), and specifically it's a subject that is rather more complicated than how to write an two x86 Linux system calls.

this is a much better example since it does away with the needless complexities, and is a good starting point for looking at interrupts and how they are used in this environment... since their importance isn't hidden behind a layer of needless logic and a c library call.

Except the interrupts are not the efficient way to make a system call anymore. The specialized syscall (sysenter) opcode is much better.

right, but it keeps it very simple

I think it's # ld hello.o -o hello

Looking at that and getting reminded of how far removed from it modern languages are.

Who thinks in terms of CPU registers these days, for instance?

> Who thinks in terms of CPU registers these days, for instance?

The people for whom it makes sense, same as the people who think about RTCs or deep sleep modes or programming single-board computers to read temperature sensors.

It isn't like the low level has gone away or become completely inaccessible. It's that now we have more options to write working code, and we can optimize for things beyond cycle-level and byte-level efficiency. Optimizing for readability, for example, wasn't really an option when all of the readable algorithms were unacceptably slow due to constant terms.

Breaking every rule about data-hiding to get somewhat better constant terms in the big-O analysis isn't virtuous, it's just what was forced on us by insufficient hardware.

This is my sentiment exactly. With all these fancy functional languages, non-imperative programming paradigms and heaps of JavaScript frameworks, there's one thing that one might forget: computers are made of silicon, not category theory.

It is easy to write down a bunch of assembly instructions. It's hard to make them do the thing you want, and it is our desires and our intent that need more than a little silicon to express.

"Who thinks in terms of CPU registers these days..."

That's pretty much the only way I think these days, but I guess assembly does not qualify as "modern language" even though it can and is used to control the lion's share of the world's "modern" computers. Matters little to me; I'm hooked.

I do not write in Lua, and I am sure I will be quickly corrected by someone who does, but isn't it considered both (virtual) "register-based" and "modern"? My sincerest apologies to the Lua experts if I am wrong.

The VM uses registers (as opposed to e.g. a stack), but that's an implementation detail and not anything you think about when you write Lua.

Reply on news.ycombinator.com