476006 - clean up CPU flags and use VMCFG prefix

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Edwin Smith]

we internally detect the compile cpu target in avmbuild.h.  Lets standardize the flag names we use in code.

strawman:

new flag      replaces
--------      --------
VMCFG_64BIT   MMGC_64BIT, AVMPLUS_64BIT, NANOJIT_64BIT
VMCFG_X86     MMGC_IA32,  AVMPLUS_IA32,  NANOJIT_IA32 
VMCFG_PPC     MMGC_PPC,   AVMPLUS_PPC,   NANOJIT_PPC
VMCFG_ARM     MMGC_ARM,   AVMPLUS_ARM,   NANOJIT_ARM
VMCFG_SPARC   MMGC_SPARC, AVMPLUS_SPARC

64BIT is meant to be orthagonal to the cpu family flag.  This is currently true for PPC (there is no PPC64 flag, we use PPC & 64BIT for PPC-64 specific stuff and PPC & !64BIT for PPC-32 specific stuff.  AMD64 flies in the face of this, so lets drop it and use (X86 & 64BIT) instead.

with a cpu family, other flags can be defined.

VMCFG_SSE2  replaces *_SSE2
VMCFG_THUMB replace *_THUMB, etc.

Comment 1

[Steven Johnson]

+1

Comment 2

[Lars T Hansen]

I'm for it.  Please let's make it clear (if and when we can) that these names are not exposed outward from the module; that probably argues for splitting avmplus.h into avmplus.h and avmplus_internal.h in the nearish future, if we can.  (I'm not sure we can but I can hope.)

Comment 3

[Rick Reitmaier]

I'm sure you will, but I'll mention it anyway...please include comments detailing the usage and come to think of it, it would also be good to include your description of the change form above.

I wonder also (just throwing it out there), should we consider using 2 sets of defs; one for for the architecture we are compiling on and the other for the target of the nanojit emitter.  One can easily imagine someone using NJ to cross-compile at some point.

So nanojit would introduce defs of form NANOJIT_EMITS_xxx or something similar.  Although if we aren't testing the various combinations then it might be dangerous to introduce this concept; others might assume its working.

Comment 4

[Edwin Smith]

> comments

will do

> cross-compiling

lets cross that bridge when we come to it! (pun intended)

Comment 5

[Lars T Hansen]

Though this is targeted for "Future" we should do it opportunistically; no central synchronization is needed at this point - the VMCFG_ flags should be in place, or can be added as needed without any synchronization.