Hi Jason, Jim, Rafael, We had plans to work on ARM MC (asm and elf), good to see there is an interest, and we'd be glad to help. The ARM part of MC is almost empty, so there's a lot of work in there, probably even before writing the assembly/ELF writers. Also, AFAIK, there is no ELF writer for MC, so wouldn't be good to write one specific for the ARM platform, but keep things generic as much as possible. As I got it, MC is generic and the file writers only get the instructions and sections and "print" them to file. Does it mean MC already have all the section, relocation, attributes, properties that both ASM and ELF have? If that's so, even though they're separate projects (as Jason pointed out), a higher degree of communication will be required to synchronize the MC part. Also, we want to make sure that the generated ASM/ELF is not only GNU compatible, but ARM ABI too (if the user require, in the target triple). We have done some changes to the ISelLowering to conform to EABI, a patch is on its way. Is it correct to assume that, if the user chooses a triple with "eabi-none", we can generate ARM EABI (including RT-ABI intrinsics) code?> 1. MC-ized Assembly PrinterWould be good to make it generic enough, so we could (hypothetically) add ARM assembly as a choice. But that could come as a great weight in the first draft, so I won't be so sad if we can't get it straight away. ;) Irrespective of the asm syntax, we need better support for build attributes, relocation information, stack unwinding, exception tables, etc. That alone should prove a good challenge. In the meantime, we have worked on support for some of these things (build attr, reloc.) for the old writer. I'm preparing some of them as patches and will send soon.> 2. Object File EmissionThat will also need support for features mentioned above, and also in the disassembler. GCC ignores most of the build attributes and "guess" everything else from cpu, fpu and the instructions used. This is far from ideal and we shouldn't follow the same route. If we need to guess anything, lets do it in MC, so when you print assembly, the user can later edit if they so want to (or pass the correct cmd-line options to create them right in the first place). The disassembler should also understand that and *always* give preference to user attributes. Because ASM and ELF writers will use MC, we need explicit relocation information in MC, so the writer can print it correctly to the file. I saw that the Dwarf printer has this working, but the old ARM AsmWriter doesn't (I sent a patch for this a while ago). Maybe we can join them all in MC this time.> 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one.We're not overly concerned about JIT at the moment, but it's good to keep in mind that we also have that route. I would as far as to suggest to create a third data section in the IR, after "target-data-layout" and "target-triple", maybe called "target-info" or "target-options". It could be a target dependent string, but would be best if it was shared among architectures, so you could run IR generated to ARM in an 32bit x86, for instance. We could also pass target specific features (such as build attributes), how to handle unions and ByVal parameters, and maybe some optimization assumptions when generating IR. That would allow the codegen phase to detect not only what was generated, but why, and make the appropriate changes if the execution target does not conform to the intended target's specifications. That is very liberating for JIT environments, but I do realise this is extremely complex. I'd be happy to have just the build attributes on it for now, though. ;) cheers, --renato
> The ARM part of MC is almost empty, so there's a lot of work in there, > probably even before writing the assembly/ELF writers. Also, AFAIK, > there is no ELF writer for MC, so wouldn't be good to write one > specific for the ARM platform, but keep things generic as much as > possible.There is one for x86/x86-64 on the works. It has some limitations, but can produce working binaries for small programs like screen.> As I got it, MC is generic and the file writers only get the > instructions and sections and "print" them to file. Does it mean MC > already have all the section, relocation, attributes, properties that > both ASM and ELF have? If that's so, even though they're separate > projects (as Jason pointed out), a higher degree of communication will > be required to synchronize the MC part.I am just starting with MC, but as I understand it, the interface to the streamer is basically one call per assembly directive. Things like relocation have to be recorded by the streamer implementation. The ELF one has to be extended to create the ARM specific relocations.> Also, we want to make sure that the generated ASM/ELF is not only GNU > compatible, but ARM ABI too (if the user require, in the target > triple). We have done some changes to the ISelLowering to conform to > EABI, a patch is on its way. Is it correct to assume that, if the user > chooses a triple with "eabi-none", we can generate ARM EABI (including > RT-ABI intrinsics) code?That is almost all decided before getting to the MC streamer I think. So there might be some work for supporting other ABIs, but I suspect most of it would be in the IL to DAG conversion.> >> 1. MC-ized Assembly Printer > > Would be good to make it generic enough, so we could (hypothetically) > add ARM assembly as a choice. But that could come as a great weight in > the first draft, so I won't be so sad if we can't get it straight > away. ;) > > Irrespective of the asm syntax, we need better support for build > attributes, relocation information, stack unwinding, exception tables, > etc. That alone should prove a good challenge.Tables in general are produced one level before MC I think.> In the meantime, we have worked on support for some of these things > (build attr, reloc.) for the old writer. I'm preparing some of them as > patches and will send soon. > > >> 2. Object File Emission > > That will also need support for features mentioned above, and also in > the disassembler. > > GCC ignores most of the build attributes and "guess" everything else > from cpu, fpu and the instructions used. This is far from ideal and we > shouldn't follow the same route. If we need to guess anything, lets do > it in MC, so when you print assembly, the user can later edit if they > so want to (or pass the correct cmd-line options to create them right > in the first place). The disassembler should also understand that and > *always* give preference to user attributes. > > Because ASM and ELF writers will use MC, we need explicit relocation > information in MC, so the writer can print it correctly to the file. I > saw that the Dwarf printer has this working, but the old ARM AsmWriter > doesn't (I sent a patch for this a while ago). Maybe we can join them > all in MC this time. > > >> 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one. > > We're not overly concerned about JIT at the moment, but it's good to > keep in mind that we also have that route. > > I would as far as to suggest to create a third data section in the IR, > after "target-data-layout" and "target-triple", maybe called > "target-info" or "target-options". It could be a target dependent > string, but would be best if it was shared among architectures, so you > could run IR generated to ARM in an 32bit x86, for instance. > > We could also pass target specific features (such as build > attributes), how to handle unions and ByVal parameters, and maybe some > optimization assumptions when generating IR. > > That would allow the codegen phase to detect not only what was > generated, but why, and make the appropriate changes if the execution > target does not conform to the intended target's specifications. That > is very liberating for JIT environments, but I do realise this is > extremely complex. > > I'd be happy to have just the build attributes on it for now, though. ;)Can you give an example of what attributes you have in mind?> cheers, > --renatoCheers, -- Rafael Ávila de Espíndola
On Wed, Sep 15, 2010 at 2:27 AM, Renato Golin <renato.golin at arm.com> wrote:> Hi Jason, Jim, Rafael, > > We had plans to work on ARM MC (asm and elf), good to see there is an > interest, and we'd be glad to help. > > The ARM part of MC is almost empty, so there's a lot of work in there, > probably even before writing the assembly/ELF writers. Also, AFAIK, > there is no ELF writer for MC, so wouldn't be good to write one > specific for the ARM platform, but keep things generic as much as > possible.Yeah, not to mention, the Apple folks are probably not interested much on ELF as mach.o, so there's probably even more genericity to be considered.> As I got it, MC is generic and the file writers only get the > instructions and sections and "print" them to file. Does it mean MC > already have all the section, relocation, attributes, properties that > both ASM and ELF have? If that's so, even though they're separate > projects (as Jason pointed out), a higher degree of communication will > be required to synchronize the MC part. > > Also, we want to make sure that the generated ASM/ELF is not only GNU > compatible, but ARM ABI too (if the user require, in the target > triple). We have done some changes to the ISelLowering to conform to > EABI, a patch is on its way. Is it correct to assume that, if the user > chooses a triple with "eabi-none", we can generate ARM EABI (including > RT-ABI intrinsics) code? > > >> 1. MC-ized Assembly Printer > > Would be good to make it generic enough, so we could (hypothetically) > add ARM assembly as a choice. But that could come as a great weight in > the first draft, so I won't be so sad if we can't get it straight > away. ;) > > Irrespective of the asm syntax, we need better support for build > attributes, relocation information, stack unwinding, exception tables, > etc. That alone should prove a good challenge. > > In the meantime, we have worked on support for some of these things > (build attr, reloc.) for the old writer. I'm preparing some of them as > patches and will send soon. > > >> 2. Object File Emission > > That will also need support for features mentioned above, and also in > the disassembler. > > GCC ignores most of the build attributes and "guess" everything else > from cpu, fpu and the instructions used. This is far from ideal and we > shouldn't follow the same route. If we need to guess anything, lets do > it in MC, so when you print assembly, the user can later edit if they > so want to (or pass the correct cmd-line options to create them right > in the first place). The disassembler should also understand that and > *always* give preference to user attributes. > > Because ASM and ELF writers will use MC, we need explicit relocation > information in MC, so the writer can print it correctly to the file. I > saw that the Dwarf printer has this working, but the old ARM AsmWriter > doesn't (I sent a patch for this a while ago). Maybe we can join them > all in MC this time. > > >> 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one. > > We're not overly concerned about JIT at the moment, but it's good to > keep in mind that we also have that route. > > I would as far as to suggest to create a third data section in the IR, > after "target-data-layout" and "target-triple", maybe called > "target-info" or "target-options". It could be a target dependent > string, but would be best if it was shared among architectures, so you > could run IR generated to ARM in an 32bit x86, for instance. > > We could also pass target specific features (such as build > attributes), how to handle unions and ByVal parameters, and maybe some > optimization assumptions when generating IR. > > That would allow the codegen phase to detect not only what was > generated, but why, and make the appropriate changes if the execution > target does not conform to the intended target's specifications. That > is very liberating for JIT environments, but I do realise this is > extremely complex. > > I'd be happy to have just the build attributes on it for now, though. ;) > > cheers, > --renato >
On 15 September 2010 15:52, Rafael Espindola <espindola at google.com> wrote:> There is one for x86/x86-64 on the works. It has some limitations, but can > produce working binaries for small programs like screen.Hi Rafael, This is good, at least we don't start from scratch and we can cooperate with the other team to make sure the generic ELF infrastructure remains generic.> I am just starting with MC, but as I understand it, the interface to the > streamer is basically one call per assembly directive. Things like > relocation have to be recorded by the streamer implementation. The > ELF one has to be extended to create the ARM specific relocations.My previous relocation patch decides which relocation to use based on the section and expression type, but that might not be the best way to go for it. I think we should try to get it *before* ELF or ASM, so we only implement that once. If we have to extend some generic relocation mechanism, even better, but that has to be generic in the MC level, not ASM/ELF streamers, IMHO.> Can you give an example of what attributes you have in mind?The EABI attributes that define the compilation options / platform definitions, to propagate them to assembler and linker in case you use multiple steps to compile. Normally, just by choosing Cortex-A8, you can assume NEON exists, but not all A8 have NEON and you can end up wrongly generating vector instructions to a platform that doesn't support it. The "solution" is to compile all at one step, but that's also far from ideal. In effect, only having "armv7a-eabi-none" as a triple is very limiting in ARM world. And since our designs can be extended in an very large number of combinations, adding it to the triple is not the way to go... The attributes can be generically used by other platforms, that, once it's required, it can help on generating correct code (sometimes better code), like in the case of unions discussed earlier. If front-ends ignore it, they can still generate code and rely on the back-end knowing what they meant, but front-ends that want to communicate to back-ends via IR/ASM/ELF can do so, especially for JIT and multi-step compilations. CodeSourcery's GCC already generates and understands that (to a point), so there is no compatibility issues. -- cheers, --renato