PicoC -> TCC

Started by a1ex, March 18, 2013, 10:36:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Proof of concept working:

- compile from https://bitbucket.org/hudson/magic-lantern/branch/tcc-scripting
- update the path passed to script_load_symbols in script.c (it's hardcoded for now)
- load script.mo and fpu_emu.mo
- don't load tcc.mo, but place it on the card
- run hello.c and clock.c
- fix the bugs and port the picoc library (library_ml.c)


yes, sobokan is back!

ted ramasola

I'm still hoping arkanoid will be added with a way to keep score.
5DmkII  / 7D


Thank you A1ex... we are close to have fun :)


Well... no comments regarding the scripting API?!


Quote from: a1ex on March 18, 2014, 03:02:51 PM
Well... no comments regarding the scripting API?!

I guess most people around here are either simple user folk ("How do I install it?") or more in-depth people who can write modules or patches if they want something done. Generating a user base for scripts might take some time and a good documentation on the api...

... but nevertheless it's great it's working now (again :-)) and we're looking forward to the mini_iso release :->


didnt find where you asked for comments :)

here are the decision i made in TriX to clearly distinguish beween scripting and internal functions.
maybe they are a good starting point as they were quite good to handle and stable for the script developers.

a) all public scripting API functions are in UpperCamelCase and are documented!
    (if it is an API function, it will only be UpperCamelCase if there is some documentation)
b) all core-internal functions are available as they are named in core, just with "__" prefix (e.g. __internal_function)
c) core-internal functions get replaced step by step with public scripting API

the public scripting API was handled by wrapper-functions that abstracted some internal stuff and called the __internal_function.
any change to internal functions - i.e. adding/removing parameters etc was handled by the wrapper function.
most of the stuff was autogenerated with scripts and made visible using includes.

e.g. see the partially autogenerated util.h file

defines all functions that are visible to the scripting engine

defines the public API with all stuff necessary to make the API sane and call the internal functions.

- all core symbols are visible to scripting engine without any restriction
    therefore core code is accessible - this is an exceptional case and not recommended
   (e.g. bmp_printf is exported into scripting engine as __bmp_printf)
- keeping the API stuff in scripting-headers only, not affecting ML core, only scripts include that API file.
   (e.g. BmpPrintf is a static inline function in scripts/include/bmp.h and calls __bmp_printf)
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: [email protected]
ONLY donate for things we have done, not for things you expect!


Not sure.  :o Is the old PicoC APIs already available to test with new TCC scripting engine?
I think it could be a good start point.


It's available in the PicoC code, waiting for somebody to port it ;)