pic c

May 03, 2007 69 Replies

Here's an interesting experiment. Take a working real-life program (in C) and translate the disassembled code into C, and pass it through the compiler again. How does that result compare in size and speed? It's possible that the resultant code is smaller (in which case, you have a new idea for improving your optimisation), but I would expect that you will get a slightly larger result. Even if your compiler has only one byte overhead for the C environment startup (such as setting up the stack pointer), then recursively passing the code through the compiler will give you an example assembly program that cannot be made the same size or smaller by the compiler.

mvh.,

David

67E38B7BB1473422696D7546 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

Didi wrote:

Walter,

thanks for taking the time to do it. I am impressed by the fact that a compiler goes to such optimization depth, I did not expect it. This does not make me more likely to give HLLs yet another chance as my main tool, but I can sense you have done some good work allright.

Dimiter

Please do not use html in newsgroups.

cbfalconer at maineline dot net

Please do not use SIG's of more than 4 lines..... We can all nit pick but it is not productive.

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Actually, in this case it is quite relevant - many newsservers, including mine, cut out html posts. So I can't see Walter's recent html post (though I see his other plain text posts - this must have been a one-off mistake).

I have to say - that's really impressive! Are SKP1 and SKP2 discovered by the peephole optimiser?

cheers, Rich.

rich walker | Shadow Robot Company | rw@shadow.org.uk technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadowrobot.com/hand/overview.shtml

Html to get fixed spacing in the code I included in the message

w..

#pragma memory ROM [2000] @ 0x2000 registera AC;

void main (void) { ENTRY1: AC = 1; // prepare value in B-acc. goto RealEntry; ENTRY2: AC = 2; // prepare another value in b goto RealEntry; ENTRY3: AC = 0; RealEntry: NOP(); }

======== Listing File =========================

2000 07D0 #pragma memory ROM [2000] @ 0x2000 0000 registera AC;

void main (void) {

ENTRY1:

2000 A6 01 LDA #$01 AC = 1; // prepare value in B-acc. 2002 65 SKP2 goto RealEntry; ENTRY2: 2003 A6 02 LDA #$02 AC = 2; // prepare another value in b 2005 A1 SKP1 goto RealEntry; ENTRY3: 2006 4F CLRA AC = 0; RealEntry: 2007 9D NOP NOP(); }

No they are part of a comprehensive branch jump call optimizer. We do full application optimization in our compilers / linkers. There is actually a translation error from Didi's code that I missed until after I posted the code fragment and listing yesterday.

The first "goto RealEntry" should have been goto l2; to chain the goto's. I looked at the generated code was happy with it and posted it. The optimizer chained the skips. The following is the corrected source which generates the same output.

#pragma memory ROM [200] @ 0x200; registera AC;

void main (void) {

ENTRY1: AC = 1; // prepare value in B-acc. goto l2; ENTRY2: AC = 2; // prepare another value in b l2: goto RealEntry; ENTRY3: AC = 0; RealEntry: NOP(); }

Regards,

Walter Banks

-- Byte Craft Limited Tel. (519) 888-6911

formatting link
snipped-for-privacy@bytecraft.com

Thanks. For good HLLs think data base of programmers tricks

w..

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required