You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Historically, the Testarossa compiler technology from which the Eclipse OMR derived did support cross compilation between different 32-bit architectures (e.g., a compiler running on a Windows IA32 host generating code for 32-bit Power). This code was never properly maintained as 64-bit architectures appeared and became prevalent, and as the need for cross compilation diminished.
There is, however, a renewed requirement for this as generic compilation moves into cloud environments.
This issue is not about creating a cross compilation story for the OMR compiler technology. That will come. Rather, it is about ensuring that the code has the infrastructural support in place to be able to provide that capability. For example, understanding the difference between a pointer size on the host machine and the pointer size on the target machine, and ensuring that internal types and arithmetic respect that difference.
clarify and document the semantics of HOST and TARGET macros required to unavoidably guard code with different semantics on the host and target
ensure existing HOST and TARGET macros as defined in compiler/env/defines.h are applied consistently throughout the code base. This is not about ensuring they are used in the correct contexts, but about that the macros as defined in that file are used consistently (there will be more on this in the issue created for this)
ensure HOST and TARGET macros are used in semantically the correct places. An unscientific sampling of macro usage in the code base while it was part of J9 a couple of years back seems to suggest that around 40% may be incorrect. This will not be a small task.
devise a test for aiding discovery of incorrect uses of HOST and TARGET macros
clarify and document the semantics of host and target address types used in the compiler technology and the scenarios in which they apply.
consider renaming [u]intptrj_t (representing an address in the target environment) to something more generic for OMR.
use host and target address types correctly in the right contexts throughout the code base. This will not be a small task.
Historically, the Testarossa compiler technology from which the Eclipse OMR derived did support cross compilation between different 32-bit architectures (e.g., a compiler running on a Windows IA32 host generating code for 32-bit Power). This code was never properly maintained as 64-bit architectures appeared and became prevalent, and as the need for cross compilation diminished.
There is, however, a renewed requirement for this as generic compilation moves into cloud environments.
This issue is not about creating a cross compilation story for the OMR compiler technology. That will come. Rather, it is about ensuring that the code has the infrastructural support in place to be able to provide that capability. For example, understanding the difference between a pointer size on the host machine and the pointer size on the target machine, and ensuring that internal types and arithmetic respect that difference.
HOST
andTARGET
macros required to unavoidably guard code with different semantics on the host and targetHOST
andTARGET
macros as defined incompiler/env/defines.h
are applied consistently throughout the code base. This is not about ensuring they are used in the correct contexts, but about that the macros as defined in that file are used consistently (there will be more on this in the issue created for this)HOST
andTARGET
macros are used in semantically the correct places. An unscientific sampling of macro usage in the code base while it was part of J9 a couple of years back seems to suggest that around 40% may be incorrect. This will not be a small task.HOST
andTARGET
macros[u]intptrj_t
(representing an address in the target environment) to something more generic for OMR.CodeCache
address type (Standardize a CodeCache address type #1689)The text was updated successfully, but these errors were encountered: