[MC1.7.10][OC1.5.x]ARM Architecture "OC-ARM" (alpha, updated 2016-06-07)

[rougeminner 0]

how would one use your makeFile to compile there own .s file into a rom file. 

[Solra Bizna 10]

This post contains instructions on how to make a .elf, requiring boot0 to load it. The procedure for making a .rom instead is nearly identical, but unless you really want to be limited to 1000ish instructions, you should probably make a .elf instead.

[Gorzoid 10]

Do you know why the emulator spams this error when you step/run?

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException

Looking at https://github.com/SolraBizna/jarm/blob/master/src/name/bizna/ocarmsim/SimThread.java#L255 I don't see how  addrInfoLock could be null unless the constructor threw an error which it didn't.

[Solra Bizna 10]

After I added -addrinfocmd, I never tested without it. Apparently the simulator has never functioned without it.

I've made a new release of the simulator, 0.0a3a, that no longer has this bug.

[Gorzoid 10]

After I added -addrinfocmd, I never tested without it. Apparently the simulator has never functioned without it.

I've made a new release of the simulator, 0.0a3a, that no longer has this bug.

It was working, it just spammed that alot, I didn't notice anything bad happening because of it. I got my code working to print a few x's on the screen and got your lua bootloader working. I didn't use -addrinfocmd as I am using windows and I only have arm-none-eabi on my raspberry pi which I build the roms on. anyway, good to see your still active

[Solra Bizna 10]

Active might be pushing it. Alive, maybe.

It would not have been completely broken; the exceptions would, however, have prevented some important updating and left the simulator subtly broken. (Unless I don't know how Java's `finally` keyword works, which is entirely possible.)

[Gorzoid 10]

Is there any way to sleep until a signal is pushed? Atm I am using this:

#define pullSignal(buffer) asm volatile(\
	"1:\n\t"			\
	"STC p3, c0, %0\n\t"	\
	"BVS 1b \n\t"		\
	::"m"(buffer))

to wait for a signal but when I do that the emulator starts using 70% of my cpu while running. I tried using "MRC p3, 0, r0, cr2, cr0" like you do in the tetris but that gives same amount of lag.

 

Also would it be easy to link libc so I can use strcmp and such? I tried linking the compiled objects in newlib but it gives the error

arm-none-eabi-ld: error: ../newlib-jarm-build/libc/string/lib_a-strcmp.o uses VFP register arguments, bin/test.elf does not
arm-none-eabi-ld: failed to merge target specific data of file ../newlib-jarm-build/libc/string/lib_a-strcmp.o

would it work if I downloaded the GNU libc source code and compiled it with the same clang arguments?

[Solra Bizna 10]

Is there any way to sleep until a signal is pushed? Atm I am using this:

#define pullSignal(buffer) asm volatile(\
	"1:\n\t"			\
	"STC p3, c0, %0\n\t"	\
	"BVS 1b \n\t"		\
	::"m"(buffer))

to wait for a signal but when I do that the emulator starts using 70% of my cpu while running. I tried using "MRC p3, 0, r0, cr2, cr0" like you do in the tetris but that gives same amount of lag.

The lag (if you're talking about the latency between causing a signal and having the program "receive" it) is a side effect of the way OpenComputers syncs with Minecraft. The simulator is simulating it accurately(ish). Doing a tight loop to wait for a signal will reduce the lag in the simulator but will increase it in Minecraft.

 

Also would it be easy to link libc so I can use strcmp and such? I tried linking the compiled objects in newlib but it gives the error

arm-none-eabi-ld: error: ../newlib-jarm-build/libc/string/lib_a-strcmp.o uses VFP register arguments, bin/test.elf does not
arm-none-eabi-ld: failed to merge target specific data of file ../newlib-jarm-build/libc/string/lib_a-strcmp.o

would it work if I downloaded the GNU libc source code and compiled it with the same clang arguments?

Getting GNU libc compiled for this target would probably not work at all, and then use too much memory if it did. The Lua source code theoretically shows the proper way to link with the compiled newlib, but I haven't released it yet (because it's still broken and I'm lazy).

Here are some snippets that should get you on the right track getting newlib working:

cd newlib-jarm-build
../newlib-2.4.0/newlib/configure --target arm-none-eabi --disable-multilib --disable-newlib-register-fini --disable-newlib-mb --disable-newlib-wide-orient --enable-lite-exit --disable-newlib-iconv --disable-newlib-supplied-syscalls --prefix=`pwd` CC="clang" CFLAGS="-g -target armv7a-eabi -march=armv7-a -mfloat-abi=hard -mbig-endian -mhard-float -mfpu=vfpv4 -mhwdiv=thumb,arm -ccc-gcc-name arm-none-eabi-gcc"
make -k
# this will error, THIS IS NORMAL

Flags to compile with:

ASFLAGS=-march=armv7-a -mfloat-abi=hard -mfpu=vfpv4 -EB -meabi=5
TARGET_FLAGS=-target armv7a-eabi -mbig-endian -mfloat-abi=hard -mhard-float -mfpu=vfpv4 -mhwdiv=thumb,arm -D__ELF__
CFLAGS=$(TARGET_FLAGS) -Oz -g -nostdlibinc -isystem include/ -isystem ../newlib-jarm-build/ -isystem ../newlib-2.4.0/newlib/libc/include/ -Wall -Werror
LDFLAGS=--be8 -z max-page-size=4 -nostdlib -L../newlib-jarm-build -L../jarmrt/lib --no-enum-size-warning
LIBS=-lm -lc -lbuiltin
ARFLAGS=rs

You'll need to write some stubs... here's sbrk:

#include <unistd.h>
#include <errno.h>

extern uintptr_t ram_bytes;
extern unsigned char __heap_start;

void* sbrk(ptrdiff_t increment) {
  static uint8_t* cur_heap_end = ((uint8_t*)&__heap_start);
  if((uintptr_t)(cur_heap_end + increment) > ram_bytes) {
    errno = ENOMEM;
    return (void*)-1;
  }
  else {
    void* ret = cur_heap_end;
    cur_heap_end += increment;
    return ret;
  }
}

gettimeofday plugged into real time:

#include <sys/time.h>

int gettimeofday(struct timeval* tv, void* tz) {
  long long millis;
  asm("MRRC p3, 0, %0, %H0, cr1":"=r"(millis);
  tv->tv_sec = millis / 1000;
  tv->tv_usec = (millis % 1000) * 1000;
  return 0;
}

I can't remember whether I released jarmrt. I think I didn't yet because I hadn't sorted out license issues; it's an incredible hack that includes huge chunks of compiler-rt verbatim.

[Solra Bizna 10]

I'm picking up this project again in earnest. I've determined that the main thing that's been gumming me up is trying to attack the software and hardware ends simultaneously and in an ad-hoc way. To that end, I'm going to focus down.

I've edited the OP with my current todo list.

[feherneoh 0]

I see that occross can build the compiler for OC-ARM Little-Endian too. Does the mod actually support switching endianness and Little-Endian binaries?
I have a project that I simply cannot get to compile as Big-Endian, as I cannot figure out which linker script stays still armel after reconfiguring everything I found as armeb

[Solra Bizna 10]

On 2/23/2017 at 9:40 AM, feherneoh said:

I see that occross can build the compiler for OC-ARM Little-Endian too. Does the mod actually support switching endianness and Little-Endian binaries?
I have a project that I simply cannot get to compile as Big-Endian, as I cannot figure out which linker script stays still armel after reconfiguring everything I found as armeb

Sure does. Just two things to keep in mind:

• The CPU boots in big-endian mode, so you'll want to do SETEND LE as your first instruction. I'm not certain, but it might switch to big-endian mode on interrupts as well. (Not that it matters, since my interrupt code is just stubs...)
• boot0 will only load big-endian ELFs. It should be (relatively) simple to make a little endian version: do SETEND LE as the first instruction, manually byte swap the constants/shifts wherever boot0 uses a 32-bit integer comparison to test 4 bytes of memory, and remove the code that checks for the BE8 flag.

I'd planned to modify boot0 to be able to load either little- or big-endian ELFs, and switch the endianness itself. Of course, I'd also planned to make it OETF-compliant, and to finish the mod in general. If only I still had the time...