[M3devel] posix/nt/32/64/endian platforms for C backend?

[Jay K]

Actually, I suggest that endianness might be removable as a factor.
I know of the following endian-dependentness:
1) bitfield layout
This matters "only" so that bitfields can be declared
that line up with C to interoperate with.

Or, sort of, to interoperate with hardware -- but hardware
probably has no endianness, i.e. much hardware can be
used with both little and big endian CPUs, and this variability
actually makes portabililiy more difficult.

I suggest this might not matter and we can pick an arbitrary endianness,
at least for the C backend.

2) To pick code that picks apart floating point numbers.
I suggest this code can be rewritten in C and/or do a runtime
detection of endianness, in C or Modula-3.

I don't think endianess matters in initialization non-bitfields.
Or at least integers. I have to check.
 
 
Potentially leaving us with just 4: 
   32bit posix  
   64bit posix  
   32bit windows  
   64bit windows  
 
 
I know at least one more Target factor to bring up, later (alignment of closures).
 

 - Jay



 
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Subject: posix/nt/32/64/endian platforms for C backend?
Date: Fri, 14 Aug 2015 20:39:10 +0000




Now that jmpbuf size is factored out.I'm wondering if, for the C backend, we can have a total of 6-8 targets.

  L64_UNIX (little endian 64bit posix/pthreads/Xwindows)   L32_UNIX (little endian 32bit posix/pthreads/Xwindows)   B64_UNIX (big endian 64bit posix/pthreads/Xwindows)   B32_UNIX (big endian 32bit posix/pthreads/Xwindows)   L64_NT   (little endian Win64 threads/gui)   L32_NT   (little endian Win32 threads/gui)   Xbox 360 is big endian, but nevermind that?   Windows CE has any big endian targets?   Call then WIN instead of NT?  I find "endian" too long and "L" too short. 

No more of this Darwin/OpenBSD/FreeBSD/Solaris/NetBSD/DragonflyBSD stuff?For the C backend.

There is a missing element here.What m3core/src/thread/PTHREAD does -- different source files for OpenBSD/FreeBSD/Apple/etc.

To address those, well, I'd surround each file with an #ifdef, and eitherconcatenate them all in git, or in the quake file, if using the C backendreference one file that #includes them all -- and says h_file for the constituents or such.Thereby making one common quake path at least for the C backend.There is slight extra I/O cost implied that the current scheme avoids.

Longer term I'd like just one target for C, but that might be difficult/impossible.Whereas this seems tractable.

Now, unfortunately, there might be more "cartesian factors".e.g. Win32 gui + pthreads. You can do that with Cygwin.e.g. has_stack_walker

But I'm hoping to avoid the last.Hopefully has_stack_walker is modeled by higher levelm3cg calls, at the very least: "call_setjmp_if_no_stack_walker"that then flow into the C through #ifdefs.

Hypothetically:

 C output  #ifdef _WIN32 .. or whatever platforms have stack walkers, will be most eventually  #define call_setjmp(buf) (0)  #else #define call_setjmp(buf) setjmp(buf) #endif 
used within an if. Something like that.
  or even #ifdef __cpluspls and...

i.e. the frontend can issue "both" sets of CG and later one C compilationignores "half" of them. If we output C++ this is simpler, just use its mechanism.

Anyway, that is getting ahead of things, the stack walker aspect.

Introduce those 6 targets?

Yes I know there is one or two more things in Target.m3 to deal with -- standard structsis the same for all C backend. I'll send mail on the other.

Too confusing?Not good enough -- given more than one?

Keep all the targets so we can write config files that say i386-apple-gcc, amd64-gnu-linux-gcc?

 - Jay
 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150816/721a74db/attachment-0002.html>