OpenEuphoria

Re: 64 bit euphoria

• Posted by Robert Craig <rds at RapidEuphoria.com> Apr 22, 2005
• 459 views

Kenneth Rhodes wrote:
> Robert Craig wrote:
> > 
> > There is hardly any asm in the Euphoria interpreter.
> > The front-end is written in Euphoria.
> > The back-end is 99.9% C. integers would likely become 63 bits 
> > instead of 31. That could lead to some small compatibility issues,
> > e.g. 
> >   if integer(x) then ... 
> > might have a different meaning.
> > 
> > It would probably not bother many people if a 
> > simple declaration of:
> >   integer x
> > now allowed x to be 63 bits in size.
> > 
> > The use of 64-bit pointers internally by the interpreter 
> > would probably not disturb most Euphoria programs. 
> > It would just allow much larger sequences to be created.
> 
> Just how big of a performance hit would the interpreter take
> if that 1% of the front-end code was written in C?

By "1% of the front-end code", 
I assume you mean "0.1% of the back-end code".  

The main use of asm is for things that can't be expressed in C,
such as pushing values onto a machine-level stack,
not so much for speed. There would be little point in trying
to eliminate the few lines of asm. It's just a minor nuisance 
in porting and understanding the code.
 
> Also, it seems that hence forth the 64bit cpus will multi-core,
> so shouldn't threads be a "must" feature for the next version of
> Euphoria?

My main concern with threads isn't how to implement them,
it's what are people going to do with them? Can any of the
pro-thread people give some examples (that couldn't easily be done
some other way, such as the Language Wars technique, or simply
using multiple processes communicating via shared memory)?

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com