<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 12:16 PM, Mikaël Fourrier <span dir="ltr"><<a href="mailto:mikael.fourrier@laposte.net" target="_blank">mikael.fourrier@laposte.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
16-bit byte was a major pain back in the day, and we never fixed all<br>
known failures. In part, it's because C standard really wants 8-bit chars.<br>
</blockquote>
<br></span>
So no real solution?</blockquote><div>My memory is cloudy, since that fun was in 2012, but if I remember correctly, the major mistake I made with that backend is the decision to pack to 8-bit chars into one 16-bit memory word. It made impossible to have pointers to odd chars in the string, and complicated everything. The port might have been cleaner if we had one 8-bit char in one 16-bit word. In this case, half of the memory for the strings is wasted, but some things would have been easier.</div><div><br></div><div>Another issue was the pointer arithmetic, and there's no good answer to that: the fixes were intrusive and non-upstreamable, and they would have been the same, if this port is done again.</div><div><br></div><div>The real solution would be to modify DCPU16 to be friendlier to C compilers. One way to achieve that is to make the registers 32-bit and allow addressing memory at 8-bit boundaries. It's okay to keep the amount of RAM available at low numbers, if it adds fun.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Btw, why is DCPU16 still a thing? :)<br>
</blockquote>
<br>
</span><a href="https://github.com/techcompliant/" rel="noreferrer" target="_blank">https://github.com/techcomplia<wbr>nt/</a>. It's a separate team not related to Mojang which took the idea. They are on alpha now.<br></blockquote><div>Oh, yes, I <a href="https://github.com/llvm-dcpu16/llvm-dcpu16/pull/196">have heard</a> of them a half a year ago. Are they rigid about using the pristine DCPU16? If not, changes like I mentioned above, would make the problem to deliver a decent LLVM backend much easier. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also because <a href="https://github.com/FrOSt-Foundation/cFrOSt" rel="noreferrer" target="_blank">https://github.com/FrOSt-Found<wbr>ation/cFrOSt</a> ;)<br></blockquote><div>Oh! </div></div><br></div></div>