1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
Bare minimum portabilty?
========================
Which platforms to support? How to decide?
What Hare supports
------------------
- Free OS:es only
- x86_64, aarch64, riscv64
A pragmatic way
---------------
- Linux and Windows
- x86_64 and aarch64
- Maybe Javascript and/or WASM+WASI
What F/OSS distributions supports
---------------------------------
(this is 8(!) arches, not counting the "arm32" variations)
A = Alpine ("Standard" edition, v. 3.22.1)
D = Debian 13 "trixie"
F = Fedora
- aarch64 [ADF]
- armel [ D ]
- armvhf [ D ]
- armv7 [A ]
- loongarch64 [A ]
- ppc64el [ADF]
- riscv64gc [ D ]
- s390x [ADF]
- x86 [A ]
- x86_64 [ADF]
The "device count" way
----------------------
(= which have the most devices that are standardized enough
and allow practical installation of 3rd party software)
- Linux and Windows
- aarch64, armhf (or whatever rpi1 is using), i386, x86_64
- Maybe Javascript and/or WASM+WASI
The F/OSS- and OSHW-only way
----------------------------
This is going to very seriously limit the number of users :P
- Free OS:es only
- Free CPU architectures only:
mrisc32, or1k, ppc64/ppc64le, riscv32/64, sparc64
How to keep code generation easy to port
========================================
The way to get most portability is to compile to C, but that makes cross-
compilation cumbersome, since it requires a C compiler toolchain and a
corresponding sysroot.
The ABI must be implemented in full regardless, for two reasons:
1. For ABI stability over time, even as the code generator gets improved.
2. For interopability with C code.
There could be multiple "mixins" for the code generator. Maybe some really
simple (but unoptimized) one. E.g. all operations could go through a
register.
|
