Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #1330 > unrolled thread

View assembly output for C code

Back to article view | Back to comp.sys.apple2.programmer

Contents

  View assembly output for C code AppleIIGSMarc <appleiigsmarc@gmail.com> - 2014-09-30 19:07 -0700
    Re: View assembly output for C code Kelvin Sherlock <email@domain.com> - 2014-10-04 10:53 -0400
      Re: View assembly output for C code AppleIIGSMarc <appleiigsmarc@gmail.com> - 2014-10-04 09:31 -0700
        Re: View assembly output for C code AppleIIGSMarc <appleiigsmarc@gmail.com> - 2014-10-04 17:33 -0700
          Re: View assembly output for C code Antoine Vignau <antoine.vignau@laposte.net> - 2014-10-05 03:55 -0700
          Re: View assembly output for C code Michael J. Mahon <mjmahon@aol.com> - 2014-10-05 17:19 -0500
            Re: Learning Assembly Language markpmlim@yahoo.com.sg - 2014-10-05 18:26 -0700
            Re: View assembly output for C code "Bill Buckels" <bbuckels@mts.net> - 2014-10-05 20:29 -0500
              Re: View assembly output for C code Michael J. Mahon <mjmahon@aol.com> - 2014-10-05 23:10 -0500
                Re: View assembly output for C code "Bill Buckels" <bbuckels@mts.net> - 2014-10-06 04:45 -0500
                  Re: View assembly output for C code AppleIIGSMarc <appleiigsmarc@gmail.com> - 2014-10-13 11:22 -0700
                    Re: View assembly output for C code Antoine Vignau <antoine.vignau@laposte.net> - 2014-10-14 13:08 -0700
                      Re: View assembly output for C code AppleIIGSMarc <appleiigsmarc@gmail.com> - 2014-10-14 17:29 -0700
                        Re: View assembly output for C code Antoine Vignau <antoine.vignau@laposte.net> - 2014-10-14 22:38 -0700

#1330 — View assembly output for C code

I was wondering if anyone had any useful advice on how best to view the assembly code that Orca/C generates for any given function.  There doesn't appear to be a compiler option to output the generated assembly code, so I currently only know of two ways to view it.  First is to compile the code with an asm 'brk' statement placed in front of the code I'd like to examine and then use GSBug to look at it.  This means I must recompile each time I want to examine a different chunk of code.  The other is to run my program through the Orca/Disassembler which lets me see everything at once, but pretty much merges all the code into one gigantic listing.

Neither method really allows me to easily see the start and end of individual functions.  I realize this may be as good as it gets, but I figured it couldn't hurt to ask and see if anyone knew of a better way or had any tips on how to make it easier.

Thanks!

[toc] | [next] | [standalone]

#1333

Disassemble the intermediate (.A) object files.  They're also OMF so 
dumpobj or orca/disassembler can handle them.

#pragma lint -1
#pragma optimize -1

#include <stdio.h>

int main(int argc, char **argv)
{
  puts("hello, world!");
  return 0;
}

Segment name  : main

00003F 000000 |          LONGA ON
00003F 000000 |          LONGI ON
00003F 000000 | main     START
00003F 000000 |          PHA
000041 000001 |          TSC
000042 000002 |          PHD
000043 000003 |          TCD
000044 000004 |          PEA   ((main+$00000023)|$FFFFFFF0)
000053 000007 |          PEA   (main+$00000023)
00005D 00000A |          JSL   puts
000068 00000E |          STZ   $01
00006B 000010 |          LDA   $04
00006D 000012 |          STA   $0A
00006F 000014 |          LDA   $03
000071 000016 |          STA   $09
000073 000018 |          LDY   $01
000075 00001A |          PLD
000076 00001B |          TSC
000077 00001C |          CLC
000078 00001D |          ADC   #$0008
00007B 000020 |          TCS
00007C 000021 |          TYA
00007D 000022 |          RTL
00007E 000023 |          PLA
000080 000024 |          ADC   $6C
000082 000026 |          JMP   ($2C6F)
000085 000029 |          JSR   $6F77
000088 00002C |          ADC   ($6C)
00008A 00002E |          STZ   $21
00008C 000030 |          BRK   ???
00008E 000032 |
00008F 000032 |          END



On 2014-10-01 02:07:35 +0000, AppleIIGSMarc said:

> I was wondering if anyone had any useful advice on how best to view the 
> assembly code that Orca/C generates for any given function.  There 
> doesn't appear to be a compiler option to output the generated assembly 
> code, so I currently only know of two ways to view it.  First is to 
> compile the code with an asm 'brk' statement placed in front of the 
> code I'd like to examine and then use GSBug to look at it.  This means 
> I must recompile each time I want to examine a different chunk of code. 
>  The other is to run my program through the Orca/Disassembler which 
> lets me see everything at once, but pretty much merges all the code 
> into one gigantic listing.
> 
> Neither method really allows me to easily see the start and end of 
> individual functions.  I realize this may be as good as it gets, but I 
> figured it couldn't hurt to ask and see if anyone knew of a better way 
> or had any tips on how to make it easier.
> 
> Thanks!

[toc] | [prev] | [next] | [standalone]

#1334

On Saturday, October 4, 2014 7:53:36 AM UTC-7, Kelvin Sherlock wrote:
> Disassemble the intermediate (.A) object files.  They're also OMF so 
> 
> dumpobj or orca/disassembler can handle them.
> 
> 
> 
> #pragma lint -1
> 
> #pragma optimize -1
> 
> 
> 
> #include <stdio.h>
> 
> 
> 
> int main(int argc, char **argv)
> 
> {
> 
>   puts("hello, world!");
> 
>   return 0;
> 
> }
> 
> 
> 
> Segment name  : main
> 
> 
> 
> 00003F 000000 |          LONGA ON
> 
> 00003F 000000 |          LONGI ON
> 
> 00003F 000000 | main     START
> 
> 00003F 000000 |          PHA
> 
> 000041 000001 |          TSC
> 
> 000042 000002 |          PHD
> 
> 000043 000003 |          TCD
> 
> 000044 000004 |          PEA   ((main+$00000023)|$FFFFFFF0)
> 
> 000053 000007 |          PEA   (main+$00000023)
> 
> 00005D 00000A |          JSL   puts
> 
> 000068 00000E |          STZ   $01
> 
> 00006B 000010 |          LDA   $04
> 
> 00006D 000012 |          STA   $0A
> 
> 00006F 000014 |          LDA   $03
> 
> 000071 000016 |          STA   $09
> 
> 000073 000018 |          LDY   $01
> 
> 000075 00001A |          PLD
> 
> 000076 00001B |          TSC
> 
> 000077 00001C |          CLC
> 
> 000078 00001D |          ADC   #$0008
> 
> 00007B 000020 |          TCS
> 
> 00007C 000021 |          TYA
> 
> 00007D 000022 |          RTL
> 
> 00007E 000023 |          PLA
> 
> 000080 000024 |          ADC   $6C
> 
> 000082 000026 |          JMP   ($2C6F)
> 
> 000085 000029 |          JSR   $6F77
> 
> 000088 00002C |          ADC   ($6C)
> 
> 00008A 00002E |          STZ   $21
> 
> 00008C 000030 |          BRK   ???
> 
> 00008E 000032 |
> 
> 00008F 000032 |          END
> 
> 
> 
> 
> 
> 
> 
> On 2014-10-01 02:07:35 +0000, AppleIIGSMarc said:
> 
> 
> 
> > I was wondering if anyone had any useful advice on how best to view the 
> 
> > assembly code that Orca/C generates for any given function.  There 
> 
> > doesn't appear to be a compiler option to output the generated assembly 
> 
> > code, so I currently only know of two ways to view it.  First is to 
> 
> > compile the code with an asm 'brk' statement placed in front of the 
> 
> > code I'd like to examine and then use GSBug to look at it.  This means 
> 
> > I must recompile each time I want to examine a different chunk of code. 
> 
> >  The other is to run my program through the Orca/Disassembler which 
> 
> > lets me see everything at once, but pretty much merges all the code 
> 
> > into one gigantic listing.
> 
> > 
> 
> > Neither method really allows me to easily see the start and end of 
> 
> > individual functions.  I realize this may be as good as it gets, but I 
> 
> > figured it couldn't hurt to ask and see if anyone knew of a better way 
> 
> > or had any tips on how to make it easier.
> 
> > 
> 
> > Thanks!

Thanks!  That worked perfectly with Orca's GUI disassembler and is exactly what I needed.  Each function shows up separately under the Segments menu and labels and global variables show up in the code.  I guess it's still a little buggy (the computer locks up if I try to open a particular .a file), but it's still extremely useful.  

Thanks for the help,
Marc

[toc] | [prev] | [next] | [standalone]

#1335

Wow, it's been really interesting to look at the code that the C compiler generates.  Even with all optimizations turned on there are still lots of things that are unnecessary or redundant.  For instance, I tried compiling this function:  

void DoStuff(void)
{
   int i=0;
   for (i=0; i<42; i++)
   { 
   }
   return;
}

Even with all optimizations turned on, this still generates code.  I guess I'm not too surprised by that, but I didn't expect to see the compiler do things such as initialize i to zero twice in a row:

0007:   ...
0008:   stz  $05
000A:   stz  $05
000C:   ...

It's also doing things such as this:
000F:   ...
0011:   lda  DESIRED_COUNT
0014:   sec
0015:   sbc  $07
0017:   beq  $0020     ;Why not jump straight to $002C?
0019:   ...

001E:   ...
0020:   bra  $002C
0022:   ...

002A:   ...
002C:   lda  $09
002E:   sta  $01
0030:   ...

It's been a fun learning experience and it's going to be interesting to go through the rest of my code and see what I can do to speed it up (either by rewriting it or moving it to assembly).  

[toc] | [prev] | [next] | [standalone]

#1336

I agree with you, code can be later optimized but that takes time.

I once rewrote parts of JPEG.View, a great JPEG/JFIF viewer for the IIgs and the speed increase was tremendous!

Antoine

[toc] | [prev] | [next] | [standalone]

#1337

AppleIIGSMarc <appleiigsmarc@gmail.com> wrote:
> Wow, it's been really interesting to look at the code that the C compiler
> generates.  Even with all optimizations turned on there are still lots of
> things that are unnecessary or redundant.  For instance, I tried compiling this function:  
> 
> void DoStuff(void)
> {
>    int i=0;
>    for (i=0; i<42; i++)
>    { 
>    }
>    return;
> }
> 
> Even with all optimizations turned on, this still generates code.  I
> guess I'm not too surprised by that, but I didn't expect to see the
> compiler do things such as initialize i to zero twice in a row:
> 
> 0007:   ...
> 0008:   stz  $05
> 000A:   stz  $05
> 000C:   ...
> 
> It's also doing things such as this:
> 000F:   ...
> 0011:   lda  DESIRED_COUNT
> 0014:   sec
> 0015:   sbc  $07
> 0017:   beq  $0020     ;Why not jump straight to $002C?
> 0019:   ...
> 
> 001E:   ...
> 0020:   bra  $002C
> 0022:   ...
> 
> 002A:   ...
> 002C:   lda  $09
> 002E:   sta  $01
> 0030:   ...
> 
> It's been a fun learning experience and it's going to be interesting to
> go through the rest of my code and see what I can do to speed it up
> (either by rewriting it or moving it to assembly).

It's disappointing that "optimization" doesn't seem to do even simple
peephole transformations. 
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1338 — Re: Learning Assembly Language

To AppleIIGSMarc

I suppose eventually you would want to code in 65816 assembly language. Let me relate some of my experiences learning basic assembly language on the various platforms.

One important idea: you need to learn how to setup stack frames.

An understanding of the various C constructs and their 65816 assembly language equivalents would be very helpful. For example, if you want to implement a shell sort, you must get the algorithm right first by writing it in C (or some other high level language). Then manually translate the sorting function into 65816 code. Of course, you may prefer to work with the code generated by the ORCA/C compiler.

NB. There is no separate instruction for signed comparison for 65816. The ORCA/M package has macros (CMPx) for this purpose.

Regards.

Mark

[toc] | [prev] | [next] | [standalone]

#1339

"Michael J. Mahon" <mjmahon@aol.com> wrote:
>It's disappointing that "optimization" doesn't seem to do even simple 
>peephole transformations.

It's an old compiler. Look at the difference between Aztec C and cc65...

Another issue is that some commercial products with a captive audience 
didn't even care... you were in a silo where APDA ruled. You weren't alone. 
Lots of silos.

Look at the difference between Microsoft C++ Version 7 and Borland C++ 
version 3.1 in MS-Windows in 1992.

Even today Win32 Microsoft C (comes with Visual Studio) compared to MinGW 
Win32 which compiles to a fraction of the size using the identical API.

It is simply about taking money. I gladly paid. I had to work.

I talked about rewritng byteworks Orca C as a commandline cross-compiler but 
seriously I haven't the skill.

Bill

[toc] | [prev] | [next] | [standalone]

#1340

"Bill Buckels" <bbuckels@mts.net> wrote:
> "Michael J. Mahon" <mjmahon@aol.com> wrote:
>> It's disappointing that "optimization" doesn't seem to do even simple 
>> peephole transformations.
> 
> It's an old compiler. Look at the difference between Aztec C and cc65...
> 
> Another issue is that some commercial products with a captive audience 
> didn't even care... you were in a silo where APDA ruled. You weren't alone. 
> Lots of silos.
> 
> Look at the difference between Microsoft C++ Version 7 and Borland C++ 
> version 3.1 in MS-Windows in 1992.
> 
> Even today Win32 Microsoft C (comes with Visual Studio) compared to MinGW 
> Win32 which compiles to a fraction of the size using the identical API.
> 
> It is simply about taking money. I gladly paid. I had to work.
> 
> I talked about rewritng byteworks Orca C as a commandline cross-compiler but 
> seriously I haven't the skill.
> 
> Bill

I see what you mean, Bill. But if you're not going to make some effort, why
even  offer an "optimize" option?

Peephole techniques have been well known since the 60's--it's not brain
surgery. ;-)
-- 
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon

[toc] | [prev] | [next] | [standalone]

#1342

"Michael J. Mahon" <mjmahon@aol.com> wrote:
>I see what you mean, Bill. But if you're not going to make some effort, why
even  offer an "optimize" option?

My contrary argument is weaker than usual. Any chance of asking Mike 
Westerfield what really happened here?

>Peephole techniques have been well known since the 60's--it's not brain 
>surgery. ;-)

Agreed.

Bill 

[toc] | [prev] | [next] | [standalone]

#1347

So the GUI version of the disassembler has been working pretty well for me and it's been tremendously helpful in understanding how the compiler generates code and allowing me to see what I can do to improve it.  However, out of curiosity and wanting to explore all possible options, I decided to check out the text based disassembler and I simply cannot figure out out to get it to display the code correctly.   No matter what file I open, I get a single line of code at the top of the screen with a white line underneath it that spans the width of the screen.  At the bottom of the screen I get the command prompt and one line of buffer above it.  The 22 lines in the middle of the screen are completely blank, although if I bring up the help screen it fills the screen as expected.  The line of code that displays at the top of the screen will change as I use the arrow keys to move through the code, but it never shows more than a single line of code at a time.

The docs for the text-based disassembler are pretty light, and I don't see anything in there that would explain what's going on.  I've tried deleting the disasm.config file, reinstalling Orca from Opus ][ Collection, and booting from a completely different hard drive image, but I always get the same results.  This surely works for everyone else, right?  Does anyone have any ideas?  Thanks!

[toc] | [prev] | [next] | [standalone]

#1348

use The flaming bird disassembler available on brutaldeluxe.fr / French underground

http://brutaldeluxe.fr/products/french/

av

[toc] | [prev] | [next] | [standalone]

#1350

On Tuesday, October 14, 2014 1:08:43 PM UTC-7, Antoine Vignau wrote:
> use The flaming bird disassembler available on brutaldeluxe.fr / French underground
> 
> 
> 
> http://brutaldeluxe.fr/products/french/
> 
> 
> 
> av

I tried it out for a bit and it looks really nice.  After a quick Google search, I noticed that you posted a link to an English translation of the documentation a few years ago.  However, that link no longer works and I wasn't able to find it on your site.  Do you still happen to have that file?  Thanks.

[toc] | [prev] | [next] | [standalone]

#1351

On Wednesday, October 15, 2014 2:29:45 AM UTC+2, AppleIIGSMarc wrote:
> I tried it out for a bit and it looks really nice.  After a quick Google search, I noticed that you posted a link to an English translation of the documentation a few years ago.  However, that link no longer works and I wasn't able to find it on your site.  Do you still happen to have that file?  Thanks.

Hum... I think I have to sort some folders...

Translated items @ http://www.brutaldeluxe.fr/products/french/tfbd/

av

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web