vm_armv7l.c is not used by default

[zturtleman]

vm_armv7l.c should be used by default on armv7l but it is not. It's possible to force using it by running make ARCH=armv7l though.

The Makefile was changed to generalize armv6l, armv7l etc architectures as "arm".[1] Using vm_armv7l.c requires ARCH Makefile variable to be armv7l.[2]

[jjbarr]

I attempted a fix for this here: jjbarr@da6c323

However, I'm not willing to submit a PR until someone's looked it over: I don't have an ARM toolchain available at present, so I can't actually test it.

Noted issues: At present, I am not sure if ARM_VERSION needs to be exported. It doesn't seem to be? but if it does, that can be done. Also, this doesn't really handle cross-compilation... at all. If we're cross compiling, you have to set ARM_VERSION by hand. I think this is The Right Thing, because we should assume lowest common denominator for the arch unless the user tells us otherwise, but that means ARM_VERSION needs to be documented, and I don't know where that documentation should be.

My apologies if I've violated style or something, this is my first attempt at contributing.

[zturtleman]

I think it would simpler to change COMPILE_ARCH to not change armv7l to arm. Then it will automatically enable armv7l VM JIT if supported for current system and cross-compiling can use make ARCH=arm or make ARCH=armv7l (with other CC etc variables for arm compiler).

It seems like ideally the armv7l VM JIT would always be compiled and check if CPU supports armv7l instructions at run-time. So there is only a single executable to distribute and ARCH can always be "arm". Though I don't know enough about it to say if that's possible. (For example, the Raspberry Pi 1 is armv6 and Raspberry Pi 2 and 3 are armv7.)

[jjbarr]

That would cause problems with distributing ui/qagame/cgame SOs across ARM systems: armv7 would look for uiarmv7l.so, for example, while armv6 would look for uiarm.so. Furthermore, by my understanding, uname could report armv7x (where x is something other than 'l'), so we have to consider that too. Although I could be wrong. For that matter, we could have a uname of armv7hl, or something along those lines, (which means my code technically isn't correct, although it at the very least won't try and compile the VM JIT on a platform that doesn't support it).

TL;DR, given the binding of ARCH_STRING in q_platform is, at least on linux, presently tied to ARCH in our makefile, and ARCH also controls the names of the SOs of game code that we build, I consider having an arch other than bare arm for ARM infeasible.

But that's all just my opinion.

It seems like ideally the armv7l VM JIT would always be compiled and check if CPU supports armv7l instructions at run-time. So there is only a single executable to distribute and ARCH can always be "arm". Though I don't know enough about it to say if that's possible.

By the looks if it, it's certainly possible. The only problem is portability. Oh, and adding a big fat #ifdef arm (or your regional equivalent: probably actually setting arm bits in q_platform and checking those) right in the middle of VM_Create, which may offend taste, because... well, that's pretty gross, innit. I guess technically you don't have to, but then we'd be running arm code on every system, which is dumb.

If you've got a cleaner place to put the code, I'd love to hear it, because if I was actually confident it wouldn't offend the senses I wouldn't be above implementing this thing.

As for portability... every unix has a totally different way of actually getting uname -m (or as the case may have it, uname -p). Technically, we don't support any that aren't linux on ARM, but I'd say it's better to write the code to get the arch portably now rather regret forever after.

[ensiform]

Most don't distribute mods in bin form, because they aren't pure capable in q3. Only a few do (for sever?) But client and ui are usually qvm which only needs interpreter.

[jjbarr]

This is true! However, there is an exception: us. We ship our gamecode as native code.

Beyond that, even if most people don't ship native code, it's still a feature we advertise, and a feature we provide on every platform. Breaking native code modules (or more accurately, making them needlessly difficult to load) on one platform is at best a Bad Idea and at worst kind of insane.

[ensiform]

I'm not familiar with what mod you are part of.

[jjbarr]

Sorry. By "we" I meant ioquake3. Our nightlies and general builds contain native gamecode.

[ensiform]

They do, but they cannot be used on servers.

[jjbarr]

I still don't consider breaking nativecode loading (or at the very least, making the interface to absurdly obtuse) to be acceptable.

[ensiform]

Native code support is for development only, especially for the nonstandard formats. the original game didn't support arm, so unless there are now actual mods being used with the old style filename, it's not really an issue. You could support both if need be.

[zturtleman]

By the looks if it, it's certainly possible. The only problem is portability. Oh, and adding a big fat #ifdef arm (or your regional equivalent: probably actually setting arm bits in q_platform and checking those) right in the middle of VM_Create, which may offend taste, because... well, that's pretty gross, innit. I guess technically you don't have to, but then we'd be running arm code on every system, which is dumb.

I meant compiling vm_armv7l.c on all arm* architectures and make vm_armv7l.c's VM_Compile() check if it can be used. If it cannot, vm_armv7l.c's VM_Compile() should set vm->compiled = qfalse and return. This causes VM_Create() to fallback to byte code interpreter. No changes needed outside of vm_armv7l.c.

ioq3/code/qcommon/vm.c

Lines 654 to 672 in e5da13f

	vm->compiled = qfalse;
	#ifdef NO_VM_COMPILED
	if(interpret >= VMI_COMPILED) {
	Com_Printf("Architecture doesn't have a bytecode compiler, using interpreter\n");
	interpret = VMI_BYTECODE;
	}
	#else
	if(interpret != VMI_BYTECODE)
	{
	vm->compiled = qtrue;
	VM_Compile( vm, header );
	}
	#endif
	// VM_Compile may have reset vm->compiled if compilation failed
	if (!vm->compiled)
	{
	VM_PrepareInterpreter( vm, header );
	}

[jjbarr]

I meant compiling vm_armv7l.c on all arm* architectures and make vm_armv7l.c's VM_Compile() check if it can be used.

D'oh. I don't know how I missed that. Sorry.

I'd be willing to try my hand at implementing this, although I confess to being new to the codebase, so... yeah. I'll try not to mess things up.

the original game didn't support arm, so unless there are now actual mods being used with the old style filename, it's not really an issue. You could support both if need be.

The issue is that with the proposed change, there wouldn't be a new style: the filename required would actually change based on compilation conditions.

[jjbarr]

Alright, here's my attempt at adding a runtime check and doing the fix that way: jjbarr@501c9f6

I'm not sure if the code is up to standards, and I'd be happy to fix it if it isn't.

The bigger problem, however, is that I don't have an arm development environment at present. So I can't test this.

[jacobo-mc]

just use q3lite

[NuclearMonster]

just use q3lite

I understand it might be frustrating but please understand it isn't useful feedback for this project.

[jacobo-mc]

maybe you should integrate q3lite renderer and vm into mainline.

[zturtleman]

q3lite relicensed as GPLv3 with additional terms from Zenimax. As is, it cannot be merged into ioquake3, A polished OpenGL ES 1 renderer is sitting in #375 though.