<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Actually, I suggest that endianness might be removable as a factor.<BR>I know of the following endian-dependentness:<BR>1) bitfield layout<br>This matters "only" so that bitfields can be declared<br>that line up with C to interoperate with.<BR><br>Or, sort of, to interoperate with hardware -- but hardware<br>probably has no endianness, i.e. much hardware can be<br>used with both little and big endian CPUs, and this variability<br>actually makes portabililiy more difficult.<BR><br>I suggest this might not matter and we can pick an arbitrary endianness,<br>at least for the C backend.<BR><br>2) To pick code that picks apart floating point numbers.<br>I suggest this code can be rewritten in C and/or do a runtime<br>detection of endianness, in C or Modula-3.<BR><br>I don't think endianess matters in initialization non-bitfields.<br>Or at least integers. I have to check.<BR> <BR> <BR>Potentially leaving us with just 4: <BR> 32bit posix <BR> 64bit posix <BR> 32bit windows <BR> 64bit windows <BR> <BR> <BR>I know at least one more Target factor to bring up, later (alignment of closures).<BR> <BR><br> - Jay<br><br><br><br> <BR><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Subject: posix/nt/32/64/endian platforms for C backend?<br>Date: Fri, 14 Aug 2015 20:39:10 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr"><div>Now that jmpbuf size is factored out.</div><div>I'm wondering if, for the C backend, we can have a total of 6-8 targets.</div><div><br></div><div><br></div><div> L64_UNIX (little endian 64bit posix/pthreads/Xwindows) </div><div> L32_UNIX (little endian 32bit posix/pthreads/Xwindows) </div><div> B64_UNIX (big endian 64bit posix/pthreads/Xwindows) </div><div> B32_UNIX (big endian 32bit posix/pthreads/Xwindows) </div><div> L64_NT (little endian Win64 threads/gui) </div><div> L32_NT (little endian Win32 threads/gui) </div><div> Xbox 360 is big endian, but nevermind that? </div><div> Windows CE has any big endian targets? </div><div> Call then WIN instead of NT?</div><div> I find "endian" too long and "L" too short. </div><div><br></div><div><br></div><div>No more of this Darwin/OpenBSD/FreeBSD/Solaris/NetBSD/DragonflyBSD stuff?</div><div>For the C backend.</div><div><br></div><div><br></div><div>There is a missing element here.</div><div>What m3core/src/thread/PTHREAD does -- different source files for OpenBSD/FreeBSD/Apple/etc.</div><div><br></div><div><br></div><div>To address those, well, I'd surround each file with an #ifdef, and either</div><div>concatenate them all in git, or in the quake file, if using the C backend</div><div>reference one file that #includes them all -- and says h_file for the constituents or such.</div><div>Thereby making one common quake path at least for the C backend.</div><div>There is slight extra I/O cost implied that the current scheme avoids.</div><div><br></div><div><br></div><div>Longer term I'd like just one target for C, but that might be difficult/impossible.</div><div>Whereas this seems tractable.</div><div><br></div><div><br></div><div>Now, unfortunately, there might be more "cartesian factors".</div><div>e.g. Win32 gui + pthreads. You can do that with Cygwin.</div><div>e.g. has_stack_walker</div><div><br></div><div><br></div><div>But I'm hoping to avoid the last.</div><div>Hopefully has_stack_walker is modeled by higher level</div><div>m3cg calls, at the very least: "call_setjmp_if_no_stack_walker"</div><div>that then flow into the C through #ifdefs.</div><div><br></div><div><br></div><div>Hypothetically:</div><div><br></div><div><br></div><div> C output </div><div> #ifdef _WIN32 .. or whatever platforms have stack walkers, will be most eventually </div><div> #define call_setjmp(buf) (0) </div><div> #else</div><div> #define call_setjmp(buf) setjmp(buf)</div><div> #endif</div><div> </div><div><br></div><div>used within an if. Something like that.</div><div><br></div><div> or even #ifdef __cpluspls and...</div><div><br></div><div><br></div><div>i.e. the frontend can issue "both" sets of CG and later one C compilation</div><div>ignores "half" of them. If we output C++ this is simpler, just use its mechanism.</div><div><br></div><div><br></div><div>Anyway, that is getting ahead of things, the stack walker aspect.</div><div><br></div><div><br></div><div>Introduce those 6 targets?</div><div><br></div><div><br></div><div>Yes I know there is one or two more things in Target.m3 to deal with -- standard structs</div><div>is the same for all C backend. I'll send mail on the other.</div><div><br></div><div><br></div><div>Too confusing?</div><div>Not good enough -- given more than one?</div><div><br></div><div><br></div><div>Keep all the targets so we can write config files that say i386-apple-gcc, amd64-gnu-linux-gcc?</div><div><br></div><div><br></div><div> - Jay</div><br> </div></div> </div></body>
</html>