[Coco] [Color Computer] Re: OS-9 as Replacement for DECB.

[jdaggett at gate.net]

James

What I was trying to say and the point seems to be missed is this:

When the interpreter sees and expression like the following as a strting: 

10 A=5+53

the line number 10 is converted to binary then the numeric expression is converted 
to floating point. Thus the ascii character $35 and character string $35, $33 are 
converted to floating point numbers and then added and then converted to an ascii 
string. Yes this does take time. 

All trig functions are converted to radians, then to floating point numbers and 
evaluated. Trig functions are evaluated with a modified Taylor series using five 
cofficients. Just looking at what it takes to just calculate the sin of a30 degress may 
take several hundreds of microseconds. Most of the time is normalizing the 
numbers and result. 

Now variables and array pointers are treated differently. Those are interger binary 
numbers. Yes loop counters are binary integers. Line numbers are also binary 
integer. Yes the Coco 3 interpreter does both interger math and floating point math. 

A VHDL 6809 with a FPU incorparated within would not fit in a 300K gate part. The 
CPU would but a decent FPU will take up to 300K gates on its own. Especially if you 
want extended precision, which is 80 bit FP #. While you can split the two it is 
always more preferable to integrate the CPU and FPU together. 

For a Coco FPU, there are FP routines for a PIC contrroller that already exist. Since 
the PIC or even an AVR can run at five to ten times the buss speeds of the current 
Coco 3 CPU,  the time to do one FP calculation is cut from 1 mSec to as short as 
25 microseconds. I would take that any day. Interfacing may prove to be a small 
challenge but nothing to difficult. 

james 

On 2 Sep 2005 at 8:34, James Diffendaffer wrote:

To:             	ColorComputer at yahoogroups.com
From:           	"James Diffendaffer" <jdiffendaffer at yahoo.com>
Date sent:      	Fri, 02 Sep 2005 08:34:40 -0000
Copies to:      	Subject:        	[Coco] [Color Computer] Re: OS-9 as 
Replacement for DECB.
Send reply to:  	CoCoList for Color Computer Enthusiasts 
<coco at maltedmedia.com>
	<mailto:coco-
request at maltedmedia.com?subject=unsubscribe>
	<mailto:coco-
request at maltedmedia.com?subject=subscribe>

> >> The Coco 3 uses floating point for all its math even addition. All
> >> the floating point math can be off loaded from the interpreter onto
> >> a PIC or and AVR at more efficiency to RSBASIC. Most of the
> >> routines are bogged down by this. 
> >> 
> >> james
> >> 
> >
> >	Anyone know what percent of of math in ROM BASIC programs
> > actually 
> > needs the dynamic range of floating point math?
> >
> >					kevin
> 
> Actually, most ROM routines use integers in the end.  It's not like
> you can have 100.75 items in an array or turn on pixel 55.005,34.222.
> And most loop counters step by an integer, not a floating point value.
> 
> Every time a variable is used by one of these routines it must be
> converted from float to integer.  Very time consuming!  Adding
> integers to CoCo Basic would yield a huge speedup *if* you were to
> define variables as integers where possible!  Even routines that do
> use floats like printing require some sort of conversion.  Only
> floating point math between variables wouldn't involve some sort of
> conversion.
> 
> When you use a fixed value rather than a variable in your source code
> such as "PSET(4,55)" the values are strings and the interpreter must
> convert them to integers... or worse... to floats and then to integers
> if you do something like this "PSET(X+5,55)".  That's why a partially
> compiled (P Code) interpreter would be much faster.
> 
> Just look at some BASIC source code and stop and think how many times
> per line that stuff takes place!!!  Add other interpreter overhead
> like garbage collection, keyboard polling and what not and you end up
> bringing a fast machine to a crawl.  Theres no reason a replacement
> Basic couldn't run many times faster than ECB.
> 
> An external floating point chip *might* speed things up but the CPU
> has to tell it what it wants it to do, then has to wait for it to do
> it and then grab the result... I'm thinking there's too much overhead
> to really speed things up that way.  At least not for the work
> involved.
> 
> A VHDL 6809 replacement with some new instructions supporting floating
> point would be different.  Those are executed inline and don't require
> the overhead so they would definately speed things up.
> 
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor
> --------------------~--> Fair play? Video games influencing politics.
> Click and talk back!
> http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/CFFolB/TM
> --------------------------------------------------------------------~-
> > 
> 
> Brought to you by the 6809, the 6803 and their cousins! 
> Yahoo! Groups Links
> 
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/ColorComputer/
> 
> <*> To unsubscribe from this group, send an email to:
>     ColorComputer-unsubscribe at yahoogroups.com
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco