A minimal elf header?

[Jamie]

I'm working on a compiler targeting the XS1 architecture and would like to be able to run my binaries through the simulator included in the tool set.

As far as I'm aware from looking at the documentation, on top of the program size and CRC required for booting, it needs a minimal ELF header but I'm not sure exactly what needs to be included in this.

Can anyone offer any help here?

Thanks,

Jamie

[Andy]

It seems to be a standard ELF header as described in 4-4 of this document: http://www.sco.com/developers/devspecs/gabi41.pdf

Hope that helps.

[richard]

I'm working on a compiler targeting the XS1 architecture

Interesting, can you give any more information about what you are working on? Is there any reason for producing a binary directly instead of assembly code which you can assemble/link with the existing XMOS toolchain? If you want to target multicore systems have you thought about how the XMOS links will be configured and how channel ends between cores will be setup?

Can anyone offer any help here?

When you build an executable using the XMOS tool chain it produces an executable in the XE file format. An XE file is a simple container that contains multiple ELF images (one for each core) together with information about the target device and how to load the images. The ELF images are standard ELF, see the document Andy referenced and the XMOS ABI.

Currently the XE file format is undocumented. This isn't out of some desire to keep it secret, just that documentation for tool writers hasn't been a priority and no one has asked for information on the executable format before.

You can use xobjdump to manipulate XE files. For example you can dump out the ELFs using xobjdump --split file.xe. You can replace files in an existing .xe using xobjdump --replace node,core,image.elf.

For the moment to run your output on the simulator I would suggest:

• Update your tool to spit out ELF images.
• Build a single core executable for your target using xcc consisting of

  Code: Select all

  int main() { return 0; }

• Use xobjdump --replace 0,0,image.elf to replace core 0
• Use xobjdump --add node,core,image.elf to add images for other cores.

[Jamie]

Interesting, can you give any more information about what you are working on?

Yes - I'm looking at language features supporting concurrency; in particular parallel recursive processes and run-time migration of computations between processors. Basically to allow simple expression of powerful concurrency structures. I have a document I wrote explaining this all in more detail which I can send you if you're interested.

Is there any reason for producing a binary directly instead of assembly code which you can assemble/link with the existing XMOS toolchain?

There were two reasons, first the extra assembler directives required seemed complicated and not too well documented, and up to this point I have been running my programs on a simple simulator which has avoided this. Although my compiler does output a .s assembly file so the directives still can be added in at any point to produce assembly code compatible with xas. Secondly though, by creating my own binary I have precise control of of the outputted instructions, which may not be the case with the XMOS tools, and which will be important with achieving an efficient implementation and hopefully obtaining some impressive results.

If you want to target multicore systems have you thought about how the XMOS links will be configured and how channel ends between cores will be setup?

This is definitely the aim, but currently I've not looked into this in much detail. I would hope to seek your advice here!

Thanks for your advice with getting a binary working with the simulator, this at least seems quite straight forward.

Cheers,

Jamie

[richard]

There were two reasons, first the extra assembler directives required seemed complicated and not too well documented, and up to this point I have been running my programs on a simple simulator which has avoided this.

Does the recently released Assembler Programming for the XMOS ABI document help?

If you want to target multicore systems have you thought about how the XMOS links will be configured and how channel ends between cores will be setup?

This is definitely the aim, but currently I've not looked into this in much detail. I would hope to seek your advice here!

Normally the connections between different nodes are described in the .xn file for the target. The mapper assigns IDs to nodes and directions to links. The mappers adds generated code which configures the node IDs and links. Link widths and speeds are taken from the .xn file. It also generates code which allocates channels ends for inter core channels and handshakes between cores to ensure all channels are established before main starts. If you bypass the mapper then you will need to implement at least some of this.

[Jamie]

Does the recently released Assembler Programming for the XMOS ABI document help?

Yes, I had noticed that had been published recently, but it seems to me it is most straight forward for what I'm doing to create my own binaries.

Normally the connections between different nodes are described in the .xn file for the target. The mapper assigns IDs to nodes and directions to links. The mappers adds generated code which configures the node IDs and links. Link widths and speeds are taken from the .xn file. It also generates code which allocates channels ends for inter core channels and handshakes between cores to ensure all channels are established before main starts. If you bypass the mapper then you will need to implement at least some of this.

Is it not possible for me to use the mapper to perform this initialisation from the XN file given a set of binaries for each core? Or does the mapper operate on the assembly file?

[richard]

We've just released documentation on The XE file format, see the Tools Developers Guide.

Is it not possible for me to use the mapper to perform this initialisation from the XN file given a set of binaries for each core? Or does the mapper operate on the assembly file?

Currently the initialisation code is generated at the same time as linking objects files to produce an executable. It is not possible to generate this code without also performing a link. The code for initialising the XMOS links is placed in a different image to the rest of the program so you may be able build a dummy program for the target once, extract the required code and then incorporate this into your executable.

[Jamie]

We've just released documentation on The XE file format, see the Tools Developers Guide.

Thanks for that, and after getting my head around ELF, things make better sense now!

Anyway, the way I have decided to do it is to create a dummy main mapping file, and link it with my main/initialisation function from the ELF file I produce from my compiler (with -nostartfiles):

Code: Select all

#include <platform.h>
extern _start();
int main(void) {
    par(int i=0; i<4; i++)
        on stdcore[i] : _start();
}

And

Code: Select all

    .globl _start, "f{}(0)"
    .cc_top _start.function,_start
    .align 2
_start:
...
    .cc_bottom _start.function

Which works well.