so just for the fun of it I wanted to see how the assembly code is compiled
so I wrote this simple code and compiled for arduino UNO.
void setup() {
pinMode(2,OUTPUT);
}
void loop() {
// put your main code here, to run repeatedly:
for(uint8_t i=0;i<8;++i){
digitalWrite(2,1<<i);
}
}
Googling I found the command to same the dissamble code to file (FYI:I copied the avr-objdump.exe file to the arduino folder):
D:\LocalData\user\Downloads\arduino-1.8.5\avr-objdump -S C:\Users\user\AppData\Local\Temp\arduino_build_956846/sketch_sep10a.ino.elf > D:\LocalData\user\Downloads\arduino-1.8.5\myskeych.txt
I can see may c-code in the file created (here attached) in it but not MY code... any idea why?
For sure it's your code. What you're seeing is all the baggage attached by the two functions you've used plus the Arduino init() to set up the timers for PWM, delay, millis, etc.
DKWatson:
For sure it's your code. What you're seeing is all the baggage attached by the two functions you've used plus the Arduino init() to set up the timers for PWM, delay, millis, etc.
ok... that's reassuring... but is it a bug that I cannot see MY code lines in the assembly output but I can all the others that I have not explicitly put in?
my point being... how can I figure out where my code actually starts in that assembly file output ( if I used another sketch for example?)
You'll need a lot more info than you're going to get here if you want to understand assembly. Basically, the listing you see contains the C code and the disassembled machine code. (The compiler goes direct to machine code and then disassembles for the listing.) All the disassembled instructions are prefixed with a memory location and colon. The other lines are the respective C statements that were responsible for the assembly code. You may or not see the exact code that you wrote depending on how the compiler chose to implement it.
What you do see id the library code that was pulled in to handle the two function calls. pinMode begins at line 296 and digitalWrite at line 348. Towards the top, beginning in line 174, you can see the init() function that gets called in the background to set all the timers etc.
Assembly is an esoteric beast. If you plan to spend any time with it, get a good book and keep it with you. While it's essentially the same on every platform (in function), each instruction set is different so trying to remember it all is a fool's errand. I've been doing it for almost 50 years now and every year I add a few new books to my library, and never throw out the old ones. The 6502 instruction set for example, has never changed since I first started playing with it in 1977!
DKWatson:
You'll need a lot more info than you're going to get here if you want to understand assembly. Basically, the listing you see contains the C code and the disassembled machine code. (The compiler goes direct to machine code and then disassembles for the listing.) All the disassembled instructions are prefixed with a memory location and colon. The other lines are the respective C statements that were responsible for the assembly code. You may or not see the exact code that you wrote depending on how the compiler chose to implement it.
What you do see id the library code that was pulled in to handle the two function calls. pinMode begins at line 296 and digitalWrite at line 348. Towards the top, beginning in line 174, you can see the init() function that gets called in the background to set all the timers etc.
Assembly is an esoteric beast. If you plan to spend any time with it, get a good book and keep it with you. While it's essentially the same on every platform (in function), each instruction set is different so trying to remember it all is a fool's errand. I've been doing it for almost 50 years now and every year I add a few new books to my library, and never throw out the old ones. The 6502 instruction set for example, has never changed since I first started playing with it in 1977!
Thank for the advice and the pointers. I will bear that in mind
is it a bug that I cannot see MY code lines in the assembly output
It is a "limitation" that the source code lines for an UNSAVED sketch will not show up in the assembly output. To include the source lines, the disassembler references the original sketch source code, and if you haven't saved the sketch, the source code is not where the IDE expects it to be!
Save your sketch into a real file, and you should see the lines from YOUR code as well as the library code.
(note that the OBJECT code of your file is still there; it can just be hard to recognize without the source in there as well. For one thing, it's likely to have been merged into the setup() function...)
I use :
...............
REM recopie du source .ino.cpp dans le répertoire du résultat de compilation
xcopy /W /F /-Y %toto% %arducomp%%fichierino%.ino
.........................
%ardudump%avr-objdump.exe --include=%adresseElf% -h -S -d -l %arducomp%%fichierino%.ino.elf > %ardustock%%fichierino%_elf.lst
You have to search about the many options of avr-objdump.exe to get what you want.
Don't forget that the optimizer does a lot of things.
[assembly language] is essentially the same on every platform (in function)
I dunno. I'd say that there are at least three dramatically-different styles. Going from a 6502 to an AVR is probably pretty easy - many concepts are quite similar, and you're essentially get more of everything. Going from an AVR to a 6502, however, is likely to require a change in the way you think about things.
The 6502 instruction set for example, has never changed since I first started playing with it in 1977!
New instructions were added in the 65C02...
The AVR series also has a bunch of variants that have slight different instructions available. (for example, the ATmega88 and ATmega8 do not have "jmp" !)
The fastest nop on a PDP-10 changed from JFCL (don't clear any flags and then don't jump anyware) to TRN (Test no bits in the right half of AC0, don't do anything to them, and then don't skip, either) when the KL-10 version came out
