Apple M1 Assembly Language Hello World

https://smist08.wordpress.com/2021/01/08/apple-m1-assembly-language-hello-world/

by _zhqs • 6 years ago

372 111 6 years ago

smist08.wordpress.com

nneonneo3• 6 years ago

The author appears to have conflated "Linux" with the "kernel" - for example, "When calling a Linux service the function number goes in X16 rather than X8.", "X16 - linux function number", "Call linux to output the string", etc. in the macOS assembly code.

Linux refers specifically to the operating system kernel that's used on Linux systems; the macOS kernel is called Mach. Technically, the non-negative-numbered system calls on macOS are those derived from BSD; macOS additionally has another (negative-numbered) set of system calls for its Mach microkernel.

athrun• 6 years ago

Yes I think he's getting some of terminology wrong.

Saying that "Linux [is] based on Unix" is not really accurate either.

But ultimately this is just nitpicking. It's great that he's sharing what he learned.

derefr2• 6 years ago

Saying that "Linux [is] based on Unix" is not really accurate either.

The context of the author's statement was syscall ABIs. And Linux's original (x86) syscall ABI is based on [a snapshot of] the syscall ABI from a Unix (4.2BSD, I think.)

Loosely based, mind you — 4.2BSD wasn't targeting a 32-bit architecture, let alone x86, so the registers et al weren't the same. But the syscall numbers match up, and the number and order of registers used have direct parallels.

Compare and contrast:

• FreeBSD ABI (direct descendant of 4.2BSD): https://github.com/freebsd/freebsd-src/blob/master/sys/kern/...

• Linux x86 ABI: https://chromium.googlesource.com/chromiumos/docs/+/master/c...

Everything lines up until you get to the OS-proprietary stuff.

Blikkentrekker• 6 years ago

The term is so often conflated because it seems as though what is wanted be a technical definition of a concept that is not technical, but social.

“Linux” the kernel is technical, but that other thing for which “Linux” is often used has no technical barriers to it, and is entirely a social thing — something is “Linux” when it declares itself part of the tribe, and is so accepted.

SteamOS as a marketing strategy always used the phrase “Linux and SteamOS” and was thus successful in moving itself outside of the tribe, for example.

There is no technical definition of “an operating system” and there are no technical reasons for what “operating systems" are and aren't “Linux”; it is purely based on social cohesion.

userbinator5• 6 years ago

Nothing a little s/Linux/macOS/ won't fix... but I sure hope the book he is promoting is less confusing than that. To his credit, he does say "in MacOS it's X, in Linux it's Y".

(I'm a long-time x86 programmer, who has done a very little of ARM but finds it boring since you can't beat a compiler as easily as you can on x86... and yet instinctively felt unease at moving 0 into a register. ;-)

nneonneo3• 6 years ago

Yeah, there's a bunch of stuff in AArch64 that takes getting used to - for example, fixed-length instructions (everything is a 32-bit instruction!), tons of sanely-named registers (X0~X30, W0~W30), shorter literals (all literals need to fit in a 32-bit instruction), and so much more. Plus, it's a total break from AArch32 - I'm pretty comfortable with 32-bit ARM code, and yet 64-bit ARM code still looks pretty unusual to me.

lovelyviking2• 6 years ago

What do you mean by “beat the compiler” ? like running code without it nor linker ? Looks like I have a mood to try that now

bananabreakfast• 6 years ago

Small nitpick, but the macOS kernel is actually called XNU which is a hybrid of Mach and FreeBSD.

reaperducer2• 6 years ago

the macOS kernel is actually called XNU

Since you seem knowledgeable about these things, how does one pronounce "XNU?"

Is it "ex-en-you" or "zznoo" or "she-no" or something else?

coldtea• 6 years ago

The author appears to have conflated "Linux" with the "kernel"

I don't think he conflated it (in his mind). In the post he's quite clear which is which.

He probably just reused an ARM Linux example code (probably from his book), made some changes required for macOS ARM, but forgot to change the name of the kernel.

raxxorrax• 6 years ago

Not yet given the M1 or MacOS a spin, but the syscall adresses should be available under /sys/syscall.h according to an answer on stack exchange.

Cannot find a table on the net and syscall adresses could be subject to changes.

saagarjha9• 6 years ago

https://opensource.apple.com/source/xnu/xnu-7195.50.7.100.1/...

wtsnz• 6 years ago

Sidenote: What a cool personal blog. Started in 2009 and still going strong. Inspirational!

userbinator5• 6 years ago

Class AMSupportURLConnectionDelegate is implemented in both ?? (0x1edb5b8f0) and ?? (0x122dd02b8). One of the two will be used. Which one is undefined.

It's both amusing and sad to see even simple command-line tools spewing those warnings which are most commonly found in the system log. I don't have a system to check at the moment, but I seem to recall using xcrun a long time ago and it didn't do that. I guess it is as they say, "beauty is only skin deep"...

marcan_423• 6 years ago

I see your userland M1 assembly language hello world and raise you a bare-metal M1 kernel assembly language hello world :-)

https://github.com/AsahiLinux/m1n1/blob/main/src/start.S

The first few lines of that will print 'm1n1' to the serial port as it initializes other things and eventually jumps to C code.

nneonneo3• 6 years ago

This looks basically like assembly code for practically any embedded system - reading/writing hardware registers to interact with UARTs. Nice job (& best of luck with the Asahi Linux project - very exciting!)

marcan_423• 6 years ago

Well, the Apple M1 is an embedded SoC after all :)

Thank you!

CyberRabbi2• 6 years ago

What baud rate does it run at?

marcan_423• 6 years ago

115200 by default (it's what iBoot initializes it at), but I spent a chunk of yesterday's live development stream yak-shaving a way to smoothly switch to 1.5Mbaud in a way that lets my Glasgow-based auto-baud-sensing serial interface resync cleanly (turns out: it seems to be impossible using any single byte repeating with 1 stopbit and no pauses due to ambiguous framing; I had to use a multiple-byte pattern).

sneak• 6 years ago

String bet! :)

(Raises are not accepted after you've already called.)

SulfurHexaFluri• 6 years ago

How do you actually load / run this code without an OS? I'm guessing its the same way something like grub gets run?

moonchild• 6 years ago

I don't know how it works on apple hardware—though I heard they used a UEFI variant with HFS+ at one point—but in general, on PCs, there are two ways to get bootcode to run.

The first is legacy BIOS: the BIOS will load the first 512 bytes of the boot sector, called the Master Boot Record (MBR) into memory location 0x7C00; they are then responsible for bootstrapping the rest of the system. Usually by doing the bare minimum to load a second-stage bootloader off the disc, and letting the second-stage bootloader do the rest of the work, since 512 bytes (actually only ~440) is really not very much.

The second is UEFI. The firmware will load a PE-formatted executable from a .efi-suffixed file on a FAT32 partition which has the EFI System Partition (ESP) flag set. Since this PE file can be any size, a second-stage bootloader is not generally necessary (but may be interesting for aesthetic reasons e.g. if you don't like PE).

CameronNemo• 6 years ago

On Rockchip boards, there is a bootrom that looks for data at a specific offset on a few storage devices, then calls the first one it finds. From there open source / flashable firmware initializes RAM, scales up CPU frequencies, and starts looking for a kernel or whatever.

TL;DR likely read only firmware, possibly more low level than a BIOS, UEFI, or Coreboot implementation would be.

Edit: then again, they could be shipping a full EFI implementation like they do on their x86 offerings.

garaetjjte• 6 years ago

It's linked into Mach-O binary that is loaded by iBoot bootloader. It is explained in detail there: https://www.youtube.com/watch?v=d5s9fYfvzmY&t=12260

user-the-name2• 6 years ago

Where is the UART on that thing?

terramex• 6 years ago

UART can be enabled on M1 Mini on "the leftmost port (closest to the power input)". It first needs to be enabled by sending special USB-PD message.

More information: https://github.com/AsahiLinux/docs/wiki/HW%3AUSB-PD

deaddodo• 6 years ago

He talks about it here:

https://www.youtube.com/watch?v=d5s9fYfvzmY

(In addition to the docs, as outlined by terramex)

cshift• 6 years ago

I see your userland M1 assembly language hello world and raise you a bare-metal M1 kernel assembly language hello world :-)

The most on-brand HN thing I've read so far today.

RantyDave• 6 years ago

LOL. Zephyr?

megablast• 6 years ago

Looking forward to the updates benchmarks on hello world programs.

cylinder714• 6 years ago

Many thanks for any assembly-language posts, but can we agree that a FizzBuzz implementation would be more interesting? ;-)

saagarjha9• 6 years ago

  #include <sys/syscall.h>
  
  modulo:
      udiv x9, x0, x1
      msub x0, x9, x1, x0
      ret
  
  print_fizz:
      mov x0, #0
      adr x1, fizz
      mov x2, #4
      mov x16, SYS_write
      svc #0x80
      ret
  
  print_buzz:
      mov x0, #0
      adr x1, buzz
      mov x2, #4
      mov x16, SYS_write
      svc #0x80
      ret
  
  print_number:
      mov x9, x0
      mov x10, #10
      udiv x11, x0, x10
      mov x0, #0
      adr x1, number_table
      add x1, x1, x11
      mov x2, #1
      svc #0x80
      msub x11, x11, x10, x9
      mov x0, #0
      adr x1, number_table
      add x1, x1, x11
      mov x2, #1
      svc #80
      ret
  
  print_newline:
      mov x0, #0
      adr x1, newline
      mov x2, #1
      mov x16, SYS_write
      svc #0x80
      ret
  
  .globl _main
  .align 2
  _main:
      mov x19, #0
  loop:
      mov x20, #0
      mov x0, x19
      mov x1, #3
      bl modulo
      cmp x0, 0
      cset x20, eq
      b.ne not_3
      bl print_fizz
  not_3:
      mov x0, x19
      mov x1, #5
      bl modulo
      cmp x0, 0
      cset x21, eq
      b.ne not_5
      bl print_buzz
  not_5:
      orr x20, x20, x21
      cmp x20, #0
      b.ne divisible
      mov x0, x19
      bl print_number
  divisible:
      bl print_newline
      add x19, x19, #1
      cmp x19, #100
      b.le loop
      mov x16, #0
      svc #0x80
  
  fizz:
      .ascii "Fizz"
  buzz:
      .ascii "Buzz"
  number_table:
      .ascii "0123456789"
  newline:
      .ascii "\n"

ffhhj• 6 years ago

Nice tutorial! In the 90's got really excited with x86, trying all the DOS/BIOS interrupts and CGA/EGA/VGA/VESA programming. Got a computer lab evacuated with a fake "computer virus" Mcafee AV couldn't detect, a resident program that would display a snake moving on the screen. So much fun.

It would be great to get a book on the new M1 and MacOS services, specially if it includes some guide to their Neural Engine and GPU programming.

rckoepke2• 6 years ago

I believe the first attempts at doing something like this were back in July of 2020. https://github.com/below/HelloSilicon : Someone with an early Developer Transition Kit (pre-M1 release) worked to convert the code from "Programming with 64-Bit ARM Assembly Language" to the M1's syntax.

Porting additional textbooks to M1's (ARMv8) syntax could help a lot in terms of making assembly accessible to more people. I believe there's a lot of value in learning it on a particularly popular real-world platform like x86 or M1 - where it may directly translate to reverse engineering userspace applications without having to then learn another assembler language as you might if you started with, say, RISC-V.

Truthfully I think someone should really add the M1 syntax to the new version of VisUAL: https://github.com/scc416/Visual2 . I've been intending to work on that to go along with porting Bob Plantz' "Introduction to Computer Organization: ARM Assembly Language Using the Raspberry Pi" to ARMv8 for the same educational purpose but haven't quite found the time to really dive in. A tool like VisUAL2 could help a lot of people learn this even if they don't own an M1 themselves.

Very tangentially to all of this, I'd like to showcase https://github.com/cornell-brg/pydgin , which is a flexible toolkit for simulating ISA's in Python, and was used to help validate the first version of VisUAL during its own development.

KMag3• 6 years ago

I'm currently auditing the Stanford compilers course online. I understand the inertia in introductory courses, and the simplicity of MIPS, but hopefully the course is eventually ported to Aarch64 or RISC-V. Presumably a spim-like simulator for Aarch64 or RISC-V is the biggest missing component.

6.004 was one of my favorite classes at MIT, and the DEC Alpha AXP was a fine architecture to simplify for the pedagogical Beta architecture. However, I'm glad to hear they've moved to RISC-V. I presume they'd been avoiding porting the course to Aarch64 (or a simplified version thereof) due to intellectual property issues.

remexre• 6 years ago

For AArch32, not AArch64, but there's https://salmanarif.bitbucket.io/visual/index.html as a SPIM replacement.

wk_end• 6 years ago

I low-key think ARM64 might be the nicest ISA around. It reminds me of a modern, RISCier 68k.

bni• 6 years ago

How is it possible that a RISC ISA can be nice to program for in Assembly? Wasn't PPC horrible for this for example?

Wasn't the point of CISC to make it easier for Assembly programmers (made sense when x86 and 68k was defined)

socialdemocrat• 6 years ago

I started with 68k on Amiga which made me love assembly. Then got exposed to x86 which I hated with a passion.

Keep in mind I was quite young then and x86 had so many oddities and inconsistencies that it made it really hard for a beginner.

In Uni when making a compiler I choose to target PPC as I figured anything was better than x86.

I kind of regretted it. I was new to RISC and the heavy use of registers threw me off. E.g. using registers for all function arguments except when there where too many. Using a register for return address but then needing to use stack anyway of call stack got too deep. How every address had to be loaded in two steps.

On top of that PPC did not offer a smaller and simpler instruction set. It was quite large from what I remember.

So getting something akin to feeling like 68k was a dream that got popped.

But I would say RISC-V gives me a bit of the 68k feeling as things are kept really small and beginner friendly.

adrian_b2• 6 years ago

Most RISC ISA's, including PPC and ARM are much nicer to program in assembly than the Intel/AMD x86 ISA.

The only exception is with RISC ISA's that are far too simple, e.g. the base RISC-V, so they lack many common instructions or addressing modes, forcing the programmer to use sequences of instructions instead of the single instructions of other, more complete, ISA's.

Most RISC ISA's are relatively orthogonal, in the sense that you have to memorize only a small list of things, e.g. of kinds of instructions, kinds of registers, kinds of addressing modes, and then you can express any program as a combination of those few elements.

On the other hand, for the Intel/AMD x86 ISA, to be able to write an optimized program, you need to know a huge list of things.

The original x86 registers are all different having different features, there are not even 2 identical registers, so to find the optimal register allocation is difficult. Even the extra 8 registers added by the AMD 64-bit extension are not identical, but they are divided in 3 or 4 groups with different properties regarding the encoding of the instructions, which result in different program izes.

Among the registers added by more recent ISA extensions, especially the SIMD extensions, SSE/AVX, there are finally groups of identical registers that are easier to allocate, but these must be used together with the integer registers, which are needed at least for addressing.

It is difficult to determine the total number of different instructions in the x86 ISA, but they are much more than a thousand, many of which are obsolete and which should be avoided.

Even when compared to older normal ISA's, which are not so complex like x86, e.g. Motorola 68k or IBM mainframes, many RISC ISA's, including POWER & ARMv8, are still an easier target for assembly programming, when you attempt to write an optimized program.

When the performance of the program was not important, assembly programs for some traditional CISC ISA's e.g. Motorola 68k or DEC VAX could be simpler than for RISC ISA's, due to using fewer more complex instructions, but those instructions typically had slower implementations, so an optimized program might have been forced to avoid them.

Knowing the very variable timing of the CISC instructions and accounting for that in order to write an optimized program, made optimized assembly programming more difficult than for RISC CPUs.

mhh__4• 6 years ago

Ignoring that ARM isn't all that RISC-y anymore, CISC vs. RISC is basically a trade-off between density and the ease of widening execution.

Intermernet2• 6 years ago

I quite like RISC-V, but have yet to buy any actual hardware to play with. I don't think the worthwhile dev hardware exists yet, but I don't think it's far away!

high_priest• 6 years ago

Does this blog have RSS feed?

banana_giraffe• 6 years ago

https://smist08.wordpress.com/feed/

pedro19762• 6 years ago

Just in case you are looking for an rss feed, you can always give rss-proxy [0] a try.

[0] https://github.com/damoeb/rss-proxy

SecurityLagoon• 6 years ago

Thanks for this. Seems like another great service to run on my pi.

Getting a little tangential but how well do you find it works in general? I imagine it is only truly reliable with SSG type websites.

mhh__4• 6 years ago

Is mentioning M1 just guaranteed karma now?

1_player• 6 years ago

Apparently yes, I doubt a generic ARM assembly tutorial that writes "Hello, world" to stdout would get almost 400 points. It's not like M1 is a totally new architecture.

Conversely, saying anything bad about M1 or anything related to it, like this article, is a good way to piss people off on this forum.

andy_threos_io7• 6 years ago

And it's a total lame, bad assembly code. Lacks any kind of material knowledge or practice.

fellellor4• 6 years ago

Sorry for the noob question, but here it is anyway. What kind of projects and career paths does this kind of programming enable?

mhh__4• 6 years ago

My snarky answer to that is that I genuinely think any software engineer should be able to read and write assembly, even if purely to remind them just how far up the stack we usually operate at.

If we take "this" to mean low-level programming, it can open doors into anywhere from reverse engineering, to OS development etc (or more boringly, writing toolchains). Some parts of compilers rely heavily on having real problem solving skills at this level - for example most books won't teach you how to integrate ELF into your compiler, let alone DWARF.

I am hesitant to say performance optimization because many people have an idea of a CPU just executing one instruction at a time rather than the heavily pipelined and out of order monsters we have today.

To become Anger Fog, you must first invent the CPU-niverse.

(Agner is a almost mythical figure for many compiler and microarchitecture folks)

Intermernet2• 6 years ago

I'm somewhat delighted that your first mention of Agner got auto-corrected to "Anger Fog" :-)

I like to think that Agner would appreciate that!

2sk21• 6 years ago

When I was a CS PhD student, I spent the summer of 1988 writing assembly code on a parallel machine (Encore Multimax) that was running a variant of Unix. I wrote the runtime system (a virtual machine actually) for a parallel programming language. Haven't used assembly language since then!

fellellor4• 6 years ago

I still don’t get it. This sounds cool, but it seems like work other people have already done and done well. My impression of the computing world is that once someone does something very well, it shuts the door for new entrants. There’s no more low hanging fruit left. So unless you think this is something cool, there’s not much left here.

Tell me how stupidly wrong I am (gently).

KMag3• 6 years ago

The direct uses would be either very specialized portions of the kernel or C/C++ runtime (mutexes, etc.) or performance-critical code, where you'd typically look at C/C++ compiler output, tweak it by hand, and then insert your modifications into the C/C++ code as inline assembly.

Though, a small amount of assembly and a small understanding of processor design and implementation (I highly recommend MIT 6.004) go a long way into having a better mental model of what Java/JavaScript/C/C++ are actually doing under the covers and what's going on.

I was working on a project where I looked at the Philox4x32 random number generator specification and implemented it in Java. A colleague was trying to speed things up by porting it to C++ and so he just used the liberally licensed reference C++ implementation. He couldn't figure out why my Java implementation was significantly faster than the C++. I had a look, at the C++ implementation, and they missed an optimization to save one register in the inner loop. I didn't disassemble the native binary or have the JVM dissassemble JIT'd code, but I guessed that a register spill (32-bit x86 is pretty register starved) in the inner loop was the problem. Just by applying my optimization, he got the C++ implementation faster than the Java implementation.

fellellor4• 6 years ago

Sounds cool. I’m interested in this now.

nsonha• 6 years ago

isn't this just ARM assembly, is there such a thing called M1 assembly (genuine question)?

fulafel• 6 years ago

Yes. I guess the author is (successfully) going along with the general popular hype that paints it as a new architecture.

_ph_3• 6 years ago

I am certain, he isn't. The book also has a special chapter for iOS, explaining the changes needed to what is shown in the book to run the code with the iOS operation system and tooling.

_ph_3• 6 years ago

Yes, it is just ARM assembly. But the tooling (Clang vs GCC) and the operation system differ, so the code from the book won't work without changes on a Mac. The book already contains a chapter for using the ARM assembly on iOS, because you have to do the same changes vs. running the sample code on Linux. The linked blog posts lists these changes. They are not large, but significant enough, that someone learning how to code in ARM assembly will be thankful for adjusted example code.

khanan• 6 years ago

Funny how you can replace MacOS with FreeBSD in this article and it's the same thing. OH WAIT! eyeroll

astrange• 6 years ago

It isn't the same thing since macOS doesn't use ELF.

musicale• 6 years ago

The macOS kernel is Xnu or Darwin, not Linux. Try this on macOS vs. Linux:

    uname -a

macOS system call numbers and interfaces are derived from (Free)BSD.

95014_refugee3• 6 years ago

Some, a long time ago. Others come from Mach, and there’s ~20 years worth of independent work and divergence between then and now...

andy_threos_io7• 6 years ago

Prime example of how you NOT write assembly code, no matter what cpu are you using.

First thing first, macro assemblers have been around for at least 40+ years. So don't use numbers in your code. use macros or defines.

Ex. you can compile with gcc flags -x assembler-with-cpp

and you can have nice defines in your code.

Second on a decent OS even in assembly link against operating system call library, no matter what. The system call numbers can change. so use symbols.

Also don't write the string length in the code, it's total lame.

and use .asciz not .ascii

and define your function symbols to function gcc:

    .global my_func_name
    .type my_func_name, function
    my_func_name:

if you use C preprocessor for assembly compile just make an include like this:

  #define _FUNCTION(A) .global A ;\
   .type A, function

EDIT: For the not well informed HN readers:

https://developer.apple.com/library/archive/qa/qa1118/_index...

"Apple does not support statically linked binaries on Mac OS X. A statically linked binary assumes binary compatibility at the kernel system call interface, and we do not make any guarantees on that front. Rather, we strive to ensure binary compatibility in each dynamically linked system library and framework."

So DON'T write direct system call numbers in your code!

saagarjha9• 6 years ago

Using .ascii is fine; the string is going to a syscall–not libc. And using the standard library in a program like this is kind of beside the point…

andy_threos_io7• 6 years ago

nope, every decent OS has system call library you can write like:

  bl _Open ; whatever syscall name you have

and the linker or the OS dynamic linker will get you the proper system call code, with the numbers.

BTW even in our small threos.io os we use dynamic linked system calls.

messe• 6 years ago

Ex. you can compile with gcc flags -x assembler-with-cpp

You don't even need the flag. Just use the .S file extension rather than .s

tcmb• 6 years ago

I'm confused, why is this showing a Linux assembly file and then the Makefile and build instructions for macOS?

mark_l_watson2• 6 years ago

That is so cool. I think that I am going to but his book.

It has been years since I wrote assembly code. I will time box an hour or two this weekend to play with this, but just for fun.

mark_l_watson2• 6 years ago

To late to edit, I meant “buy his book”. Typo.

_ph_3• 6 years ago

This is very nice to see. I recently got this book to get into ARM assembly language, with the long-term goal of using it on an M1 Mac, I barely could resist on getting a MacBook Air immediately :). Right now, I am setting up a Raspberry Pi 400 for first experiments. Unfortunately, it still ships with a 32 bit install.

While the differences between a M1 Mac and Linux-ARM machine are small, it is very nice to have the examples ported and especially tested on the Mac, as especially during learning a small mistake can be difficult to be noticed.

bobrippling• 6 years ago

A few extra things to note for enthusiasts:

The MacOS linker/loader doesn’t like doing relocations, so you need to use the ADR rather than LDR instruction to load addresses. You could use ADR in Linux and if you do this it will work in both.

I think this is more the assembler - the linker's perfectly happy performing relocations

In MacOS you need to link in the System library even if you don’t make a system call from it or you get a linker error. This sample Hello World program uses software interrupts to make the system calls rather than the API in the System library and so shouldn’t need to link to it.

You can get around this by creating a statically linked executable, which requires a bit of wrangling, but is supported (and perhaps handy if you're going on to write a kernel).

In MacOS the default entry point is _main whereas in Linux it is _start. This is changed via a command line argument to the linker.

In macOS the default entry point is start (linux is still _start), the C runtime still needs to be setup - the kernel can't jump a program straight to main.

95014_refugee3• 6 years ago

I think this is more the assembler - the linker's perfectly happy performing relocations

No, this is “all executables are PIE because applying relocations to shared code is stupid and inefficient in the presence of ASLR”.

95014_refugee3• 6 years ago

In macOS the default entry point is start (linux is still _start), the C runtime still needs to be setup - the kernel can't jump a program straight to main.

macOS has no interest in what the symbol is called; it pulls the initial PC from the LC_MAIN command in the Mach-o header.

ld64 (the linker) will by default populate that load command by looking up “_start”, but that’s a separate thing...

Apple M1 Assembly Language Hello World

Related Stories