On Sep 29, 2008, at 9:41 PM, Gavin Barraclough wrote:
I can imagine that we'll face a range of issues from the very micro- architectural (e.g. dependencies on flag state between operations, code scheduling differences due to limited register availability, and 'quirks' in the requirements of particular operations on given architectures – e.g. specific register requirements) – to much more macro issues based on higher-level design decisions we take on different platforms (e.g. we may want to make use of differing internal implementations of JSImmediate on different platforms). More immediately there will be a decision of where the differences in ABI in function call setup are captured, and in the longer run we'll also have to decide where we want register allocation to live.
The best place to capture some of these differences may be in the Masm, may be in the code generator, or may be in a additional delegation layer between the two. As an ideal I would like to keep all knowledge of JSC concepts of such as JSImmediate and JSCell out of the Masm, so that it can provide an entirely abstract interface (potentially applicable to any code generation task). I'd also like to try to keep artifacts specific to the current code generation strategy (e.g. slow-cases) back out in the code generator rather than in the Masm, so the Masm is immediately reusable if we want to explore different code generation strategies (as one example, in case we wanted to explore something more akin to trace trees). In practice we may find it necessary to blur these lines.
In general that sounds reasonable, but I wonder how much of this we could achieve through platform-specific methods on NativeCodeGenerator, while the core of it remains cross-platform. I can imagine we will want some platform-specific operations that are too high-level for the macro assembler as you describe it. For example, "get StructureID given a JSCell*" or even "test whether a given JSCell has a particular TypeInfo flag set". Are there going to be a lot of useful chunks that are below this level but above the level of concrete assembly instruction? My personal bias would be against too many layers, but perhaps this way will make sense.
My plan of action is to start abstracting out the assembler and ABI as one unit of work, with a goal that we will then be able to bring up support for a second native platform with a reasonably contained set of changes (implementing the Assembler, the Masm, and then hopefully this leave a much reduced set of changes to the code generation).
As a general plan that totally makes sense. Regards, Maciej