[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New very simple methodology to create a m-file compiler.

From: GoSim
Subject: Re: New very simple methodology to create a m-file compiler.
Date: Sun, 5 May 2019 14:12:21 -0500 (CDT)

apjanke-floss wrote
> On 5/5/19 12:15 PM, GoSim wrote:
>> If the user wants to compile the code force the user to write code where
>> the
>> variable types are static. The syntax is still m-code syntax. Use your
>> interpreter and check if any variable changes type and then display an
>> error
>> message: 
>> "Variable x changes type from ? to ? at line ?, please restructure your
>> code
>> so that variables never change type to use the Octave compiler"
>> Now just take the compiled segments and put them after eachother, declare
>> the variables at the top or just before they are used in the m-file.
>> This is very user friendly, much easier than your current oct-file method
>> and would attract more users and it is also very simple to implement.
>> Restricting the m-file to not allow variable type changes is no challenge
>> for most scripters, and for the performance gain it's a nobrainer. 
>> So with this method there is no need to automatically make the m-file
>> only
>> have static types or to hack the compiled code. This effort is put on the
>> scripter and it is not much of an effort. 
>> C code is considered to be 7 times faster than java. I consider java to
>> be
>> 5-20 faster than m-code.....you have to implement this.
> This probably wouldn't work, because the types of M-code expressions
> can't be determined at "compile" time. You could do it for variables
> that were initialized from literal expressions in the code. But function
> calls (and due to operator overloading, most non-trivial M-code
> expressions) can generally return any type they want, and that type is
> not determined until run time. And what function actually gets called is
> also not determined until run time, because that depends on the run time
> types of the arguments to the function, and what's on the Octave path.
> So the compiler doesn't generally have access to compile-time type
> information for variables in M-code.
> It's also probably not "simple to implement", because then you're still
> left with the problem of how to translate M-code into more efficient C
> code. Octave's runtime and data structures are _already written in C++_;
> you'd need to find alternate faster ways of implementing their semantics
> in C, and a way of generating that code automatically.
> Cheers,
> Andrew

Functions giving any type will affect the error messages when checking the
static type code but assuming the types are static it still works (give the
user the responsibility of static types). Maybe try to give error messages
when the compiled code is running somehow if there is a type error. Maybe
there are compile code analyzers that can give error messages? How hard can
it be to check variable types?

The other part you write about I don't understand, why should the m-code be
turned into C? The idea is to use the interpreter on every line of the
m-file and create compiled code segments. Putting these segments together
would be the runnable program.

Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

reply via email to

[Prev in Thread] Current Thread [Next in Thread]