OpenEuphoria

Re: 64 bit euphoria

• Posted by Daniel Kluss <codepilot at gmail.com> Apr 23, 2005
• 455 views

Robert Craig wrote:
> 
> 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)?
> 
Well the main argument for threads is multiple simultaneous operations, and
in windows, not having to wait for blocking API functions. Multiple processes
with shared memory do provide that, but there is alot of startup delay with
each new process and not with threads. That the story I think.
Dan
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>