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.

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

Thank you!

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

https://developer.apple.com/support/downloads/Apple-File-Sys...

The boot process for HFS+ is more involved, because you have to actually read the HFS+ file system to locate the EFI image, since it's stored in a regular file.

I'm not sure what happens after jumping into the EFI code.

(Disclaimer: I worked on the linked document.)

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.

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

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

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

This made me laugh because I spent a good chunk of last weekend trying to debug a problem with some of my old computer hardware and the problem turned out to be a link that couldn't handle anything over 150 baud.

Now we're squirting 115,200 straight out of a chip. It's like the future!

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.

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.

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?

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.

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.

Further, the common denominator you're seeing goes back much, much further than BSD itself. Behold! "Version 1" of UNIX, written in just 14 files of PDP-11 assembly. And if you look at u1.s, you'll see the sysent routine which handles syscalls. The numbering should be familiar :-)

https://github.com/dspinellis/unix-history-repo/blob/Researc...

If you go to 4.2BSD, you'll see many of these syscalls labeled as "old", e.g. "old pause", "old wait", "old break".

https://github.com/dspinellis/unix-history-repo/blob/BSD-4_2...

You can go a little further back to the original PDP7 assembly, but I don't believe the "kernel" actually ran on a separate "process" at all, and the userland simply linked into kernel symbols and called "read", "readdir" etc directly, hence why even later unix documentation tends to call these "routines" or "library calls".

Interesting, I didn’t know that! There’s definitely an essay to be written here about the evolution of this “Unix system-call convention” over the decades, going into how this table of calls survived each transition and port mostly-unscathed. (Given that we’re throwing actual source syscall tables back and forth as proofs, there’s definitely some narrativizing to be done here, The Old New Thing-style.)

I assume the syscalls weren’t retained in ports with the goal of “binary compatibility”, given that these descendant Unix ports were on different architectures that couldn’t literally exec(2) binaries from their ancestor. Guesses:

• Toolchain compatibility?

• Some shared cross-compiling assembler/linker that nevertheless had hard-coded syscalls?

• (The perhaps never-achieved-in-practice goal of) emulation-assisted descendant cross-compatibility, ala z/OS?

• The existence of hybrid/transitional minicomputer generations, that had application processors for both the old and new architectures (or application processors that could execute on both ISAs!), such that at least some of the systems being ported to could exec(2) the ancestor’s binaries straight from tape?

• Or just the expectation that, despite Unix and C being so intertwined, there were still enough people writing ASM for these machines — using a non-macro assembler — who had developed reflex-memory for the existing syscall numbers, that it would be a bad idea to change the table out from under them?

> the userland simply linked into kernel symbols and called "read", "readdir" etc directly

So basically, the original Unix was a DOS, rather than a kernel/supervisor. Was that just because the PDP7 didn’t have virtual memory management, or was it a conscious design decision that was later reversed?

https://github.com/DoctorWkt/pdp7-unix/blob/master/src/sys/s...

It's all just guessing, but I figure the explanation is much simpler -- for PDP11 UNIX, they just kept using the same syscalls up till V7 / 2BSD, and there should have been a sort of "rolling release" binary compatibility. For the VAX, the first port (32v) probably just retained the original numbering since there was no reason to deviate from it, which colored 3BSD and 4BSD, hence {Net,Free,Open}BSD and Darwin and friends.

Worth pointing out that several versions of Linux have rather different syscall tables. 32 bit ARM and x86 are more-or-less matches, with ARM differing on a few early syscalls, while 64 bit ARM and amd64 differing quite dramatically. The old ABI for 32bit MIPS also matches, but both the n32 and n64 ABIs use slightly variant syscall tables. PowerPC 32/64 bit is also a close match, although it has some impedance (I think it matches closer to AIX by design)

At the end of the day, I think the similarity is mostly a mixture of coincidence, system developers being influenced by their bootstrap system's syscall tables, and no real reason to change them up. No reason to not change them, either, since it's pretty trivial to use different dispatch tables for different types of processes, like how the BSD's handle other-OS compat.

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

(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. ;-)

Could you give a direction to a good place for learning it ? Where is better to start? I wish to write hello world without linker or assembler for linux.

[0]: https://azeria-labs.com/writing-arm-assembly-part-1/

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

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.

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.

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.

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:

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

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!

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

  bl _Open ; whatever syscall name you have

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

Golang used to run into this, they switched to using libSystem in 1.11: https://golang.org/doc/go1.11#runtime

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.

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

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.

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.

x86 is very orthogonal and has been since the 386. There's something called a ModRM, and the majority of the instructions use that form. The encoding is based on octal: https://gist.github.com/seanjensengrey/f971c20d05d4d0efc0781...

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.

On the contrary, that guides register allocation. Too bad most compilers don't seem to know, which is why they are often very easy to beat (and why compiler output looks so distinctively different from good handwritten Asm.)

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.

I have no idea what you mean by "divided in 3 or 4 groups". The "high registers" are all accessed with an extra prefix byte.

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.

FUD, no one really cares about "total number of different instructions". If you think of the typical RISC with fixed 32-bit instructions, that's over 4 billion values...

RISC is so bland and boring that it's hard to do a better job than a stupid compiler. An "op mem, reg" which is usually 2 or 3 bytes on x86 turns into at least 3 instructions (=12 bytes) and an explicit register allocation on a RISC. It's like writing microcode. No wonder they have so many registers --- they're really what a more intelligent CISC would use dynamically allocate internally in its uop execution engine/register renamer, saving cache occupancy and fetch bandwidth.

I agree that you are right that for simple programs you can use the x86 registers for the purpose chosen by Intel, e.g. CX for storing a loop counter and so on.

Nevertheless, in my experience that are a lot of programs where you also want to use the registers for other things and if you would want to ensure that the program has the minimal size possible with the x86 encoding, you would have to move that variable from one register to another many times, to be able to use the shorter instructions possible with certain registers.

Of course, you can just ignore a large number of the 8086 special instruction encodings that were designed to enable shorter programs, in which case you can use most registers in an almost orthogonal way.

However, that is not very satisfying, to waste the extra existing hardware, just because it is hard to use. I prefer a CPU which does not implement features with little benefits, but if the features have already been implemented, I will rather use them.

"The "high registers" are all accessed with an extra prefix byte."

This is how it should have been, except that AMD was super lazy for unknown reasons and they saved a few decoding gates in a 64-bit CPU with millions of gates by not fully-decoding that extra prefix byte.

Because of that, there are addressing modes where you cannot encode R12 and other addressing modes where you cannot encode R13. When using R12 or R13, certain instructions are longer than when using other registers and those instructions are not the same for R12 and for R13.

So, to write the minimum-length program you must allocate differently R12, R13 and the other high registers. Moreover, there are other differences in the high registers that are not enforced by hardware, but they are enforced by the AMD64 ABI conventions about register usage, further dividing the high registers into groups with different properties.

Also the high number of registers in RISC CPUs vs. CISC CPUs has almost no relationship with the RISC concept.

One or two extra registers in a RISC are enough to cover the fact that a CISC instruction that combines a load with an operation uses an implicit register, besides the architectural registers.

The fact that most RISC ISAs have more registers than older ISAs, which happened to be CISC, is due to the need for higher performance in modern CPUs.

When you have more registers, you can interleave more chains of dependent operations, being thus able to hide the latencies of various execution units or to fully use all the execution units that would have stayed idle otherwise.

Too many registers can lower the performance, due to the need for saving and restoring them, but 32 registers are definitely better than 16, because they frequently enable faster programs.

Register renaming does not help with this. Register renaming eliminates the problem of shared resources (i.e. shared registers) in concurrent instructions, but it does not enable you to write a program that will hide the latencies caused by dependencies between instructions or that will be able to fully use all the execution units.

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.

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

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

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

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.

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

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.

Next time you have some tricky inner loop showing up in profiles, write a few alternative implementations, benchmark each, and use the -S flag to get gcc/clang to dump out assembly.

There are some people who write a lot of assembly language, but I think orders of magnitude more people read assembly regularly while writing it rarely.

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)

Tell me how stupidly wrong I am (gently).

I like to think that Agner would appreciate that!

    uname -a

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

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

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.

There is basic JavaScript support [0], but this is rather new and not sure how well it works. I tested it with a couple of webapps and craigslist and it worked ok. If you host it on your pi, you can just run the big js-image.

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

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.

Your program (made this way) will NOT WORK at all in the near future, ex when the system call number is changed (it's happened).