@ppcamiga1

Quote:

This is hand made assembler code not what produce gcc for example on rpi.

Are you trying to be smart? Have you ever worked with aarch32/aarch64? Have you ever programmed them? HAve you ever used/programmed ARM in big endian mode? Have you ever read ARM manuals? Hand made assembler? Hmm, here you go:

Quote:

➜ ~ cat foo.c unsigned int foo() { return 0xdeadbeef; } ➜ ~ /opt/cross/bin/aarch64-linux-gcc -Os -S -mbig-endian foo.c ➜ ~ cat foo.s .arch armv8-a .file "foo.c" .text .align 2 .global foo .type foo, %function foo: .LFB0: .cfi_startproc mov w0, 48879 movk w0, 0xdead, lsl 16 ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (GNU) 8.2.0" .section .note.GNU-stack,"",@progbits ➜ ~ /opt/cross/bin/aarch64-linux-gcc -Os -c -mbig-endian foo.c ➜ ~ /opt/cross/bin/aarch64-linux-objdump -S foo.o foo.o: file format elf64-bigaarch64 Disassembly of section .text: 0000000000000000 : 0: 5297dde0 mov w0, #0xbeef // #48879 4: 72bbd5a0 movk w0, #0xdead, lsl #16 8: d65f03c0 ret

Do you prefer 32-bit arm? Here you go, this time with dump of binary files:

Quote:

➜ ~ /opt/cross/bin/arm-linux-gnueabihf-gcc -nostartfiles -nostdlib -Os -o foo foo.c /opt/cross/lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010074 ➜ ~ /opt/cross/bin/arm-linux-gnueabihf-objcopy -O binary foo foo.bin ➜ ~ hexdump -C foo.bin 00000000 00 00 9f e5 1e ff 2f e1 ef be ad de |....../.....| 0000000c ➜ ~ /opt/cross/bin/arm-linux-gnueabihf-gcc -mbe8 -mbig-endian -Wl,--be8 -Wl,--format=elf32-bigarm -nostartfiles -nostdlib -Os -o foo foo.c /opt/cross/lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000010074 ➜ ~ /opt/cross/bin/arm-linux-gnueabihf-objcopy -O binary foo foo.bin ➜ ~ hexdump -C foo.bin 00000000 00 00 9f e5 1e ff 2f e1 de ad be ef |....../.....| 0000000c

There you can clearly see that loading constant from the code section does not change instruction stream (first 8 bytes), but definitely changes the last 4 bytes from little endian byte order to big endian byte order. From programmer point of view the CPU behaves in this case as any regular big-endian cpu. Even if byte order of CPU instructions remained LE.

Quote:

Old C/C++ Amiga code should work after just recompilation. It works on ppc because on ppc like m68k data AND code are 32 bit big endian.

This is exactly the case. If AmigaOS was using 32bit ARM cpu operated in big endian mode, re-using old C/C++ Amiga code would be just a matter of recompilation.

Quote:

It is not possible on ARM because on ARM code is little endian.

Again. It does not matter what byte order the instruction stream is using. And, yet again, feel free to prove me wrong with something more than words.

Last edited by michalsc on 21-Apr-2021 at 10:04 AM.
Last edited by michalsc on 21-Apr-2021 at 10:02 AM.