Problem in converting the ARM code into THUMB

 Problem in converting the ARM code into THUMB

Hi,
Good Day.

I am working on ARM7TDMI core processor from Analog Devices family (ADuC703x). I developed a preemptive scheduler on the same in ARM environment. The functionality of the same is fine and its working well. For the purpose of optimization, i migrated into thumb mode using Keil RV compiler option (by changing the code generation option to THUMB mode and the optimization level option to 3 in C/C++ tab of the target settings option).

After changing the settings my code size is reduced by 2 KB. But, the complete functionality of the software got changed.

Can anybody help me out to get out of this problem?
Also, I would like to know why this kind of behavior is occurring... Please let me know your valuable suggesions.

Thanking you in anticipation,
Ravi Kumar Desaraju.

 RE: Problem in converting the ARM code into THUMB

If I am not mistaken, a CPU scheduler must contain some code in assembly language to save/restore registers, manipulate the stack pointer and so on. Because of this, I don't think that switching to THUMB can be achieved by simply changing compiler options.
Without seeing the code, I don't think much more can be said.

Regards,
- mike

 RE: Problem in converting the ARM code into THUMB

Hi Mike,
Thanks for your response.

I understand your point. But, I enabled the option "ARM to THUMB interworking" option in the C/C++ and ASM tabs from the target settings menu. I think, the compiler will automatically generate the corresponding code in generating the object.

Well, as you said, I am using many instructions in the assembly code like... MSR, MRS, PUSH and POP. As I conveyed in my previous message, I developed this code in ARM. ARM architecture doesn't support PUSH and POP instructions. By using the above mentioned option in the compiler (i.e. ARM/THUMB interworking), I observed the code in disassembly window and found that the compiler is internally changing the same. So, I did not modify my assembly code. Also, can you please suggest me any important areas in which I have to concentrate?

Thanks and Regards,
Ravi Kumar Deasaraju.

 why are you doing this?

Desaraju,
Are you trying to increase code density? please not that if you are using a 32 bit data bus, you actually decreased your system performance. Note that not all processor registers are as easily accessable when in thumb mode: R8-R12 are only modifiable via MOV, ADD and CMP. Have you remembered to manually change to thumb mode before your context switch is taking place (can be done by a branch)? Also notice that the multiple-register load-store instructions only support the increment after (IA) addressing mode.
Pay attention to the following table, which represents offsets available from a base pointer per instruction when in thumb mode:

LDRB, LDRSB, STRB       0 to 31 bytes
LDRH, LDRSH, STRH       0 to 62 bytes
LDR, STR                0 to 124 bytes

I am busy with a similar project, never tried it with thumb but I don't see how such a relatively small piece of assembly can win you that much performance when compiled in thumb.

 RE: why are you doing this?

Hi Michel,

Thanks for your response.

Actually, my code is into 2 parts. The scheduling algorithms and task creation part is implemented in C and ISR, Context switching and Wait state machine are developed in assembly. The C code is consumed huge memory in ARM mode (around 3.5KB) and 1.3 KB is assembly (with ARM mode and optimization level as 0).

for the above mentioned figures (ROM), I opted for THUMB mode and observed huge optimization result.

Any ways, the functionality got affected. But, If we use "ARM/THUMB interworking" option from the C/C++ and ASM tab from the target options, I think we can work with any instruction set (ARM/THUMB) since the compiler is taking care about the conversion of instruction from one mode to another mode (ARM to THUMB or THUM to ARM).

Please give me your valuable suggestions if any?

Thanks and Regards,
Ravi Kumar Desaraju.

 RE: why are you doing this?

can you explain what you mean by "the functionality got affected"? does you context switch no longer work?
checking ARM/Thumb interworking will generate assembly code that can either be executed in ARM or in thumb. It has no effect, as far as I know, on pure assembly code.
So if your context switch does not work, you better carefully check whether your assembly code complies with all thumb rules.

 RE: why are you doing this?

Hi,

Yes.... the problem is with context switching only. I am using few 32-bit move instructions in context switching does it affects any functionality in THUMB mode?

 RE: Problem in converting the ARM code into THUMB

I'm not sure how intelligent the 'ARM/THUMB interworking' facility is. Hopefully, it detects all function calls and converts them appropriately.
I would check the ISR, though. I don't know how interrupts are handled in ADuC703x, but in the MCU I'm dealing with the interrupt handling code enters the ISR in ARM mode.

- mike

 RE: Problem in converting the ARM code into THUMB

Hi Mike,

Yes, you are right. The same thing is happening with ADuC703x. think its the architecture of ARM7TDMI. I read sme where in the ARM core architecture document saying that, the first instruction of your exception handling (FIQ/IRQ/DATA ABORT/PABORT/SWI) should be written with ARM instruction. The ISR exit will automatically switching the ARM mode into THUM mode in my case. The problem is, in context switching code (independent to ISR), I am invoking the THUMB mode using branch instruction which is not happening properly. The other point is, with in ISR and context switching code I am using few 32-bit move instructions for condition checking. Is there any impact for the same, while working on THUMB architecture (THUMB mode doesn't have any 32-bit move instructions)?

 RE: Problem in converting the ARM code into THUMB

The problem is, in context switching code (independent to ISR), I am invoking the THUMB mode using branch instruction which is not happening properly.

More details would help, preferably the code.

The other point is, with in ISR and context switching code I am using few 32-bit move instructions for condition checking. Is there any impact for the same, while working on THUMB architecture (THUMB mode doesn't have any 32-bit move instructions)?

Not sure what you mean. Are you saying you are trying to execute ARM instructions in THUMB mode? If so, of course it won't work.

 RE: Problem in converting the ARM code into THUMB

Make sure your branch instruction is the BX (branch and exchange) allowing branching to ARM or Thumb code.

 RE: Problem in converting the ARM code into THUMB

Hi,

I am executing the "BX LR" instruction with least significant bit of the LR register as 1. Also, I observed the state of T bit in CPSR register after executing the above mentioned instruction. Its switching from ARM mode to THUMB mode.

 RE: Problem in converting the ARM code into THUMB

Hi,

Well, the Keil Real view compiler has an option to interwork with both ARM and THUMB mode. It will convert the code into the corresponding architecture.

 RE: Problem in converting the ARM code into THUMB

Hi All,

Is there any impact of running the scheduler in FIQ mode?

What is the difference between executing the code in user mode and FIQ mode?

I am running the scheduler in FIQ mode only. The reason for the same is as follows:

The stack for the FIQ interrupt is defined seperately. Hence, in the occurrence of FIQ interrupt, the ISR is referring the stack defined for FIQ instead of currently executing stack. Therefore, I am running the scheduler in FIQ mode only be y executing "BX LR" instruction in the ISR instead of SUBS PC, LR, #4. By executing the scheduler in FIQ mode, I am able to get the current executing stack reference in FIQ mode and my task switching is happening as expected in ARM mode. When I use the same code for THUMB mode it is not working. Is there any difference in executing the code in FIQ mode and user mode?

 RE: Problem in converting the ARM code into THUMB

A major difference is that FIQ is a privileged mode and user mode is not, which affects access to CPSR (user mode can only read it). Why do you plan to execute your scheduling code in user mode? You can of course adjust CPSR while in FIQ mode (as you can from every privileged mode), but why would you? also note that CPSR is not saved automatically if you do that to switch to another privileged mode.

Note:
------
"There are several ways to enter or leave the Thumb state properly. The usual method is via the Branch and Exchange (BX) instruction. See also Branch, Link, and Exchange (BLX) if you're using an ARM with version 5 architecture. During the branch, the CPU examines the least significant bit (LSb) of the destination address to determine the new state. Since all ARM instructions will align themselves on either a 32- or 16-bit boundary, the LSB of the address is not used in the branch directly. However, if the LSB is 1 when branching from ARM state, the processor switches to Thumb state before it begins executing from the new address; if 0 when branching from Thumb state, back to ARM state it goes."

 RE: Problem in converting the ARM code into THUMB

Hi Michel,

Thanks for your response.

You mean to say, scheduler should be running in privileged mode (FIQ) and the tasks should run in User mode right?

Is there any way to switch the modes dynamically....? (i mean can we change the mode setting bits of the CPSR)

 RE: Problem in converting the ARM code into THUMB

Why not run your scheduler in IRQ mode? You only have one FIQ source - are you sure you want to spend it on your scheduler? Basically, your tasks should not run in privileged mode - executing

SUBS       PC, LR, #4

from IRQ mode should bring you to the right task assuming your LR is restored correctly.
You can switch modes manually while in privileged mode by writing to CPSR. Changing modes while in user mode can only occur by an exception.

 RE: Problem in converting the ARM code into THUMB

Note that FIQ is a privileged mode. But not the only one.

 magic solution

why not compile everything but the context switch code in THUMB, and only the context switch assembly in ARM?

 RE: magic solution

Hi Michel,

Thanks for your response.

I tried that option using compiler directive #pragma thumb

I converted whole "C" code into THUMB and the assembly code in ARM. Its working fine.

But my specific requirement for this project is THUMB mode with optimization level as 3.

 post your code

I cannot help you further unless I see your code.

 RE: post your code

"But my specific requirement for this project is THUMB mode with optimization level as 3."

Exacly why?

 RE: post your code

to reduce the ROM/code size.....

 RE: post your code

to reduce the ROM/code size.....<p>

But what if the compiler generated smaller code at optimization level 2 ? Sometimes, the optimizer will do things that are actually counter-productive.

 O3 may prioritize speed more than size.

The IDE has a specific check-box for "Optimize for Time", but no corresponding "Optimize for Size".

Many compilers starts to generate larger code for the highest optimization levels, because a higher priority is given to speed. Unrolling small loops can give great speed improvements, at the cost of size.

Depending on cache architecture, many compilers also starts to use a larger align value for really high optimization levels.

 RE: O3 may prioritize speed more than size.

The IDE has a specific check-box for "Optimize for Time", but no corresponding "Optimize for Size".

I think that's an either-or thing. It optimizes for size by default, but will optimize for time if the user requests it. So a separate check-box for "Optimize for size" is not necessary.

 Problem in converting the ARM code into THUMB

It makes sense to use Thumb "as much as you can" to optimize for size.

on an ARM7TDMI you CANNOT run with thumb code exclusively, you must have SOME ARM code. It really cannot be done so don't try to.

That being said, I would assume that having working code is more important than the size. Because it is much easier to get a scheduler to work in ARM code than Thumb code, you should write you scheduler in ARM code. I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode. When you return from this you can have the USER registers all set up/restored and return to either thumb or ARM mode directly, without using a BX instruction.

 RE: Problem in converting the ARM code into THUMB

Robert,

you wrote

I would also write it to be run though the SWI execption handler. This will put you into a priviledge mode AND into ARM mode.

I thought that all exception code is executed in ARM, even if the non-exception code runs in thumb? it is possible to switch to thumb in the handler, of course.

 RE: Problem in converting the ARM code into THUMB

Yes, all exception/interrupt code has to start in ARM mode, since the processor does not know anything about the code when entering the exception handler.

I think he is trying to say that an SWI handler is an easy way to get into priviledged mode and into ARM mode. No need to consume the FIQ handler.

 RE: Problem in converting the ARM code into THUMB

Yes, All the exceptions must be written in ARM mode. While you exit from the exception, the statement (return) itself switches the control back to THUMB mode. No need to execute a branch exchange instruction again to switch back to THUMB mode. This I experimented in FIQ handler and IRQ handler. I think it is same for all exceptions.

Well, coming to running the scheduler with SWI, how sure you are maintaining the performance of your scheduler with in the tolerance range. My application is to execute few tasks on a specific timing interval/periodicity. That's why I opted for a FIQ (using timer interrupt).

 RE: Problem in converting the ARM code into THUMB

why then not use a periodic timer that uses an IRQ? IRQ has a higher interrupt priority than SWI:

Exceptions      Priority        I bit   F bit
Reset                      1              1       1
Data Abort                 2              1       -
Fast Interrupt Request     3              1       1
Interrupt Request          4              1       -
Prefetch Abort             5              1       -
Software Interrupt         6              1       -
Undefined Instruction      6              1       -

 RE: Problem in converting the ARM code into THUMB

Hi Michel,

I may require few peripheral interrupts in my application. I dont want to use those interrupts in FIQ since, FIQ holds the higher priority than IRQ. Therfore, I am using the FIQ handler for scheduler. In future, if I require any peripheral interrupts in my application, I can configure the same in IRQ handler.

 RE: Problem in converting the ARM code into THUMB

think of this: what is more important to you - switching a task in a timely manner or servicing a peripheral at a timely manner? I don't know about you, but unless what you are writing is truly time critical and has clear deadlines (per task), servicing a peripheral sounds more important to me (so: keep the FIQ for a peripheral). You are aware that the difference between FIQ/IRQ servicing is one branch instruction at most, as the FIQ is the last entry in the vector table hence the servicing code can be placed in the table itself. is your application that time critical?
and don't be stubborn - do as you are told :-)

 RE: Problem in converting the ARM code into THUMB

Hi Michel,

Mine is safety critical system. For this kind of application, we feel its better to use FIQ service handler (since it has the high priority).

The tasks in this system must run over a specific periodicity. No latencies are allowed and the scheduler must be built with hard realtime concept. These are the key requirements which are forced me to go for FIQ. Yes, I do agree your opinion about the peripheral interrupts. In our case, the priority is task switching over the specific periodicity.

Apart from this, I would like to know few points about the ISRs in ARM7TDMI core processors.

My FIQ handler was developed in ARM code and the CPU mode is switch from THUMB to ARM in case of FIQ interrupt. After leaving the handler, CPU mode is switching from ARM to THUMB. There is no problem in executing the interrupt service. My question is, is it suggestible to implement the context switching with in the ISR....?

 RE: Problem in converting the ARM code into THUMB

if you are writing a safety critical system you are probably much better off with a real RTOS rather than writing you own scheduler. Your expectations of having no interrupt latency are not realistic, I am afraid, as there is usually a trade-off between interrupt latency, throughput, and processor utilization. One way of the other, high system load will cause some delays and there is no way around it.
As to your final question - have you seen this link?
http://www.keil.com/forum/docs/thread12635.asp

 Safety critical?

Hmm... I'm afraid the system in question cannot qualify as 'safety critical': it appears some basic problems have not been sorted out yet.
I agree with Tamir, why not look around for a 'tried and true' third-party RTOS? After all, you are not trying to develop your own compiler, shouldn't the same apply to an RTOS?

 RE: Safety critical?

Hi Mike and Tamir,

I do agree with you ppl about using the IRQ handler instead of FIQ. As I explained earlier, my system is a safety critical thats the only point which forced me to work with FIQ. Moreover, my scheduler is working fine with all the timing considerations in ARM mode. I am facing the problem with THUMB mode only.

The reason why we did not prefer to go with already available RTOS is memory consideration... This particular chip is having 30KB of FLASH and 4 KB of SRAM. So.. we are developing our own scheduler with minimum functionality (viz., we don't have resource sharing concept in this project, so no need to develop mutex and seam phore etc... In a broad way we are implementing the RM algorithm in our scheduler).

In ARM mode the size of my code is 3 KB. When I convert and build the code in THUMB mode, I observed that the scheduler code is occupying just 1.8KB. So, I thought its better to go for THUMB mode to reduce the code size further (worst case, it would become 2 KB. which saves 1 KB of FLASH memory....).

Tamir,

I referred the link which you have provided. Its really useful... thanks a lot.

 RE: Safety critical?

Keil's RTL has all the features you want, plus more that you do not need AND meets your tight space requirements. (That if 2K or less of ROM space for the kernel is a requirement) It also works in ARM or Thumb Mode. You can also buy the source code so that you can modify it if you need too (I believe it is still under $5k US to buy). One of the ways they keep the code size small is that if you do not use a feature, it will not link in that feature (i.e. Semaphores, Mailboxes, Mutexes...). You can just use the Real Time Task Scheduler... that works. If nothing else by buying the source that works, you might be able to figure out what you are doing wrong. It never hurts to understand more.

 RE: Safety critical?

Make that $5k for each user who need to be able to work with the project.

 RE: Safety critical?

(30k of Flash + 4k of RAM) == ($5k * 1)

 RE: Safety critical?

Sorry, I can parse - but not understand - that equation. $5k * 1 for the RTXC source if only a single user needs to compile the project.

 RE: Safety critical?

It was a Joke.

It meant to fill up 30K of Flash and 4k of RAM would only require 1 developer, especially if that developer did not have to develop the RTOS from scratch.

 RE: Safety critical?

I agree. 30k ROM implies a quite small application.

Buying - or settling for the pre-compiled version - of RTXC saves a lot of time.

Not just time to write the code, but also to verify that the scheduler really works. Better to spend that time on debugging the final application.

The saved time could possibly be used to write tighter code for the actual application. That would probably affect the total flash and RAM requirements way more than the size difference between the two scheduler implementations.

 RE: Safety critical?

Hi All,

I found the solution for my problem and able to fix the same. My scheduler is functioning as expected and meeting all our timing requirements. Currently the code size for the scheduler is 2 KB.

 RE: Safety critical?

Please tell us - what was the problem?

 RE: Safety critical?

The context switching code was developed in ARM mode and the same is performing out side the FIQ handler. The context switching code will be invoked from the FIQ handler. While entering into the FIQ handler the processor mode was stored in the SPSR register as THUMB mode and the same was restored while leaving the FIQ handler.

At this point of time, the code was in ARM mode and the processor mode was in THUMB which is the major problem caused to enter into PABORT exception. Also, my earlier code (in ARM mode)contains the context switching code within the FIQ handler. I am retrieving and storing the context of a particular task within the FIQ service handler (which requires to change the processor Stack pointer). The processor will remember the current SP value while exiting from the FIQ handler. Therefore, after performing the context switching, FIQ handler is using the SP which was restored last time. This was the reason why I moved my contextswitching code out side the FIQ handler.

Tamir,

I have gone through the link u provided last time. In your code u defined an element in the TCB for each register. In my code, TCB doesn't contain any info abt the registers. It just contain the SP, LR, TAsk ID and the next element/previous elemnt. I am taking the SP value from the TCB and retrieving the context using a POP instruction. I think this was the difference between your code and mine.

 But is it indeed a context switch?

In my code, TCB doesn't contain any info abt the registers. It just contain the SP, LR, TAsk ID and the next element/previous elemnt.

...

I am taking the SP value from the TCB and retrieving the context using a POP instruction.

Fine, but the drawback is that you consume some stack space that can be used by the task itself.

 RE: But is it indeed a context switch?

Hi Michel,

Yes, you are right. I am consuming some stack space of the user. But, if you have the register contents in the TCB, the same will be allocated in the RAM memory... user stack is also resides in the RAM memory only.... so if the size of the TCB gets reduced and the other hand the size of the user stack will be increased by a significant amount.

Also, execution time will be higher if we perform store and restore operations in case of TCB containing the register elements. If the contents of registers are stored in the user stack itself, the same (Storing and restoring the register contents) can be done with the help of PUSH and POP instructions. Which will speedup the context switching code. This is the only point for which I made my design in that way.....

 RE: But is it indeed a context switch?

If the contents of registers are stored in the user stack itself, the same (Storing and restoring the register contents) can be done with the help of PUSH and POP instructions. Which will speedup the context switching code

Both approaches write to RAM, using similar instructions (PUSH/POP vs. LDMIA/STMIA). Why is writing to memory pointed by SP any faster? Besides, using PUSH/POP assumes your stacking is always descending, while STM/LDM do not.

 RE: But is it indeed a context switch?

Hi Michel,

Sorry for my late reply.

Yes, you are correct. I designed my user stack in such a way to keep the register contents in the bottom of the stack.

 RE: But is it indeed a context switch?

have you remembered to reset your R13 to the IRQ stack pointer (as acquired at startup - you may have to make the linker place the variable that keeps the address into a section that is not set to zero by _main.) after your context switch has finished? I have fallen into that trap...

 RE: But is it indeed a context switch?

Sorry, I forgot that you use the FIQ. If you have a stack defined for that mode - then my previous comment applies. Actually, doing a context switch in FIQ might be slightly faster as you have registers R8-R12 (in addition to R13-R14) banked, which means you don't have to back then up of you want to do something (because the user mode registers R8-R14 won't be affected). on the other hand, you might not be able cannot call functions without a stack...

 RE: But is it indeed a context switch?

Hi,

Yes michel, you are right. performing context switching using FIQ is faster. To execute any scheduler related functions, I specified a stack of 20 bytes as the OS stack..... therefore, for the execution of any scheduler related stack, I am using the smae. Therefore, your task stack/FIQ handler stack wouldn't be distrubed.

Coming to youe previous scrap, I didn't understand about the reset issue. Could you please explani me in detail.

 RE: But is it indeed a context switch?

doing the context switch in FIQ can be faster. the thing is that if you do it in IRQ, none of the registers except R13 and R14 is banked so you have to push then into the stack when you want to do something, and then use R13 as a variable at the critical stages when you actually backup the context. This is why you need to point R13 to the IRQ stack once you are done: R13 for the IRQ mode is set in your startup file and retains its value throughout the program execution. If you use R13 as a variable, you lose your IRQ stack! or in your case, the FIQ stack. you may not need to do this, as you have more registers to work with.