Starting with Assembler

[Jamie]

Assuming you want nothing but your own code in the binary, you need to do something like:
Code:
xmap g4th.o --nochaninit --bootable -target=XK-1 -o g4th.xb

Note than an XB is not a binary image - it's the same as an XE but with binary data inside instead of elves - i.e. it's much like a stripped executable. AFAIK there's no advantage to XB and XE.

How come --nochaninit is not listed in the mapper --help options (possibly since a recent tools release)?

And is there any xmap documentation at all?

Jamie

[m_y]

How come --nochaninit is not listed in the mapper --help options (possibly since a recent tools release)?

It's not a supported option and almost certainly not useful in this case.

For a single core program invoking the front end with -nostdlib is sufficient for the resultant program to contain nothing but user code. For multicore programs the code automatically inserted by the mapper is necessary for correct operation. Thus using --nochaninit will be either a no-op, or cause your app not to work.

And is there any xmap documentation at all?

The mapper is covered in the tools user guide http://www.xmos.com/system/files/toolsuser_10v4.pdf in chapter 11, as part of the compiler collection.

[Jamie]

For a single core program invoking the front end with -nostdlib is sufficient for the resultant program to contain nothing but user code. For multicore programs the code automatically inserted by the mapper is necessary for correct operation. Thus using --nochaninit will be either a no-op, or cause your app not to work.

But that is assuming you're not setting up channels yourself, in which case it would be useful.

The mapper is covered in the tools user guide http://www.xmos.com/system/files/toolsuser_10v4.pdf in chapter 11, as part of the compiler collection.

Right, okay but still pretty brief and no mention of the kind of initialisation code it inserts.

[m_y]

For a single core program invoking the front end with -nostdlib is sufficient for the resultant program to contain nothing but user code. For multicore programs the code automatically inserted by the mapper is necessary for correct operation. Thus using --nochaninit will be either a no-op, or cause your app not to work.

But that is assuming you're not setting up channels yourself, in which case it would be useful.

Yes and no. For a single core program there is no mapper generated code so you're free to write a main which allocates channel ends itself. Using --nochaninit has no effect here.

In a multicore situation --nochaninit precludes the use of a multi-core top-level main (i.e. one with "on"s). Thus you'd need some other means of specifying what codes goes on which core. This is non-trivial. If I was doing that I'd generate a series of single-core XEs, and use xobjdump to combine them into a single executable.

For example:

Program for core 0 (file1.s):

Code: Select all

  .globl main
  .globl _start
  .text
  .align 2
main:
_start:
  ldc   r0, 1
stophere:
  bu  stophere

Program for core 1 (file2.s):

Code: Select all

  .globl main
  .globl _start
  .text
  .align 2
main:
_start:
  ldc   r0, 2
stophere:
  bu  stophere

Program for core 2 (file3.s):

Code: Select all

  .globl main
  .globl _start
  .text
  .align 2
main:
_start:
  ldc   r0, 3
stophere:
  bu  stophere

Program for core 3 (file4.s):

Code: Select all

  .globl main
  .globl _start
  .text
  .align 2
main:
_start:
  ldc   r0, 4
stophere:
  bu  stophere

Compile with

Code: Select all

xcc file1.s -target=XDK -nostdlib -o prog1.xe
xcc file2.s -target=XDK -nostdlib -o prog2.xe
xcc file3.s -target=XDK -nostdlib -o prog3.xe
xcc file4.s -target=XDK -nostdlib -o prog4.xe

Join them together with:

Code: Select all

xobjdump --split prog2.xe
xobjdump prog1.xe -a 0,1,image_n0c0.elf
xobjdump --split prog3.xe
xobjdump prog1.xe -a 0,2,image_n0c0.elf
xobjdump --split prog4.xe
xobjdump prog1.xe -a 0,3,image_n0c0.elf

You can then run prog1.xe on an XDK and observe that each core gets an entirely independent program which consists of nothing but user code.

The mapper is covered in the tools user guide http://www.xmos.com/system/files/toolsuser_10v4.pdf in chapter 11, as part of the compiler collection.

Right, okay but still pretty brief and no mention of the kind of initialisation code it inserts.

Yes, that's right; this is not documented and I'm not aware of any plan so to do.

[Jamie]

If I was doing that I'd generate a series of single-core XEs, and use xobjdump to combine them into a single executable.

But I this wouldn't work for systems that require link initialisation, such as the XMP-64.

In a multicore situation --nochaninit precludes the use of a multi-core top-level main (i.e. one with "on"s).

I would have assumed that --nochaninit would have disabled the inclusion of code to initialise channels, that is to setup the destination registers of each pair of channel ends. Does it preclude the use of a main multi-core 'mapping' function because the booting procedure requires initialised channel connections to each core?

[m_y]

I would have assumed that --nochaninit would have disabled the inclusion of code to initialise channels, that is to setup the destination registers of each pair of channel ends. Does it preclude the use of a main multi-core 'mapping' function because the booting procedure requires initialised channel connections to each core?

--nochaninit is a slight misnomer. It inhibits almost all the mapper generated startup code - that includes xmoslink initialisation, channel allocation, synchronisation, and closedown.

I feel I should repeat here that --nochaninit is not a supported option and is not guaranteed to do anything in particular at all. I cannot recommend using it, even unofficially.

If what you want is a multi-core program that doesn't set up any channels then simply declare all you top-level functions to take no parameters. Channel end zero on each core will be allocated but other than that you then have a free rein.

[Jamie]

Okay, thanks for explaining that -- I was just curious about the kind of control you get over the added initialisation code (and what exactly it does), and if there were any other possibly useful hidden options!

It would be useful to know more about the specification of the XC/XCC runtime (apart from studying the disassembly) ...I don't know if there is any plan to document this?

[m_y]

It would be useful to know more about the specification of the XC/XCC runtime (apart from studying the disassembly) ...I don't know if there is any plan to document this?

AFAIK there're no plans to do this.