Under Review
over 1 year ago

Feature-request: add pre-processor with inline functions to Monkey C

Please consider adding some pre-processor to Monkey C, similar to C.

For example we could have inline functions. It would make developers life much easier: the readability of the code would improve, in many cases the binary size could be decreased  litte-bit.

#inline function myfunc(a) {return App.getApp().getProperty("LeftGoalType") == GOAL_TYPE_FOO || App.getApp().getProperty("RightGoalType") == GOAL_TYPE_FOO;}

or:

#inline myfunc(a) App.getApp().getProperty("LeftGoalType") == GOAL_TYPE_FOO || App.getApp().getProperty("RightGoalType") == GOAL_TYPE_FOO

flocsy🤠
  • 9 months ago

    So far, my biggest limitation is memory limits from code.  About 80% of my memory limit is code, whether from the data engine (that provides all my metrics), the on-device settings, or the licensing system.  Good quality experiences for customers require code - lots of it to handle various cases.  Anything to shrink that footprint and allow more logic will yield better customer experiences.

  • over 1 year ago

    For anyone interested (Gavriel already uses it), I implemented inline functions in my optimizer a while back. It has the bonus of working with normal monkeyc syntax. You just add a (:inline) attribute to the functions, so you can compile with or without the optimizer, and it works either way.

  • over 2 years ago

    Not quite the same, but I've just published an extension which does source-to-source optimization. Currently it just substitutes enums and consts for their values, does simple inlining when the result is a literal, and does some constant folding on the results. It also strips dead code where possible. I'm also planning to do conditional elimination when the condition is constant. so you could do things like:

    (:release)
const DEBUG = false;
(:debug)
const DEBUG = true;
...
function foo() {
  if (DEBUG) {
     System.println("whatever");
  }
  ...
}

    and the code under DEBUG would be fully eliminated in release builds.

    See forums.garmin.com/.../optimizing-monkey-c-code

  • over 3 years ago in reply to flocsy🤠

    and yes, the "selling point" is to provide 1) better project structure, 2) a ton of QoL(Quality of Life) features, and most of all 3) simplicity.

  • over 3 years ago in reply to flocsy🤠

    Well, Gradle isn't familiar with anything but JVM languages and C++, and also it will be a bit of an overkill. I think making a build system from scratch will be better, because it will fit the CIQ ecosystem better, and it will be easier to control how it works. For now this project is in alpha-beta stage, and I am looking forward to add a lot of good features such as remote dependency repositories, code analysing, code pre-processing, plugins, and much more