Small Device C Compiler suite

Patches item #1579953, was opened at 2006-10-18 19:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=1579953&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Miller (pmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: asx8051 -I

Initial Comment:
This patch adds a -I (inclode) command line options,
just like the adcc -I command line option, to add an
include file search path to the assembler.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=1579953&group_id=599

Please, don't startle when you see the regression test tick counts for th=
e
mcs51 as of today. I've increased the baudrate from 9600 to 57600 and now
the outcome is about 5x less ticks! All output is framework related and
not functional to the tests anyway. I call it overhead.

Patches item #1579953, was opened at 2006-10-18 21:31
Message generated for change (Settings changed) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=1579953&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Peter Miller (pmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: asx8051 -I

Initial Comment:
This patch adds a -I (inclode) command line options,
just like the adcc -I command line option, to add an
include file search path to the assembler.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=1579953&group_id=599

Maarten Brock schrieb:
> Please, don't startle when you see the regression test tick counts for the
> mcs51 as of today. I've increased the baudrate from 9600 to 57600 and now
> the outcome is about 5x less ticks! All output is framework related and
> not functional to the tests anyway. I call it overhead.

Hey - such a subtle change and this effect: time, $, trees - this is _really_ cool!

Would serial port mode 0 (1/12 sysclk) be an option too?

Greetings,

Frieder

Mode 0 will not help anymore. The timer is now set at 
0xFF so it overflows every tick. That is 10 ticks per 
byte. Calling putchar, checking TI and loading SBUF will 
consume those 10 ticks.

Running the mcs51 regression test reduced from 13 to 10 
minutes on my system too.

> Maarten Brock schrieb:
> > Please, don't startle when you see the regression test tick counts for the
> > mcs51 as of today. I've increased the baudrate from 9600 to 57600 and now
> > the outcome is about 5x less ticks! All output is framework related and
> > not functional to the tests anyway. I call it overhead.
> 
> Hey - such a subtle change and this effect: time, $, trees - this is _really_ cool!
> 
> Would serial port mode 0 (1/12 sysclk) be an option too?
> 
> Greetings,
> 
> Frieder
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sdcc-devel mailing list
> sdcc-devel@...
> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>

Hello Maarten,

Maarten Brock schrieb:
> Mode 0 will not help anymore. The timer is now set at 
> 0xFF so it overflows every tick. That is 10 ticks per 
> byte. Calling putchar, checking TI and loading SBUF will 
> consume those 10 ticks.

I just gave it a run with mode 0:


--- support/regression/ports/mcs51/support.c.orig       2006-10-18 00:23:21.000000000 +0200
+++ support/regression/ports/mcs51/support.c    2006-10-19 21:55:45.000000000 +0200
@@ -6,7 +6,7 @@ _sdcc_external_startup (void)
 {
   /* copied from device/examples/mcs51/simple2/hi.c */
   PCON = 0x80;  /* power control byte, set SMOD bit for serial port */
-  SCON = 0x40;  /* serial control byte, mode 1, RI _NOT_ active */
+  SCON = 0x00;  /* serial control byte, mode 0, RI _NOT_ active */
   TMOD = 0x21;  /* timer control mode, byte operation */
   TCON = 0;     /* timer control register, byte operation */



it uses about 60 million ticks instead of 150 million ticks
but it actually lasts longer: two tests (setjmp.c and
critical.c) run into timeout.

> Running the mcs51 regression test reduced from 13 to 10 
> minutes on my system too.

Thats long. Running the tests in linux under VMware or
http://en.wikipedia.org/wiki/QEMU
on your Windows host instead of on your good old
linux machine might be quicker.
(Your new test finishes in about 2m20s (athlon 2800+) here)

Greetings,
Frieder

Maarten,

Frieder's answer reminded me that you once complained that reg. tests 
run very slow in cygwin environment.
If I remember well I had the same experience, but it was much better 
when running reg. tests compiled as native WIN32 (mingw) application. 
Did you try that?

P.S.: I'm also using a virtual machine running Linux guest on Windows host.

Borut


Frieder Ferlemann wrote:
> ... Running the tests in linux under VMware or
> http://en.wikipedia.org/wiki/QEMU
> on your Windows host instead of on your good old
> linux machine might be quicker.
> (Your new test finishes in about 2m20s (athlon 2800+) here)
>

> Please, don't startle when you see the regression test tick counts for the
> mcs51 as of today. I've increased the baudrate from 9600 to 57600 and now
> the outcome is about 5x less ticks! All output is framework related and
> not functional to the tests anyway. I call it overhead.
Many thanks for your optimizations, they make testing life much easier.

I'm unhappy about the summary for quite some time. Today I made a small
test: first I run the regression tests with today's svn:
> Summary for 'mcs51': 0 failures, 4843 tests, 630 test cases, 889592 bytes,
143378976 ticks

Then I added an empty dummy test (see below) in order to measure the
overhead:
> Summary for mcs51: 0 failures, 4844 tests, 631 test cases, 890706 bytes,
143616060 ticks

The number of bytes increased by 1114 bytes, the number of ticks increased
by 237084.

Ok, now we know the overhead of an empty test. Now let's calculate the
average size and tick count:
889592 / 630 = 1412 (bytes)
143378976 / 630 = 227600 (ticks)

In this simple approach the average tick count is even smaller than the
number of additional ticks needed by dummy.c. Most propably it's necessary
to add more tests to evaluate numbers for a "test" and a "test case". A
further (not exact) result is that 80% of the average test size (1114 /
1412) is overhead.

The numbers in the regression test results are obviously mostly determined
by the overhead. Therefore they are not very usefull when evaluating
optimizations. I would love to see the numbers in the result minus the
overhead. I'll supply the dummy tests and the correct mathematics, if
somebody helps me with the python script "collate-results.py".

Bernhard


/* dummy test for evaluation of overhead
 */
#include <testfwk.h>

void
testDummy(void)
{
  ASSERT(1);
}

Borut,

> Frieder's answer reminded me that you once complained that reg. tests 
> run very slow in cygwin environment.
> If I remember well I had the same experience, but it was much better 
> when running reg. tests compiled as native WIN32 (mingw) application. 
> Did you try that?

I'm not sure I understand what you mean. I recompiled 
SDCC with the script sdcc_cygwin_mingw32 under cygwin 
and then tried to run regression tests under cygwin. It 
failed because it could not find <sys/wait.h>.

I then changed the Makefile for the regression tests and 
removed -mno_cygwin from CC and tried again. This made 
timeout.c compile ok, but all simulations then timed 
out. I even tried to double the timeout value, but to no 
avail.

Am I going the wrong way?

> P.S.: I'm also using a virtual machine running Linux guest on Windows host.

Maybe I should just forget about cygwin and go for the 
virtual machine approach too.

Greetings,
Maarten

Hi,

Bernhard Held schrieb:
> The numbers in the regression test results are obviously mostly determined
> by the overhead. Therefore they are not very usefull when evaluating
> optimizations. I would love to see the numbers in the result minus the
> overhead. I'll supply the dummy tests and the correct mathematics, if
> somebody helps me with the python script "collate-results.py".

An intermediate solution could be to show the
diff of two consecutive regression test logs
in the snapshot page if (and only if:) the
diff returns 1.

[shameless advertising on]
"diff --unified=0" would look like:

--- regression-test-i386-unknown-linux2.3-20061109-4467.log     2006-11-10 10:48:21.000000000 +0100
+++ regression-test-i386-unknown-linux2.3-20061110-4470.log     2006-11-10 10:48:26.000000000 +0100
@@ -383 +383 @@
-Summary for 'mcs51': 0 failures, 4843 tests, 630 test cases, 881158 bytes, 64024092 ticks
+Summary for 'mcs51': 0 failures, 4843 tests, 630 test cases, 820806 bytes, 63074508 ticks
@@ -511 +511 @@
-Summary for 'mcs51-stack-auto': 0 failures, 4843 tests, 630 test cases, 998157 bytes, 69437808 ticks
+Summary for 'mcs51-stack-auto': 0 failures, 4843 tests, 630 test cases, 916618 bytes, 67340448 ticks

..
[shameless advertising off]


Greetings,

Frieder

Patches item #1579668, was opened at 2006-10-18 15:14
Message generated for change (Comment added) made by maartenbrock
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=1579668&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: Peter Miller (pmiller)
>Assigned to: Maarten Brock (maartenbrock)
Summary: asx8051 -I

Initial Comment:
This patch adds a -I (inclode) command line options,
just like the adcc -I command line option, to add an
include file search path to the assembler.

----------------------------------------------------------------------

>Comment By: Maarten Brock (maartenbrock)
Date: 2007-04-20 20:36

Message:
Logged In: YES 
user_id=888171
Originator: NO

Thanks,

Patch applied with minor changes in SDCC 2.6.5 #4760.

But don't know what to do with updates to sdcc-2.5.0/debian/asxxxx.1 as we
do not create debian packages.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300599&aid=1579668&group_id=599