On Mon, Jul 22, 2013 at 1:43 PM, Nick Wellnhofer <[email protected]> wrote:
> On Jul 22, 2013, at 17:30 , Marvin Humphrey <[email protected]> wrote:
>> On Sun, Jul 21, 2013 at 12:32 PM, Nick Wellnhofer <[email protected]>
>> wrote:
>>> Besides, I already introduced platform-dependent code in cfish_parcel.h. But
>>> we can put the platform-dependent parts in a separate header file like
>>> cfish_platform.h.
>>
>> OK, that works.
>
> This is now implemented in branch 'charmonizer-decoupling'.
Nice. :)
> The endian helpers might be useful for other modules. I'd keep them in
> Clownfish.
Endian helpers are definitely useful. But are they an essential part of the
core Clownfish runtime? JSON parsing is also useful -- is it core to
Clownfish? Isn't Clownfish ambitious enough already?
I could understand if you were making the argument that it's not worth the
effort to move the endian stuff elsewhere, but if you're arguing that it
really belongs where it is, we may have different visions for the scope of the
Clownfish runtime.
Regardless, we still don't need to determine endianness with a probe. Here's
a static inline function for determining endianness which the compiler will
optimize away:
$ cat endian.c
#include <stdio.h>
static inline int
SI_machine_is_big_endian(void) {
union { int i; char chars[sizeof(int)]; } num = {1};
return !num.chars[0];
}
void
foo(void) {
if (SI_machine_is_big_endian()) {
printf("Big!\n");
}
}
$ gcc -fomit-frame-pointer -O2 -c endian.c -o endian.o
$ objdump -d endian.o
endian.o: file format elf32-i386
Disassembly of section .text:
00000000 <foo>:
0: f3 c3 repz ret
$
I'm not sure whether it is undefined behavior according to various C/C++
standards to write to one member in a union then read a different member, but
this code yielded identical results using gcc and g++ on Linux, and clang in
both C and C++ mode on OS X.
Let's go back to your list of platform-specific code the runtime currently
depends on:
* (Emulated) C99 bool type
* (Emulated) C99 integer types
Only an issue on MSVC. Should be doable.
* alloca
This one's tricky, but maybe we can get away with preferring
`__builtin_alloca` except under MSVC.
* Variadic macros
By now, I think we can assume good support for ISO-style variadic macros
except on MSVC.
* Endianness
See above.
* __func__ macro
Defined in C99, and the rest we can deal with via _MSC_VER.
* Symbol visibility
This I'm less sure of, but I think we may be able to switch up around the GCC
version number.
* u64 to double conversion for MSVC6
Seems like it shouldn't be a problem (but I didn't write that code).
Marvin Humphrey
