<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'> Currently the C output is target-specific. <br> I want to generate one set of C output for all platforms. <br> So you just download one portable "m3.tar.gz".<br><br><br> Is there agreement on this goal? <br> Others might help? <br> And no generally object to my changes to make it so? <br><br><br>Here are the obstacles to getting there as I understand:<br> win32 vs. posix (or more generally, logic on the m3makefile's that change what source is compiled) <br> jmpbuf size <br> endian <br> word size/layout <br><br><br>I believe the "layout rules" (padding/alignment) are now fairly target independent,<br>EXCEPT that endianness and word size vary.<br>That is, interop with C has been compromised.<br><br><br>jmpbuf size is probably the easiest to fix.<br>In the near term, solve it like I already tried.<br>change<br>jmpbuf x<br>to void*x = 0;<br> x = x ? x : alloca(sizeof_jmpbuf);<br><br><br>contants.c<br>#include <setjmp.h><br>extern const size_t sizeof_jmpbuf = sizeof(jmpbuf)<br>(plus possible Cygwin hack -- they accidentally blow up the size by a factor of 4)<br><br><br>long term:<br> generate C++ and no more setjmp/longjmp, or possibly C on OpenVMS, Tru64, and NT, possibly #ifdefed <br><br><br>Endianness is partly solved by moving the "floating point cracking" code to C.<br>But that doesn't suffice.<br>There remain bitfields in the runtime, I don't think they can/should be removed, and their layout<br>is endian-specific. Maybe we can just change layout to not be endian specific?<br>I don't care to enable or keep working interop with C bitfields.<br><br><br>win32 vs. posix (also pthreads vs. user threads)<br>requires "something" in the "builder", interacting with the backend perhaps, or with bootstrapping<br>Basically whenever there is an "if" in quake, you kind of need to go down both paths, but communicate the condition<br>to the next level down.<br><br><br>Like if we had FooPosix.m3 and FooWin32.m3<br><br>we either want both<br>FooPosix.c and FooWin32.c generated and we'll only compile one of them,<br>or Foo.m3 with both contents concatenated but with an #if/#else/#endif between them.<br><br><br><br>But what if we had FooWin32.i3 and FooPosix.i3?<br>We can't let FooPosix.i3 be fixible BarWin32.m3.<br>Like, we want to compile everything to C, but not otherwise "infect" the compilation system with the conceptual output.<br>Does that make sense?<br><br><br>The layout problem is tricky.<br>We need separate notions in the backend for UINT32, UINT64, and size_t; and INT32, INT64, and ptrdiff_t (INTEGER).<br>We can't have the frontend resolve to a specific size, at least not without maintaining some notion of the abstraction that the backend sees.<br>The existing typeids might suffice.<br><br><br>As well, records/fields have to treated differently, or in an extra way.<br>That is, we can pass computed sizes and offsets to the backend, and we'd also have to pass other information,<br>and the backend could chose which to use. A reasonably easy approach is to pass a list of integers to add up<br>and maybe multiple, and besides the obvious 1, 2, 4, 8, there'd also be stand-in values for "size_t", like maybe -1.<br>This might be deducable from the declarations we have about arrays and records.<br><br><br><br>It is also tempting to give up on the majority of this.<br>If we solve the jmpbuf problem..including, heck, just blow up jmpbufs to 1K, or use C++ exception handling, then there<br>are only a few targets remainaing:<br> 32bit little endian posix <br> 64bit little endian posix <br> 32bit little big posix <br> 64bit little big posix <br> 32bit little endian NT <br> 64bit little endian NT <br> big endian NT doesn't really exist (Xbox 360?).<br><br><br>We could distribute 6 source archives and let the user chose?<br>Seems too lame to me.<br>But that might be the short term solution.<br><br><br>?<br><br><br> - Jay<br><br><br> </div></body>
</html>