Dmitry wrote:
well, no...
I did not make this possibility...
How do you want to parse elf file?
I am writing some routines in C to read the elf-file. (open the binary
file, using fseek, freed ...)
Why this is usefull in _msp430_ case?
I am doing some research about low-power-algorithms. I am working with a
MSP430-compatible microcontroller written in the hardware language VHDL.
For this device I am trying make a relation between one
MSP430-instruction and the dissipated power. Finally I try to realize a
program, that assigns (estimated) energy values to a instruction written
in C.
Example - a (useless) simple C program for MSP430:
int main (void){
int i=123;
int j;
j = i & (int)P1IN;
return j;
}
Then my program should take the compiled C program for the MSP430 (the
elf-file), should estimate the energy per C instruction and give out
something like:
int main (void){
/*costs 3.21pJ*/
int i=123;
/*costs 1.1pJ*/
int j;
j = i & (int)P1IN;
/*costs 4.15pJ*/
return j;
/*costs 2.8pJ*/
}
(All values are complete nonsense.)
The elf-file contains a lot of information that I can use. Unfortunately
if the elf-file is little-endian everything -even all the header
structures of the elf (section header, program header...)- has
byte-reversed (little endian) order.
Let Elf32_Ehdr be a struct (the Elf32 header) containing some members.
If the elf-file is big-endian
fread(pointer, sizeof(Elf32_Ehdr), 1, filepointer)
would read the complete structure from the elf-file to the location
pointed by pointer. I would be done.
With little-endian now I have to byte-rotate _every_ member of the
structure. This is a error-prone task.
I agree that little-endian is a satan's thing but TI made msp430
little-endian :)
;-)
I guess it has some relation to fact, that the MSP430 uses two RAMs -
one for the low und one for the high byte.
Thanks for answering!
Ralf
