Generated assembly instructions ?

Created Thu, 06 Oct 2011 23:56:20 +0000 by luxeomni

luxeomni

Thu, 06 Oct 2011 23:56:20 +0000

Hi, How can we see the generated pic32/mips assembly instructions for each line of the C++ source code? I was not successful using pic32-objdump with the .elf file (like I used to do with avr-objdump with the Arduino).

lloyddean

Fri, 07 Oct 2011 00:15:36 +0000

Hold the Shift key down when you go to compile - note the output.

If that doesn't give you an idea of how to get what you want post again and I'll give you more direct answer.

luxeomni

Fri, 07 Oct 2011 19:00:37 +0000

Hi again,

Shift-verify(compile) I do often. It is the output of the build commands. I use it to find the location of the .elf file and .hex file to then feed other tools manually. But that alone does not give me the assembler instructions for every C++ source line. Or am I missing something?

regards

lloyddean

Fri, 07 Oct 2011 19:26:11 +0000

Note that as long as the IDE is running all the temp files you're seeing in the output still exist.

An example from my system, Mac OS, compiling an C version of the Asteroids for the Gameduino. I'm sitting in Terminal having set my current working directory to that of the temp directory where all these intermediate files exist.

With

/Applications/mpide.app/Contents/Resources/Java/hardware/pic32/compiler/pic32-tools/bin/pic32-g++  -O2  -c  -mno-smart-io  -w  -fno-exceptions  -ffunction-sections  -fdata-sections  -G1024  -g  -mdebugger  -Wcast-align  -mprocessor=32MX320F128H  -DF_CPU=80000000L  -DARDUINO=22  -D_BOARD_UNO_  -Danything_you_want  -Danything=1   -I/Users/lloyd/Desktop/AsteroidsInC   -I/Applications/Mpide.app/Contents/Resources/Java/hardware/pic32/cores/pic32 ./AsteroidsInC.cpp

I can compile the .PDE turned to a .cpp file into an .o object file.

With the addition of '-S' I can have the compiler create the assembler file that is normally further processed by the assembler with:

/Applications/mpide.app/Contents/Resources/Java/hardware/pic32/compiler/pic32-tools/bin/pic32-g++  -O2  -c  -mno-smart-io  -w  -fno-exceptions  -ffunction-sections  -fdata-sections  -G1024  -g  -mdebugger  -Wcast-align  -mprocessor=32MX320F128H  -DF_CPU=80000000L  -DARDUINO=22  -D_BOARD_UNO_  -Danything_you_want  -Danything=1   -I/Users/lloyd/Desktop/AsteroidsInC   -I/Applications/Mpide.app/Contents/Resources/Java/hardware/pic32/cores/pic32 -S ./AsteroidsInC.cpp

Hope this helps!

EDIT: My wording was for the benefit of others that my trip across this in the future,

Darth Maker

Sat, 08 Oct 2011 00:19:28 +0000

Well that's from the command line. I believe he (and I am interested as well) to do it from the IDE.

lloyddean

Sat, 08 Oct 2011 01:17:09 +0000

To the best of my limited knowledge pic32-objdump can't be called from the IDE and the original request makes no mention of the IDE.

luxeomni

Fri, 21 Oct 2011 03:14:26 +0000

Thanks, No, I did not want this through the IDE, using the command line is perfectly fine.

Although this is a good way to get the assembleur for one cpp file, it does not seem to mix in the C++ source code. Without that it becomes incredibly difficult to spot how a certain piece of code gets compiled. I have seen that elsewhere with other (non-mips) gnu cpp-based toolchains, but cannot find where and how. You can easily spot every function start (and end) -- which is fine for tiny functions, but not so for slightly bigger ones.

Output snippet. (Only assembler without C/C++ source code intermixed):

.LFB31:
.LSM32:
.LVL10:
/* prologue: function */
/* frame size = 0 */
.LSM33:
	sbi 40-32,5
.LSM34:
	out 43-32,r25
.LVL11:
	in r25,40-32
.LVL12:
	andi r25,lo8(-4)
	out 40-32,r25
	in r18,40-32
	mov r25,r24
	swap r25
	lsr r25
	lsr r25
	andi r25,lo8(3)
	or r25,r18
	out 40-32,r25
	andi r24,lo8(63)
.LVL13:
	out 37-32,r24
.LSM35:
	cbi 40-32,4
	sbi 40-32,4
/* epilogue start */
.LSM36:
	ret

jasonk

Fri, 21 Oct 2011 04:08:08 +0000

pic32-objdump should work on the generated ELF file just like it does for AVR. Just make sure that all of the source files are compiled with the -g option. Recent builds of mpide should pass the -g option by default, but you can customize the options in the platforms.txt file or the boards.txt file.

lloyddean

Fri, 21 Oct 2011 04:17:46 +0000

If I understand correctly the current lament is that the assembler source is not interspersed with lines of C/C++ source proceeding its corresponding assembler.

I haven't seen away to provide such with this tool-chain.

jasonk

Fri, 21 Oct 2011 05:19:10 +0000

It should work with the pic32-objdump -S option. However, if I remember correctly, the Arduino/mpide build environment copies the source files to a temp directory before compiling them. This means that you'll need to keep mpide open when you run pic32-objdump or it won't be able to find the source files. Also make sure that the the files are compiled with the -g option.

Edit: Oh, also make sure that you're using the latest linker scripts (*.ld files) from github. I believe that they are also in the latest test build of mpide... I'm not sure if they are in the last main release. The linker scripts are here: https://github.com/chipKIT32/chipKIT32-MAX/tree/master/hardware/pic32/cores/pic32

luxeomni

Sat, 22 Oct 2011 16:22:08 +0000

Ok, finally found it. Yeah, it works using pic32-objdump -- I had problem using it simply because... I picked the wrong board to start with, mpide was compiling to an AVR board(!!) pic32-objdump did not recognize the avr stuff (duh!).

So here's how to do this:

In the IDE, Shift-compile (verify), wait till it stops, pick the location of the .elf file near the bottom of the output.

Find the location of pic32-objdump -- on my system this was located:

<mpide_install_dir>\hardware\pic32\compiler\pic32-tools\bin

then, on the command line, invoke pic32-objdump with various flags to dump interesting stuff, while redirecting the output to a "listing" file:

pic32-objdump -h -S -s -x \Temp\build9075922019932059052.tmp\myproject.cpp.elf > listing.lss

I find the output not as clean as the avr one. Often the source lines are repeated or not registering the good ones. But it is much better than nothing I must say.

Output snippet:

for (int i=1; i<318; i++)

9d00154c:	24150001 	li	s5,1

  {

    setPixel(i,119+(sin(((i*1.13)*3.14)/180)*95));

9d001550:	0f40126a 	jal	9d0049a8 <__floatsisf>
9d001554:	02a02021 	move	a0,s5
9d001558:	00402021 	move	a0,v0
9d00155c:	0f401171 	jal	9d0045c4 <__mulsf3>
9d001560:	02202821 	move	a1,s1
9d001564:	00402021 	move	a0,v0
9d001568:	0f401171 	jal	9d0045c4 <__mulsf3>
9d00156c:	02002821 	move	a1,s0
9d001570:	00402021 	move	a0,v0
9d001574:	0f4011df 	jal	9d00477c <__divsf3>
9d001578:	02402821 	move	a1,s2
9d00157c:	0f4013be 	jal	9d004ef8 <fpsin>
9d001580:	00402021 	move	a0,v0
9d001584:	00402021 	move	a0,v0
9d001588:	0f401171 	jal	9d0045c4 <__mulsf3>
9d00158c:	02602821 	move	a1,s3
9d001590:	00402021 	move	a0,v0
9d001594:	0f4010d6 	jal	9d004358 <__addsf3>
9d001598:	02802821 	move	a1,s4
9d00159c:	0f401294 	jal	9d004a50 <__fixsfsi>
9d0015a0:	00402021 	move	a0,v0
9d0015a4:	00402821 	move	a1,v0
9d0015a8:	0f400b0d 	jal	9d002c34 <_ZN6lcd8setPixelEii>
9d0015ac:	02a02021 	move	a0,s5

jasonk

Sat, 22 Oct 2011 17:49:46 +0000

You might also try dialing back the optimization. With default -O2 optimization level you get a lot of aggressive code transformations that make it harder to correlate assembly instructions back to lines of source code. There's a lot of re-ordering going on. You can change the optimization level in the platforms.txt file for the Max32 or the boards.txt file for the Uno32.