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
ASM Fundamentals for my project
-
- New User
- Posts: 3
- Joined: Fri Jan 08, 2010 9:46 am
-
- Active Member
- Posts: 44
- Joined: Fri Dec 11, 2009 10:20 am
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.joandunning wrote: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).
Not natively but the tools front end will pass assembler through cpp on request which gets you simple macro facilities.joandunning wrote:2. Does the command line assembler support macros?
Yes.joandunning wrote:3. Also, I use my own bootloader and flash write routines, can the xmos write to its own program area?
Last edited by trousers on Fri Jan 08, 2010 1:05 pm, edited 1 time in total.
Best friends with the code fairy.
-
- New User
- Posts: 3
- Joined: Fri Jan 08, 2010 9:46 am
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.
-
- XCore Expert
- Posts: 546
- Joined: Thu Dec 10, 2009 10:41 pm
- Location: St. Leonards-on-Sea, E. Sussex, UK.
Complex macros could be implemented in m4, which is a very powerful macro-processor.
Leon
Leon
-
- New User
- Posts: 3
- Joined: Fri Jan 08, 2010 9:46 am
Thanks, hadn't heard of m4, before.. will try it out..
-
- Experienced Member
- Posts: 65
- Joined: Fri Dec 18, 2009 1:27 pm
- Location: The Interzone
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.
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.
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
-
- XCore Addict
- Posts: 234
- Joined: Thu Dec 10, 2009 11:11 pm
- Location: Newcastle, UK
for anyone interested in m4 you can find it at www.gnu.org/software/m4/
-
- Experienced Member
- Posts: 65
- Joined: Fri Dec 18, 2009 1:27 pm
- Location: The Interzone
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.
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.
"Dr Fingers Schaefer, The Lobotomy Kid"
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
Caesar ad sum iam forti
Brutus ad erat
Caesar sic in omnibus
Brutus sic in at
:ugeek:
-
- XCore Addict
- Posts: 238
- Joined: Thu Dec 17, 2009 5:15 am
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
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
-
- Respected Member
- Posts: 296
- Joined: Thu Dec 10, 2009 10:33 pm
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.
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.