Consider the following Objective C interface definition
#import <Foundation/Foundation.h>
#interface MyClass : NSObject
#property NSObject* myprop;
#end
The assembly generated for ARMv7 by Xcode 5 for [MyClass myprop] looks like
.code 16 # #"\01-[MyClass myprop]"
.thumb_func "-[MyClass myprop]"
"-[MyClass myprop]":
Lfunc_begin0:
.cfi_startproc
# BB#0:
sub sp, #8
#DEBUG_VALUE: -[MyClass myprop]:self <- undef
#DEBUG_VALUE: -[MyClass myprop]:_cmd <- undef
str r0, [sp, #4]
str r1, [sp]
ldr r0, [sp, #4]
movw r2, :lower16:(_OBJC_IVAR_$_MyClass.myprop-(LPC0_0+4))
movt r2, :upper16:(_OBJC_IVAR_$_MyClass.myprop-(LPC0_0+4))
LPC0_0:
add r2, pc
ldr r2, [r2]
movs r3, #1
add sp, #8
b.w _objc_getProperty
Ltmp0:
Lfunc_end0:
.cfi_endproc
I want to understand the resulting assembly and have the following questions about it:
1) The last instruction (b.w _objc_getProperty) sets the PC to the address of the label _objc_getProperty. But how does this procedure know where to jump back? Does it assume that the method is invoked with bl, and therefore the link register contains the target address?
2) What do the 3 lines below the second #DEBUG_VALUE do?
If I understand it correctly, the content of r0 is stored at stack offset 4, r1 is stored at the current stack (offset 0), and r0 is filled with stack offset 4. But why does the last instruction changes anything? Doesn't it just mean that r0 is filled with what it already contained? What are the values used for? _obj_getProperty?
3) Why is r3 set to 1 at the end? (movs r3, #1)?
In C code the function would probably look like this:
resulttype Lfunc_begin0(type1 arg1, type2 arg2)
{
return _objc_getProperty(arg1, arg2, Myclass_myprop, 1);
}
First let's look at the following example:
int func(void)
{
a();
b();
return c();
}
It would now be possible to do the function call to "c()" the following way:
save_lr
bl a
bl b
bl c
restore_original_lr
bx lr
Alternatively it would be possible to perform the following code:
save_lr
bl a
bl b
restore_original_lr
b c
In this case the "bx lr" instruction at the end of "c()" will directly jump to the function that called ourself and we do not have to do the "bx lr".
Because some function calls in the C code may destroy the content of R0 and R1 unoptimized C code will save these registers to the stack just for the case that their value is needed later. Well-optimized C code would check this and remove the three instructions after the "#DEBUG" lines. Even the "add SP," and "sub SP," lines could be optimized away!
The _obj_getProperty function obviously takes four arguments. R0 and R1 are simply passed (as shown in the C code above) while R2 and R3 are the additional arguments for that function.
What the 4th argument (R3=1) really means cannot be seen from the assembler code shown here.
Related
Consider this code snippet:
__asm volatile (
" MOVW R0, #0x0000 \n\t"
" MOVT R0, #0x3004 \n\t"
" LDRSH R1, [R0, #12] \n\t"
⋮
)
This is the hard-coded way for loading what's stored at address 0x30040000 + 12 into R1.
I understand I can use a list of input and output variables and a clobber list. So if I use something like this:
int16_t localVar = 10;
__asm volatile (
" <some code with %[lv]> \n\t"
" LDRSH R1, ??? \n\t"
⋮
: [lv] "r" (localVar)
⋮
)
What do I need to replace <some code with %[lv]> and/or the question marks with so that I end up with value 10 in register R1? I generally don't know how to do this. It would be great to learn the most efficient way for ARM-v7 in terms of execution time needed.
In asm file1 I try to export a variable and use it in another.
I've tried to find how to do that from manuals & tutorials, but no success.
So, how can I share a global variable between asm files?
// File 1
// Here is saved value of a register (r10) to a variable.
.section .data
.global r10_save
r10_save_addr: .word r10_save
.section .text
ldr r13, =r10_save_addr // Load address for the global variable to some reg (r13)
str r13, [r10] // Save r13 to global variable
// File 2
// Here the intention is to use the variable (that should have r10 value stored).
.section .data
str_r10:
.asciz "r10 = 0x"
strlen_r10 = .-str_r10
.section .text
/* Here I want to use the reference of a variable
which has got its value in other file.
*/
mov r0, $1 //
ldr r1, =str_r10 // address of text string
ldr r2, =strlen_r10 // number of bytes to write
mov r7, $4 //
swi 0
You can use extern to get the value of global varibles:
// File 2
// Here the intention is to use the variable (that should have r10 value stored).
.section .data
str_r10:
.asciz "r10 = 0x"
strlen_r10 = .-str_r10
.section .text
/* Here I want to use the reference of a variable
which has got its value in other file.
*/
.extern r10_save // or EXTERN DATA(r10_save)
mov r0, $1 //
ldr r1, =str_r10 // address of text string
ldr r2, =strlen_r10 // number of bytes to write
mov r7, $4 //
swi 0
Then you can access r10_save in the second file too.
I am using a MSP 432 and have to create an assembly functions in C. I tried creating the functions using __asm void PendSV_Handler{}. But that does not work and says Expected an Identifier.
Also, I am trying to run this assembler command cpsid i but it says CPSID is undefined but CPSIE i works. I am a bit confused at this point. I am fairly new to this and I am still learning.
Below is the code I am trying to make assembly. I try making the function assembly by doing __asm void PendSV_handler.
I was not sure if it would be easier to just create a asm. file with these instructions.
OSThread *volatile OS_curr;
OSThread *volatile OS_next;
void PendSV_Handler(void){
__asm__("cpsid i"
//if(OS_curr != (OSThread *)0)
"ldr r0, =OS_curr"
"ldr r0, [r0]"
"cbz r0, PendSV_restore");
// Push r4 - r11
__asm__("PUSH {r4-r11}"
"ldr r1, =OS_curr"
"ldr r1, [r1]"
// OS_curr -> sp = sp;
"str sp, [r1]");
PendSV_restore
// sp=OS_next -> sp;
__asm__("ldr r0, =OS_next;"
"ldr r0, [r0]"
"ldr r0, [r0]"
"str sp, [r13]");
// OS_curr = OS_next;
__asm__("ldr r0, =OS_next"
"ldr r1, [pc, 0xc]"
"ldr r0, =OS_curr"
"str r0, [r1]"
//Pop r4-r11
"POP {r4-r11}"
// __enable_interrupts();
"cpsie i"
//return to next thread
"bx r14");
}
Inline assembler syntax is not redefined in the C programming language, and its support and syntax is compiler specific. In GCC:
void PendSV_Handler(void)
{
__asm__("cpsid i");
//if(OS_curr != (OSThread *)0)
__asm__("ldr r0, =OS_curr");
__asm__("ldr r0, [r0]");
__asm__("cbz r0, PendSV_restore");
// Push r4 - r11
__asm__("PUSH {r4-r11}");
__asm__("ldr r1, =OS_curr");
__asm__("ldr r1, [r1]");
// OS_curr -> sp = sp;
__asm__("str sp, [r1]");
PendSV_restore:
// sp=OS_next -> sp;
__asm__("ldr r0, =OS_next;");
__asm__("ldr r0, [r0]");
__asm__("ldr r0, [r0]");
__asm__("str sp, [r13]");
// OS_curr = OS_next;
__asm__("ldr r0, =OS_next");
__asm__("ldr r1, [pc, 0xc]");
__asm__("ldr r0, =OS_curr");
__asm__("str r0, [r1]");
//Pop r4-r11
__asm__("POP {r4-r11}");
// __enable_interrupts();
__asm__("cpsie i");
//return to next thread
__asm__("bx r14");
}
Referencing
Inline assembler syntax is not redefined in the C programming language
I did in the past for a university project
inline void function(param1,param2)
{
asm volatile ("param1");
asm volatile ("param2");
}
But, if u are working on ARM, look at the instruction set to see whitch commands are possible
As an example:
If you want to write some timing critical stuff, that needs to be in the written order you could do something like this
inline void COLOUR_GLCD_write_address_data(uint8_t address, uint16_t data)
{
asm volatile ("DMB");
*(volatile uint16_t*)LCD_CMD_ADDRESS = address;
asm volatile ("DMB");
*(volatile uint16_t*)LCD_DATA_ADDRESS = data;
}
This was for sending data to an external lcd via the BUS Interface on an Atmel SAME70.
Hope that helped =)
The ARM Coretex STM32's HardFault_Handler can only get several registers values, r0, r1,r2, r3, lr, pc, xPSR, when crash happened. But there is no FP and SP in the stack. Thus I could not unwind the stack.
Is there any solution for this? Thanks a lot.
[update]
Following a web instruction to let ARMGCC(Keil uvision IDE) generate FP by adding a compiling option "--use_frame_pointer", but I could not find the FP in the stack. I am a real newbie here. Below is my demo code:
int test2(int i, int j)
{
return i/j;
}
int main()
{
SCB->CCR |= 0x10;
int a = 10;
int b = 0;
int c;
c = test2(a,b);
}
enum { r0 = 0, r1, r2, r3, r11, r12, lr, pc, psr};
void Hard_Fault_Handler(uint32_t *faultStackAddress)
{
uint32_t r0_val = faultStackAddress[r0];
uint32_t r1_val = faultStackAddress[r1];
uint32_t r2_val = faultStackAddress[r2];
uint32_t r3_val = faultStackAddress[r3];
uint32_t r12_val = faultStackAddress[r12];
uint32_t r11_val = faultStackAddress[r11];
uint32_t lr_val = faultStackAddress[lr];
uint32_t pc_val = faultStackAddress[pc];
uint32_t psr_val = faultStackAddress[psr];
}
I have two questions here:
1. I am not sure where the index of FP(r11) in the stack, or whether it is pushed into stack or not. I assume it is before r12, because I compared the assemble source before and after adding the option "--use_frame_pointer". I also compared the values read from Hard_Fault_Handler, seems like r11 is not in the stack. Because r11 address I read points to a place where the code is not my code.
[update] I have confirmed that FP is pushed into the stack. The second question still needs to be answered.
See below snippet code:
Without the option "--use_frame_pointer"
test2 PROC
MOVS r0,#3
BX lr
ENDP
main PROC
PUSH {lr}
MOVS r0,#0
BL test2
MOVS r0,#0
POP {pc}
ENDP
with the option "--use_frame_pointer"
test2 PROC
PUSH {r11,lr}
ADD r11,sp,#4
MOVS r0,#3
MOV sp,r11
SUB sp,sp,#4
POP {r11,pc}
ENDP
main PROC
PUSH {r11,lr}
ADD r11,sp,#4
MOVS r0,#0
BL test2
MOVS r0,#0
MOV sp,r11
SUB sp,sp,#4
POP {r11,pc}
ENDP
2. Seems like FP is not in the input parameter faultStackAddress of Hard_Fault_Handler(), where can I get the caller's FP to unwind the stack?
[update again]
Now I understood the last FP(r11) is not stored in the stack. All I need to do is to read the value of r11 register, then I can unwind the whole stack.
So now my final question is how to read it using inline assembler of C. I tried below code, but failed to read the correct value from r11 following the reference of http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472f/Cihfhjhg.html
volatile int top_fp;
__asm
{
mov top_fp, r11
}
r11's value is 0x20009DCC
top_fp's value is 0x00000004
[update 3] Below is my whole code.
int test5(int i, int j, int k)
{
char a[128] = {0} ;
a[0] = 'a';
return i/j;
}
int test2(int i, int j)
{
char a[18] = {0} ;
a[0] = 'a';
return test5(i, j, 0);
}
int main()
{
SCB->CCR |= 0x10;
int a = 10;
int b = 0;
int c;
c = test2(a,b); //create a divide by zero crash
}
/* The fault handler implementation calls a function called Hard_Fault_Handler(). */
#if defined(__CC_ARM)
__asm void HardFault_Handler(void)
{
TST lr, #4
ITE EQ
MRSEQ r0, MSP
MRSNE r0, PSP
B __cpp(Hard_Fault_Handler)
}
#else
void HardFault_Handler(void)
{
__asm("TST lr, #4");
__asm("ITE EQ");
__asm("MRSEQ r0, MSP");
__asm("MRSNE r0, PSP");
__asm("B Hard_Fault_Handler");
}
#endif
void Hard_Fault_Handler(uint32_t *faultStackAddress)
{
volatile int top_fp;
__asm
{
mov top_fp, r11
}
//TODO: use top_fp to unwind the whole stack.
}
[update 4] Finally, I made it out. My solution:
Note: To access r11, we have to use embedded assembler, see here, which costs me much time to figure it out.
//we have to use embedded assembler.
__asm int getRegisterR11()
{
mov r0,r11
BX LR
}
//call it from Hard_Fault_Handler function.
/*
Function call stack frame:
FP1(r11) -> | lr |(High Address)
| FP2|(prev FP)
| ...|
Current FP(r11) ->| lr |
| FP1|(prev FP)
| ...|(Low Address)
With FP, we can access lr(link register) which is the address to return when the current functions returns(where you were).
Then (current FP - 1) points to prev FP.
Thus we can unwind the stack.
*/
void unwindBacktrace(uint32_t topFp, uint16_t* backtrace)
{
uint32_t nextFp = topFp;
int j = 0;
//#define BACK_TRACE_DEPTH 5
//loop backtrace using FP(r11), save lr into an uint16_t array.
for(int i = 0; i < BACK_TRACE_DEPTH; i++)
{
uint32_t lr = *((uint32_t*)nextFp);
if ((lr >= 0x08000000) && (lr <= 0x08FFFFFF))
{
backtrace[j*2] = LOW_16_BITS(lr);
backtrace[j*2 + 1] = HIGH_16_BITS(lr);
j += 1;
}
nextFp = *((uint32_t*)nextFp - 1);
if (nextFp == 0)
{
break;
}
}
}
#if defined(__CC_ARM)
__asm void HardFault_Handler(void)
{
TST lr, #4
ITE EQ
MRSEQ r0, MSP
MRSNE r0, PSP
B __cpp(Hard_Fault_Handler)
}
#else
void HardFault_Handler(void)
{
__asm("TST lr, #4");
__asm("ITE EQ");
__asm("MRSEQ r0, MSP");
__asm("MRSNE r0, PSP");
__asm("B Hard_Fault_Handler");
}
#endif
void Hard_Fault_Handler(uint32_t *faultStackAddress)
{
//get back trace
int topFp = getRegisterR11();
unwindBacktrace(topFp, persistentData.faultStack.back_trace);
}
Very primitive method to unwind the stack in such case is to read all stack memory above SP seen at the time of HardFault_Handler and process it using arm-none-eabi-addr2line. All link register entries saved on stack will be transformed into source line (remember that actual code path goes the line before LR points to). Note, if functions in between were called using branch instruction (b) instead of branch and link (bl) you'll not see them using this method.
(I don't have enough reputation points to write comments, so I'm editing my answer):
UPDATE for question 2:
Why do you expect that Hard_Fault_Handler has any arguments? Hard_Fault_Handler is usally a function to which address is stored in vector (exception) table. When the processor exception happens then Hard_Fault_Handler will be executed. There is no arguments passing involved doing this. But still, all registers at the time the fault happens are preserved. Specifically, if you compiled without omit-frame-pointer you can just read value of R11 (or R7 in Thumb-2 mode). However, to be sure that in your code Hard_Fault_Handler is actually a real hard fault handler, look into startup.s code and see if Hard_Fault_Handler is at the third entry in vector table. If there is an other function, it means Hard_Fault_Handler is just called from that function explicitly. See this article for details. You can also read my blog :) There is a chapter about stack which is based on Android example, but a lot of things are the same in general.
Also note, most probably in faultStackAddress should be stored a stack pointer, not a frame pointer.
UPDATE 2
Ok, lets clarify some things. Firstly, please paste the code from which you call Hard_Fault_Handler. Secondly, I guess you call it from within real HardFault exception handler. In that case you cannot expect that R11 will be at faultStackAddress[r11]. You've already mentioned it at the first sentence in your question. There will be only r0-r3, r12, lr, pc and psr.
You've also written:
But there is no FP and SP in the stack. Thus I could not unwind the
stack. Is there any solution for this?
The SP is not "in the stack" because you have it already in one of the stack registers (msp or psp). See again THIS ARTICLE. Also, FP is not crucial to unwind stack because you can do it without it (by "navigating" through saved Link Registers). Other thing is that if you dump memory below your SP you can expect FP to be just next to saved LR if you really need it.
Answering your last question: I don't now how you're verifying this code and how you're calling it (you need to paste full code). You can look into assembly of that function and see what's happening under the hood. Other thing you can do is to follow this post as a template.
I'm under the impression that these two commands result in the same end, namely incrementing X by 1 but that the latter is probably more efficient.
If this is not correct, please explain the diff.
If it is correct, why should the latter be more efficient? Shouldn't they both compile to the same IL?
Thanks.
From the MSDN library for +=:
Using this operator is almost the same as specifying result = result + expression, except that result is only evaluated once.
So they are not identical and that is why x += 1 will be more efficient.
Update: I just noticed that my MSDN Library link was to the JScript page instead of the VB page, which does not contain the same quote.
Therefore upon further research and testing, that answer does not apply to VB.NET. I was wrong. Here is a sample console app:
Module Module1
Sub Main()
Dim x = 0
Console.WriteLine(PlusEqual1(x))
Console.WriteLine(Add1(x))
Console.WriteLine(PlusEqual2(x))
Console.WriteLine(Add2(x))
Console.ReadLine()
End Sub
Public Function PlusEqual1(ByVal x As Integer) As Integer
x += 1
Return x
End Function
Public Function Add1(ByVal x As Integer) As Integer
x = x + 1
Return x
End Function
Public Function PlusEqual2(ByVal x As Integer) As Integer
x += 2
Return x
End Function
Public Function Add2(ByVal x As Integer) As Integer
x = x + 2
Return x
End Function
End Module
IL for both PlusEqual1 and Add1 are indeed identical:
.method public static int32 Add1(int32 x) cil managed
{
.maxstack 2
.locals init (
[0] int32 Add1)
L_0000: nop
L_0001: ldarg.0
L_0002: ldc.i4.1
L_0003: add.ovf
L_0004: starg.s x
L_0006: ldarg.0
L_0007: stloc.0
L_0008: br.s L_000a
L_000a: ldloc.0
L_000b: ret
}
The IL for PlusEqual2 and Add2 are nearly identical to that as well:
.method public static int32 Add2(int32 x) cil managed
{
.maxstack 2
.locals init (
[0] int32 Add2)
L_0000: nop
L_0001: ldarg.0
L_0002: ldc.i4.2
L_0003: add.ovf
L_0004: starg.s x
L_0006: ldarg.0
L_0007: stloc.0
L_0008: br.s L_000a
L_000a: ldloc.0
L_000b: ret
}
I wrote a simple console app:
static void Main(string[] args)
{
int i = 0;
i += 1;
i = i + 1;
Console.WriteLine(i);
}
I disassembled it using Reflector and here's what i got:
private static void Main(string[] args)
{
int i = 0;
i++;
i++;
Console.WriteLine(i);
}
They are the same.
they compile to the same, the second is just easier to type.
IMPORTANT:
The answers specifying evaluation are certainly correct in terms of what a += do, in general languages. But in VB.NET, I assume X specified in the OP is a variable or a property.
They'll probably compile to the same IL.
UPDATE (to address the probably controversy):
VB.NET is a specification of a programming language. Any compiler that conforms to what's defined in the spec can be a VB.NET implementation. If you edit the source code of the MS VB.NET compiler to generate crappy code for X += 1 case, you'll still conform to VB.NET spec (because it didn't say anything about how it's going to work. It just says the effect will be exactly the same, which makes it logical to generate the same code, indeed).
While the compiler is very very likely (and I feel it really does) generate the same code for both, but it's pretty complex piece of software. Heck, you can't even guarantee that a compiler generates the exact same code when the same code is compiled twice!
What you can feel 100% secure to say (unless you know the source code of the compiler intimately) is that a good compiler should generate the same code, performance-wise, which might or might not be the exact same code.
So many speculations! Even the conclusion with the Reflector thingy is not necessarily true because it can do optimizations while dissassembling.
So why does none of you guys just have a look into the IL code? Have a look at the following C# programme:
static void Main(string[] args)
{
int x = 2;
int y = 3;
x += 1;
y = y + 1;
Console.WriteLine(x);
Console.WriteLine(y);
}
This code snippet compiles to:
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
// Code size 25 (0x19)
.maxstack 2
.locals init ([0] int32 x,
[1] int32 y)
// some commands omitted here
IL_0004: ldloc.0
IL_0005: ldc.i4.1
IL_0006: add
IL_0007: stloc.0
IL_0008: ldloc.1
IL_0009: ldc.i4.1
IL_000a: add
IL_000b: stloc.1
// some commands omitted here
}
As you can see, it's in fact absolutely the same. And why is it? Because IL's purpose is to tell what to do, not how to. The optimization will be a job of the JIT compiler. Btw it's the same in VB.Net
On x86, if x is in register eax, they will both result in something like
inc eax;
So you're right, after some compilation stage, the IL will be the same.
There's a whole class of questions like this that can be answered with "trust your optimizer."
The famous myth is that
x++;
is less efficient than
++x;
because it has to store a temporary value. If you never use the temporary value, the optimizer will remove that store.
Yes, they behave the same.
No, they are probably equally efficient. Optimizers are good at that sort of thing. If you'd like to double check, write the optimized code and view it in reflector.
The optimizer probably produces the same result, if x is a simple type like int or float.
If you'd use some other language (limited VB knowledge here, can you overload +=?) where x could be one big honking object, the former creates and extra copy, which can be hundreds of megs. The latter does not.
are the same.
x=x+1
is mathematical seen a contradiction whereas
x+=1
isn't and is light to be typed.
They may be the same in VB; they are not necessarily the same in C (where the operator comes from).
In C++ it depends what datatype is x and how are operators defined. If x is an instance of some class you can get completely different results.
Or maybe you should fix the question and specify that x is an integer or whatever.
i thought the differences are due to the additional clock cycles used for memory references, but i turned out to be wrong! can't understand this thing myself
instruction type example cycles
===================================================================
ADD reg,reg add ax,bx 1
ADD mem,reg add total, cx 3
ADD reg,mem add cx,incr 2
ADD reg,immed add bx,6 1
ADD mem,immed add pointers[bx][si],6 3
ADD accum,immed add ax,10 1
INC reg inc bx 1
INC mem inc vpage 3
MOV reg,reg mov bp,sp 1
MOV mem,reg mov array[di],bx 1
MOV reg,mem mov bx,pointer 1
MOV mem,immed mov [bx],15 1
MOV reg,immed mov cx,256 1
MOV mem,accum mov total,ax 1
MOV accum,mem mov al,string 1
MOV segreg,reg16 mov ds,ax 2, 3
MOV segreg,mem16 mov es,psp 2, 3
MOV reg16,segreg mov ax,ds 1
MOV mem16,segreg mov stack_save,ss 1
MOV reg32,controlreg mov eax,cr0 22
mov eax,cr2 12
mov eax,cr3 21, 46
mov eax,cr4 14
MOV controlreg,reg32 mov cr0,eax 4
MOV reg32,debugreg mov edx,dr0 DR0-DR3,DR6,DR7=11;
DR4,DR5=12
MOV debugreg,reg32 mov dr0,ecx DR0-DR3,DR6,DR7=11;
DR4,DR5=12
source:http://turkish_rational.tripod.com/trdos/pentium.txt
the instructions may be tranlated as:
;for i = i+1 ; cycles
mov ax, [i] ; 1
add ax, 1 ; 1
mov [i], ax ; 1
;for i += 1
; dunno the syntax of instruction. it should be the pointers one :S
;for i++
inc i ; 3
;or
mov ax, [i] ; 1
inc ax ; 1
mov [i], ax ; 1
;for ++i
mov ax, [i] ; 1
;do stuff ; matters not
inc ax ; 1
mov [i], ax ; 1
all turn out to be same :S
its just some data that may be helpful. please comment!
Something worth noting is that +=, -=, *= etc. do an implicit cast.
int i = 0;
i = i + 5.5; // doesn't compile.
i += 5.5; // compiles.
At run time (at least with PERL) there is no difference. x+=1 is roughly .5 seconds faster to type than x = x+1 though
There is no difference in programmatic efficiency; just typing efficiency.
Back in the early 1980s, one of the really cool optimizations of the Lattice C Compiler was that "x = x + 1;", "x += 1;" and "x++;" all produced exactly the same machine code. If they could do it, a compiler written in this millenium should definitely be able to do it.
If x is a simple integer scalar variable, they should be the same.
If x is a large expression, possibly with side effects, +=1 and ++ should be twice as fast.
Many people concentrate on this kind of low-level optimization as if that's what optimization is all about. I assume you know it's a much bigger subject.