Compiling ML with GCC 6

[nkls]

GCC 6 is released, and the linux distro I'm using (arch linux) has decided to upgrade my compiler. Ignoring the fact that I can downgrade/recompile/use a VM and the risk of using untested GCC versions, there is one major issue with the newest version:

The support for the -fshort-double flag is removed, i.e. demoting all doubles to floats.

As far as I understand, the ABI used by Canon actually has 32-bit doubles instead of 64-bit, so it's not just a flag we are using to make ML faster. I've compiled and tested ML with GCC 6 without the -fshort-double flag and all the basic stuff works, but I suspect that printf("%f") and such are broken, and that the binaries should be larger since there might be extra double precision code in there.

Are there other issues that should be expected? Any way to work around this?

My thought are:
Hope that GCC includes a -m32bit-doubles flag for the ARM architecture in the future.
Create a custom arm-eos ABI and recompile GCC.

It's not a big issue right now since we can use GCC 4/5, but in a few years we might be missing out on any new gcc goodies.

[a1ex]

Canon's printf doesn't support %f, and I don't remember any Canon API called by us that requires floats. This was just an old trick to keep binary small, but now that we can move stuff to modules, I think it's a good idea to refactor the code and get rid of it.

If we move to doubles, I'd say we should get rid of 32-bit floats, as I don't see the point of having both.

[nkls]

I looked into my 100D rom again, and behold:

Code Select Expand


100D:FF6F47F0  BL      unk_double_0x61584 ; [R0,R1] = f(R0,R1,R2,R3)
100D:FF6F47F4  STRD    R0, [SP]
100D:FF6F47F8  ADR     R2, "***** GuiUtilOlcData GUI_GetOlcTvForCode8def UniqueNum(%lf)"
100D:FF6F47FC  MOV     R1, #6
100D:FF6F4800  MOV     R0, #131
100D:FF6F4804  BL      DryosDebugMsg


Seems like the double's are 64-bit after all, and the 100D's prinft support floats.

I can't find any explicit use of double in the src dir, but there are cases where doubles should be used implicitly:

Code Select Expand

src/fps-engio.c:    float frame_duration_orig = 1000.0 / default_fps;
I'm not sure if the -ffast-math flag will demote them here or not.

Anyways, floats are preferable unless high-precision is needed, e.g. more than roughly 7 decimal digits.

[a1ex]

Seems like the double's are 64-bit after all, and the 100D's prinft support floats.

Nice find, all DIGIC 5/6 cameras seem to have it, but not DIGIC 4 ones.

Related: Canon printf has a few non-standard behaviors, so I'd like to use one closer to the C library:
https://bitbucket.org/hudson/magic-lantern/pull-requests/705/use-vsnprintf-from-dietlibc-instead-of/diff

Also 64-bit printf experiments for Lua (not yet fully working):
https://bitbucket.org/hudson/magic-lantern/pull-requests/712/64-bit-integers-in-lua-wip

And I'd also like to use plain C STDIO at some point in the entire ML core (Lua already has it from dietlibc). See also the discussion regarding musl libc in the above PRs.

May I ask for your opinion regarding these changes?

[nkls]

I can't see any problem with either of the changes really.

Using vsnprintf from dietlibc/musl seems like a good idea, especially since Canon's implementation is non-standard and obviously differ between DIGIC 4 and 5. And as mentioned, it's needed for printing 64-bit integers.

Would the stdin/stdout pipe into DryosDebugMsg then? And are you thinking about wrapping the FIO_* functions into FILE's such that we can use fopen and fwrite as well?

[a1ex]

Would the stdin/stdout pipe into DryosDebugMsg then?

Currently, printf goes to ML console. DebugMsg is a bit tricky, since Canon code filters those messages somehow (which is why I'm intercepting the calls to DebugMsg to catch all messages).

And are you thinking about wrapping the FIO_* functions into FILE's such that we can use fopen and fwrite as well?

That's right. The FIO functions behave very much like open (with integer file descriptors) and they seem to be unbuffered (reading individual characters is very slow), so we could have a direct mapping from open/read/write to FIO calls, and a buffered wrapper using fopen/fwrite/fread (for small text files).