ASM Fundamentals for my project

[joandunning]

Hi, I only discovered XMOS an hour ago, looks interesting!

My application is currently running on pic/avr and written in assembly code.

I'd like to try xmos but firstly I have a few questions that let me know if I can continue:

1. My app requires 3 index registers for managing data access, how many does the xcom have? Could you outline the addressing types ? I use index register with an offset (always positive even though relative may be available, as long as it does the offset that's ok for me).

2. Does the command line assembler support macros?

[edit]
3. Also, I use my own bootloader and flash write routines, can the xmos write to its own program area?

Thanks

[trousers]

1. My app requires 3 index registers for managing data access, how many does the xcore have? Could you outline the addressing types ? I use index register with an offset (always positive even though relative may be available, as long as it does the offset that's ok for me).

There are 12 general purpose registers all of which can be used to access memory with offsets - either contant or another register. The instruction set and addressing modes are rich and mostly othogonal. I suggest you download "The XMOS XS1 Architecture" manual from here: http://www.xmos.com/support/documentation (top link). The last section "Instruction Details" is probably the most lucid explanation, along with teh "XS1 Assembly Language Manual" from the same page.

2. Does the command line assembler support macros?

Not natively but the tools front end will pass assembler through cpp on request which gets you simple macro facilities.

3. Also, I use my own bootloader and flash write routines, can the xmos write to its own program area?

Yes.

[joandunning]

Thanks for that, the lack of macro support in the command line assembler could be a problem for me, all my development is done with macros, I guess I will need to try it out.. It's good to hear the other 2 points are covered.

[leon_heller]

Complex macros could be implemented in m4, which is a very powerful macro-processor.

Leon

[joandunning]

Thanks, hadn't heard of m4, before.. will try it out..

[DrFingersSchaefer]

I can certainly confirm leon's suggestion of using m4. I have been messing with it this afternoon to pre-process assembler and it looks to work fine so far.

I create my assembler and macro code in files with one extension and then process them into a single assembler only file with all the macro's processed/expanded ready to feed to the assembler.

Just need to get the XDE assembling now and we are away. Although it looks like it should if I fed it properly.

[TonyD]

for anyone interested in m4 you can find it at www.gnu.org/software/m4/

[DrFingersSchaefer]

Good tip for most of the documentation produced for the Gnu stuff. It's worth having as a reference but terrible to teach yourself from.

I think the folk who write it are a touch overly academically inclined. Clever, but sometimes too much.

I tend to get their PDF docs and dip in on a needs basis, Google is the best port of call as the internet is full of folk who have probably already done what you want to do and documented the bit that they did.

[shawn]

M4 that's interesting... <<<grinning>>>
Becarefull in all the absraction it's addicting.
Absractions even well implemented have tax.
Pourly implemented and there's penalties.
Then there's no ESC, only death.

Death abstracts me,
Shawn

[Heater]

I think if you are creating a lot of assembler using a lot of complex macros you may as well bite the bullet and write your code in C or XC. With a sprinkling of assembler where it is really needed.

Given that your existing app is for PIC/AVR the XMOS will have plenty of performance spare for you to work in C. Compilers are pretty damn efficient at code generating anyway.