[Coco] Speed question

Becker, Gary Gary.Becker at amd.com
Fri Aug 17 23:57:57 EDT 2007


The reason I wanted to do this little study was to prove to me that the CPU is not cycle accurate to the original CPU. It is actually a little more efficient. That was also what I was told. I do not know the cycle count for each instruction of the FPGA implementation. It makes it harder to do things like Sock Master's Boink program. But it does explain why Boink fails.
 
You are exactly correct about the 12.5 reading. I am going to have to repeat this test. I am not sure if I made a mistake when running the test, made a mistake in typing in the results, or have a problem with the FPGA timing.
 
A benchmark would be really good. A mix of all the instructions and addressing modes would give a better indication of real speed.

________________________________

From: coco-bounces at maltedmedia.com on behalf of John Guin
Sent: Fri 8/17/2007 10:31 PM
To: 'CoCoList for Color Computer Enthusiasts'
Subject: Re: [Coco] Speed question



Someone feel free to correct me if I am wrong, but are trials even needed at
this point of the 6809/6803's life?

Can't we (at this point) know exactly what the interpreter will generate
from BASIC?

Don't we also know that instruction BSR takes X cycles on a 6809, LDA takes
Y, for every instruction in the instruction set?

So, couldn't we simply sum up the clock cycles needed for a routine?

Then just take the total cycles needed and compute the number of seconds
needed based on the number of cycles per second the CPU is given at each
speed?

(Logically, you could extend this to any processor if you had the binary
file.  You could get a rough benchmark - minus looping - by simply looking
up the clock cycles the binary needs to run on an AMD vs. an Intel, for
instance. If you just drag/drop an EXE or DLL into Visual Studio, for
instance, you get a disassembly. Then just look up how many cycles each
instruction needs and sum it up*).


This line of reasoning almost holds up to the real world data generated
below.  There is one exception.

Assuming the interpreter is deterministic and will always interpret the
three lines below exactly the same.
There should be a directly linear speed increase when the CPU speed is
increased. 
There is from 879KHz to 1.79MHz.  172 seconds to 86 seconds is twice as fast
timing for a twice as fast CPU.
There is a linear relationship to 4.167 MHz as well.  43% faster in both
seconds needed and CPU speed.

At 12.5 Mhz, the time should 12 seconds. But it's 25 - odd, that's almost
exactly a factor of 2 from what was expected.

At 21.875 MHz, I could expect either 6.8 seconds (4.175/21.875 * 36 seconds
from the 4.167Mhz run) or 14.3 seconds, assuming the 12.5 Mhz run was the
"good run"

So, figuring a stopwatch was used to generate these times, there is only a
one second discrepancy between the expected time for the 21.875 run, and the
expected result from the 12.5 MHz run can be assumed to be off by exactly a
factor of 2.

It also looks like if the 12.5MHz run was ignored, the data is actually
linear (which makes sense, since the interpreter, CPU, etc.. are all held
constant, there is only one CPU, and we are not timing screen drawing, file
IO and the like).

So, is there any reason to suspect the 12.5 MHz run?  Was the chip really
running at half that speed?

Just wondering,
John

*Call it the "ROPE" number - rating of processor efficiency - and run with
it - just give me credit where due! 


** Has anyone developed a benchmark for the Coco?  Anyone want to?


-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Bob Devries
Sent: Friday, August 17, 2007 6:36 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Speed question

Just to be different, I used Basic09 to do that. Here's my source:

DIM A:REAL
D$=DATE$
FOR A=1 TO 10000.
PRINT A
NEXT A
PRINT D$
PRINT DATE$
END

This took 2 minutes 38 seconds on my 1MB Coco3 running NitrOS9 V030206. With

Basic09 running in interpreted mode (I.e. not PACKED). NitrOS9 of course,
runds in high speed mode.

--
Regards, Bob Devries, Dalby, Queensland, Australia

Isaiah 50:4 The sovereign Lord has given me
the capacity to be his spokesman,
so that I know how to help the weary.

website: http://www.home.gil.com.au/~bdevasl
my blog: http://bdevries.invigorated.org/

----- Original Message -----
From: "Becker, Gary" <Gary.Becker at amd.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Saturday, August 18, 2007 7:43 AM
Subject: [Coco] Speed question


>
> I am trying to gauge the speed of the CoCo3FPGA with a real CoCo3. I am
> running a simple BASIC program.
>
> 10 FOR A=0 TO 10000
> 20 PRINT A
> 30 NEXT A
>
> Can someone with a real CoCo type in this simple program, time how long
> it takes, and send me back the results? I would like to see 6809 and
> 6309 runs. It can be run at either the standard speed or the fast speed,
> since it scales nicely. Here is a list of the ones that I have taken.
>
> 0.89 MHz 172 sec.
> 1.79 MHz 86 sec
> 4.167 MHz 36 sec
> 12.5 MHz 25 sec
> 25 MHz 8 sec (really 21.875 MHz)
>
>
> Thanks
>
> Gary
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco




-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 8306 bytes
Desc: not available
URL: <http://five.pairlist.net/pipermail/coco/attachments/20070817/f3e82eae/attachment-0001.bin>


More information about the Coco mailing list