[Top][All Lists]

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

Re: Is there a command that shows the C-code the interpreter creates?

From: Andrew Janke
Subject: Re: Is there a command that shows the C-code the interpreter creates?
Date: Tue, 16 Apr 2019 18:36:45 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 4/16/19 3:12 PM, Ian McCallion wrote:
> On Tue, 16 Apr 2019 at 18:42, GoSim <address@hidden> wrote:
>> The Bison parser implementation file is C code which defines a function named
>> yyparse which implements that grammar. This function does not make a
>> complete C program: you must supply some additional functions. One is the
>> lexical analyzer. Another is an error-reporting function which the parser
>> calls to report an error. In addition, a complete C program must start with
>> a function called main; you have to provide this, and arrange for it to call
>> yyparse or the parser will never run. See Parser C-Language Interface.
>> from:
>> I am assuming this is someting that you do? Somehow you are running the
>> code, can't you just make it available? I will try to solve the differing
>> variable problem and create a m-file compiler which everyone wants.
>> Are you running it line by line? How do you run your c-code?
> I think there is a terminological misunderstanding here. Clearly,
> during Octave execution, functions are parsed when first encountered
> and the parser output is cached as a data structure in memory.  These
> cached data structures could be considered as compiled code (and could
> be the starting point of your compiler) but obviously no-one with
> knowledge of Octave internals thinks this way, whence the
> misunderstanding!
> For what its worth, a decade or so ago I had access to Matlab and
> experimented briefly with their compiler. From memory the compiled C
> code consisted almost entirely of function calls to a large runtime
> library containing entry points to do such things as "add". Could this
> be your first step? It would have no significant performance advantage
> but the basis for further development.
> Cheers... Ian

There are two different Matlab "compiler" products that work in
completely different ways.

The Matlab Compiler, which is used to "compile" and deploy/redistribute
arbitrary Matlab code, doesn't actually compile code at all. It just
bundles up M-code into obfuscated encrypted zip files, and then the
Matlab Runtime executes them by running a headless (no visible desktop
IDE) version of Matlab that is embedded in your application. There's no
performance advantage at all here; in fact, there's some overhead due to
the de-encryption stage at execution time.

The Matlab Coder generates C/C++ programs from M-code programs. It only
supports a subset of Matlab language features and library functions. The
performance advantage is going to be limited to the parts of your code
that do scalar operations, have stateful loops, have non-vectorizable
code, or the like, since most vectorized/array operations are going to
be implemented with basically the same library functions that the M-code
interpreter uses at run time, but it is there. I'm guessing this is the
one you were using, Ian, because of the library entry points like "add"?

There's also the pcode() command, which is an alternate code obfuscation
mechanism. I believe this is purely an obfuscation mechanism, and
doesn't alter how the program is interpreted at runtime, so also offers
no performance or portability advantage.


reply via email to

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