<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'><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></body>
</html>