Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Philipp Klaus Krause <pkk@sp...>  20121226 22:49:14

Uh, any opinions on the blocktree branch? Should it be merged now? Philipp 
From: Philipp Klaus Krause <pkk@sp...>  20121220 10:50:53

Dear sdcc developers, some time ago I worded on improving stack allocation in sdcc (i.e. placing variables on the stack in a way that tries to minimize stack space). My plan was to implement and compare four or five approaches, and then use the best one. However, I don't have the time to do so in the coming months. One of the approaches was a notsocomplex improvement to the current approach; I call it the blocktree based approach: Currently our allocation assumes that any two local variables that had their address taken, are aggregates or unions might have overlapping liverange. Te longterm solution here would be to have more accurate liverange analysis. The blocktree based approach at least recognizes, when two variables have nonoverlapping scope and thus nonoverlapping live range. This gives a substancial improvement for some cases. A minimal example would be: void f(void) { {struct a a1;} {struct a a2;} } I have done this in the blocktree branch. Currently, there is a remaining issue, which results in some floatingpoint regression tests failing for the z80 port, but I hope to be able to resolve that soon. Philipp 
From: Philipp Klaus Krause <pkk@sp...>  20121221 09:50:58

BEGIN PGP SIGNED MESSAGE Hash: SHA1 The blocktree branch works for me now. Please test it, so we can decide if it is ready for merge. Philipp P.S.: Here are some regression test results for the blocktree branch: Running hc08 regression tests Summary for 'hc08': 0 failures, 6960 tests, 1684 test cases, 2618377 bytes, 44708396 ticks Running s08 regression tests Summary for 's08': 0 failures, 6960 tests, 1684 test cases, 2439001 bytes, 42872252 ticks Running ucgbz80 regression tests Summary for 'ucgbz80': 0 failures, 6959 tests, 1684 test cases, 4783291 bytes, 27393945 ticks Running mcs51stackauto regression tests Summary for 'mcs51stackauto': 0 failures, 7033 tests, 1683 test cases, 2416899 bytes, 270049848 ticks Running ucr2k regression tests Summary for 'ucr2k': 0 failures, 6963 tests, 1684 test cases, 3881909 bytes, 16061531 ticks Running ds390 regression tests Summary for 'ds390': 0 failures, 6995 tests, 1683 test cases, 6539737 bytes, 994927320 ticks Running ucz180 regression tests Summary for 'ucz180': 0 failures, 6963 tests, 1684 test cases, 4104090 bytes, 16866331 ticks Running ucz80 regression tests Summary for 'ucz80': 0 failures, 6965 tests, 1684 test cases, 4245923 bytes, 17208363 ticks For comparison, on the same machine, trunk gives: Running hc08 regression tests Summary for 'hc08': 0 failures, 6960 tests, 1684 test cases, 2618387 bytes, 44708994 ticks Running s08 regression tests Summary for 's08': 0 failures, 6960 tests, 1684 test cases, 2438993 bytes, 42872841 ticks Running ucgbz80 regression tests Summary for 'ucgbz80': 0 failures, 6959 tests, 1684 test cases, 4774965 bytes, 27280328 ticks Running mcs51stackauto regression tests Summary for 'mcs51stackauto': 0 failures, 7033 tests, 1683 test cases, 2417097 bytes, 270051600 ticks Running ucr2k regression tests Summary for 'ucr2k': 0 failures, 6963 tests, 1684 test cases, 3882138 bytes, 16074611 ticks Running ds390 regression tests Summary for 'ds390': 0 failures, 6995 tests, 1683 test cases, 6539573 bytes, 994926768 ticks Running ucz180 regression tests Summary for 'ucz180': 0 failures, 6962 tests, 1683 test cases, 4101661 bytes, 16876231 ticks Running ucz80 regression tests Summary for 'ucz80': 0 failures, 6965 tests, 1684 test cases, 4245982 bytes, 17222338 ticks So in the regression tests, the blocktree branch gives a small improvement over trunk in bytes and ticks. The improvement is really small, which is not surprising: Regression tests mostly are minimal examples to reproduce some bug. The blocktree aprroach, on the other hand is meant to yield big improvements in large functions with many aggregates/unions. BEGIN PGP SIGNATURE Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla  http://enigmail.mozdev.org/ iEYEARECAAYFAlDUMPIACgkQbtUV+xsoLprjkgCgweQCzg1zaPoGaip3S+4Tl4dC dDIAoINPc244KImgBCs3mur8sPl7sybp =5MxV END PGP SIGNATURE 
From: Philipp Klaus Krause <pkk@sp...>  20121226 22:49:14

Uh, any opinions on the blocktree branch? Should it be merged now? Philipp 
From: Erik Petrich <epetrich@iv...>  20121227 08:38:25

On Wed, 26 Dec 2012, Philipp Klaus Krause wrote: > Uh, any opinions on the blocktree branch? Should it be merged now? > > Philipp I have no objections to merging it back to the trunk. Erik 
From: Borut Ražem <borut.razem@gm...>  20121227 08:51:15

On 27. 12. 2012 09:38, Erik Petrich wrote: > > On Wed, 26 Dec 2012, Philipp Klaus Krause wrote: > >> Uh, any opinions on the blocktree branch? Should it be merged now? >> >> Philipp > I have no objections to merging it back to the trunk. > > Erik Me neither. Borut 
Sign up for the SourceForge newsletter:
No, thanks