LPCXpresso IDE中的主题 Re: Jump Table

Jump Table

lpcware — Thu, 16 Jun 2016 00:56:22 GMT

Content originally posted in LPCWare by IanB on Mon Mar 30 09:22:31 MST 2015
I wrote some code for the LPC11xx, which included a jump table

noswitch:LDR R3,=progtable
LDR R3,[R3,R2]
BX R3
@ ------------------------------------------------------------------------------------
.align
progtable:.word spare
.word spare
.word scroll
.word fill
.word randomsound
.word random
.word manual

And then I copied it to a piece of LPC13xx code

ADR R0,modetable
LDR R10,[R0,R2,LSL #2]
BX R10

modetable:.word mode0LED
.word mode1LED
.word mode2LED
.word mode3LED
.word mode4LED
.word mode5LED
.word mode6LED
.word mode7LED

The LPC11 code was assembled with bit zero set in the jump table, but the LPC13 code assembled with bit zero clear, so that when the jump was taken the processor attempted an illegal change to ARM mode, and crashed with a hard fault exception.

.thumb_func was used correctly on both occasions.

Comments please?

Re: Jump Table

lpcware — Thu, 16 Jun 2016 00:56:23 GMT

Content originally posted in LPCWare by MikeSimmonds on Mon Mar 30 11:47:54 MST 2015
I seem to remember that there is an assembler directive ".thumb_set" to indicate a function address.

Are .syntax unified and .thumb at the top of the file the same in both cases.
do both assembler command lines have a -thumb switch?

ldrr12, =LibSetTimer; trampoline
bxr12;

works for me on a 1788 where LibSetTimer is a .thumb_func declared local function (in an internal SRAM section).

Just thoughts, Mike

Re: Jump Table

lpcware — Thu, 16 Jun 2016 00:56:24 GMT

Content originally posted in LPCWare by MikeSimmonds on Mon Mar 30 12:21:14 MST 2015
I just added this

fn SwitchTest

adrr3, JumpTbl
ldrr10, [r3, r0, lsl 2]
bxr10

JumpTbl:

.wordReadSwitches
.wordDebugSwitches
.wordSetLeds
.wordSetActLed
.wordSetFaultLed


fe SwitchTest

fn/fe are macros

.macrofn n
.type\n, %function
.func\n
.thumb_Func
\n:
.endm

.macrofe n
.endfunc
.size\n, .-\n
.align2,0
.endm

to one of my files. Using existing functions later in the file

Command line from the log file

C:/Dev/NXP/tools/bin/arm-none-eabi-as -mcpu=cortex-m3 -mthumb -g3 -I. -o LibIO.o LibIO.s
--------------
C:/Dev/NXP/tools/bin/arm-none-eabi-size LibIO.o
   text   data    bss    dec    hexfilename
    208      0      0    208     d0LibIO.o

Disassembly shows that the thumb bit is being set.

00010a50 SwitchTest:
   10a50:a301      addr3, pc, #4; (adr r3, 10a58 JumpTbl)
   10a52:f853 a020 ldr.wr10, [r3, r0, lsl #2]
   10a56:4750      bxr10

00010a58 JumpTbl:
   10a58:00010a6d .word0x00010a6d
   10a5c:00010a75 .word0x00010a75
   10a60:00010a7d .word0x00010a7d
   10a64:00010aa1 .word0x00010aa1
   10a68:00010ab1 .word0x00010ab1

For what it is worth.
I use external build via my own makefile and linker script

Cheers, Mike

Edit: Bloody forum removed labels because of angle brackets - edited them out from the disassembly.

Edit Again: I am using the tool chain that came with IDE 6.?
[Because the latest assembler started using wide branches for local jumps all of a sudden. (No explanation either!)]
I use IDE 7 for debugging,

Re: Jump Table

lpcware — Thu, 16 Jun 2016 00:56:24 GMT

Content originally posted in LPCWare by IanB on Mon Mar 30 13:02:19 MST 2015
Thanks for that.
Just for a laugh, I changed the .cpu cortex-m0 statement in my first program to .cpu cortex-m3 and recompiled it; and guess what?
The jump table values remained ODD.
Unfortunately I can't try the converse, as I have some M3-exclusive instructions in the program.

I noticed the thing about the 32-bit instructions for all the branch instructions. I added .n with find-and-replace.

Another thing that strikes me as odd is that in my M0 program, the text editor has changed all the labels and assembler directives to purple, and in my M3 program all the text is black. I don't know what setting is involved here, but I wonder what would happen if I changed it.

And something else - if I put the jump table in the .rodata section, then the ADR instruction can't find it and compiles to SUBS R10,PC,#4 but LDR = has no problem.

The ultimate solution if I can't reach a sensible explanation is to add +1 to all the jump table values!

Re: Jump Table

lpcware — Thu, 16 Jun 2016 00:56:25 GMT

Content originally posted in LPCWare by MikeSimmonds on Mon Mar 30 16:12:53 MST 2015
ADR is a special assembler mnemonic for add/sub pc constant.
It has a limited range.

Try ADRL. this uses two opcodes and has a larger range.

The LDR =xxx construct places a constant close by (within 4K?) in the code stream (where it won't get accidentally executed)
and uses an LDR rx, [PC, zz]

I don't use the IDE editor (and would disable syntax colouring any way) so I can't advise on that.

I seems that your m3 code source is being mis-diagnosed as something else.

I would double check the start of file directives, the assembler switches, and even the file extension case.
Are you on unix perhaps?

Mike.

Re: Jump Table

lpcware — Thu, 16 Jun 2016 00:56:26 GMT

Content originally posted in LPCWare by IanB on Tue Mar 31 02:35:07 MST 2015
Found it! (Daft problem)
I forgot the .text directive after the code-protect-word section.
It seems a bit odd that everything else worked fine!

I like ADR - it's somehow "neater" than the "LDR =" solution which puts the data in the literal pool.
In the M3 it can set bit 0, but you have to write ADR R0,label+1

In the M0 it's rather a chocolate teapot of an instruction, as it can only generate even addresses, and it can't refer to labels in other sections (if the address it is trying to generate is in .rodata then it fails), so you can neither use it to refer to data tables, nor to jump tables.

I've also found out how what makes the editor colour the labels purple.
When setting up a new project.
If I start with the .c file that is automatically generated with the project, delete its contents and change its name to .s then all the text is black.
If I delete the .c file and then add another file File->new->other->general file, and call it .s then it colours the labels and assembler directives; but it makes no difference to how the assembler operates/