flat assembler
Message board for the users of flat assembler.

flat assembler > Non-x86 architectures > swap from arm to thumb mode ...

Author
Thread Post new topic Reply to topic
Gyver



Joined: 13 Jul 2009
Posts: 7
Hi guys! i need your help to understand what this arm instruction really does:

"0x00010000: sub PC, PC, #1"; (we are in "Arm" mode)

Now, reading many posts, seems that instruction forces the cpu to enter in thumb mode but ... why? I know that, in Arm mode, PC is word aligned, so PC[1:0] == 0; when this instruction is executed the PC is 0x010007 ( PC = PC + 8 - 1 , this is the effect of pipeline right?). But what happen now? A "prefech abort exception" is raised ? And, above all, when the T bit is set?

Thx in advance for your help and sry for my bad english.
Post 17 Jul 2018, 16:48
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16050
Location: 112 Ocean Avenue, Amityville
The lowest bit of PC tells the CPU which mode to use to decode instructions. The actual address fetched from RAM does not use the lowest bit from PC, so no exceptions are raised.

The T bit is only used when the OS is returning from an exception. In general you shouldn't change the T bit manually in code.
Post 18 Jul 2018, 03:13
View user's profile Send private message Visit poster's website Reply with quote
Gyver



Joined: 13 Jul 2009
Posts: 7
Thx revolution! i understood, referring to my example:

0x010000: sub pc, pc #1
… entering in thumb mode…
0x010006:
… thumb code here …
right?
Post 18 Jul 2018, 06:09
View user's profile Send private message Reply with quote
ProMiNick



Joined: 24 Mar 2012
Posts: 189
Location: Russian Federation, Sochi
revolution wrote:
The lowest bit of PC tells the CPU which mode to use to decode instructions.
Dosn`t that apply only for earliest APM cores, where T flag was directly located in lowest pc bit, but not in flags?

sub pc,pc #1 - affect only ARM cpus where T flag is located at lowest pc bit, and flags not exist as separate entity(register).
From ARM versions where T moved to flags: instruction version without postfix "s" dosn`t affect flags.

Even more from ARMv6:
instruction variant "sub pc,reg #imm" - not exist anymore, only "subs pc,reg #imm" stayed.
instuction "sub pc, reg #imm" - In linux it is very slow form of switching to thumb mode via handling of exception generated by deprecated instruction. In other OSes it can be not handled at all.
Am I right?

_________________
I don`t like to refer by "you" to one person.
My soul requires acronim "thou" instead.
Post 18 Jul 2018, 07:28
View user's profile Send private message Send e-mail Reply with quote
Gyver



Joined: 13 Jul 2009
Posts: 7
Quote:
instruction "sub pc, reg #imm" - In linux it is very slow form of switching to thumb mode via handling of exception generated by deprecated instruction. In other OSes it can be not handled at all.



You are right ProMiNick! Actually this is the first instruction of an elf program Wink
Post 18 Jul 2018, 07:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16050
Location: 112 Ocean Avenue, Amityville
ProMiNick wrote:
Dosn`t that apply only for earliest APM cores, where T flag was directly located in lowest pc bit, but not in flags?

sub pc,pc #1 - affect only ARM cpus where T flag is located at lowest pc bit, and flags not exist as separate entity(register).
From ARM versions where T moved to flags: instruction version without postfix "s" dosn`t affect flags.
The implementation could be anything. It doesn't matter to the app or the OS how the CPU implements thumb/arm mode, the instructions will still work fine.
ProMiNick wrote:
Even more from ARMv6:
instruction variant "sub pc,reg #imm" - not exist anymore, only "subs pc,reg #imm" stayed.
instuction "sub pc, reg #imm" - In linux it is very slow form of switching to thumb mode via handling of exception generated by deprecated instruction. In other OSes it can be not handled at all.
Am I right?
The switching is not handled by the OS from an exception. It is all handled by 100% the CPU. The OS won't know what mode the app is running until the next interrupt. The app could change arm/thumb mode many times and the OS would never know or care.

So I'd say that the "slowness" is not important. But as always measure it in the app if you think it is some sort of performance bottleneck. And of course different CPU implementations will have different timings so test it across all versions you intend to support.
Post 18 Jul 2018, 09:57
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.