What would need to be changed for 64-bit port?

Well, it's a completely different instruction set.

On a PI3-B (old version without "+") running Devuan2 ...

~$ uname -a
Linux pi3-0 4.14.18-v8+ #1 SMP PREEMPT Tue Feb 13 12:54:55 CET 2018 aarch64 GNU/Linux
~$ cat /etc/devuan_version 
ascii

... MicroPython builds without problems:

/home/wrk/micropython/ports/unix$ ./micropython 
MicroPython v1.9.4-568-g4df194394-dirty on 2018-09-23; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> █

So micropython works even without an assembly emitter for the architecture? I saw that there are only for x86, x86_64 and arm, and it looked like a new arm64 emitter was needed.

Actually, you may still be compiling it for 32-bit. Can you run gcc --version? Your kernel is 64-bit but that doesn't say anything about your toolchain.

Interesting. How does micropython work there? Is it just a pure interpreter?

Summary of make test:

657 tests performed (18989 individual testcases)
655 tests passed
59 tests skipped: builtin_help builtin_range_binop class_delattr_setattr io_buffered_writer namedtuple_asdict sys_getsizeof cmd_parsetree framebuf1 framebuf16 framebuf2 framebuf4 framebuf8 framebuf_subclass uhashlib_md5 urandom_extra urandom_extra_float ure_groups ure_span ure_sub ure_sub_unmatched vfs_basic vfs_fat_fileio1 vfs_fat_fileio2 vfs_fat_more vfs_fat_oldproto vfs_fat_ramdisk vfs_userfs mpy_invalid resource_stream native_closure native_const_intbig native_misc native_try native_try_deep native_with schedule viper_addr viper_args viper_binop_arith viper_binop_comp viper_binop_comp_imm viper_binop_divmod viper_binop_multi_comp viper_cond viper_error viper_globals viper_import viper_misc viper_misc_intbig viper_ptr16_load viper_ptr16_store viper_ptr32_load viper_ptr32_store viper_ptr8_load viper_ptr8_store viper_subscr viper_try viper_with extra_coverage
2 tests failed: float_parse float_parse_doubleprec
Makefile:190: recipe for target 'test' failed
make: *** [test] Error 1

I have no idea how severe the 2 fails are. Let's wait for the MicroPython demigods explaining it.

@AntonioND

Interesting. How does micropython work there? Is it just a pure interpreter?

By default code is compiled to bytecode which is interpreted. However it can emit native machine code using @micropython.native or @micropython.viper decorators, and it also enables writing inline assembler. Clearly these features would need to be ported to a new instruction set.

@dpgeorge is the FP guru but I guess that by default MicroPython assumes a 32 bit hardware FPU. This is just a guess - I haven't studied the code.

I've just compiled the minimal unix target it in my RPi3+ with Fedora (aarch64) and it works out of the box indeed. I guess it's slower than having the machine code compiler but it does the trick for me.

uPy works also on a Renesas RCar-M3 (AArch64), compiled with linaro-toolchain. no big changes necessary. But FPU does not work.

@AntonioND I'm not saying this is exhaustive but here's the two major configurations you have to set up that depend on 32- vs 64-bit.

1. "must be pointer size" - search for this and you'll find a few places where you need to set typedef to the 64-bit signed and unsigned int. In 64-bit, void* are 64-bit, right?
2. MICROPY_OBJ_REPR - 64-bit precludes representation C.
3. garbage collection - when you're garbage collecting, you need to take care of the registers which are specific to the architecture; see gc_helper_get_regs_and_sp

NLR and GC helper code was added in 2d5cece and 098ac11

Is anyone working on porting py/dynruntime.mk and all it requires to aarch64?
micropython builds easily for aarch64, and I can include C code into the executable. I'm looking to put C code into .mpy files to be dynamically loaded in micropython on an aarch64 system. This does not appear supported yet. For example going into examples/natmod/features0 , edit Makefile to set ARCH = aarch64, type make.

@egbit you can try do add something like the following to py/dynruntime.mk - assuming that your host is aarch64 (not cross compiling).

else ifeq ($(ARCH),aarch64)

# aarch64
CROSS = 
CFLAGS += -fno-stack-protector
MICROPY_FLOAT_IMPL ?= double

@jonnor I get the impression that @egbit's question is about cross-compiling.

To support aarch64 for dynamic native modules there's more work to be done, mostly in mpy_tool.py (you can see how all the other supported architectures are implemented there).

I'm going to close this issue because the original issue is solved (there's NLR and GC support for aarch64). There is not yet a native emitter, but as @peterhinch has pointed out this is not necessary. MicroPython just uses the compiler's floating point support (and optionally you can use our libm) so setting MICROPY_FLOAT_IMPL=double will use double precision float (either soft or hard depending on compiler flags and target).