You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • @fanoush that's neat! I think I'd been put off doing it because I was concerned there were only 3 bits for the argument type, and we already had 7 arg types - but we do have one free so we might as well use it :)

    I've just merged that in...

    it looks like the code in jsnative.c and jswrap_espruino.c could be ifdef-ed by __ARM_PCS

    Which bit?

    @FManga thanks for the d2f implementation - it's a bit odd it's not getting picked up by the linker automatically if it's in the file though. There's something odd going on there as for Espruino it appears to work fine for us: https://github.com/espruino/Espruino/blob/master/src/jswrap_math.c#L33

  • Which bit?

    well the code with union of int32 and float will work only on arm with soft or softfp convention so I am not sure what to do when building for other platforms (like linux or esp32) so for those I was thinking about keeping just the enum but ifdef everything out including the nativeCallGetCType "float" line. Or keep it in nativeCallGetCType but fail at runtime when someone calls E.nativeCall on such platforms with float argument in signature - then the ifdef can be only for the 'case JSWAT_FLOAT32:' bits. however for RELEASE=1 it will fail silently. I am not actually sure for which platforms the Inline C and/or E.nativeCall is implemented. So maybe it is Ok to keep it as is. I don't know :-)

    @FManga thanks for the d2f implementation - it's a bit odd it's not getting picked up by the linker automatically if it's in the file

    can be C vs C++ name mangling, Inline C is actually compiled as C++ source (unlike espruino jswrap_math.c) so something like wrapping it into extern "C" { } could work. EDIT: oh it is already there!! so I don't know

About

Avatar for Gordon @Gordon started