assembly not directly to executable elf but first linkable elf (object file) -- sections instead of segments

phase 1

Aback header files (.ab) equivalent to C header files so that external code can be type-checked and C functions can be called from Aback)

func is_prime?
    int -> bool
end

phase 2

transpiration from Aback to C headers
(.abh -> .h) and vice versa so that there is no disparity between them

aback trans primes.h primes.abh

int is_prime(int);
// invalid characters are skipped
// types are cast to nearest equivalent type (no bools in c)

additional instructions:

CALL addr (PUSH ip + JMP addr)
RET (jump to the addr at the top of the stack
PUT_BP
TAKE_BP

Have a secondary stack just for storing the return addresses and local variables (taken/peeked values). That way you never have to copy the return values as they're already on the primary stack where they should be.

The secondary stack should start at (initial rsp) / 2. Have rbp point at its base so you can check if they ever overlap.

Add a main proc.

make an exaple of 1 billion row challenge

Include QBE backend instead of the current custom one. This will bring pros like targeting multiple architectures (amd64, aarch64, riscv64) and optimization. But it will require rewriting the entire parser to produce an AST which will then be used to output QBE IR.

steps

• parser builds an AST from tokens
• typechecker checks AST output
• post-processor expands macros, creates data for static strings
• separate front-, middle- and backend
• middle-end (post-processor) emitting QBE IL
• implementing backend (QBE IL -> asm -> executable)

stages

frontend

• lexer
• preprocessor
• parser
• type-checker

middle-end

• post-processor
• QBE IR generator, (Erlang generator)

backend

• QBE + CLang/MinGW
• (Erlang compiler)

--
Backend is basically

qbe -o <name>.s <name>.ssa 
cc -o <name> <name>.s
rm <name>.ssa <name>.s

or

erlc <name>.erl

but called from OCaml.

Procedures are functions that don't return anything. Don't use that name anymore, rename them to func. Also rename macro to inline func since untyped and numbered macros have been removed.

Introduce pure func that doesn't have side effects. It may read the environment but not change it.

write Aback compiler in itself when it has enough features that it's not uncomfortable but not too large that it would be too big a feat

No more treating each word as an instruction to push to the stack and then checking the sequence.
If we want to have a more sophisticated backend we have distinguish between function arguments and ordinary words being pushed to the stack which we will consider as variables.

also treat take and peek as variable assignment

use ld instead of gcc?

To create a shared object (.so) file from one or more object files on Unix-like operating systems (including Linux and macOS), you typically use the gcc or g++ compiler (for C or C++ projects, respectively) with the -shared option. This tells the compiler to produce a shared library rather than an executable. Here's how you do it:

gcc -shared -o libmyshared.so file1.o file2.o file3.o

This command will take object files file1.o, file2.o, and file3.o and combine them into a shared object file named libmyshared.so.

Additional Considerations:

• Position Independent Code (PIC): When compiling the source files into object files that will be used in a shared library, it's often recommended (or required) to compile them with the -fPIC option, which generates position-independent code. This makes the resulting shared library more flexible in terms of where it can be loaded into memory, which is important for shared libraries. The compilation step for each source file would look something like this:

  gcc -fPIC -c file1.c
  gcc -fPIC -c file2.c
  gcc -fPIC -c file3.c

• Library Naming Convention: It's a common convention to prefix the name of shared libraries with lib and use the .so extension. This helps tools like the dynamic linker (ld.so) and compilers (gcc, g++) recognize and handle them appropriately.

• Linking with Other Libraries: If your shared library depends on other shared libraries, you can specify them using the -l (lowercase L) option followed by the library name (without the lib prefix and .so extension). You may also need to specify the path to these libraries with -L.

• Visibility: Consider using visibility attributes or pragmas to control which symbols are exported from your shared library. By default, all symbols may be exported, but it's often a good practice to limit exports to only those symbols that should be publicly available.

Here is an example command that compiles source files directly into a shared object, assuming the source files do not depend on other shared libraries:

gcc -shared -fPIC -o libmyshared.so file1.c file2.c file3.c

Remember, the exact command and options might vary depending on your specific development environment and the languages you're using.

Print all comments containing TODO, TODO:, ISSUE ... tokens.

$ cat program.ab
(ISSUE: program not implemented)
(TODO: implement the program)

$ aback todos program.ab
'program.ab':1:1:
    (ISSUE: program not implemented)
'program.ab':2:1:
    (TODO: implement the program)

When the language (and dependencies) are mature enough, publish it as a package on homebrew.

Publish JS executable on NPM for Windows users and the ones who don't want to install Homebrew or build from source.

Eventually publish DEB, RPM and Flatpak packages

compilation to BEAM bytecode,
BEAM specific features like processes and messages

implement backend yourself and make a library out of it?

The backend can easily be platform-independent (at least on UNIX) if wrapper functions are created for each system call which can be swapped depending on the platform. This immediately discards Windows as a target platform but perhaps syscalls can somehow be emulated on it or a higher-level concept can be divised down the line.

Make a file with system call functions for every target so you don't have to link with libc (-nostdlib).

https://filippo.io/linux-syscall-table/
https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master

core/syscalls/
  arm64-darwin.asm
  arm64-linux.asm
  riscv64-linux.asm
  x86_64-darwin.asm
  x86_64-linux.asm
  x86_64-windows.c??

See
https://github.com/jkenda/qbe-example

// syscalls-amd64_linux.s
.text
.globl _start
_start:
    # get argc, argv
    mov 0(%rsp), %rdi
    lea 8(%rsp), %rsi

    call main

    mov %rax, %rdi
    jmp exit

.macro def_syscall name num
.globl \name
\name:
    push %rcx
    push %r11

    mov $\num, %rax
    syscall

    pop %r11
    pop %rcx

    ret
.endm


def_syscall read,   0
def_syscall write,  1
// ...
def_syscall exit,   60
// ...

// syscalls-arm64_apple.s
.section __TEXT,__text
.globl _start
_start:
    ldr x0, [sp]
    add x1, sp, #8

    bl _main
    b _exit

.macro def_syscall name num
.globl _\name
_\name:
    mov x16, #\num
    svc #0x80

    ret
.endm


def_syscall read,   1
// ...
def_syscall write,  3
def_syscall exit,   4
// ...

Extend QBE to target the Windows ABI in addition to System V.