[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: Andrew Janke
Subject: Re: New very simple methodology to create a m-file compiler.
Date: Sun, 5 May 2019 13:10:40 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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.


reply via email to

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