<div dir="ltr">I'm irrationally thrilled that you're doing this. The 68K is, to this day, my favorite CPU to code for, probably because 68K-based Macs were bare-metal machines, where application programs ran in full supervisor mode, and the "programmer's switch" that came with each Mac allows you to interrupt the CPU no matter what it was doing - user code or system code - and drops you into the machine's debugger right at that point.<div><br></div><div>Thank you so much for taking this on.<br><div><br></div><div>I took a very quick look at your 68K code for main:</div><div><font face="monospace"><br></font></div><div><font face="monospace">int main () {<br> printf("Hello World!\n");<br> return 0;<br>}<br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace">gcc:<br>8000044c <main>:<br>8000044c: 4e56 0000 linkw %fp,#0<br>80000450: 4879 8000 04fc pea 800004fc <_IO_stdin_used+0x4><br>80000456: 4eb9 8000 0330 jsr 80000330 <puts@plt><br>8000045c: 588f addql #4,%sp<br>8000045e: 4280 clrl %d0<br>80000460: 4e5e unlk %fp<br>80000462: 4e75 rts<br><br></font></div><div><font face="monospace">Your llvm:<br>8000042c <main>:<br>8000042c: 2f0e movel %fp,%sp@-<br>8000042e: 2c4f moveal %sp,%fp<br>80000430: 9ffc 0000 0010 subal #16,%sp<br>80000436: 2d7c 0000 0000 fffc movel #0,%fp@(-4)<br>8000043e: 41fb 0170 0000 00bc </font><font face="monospace">lea %pc@(800004fc <_IO_stdin_used+0x4>),%a0<br>80000446: 224f moveal %sp,%a1<br>80000448: 2288 movel %a0,%a1@<br>8000044a: 4eb9 8000 0310 jsr 80000310 <printf@plt><br>80000450: 7200 moveq #0,%d1<br>80000452: 48ee 0001 fff8 moveml %d0,%fp@(-8)<br>80000458: 2001 movel %d1,%d0<br>8000045a: dffc 0000 0010 addal #16,%sp<br>80000460: 2c5f moveal %sp@+,%fp<br>80000462: 4e75 rts<br></font></div><div><br></div><div><br></div><div>This immediately makes me wonder what you mean by "default optimization settings"...</div><div><br></div><div>But more importantly, I share Chris' concern about ABI. In particular, in the Mac world, there were two ABIs in common use:</div><div><br></div><div>1) For code written in pascal, including the Mac OS itself, parameter passing was on the stack, where you reserve space for the return value, then push the parameters in order, and the called function clears up the stack prior to returning to you. If you were to try to generate code for Mac applications, you would have to have some way of using this convention on a per-call basis, because you'd need it in order to make system calls. Early compilers dodged this requirement by having glue libraries that took C conventions and then made the appropriate Pascal calls using assembly, so it's not necessary for your initial check-in. Just something to keep in mind.</div><div><br></div><div>2) For code written in C, parameter passing was on the stack, where you push the parameters in reverse order, and the called function puts the return value in register d0. It's the callers responsibility to clean up the stack, in order to support variadic functions such as printf. As Chris says, there were variations on this, even on the Mac, because Apple's language of choice was originally Pascal so each compiler vendor had a different idea of what "C" conventions were. In particular, early on, many vendors chose a 16-bit size for int, which had important implications for ABI since it changes how you call printf("%d\n", 2); Apple's MPW (Macintosh Programmer's Workshop) chose a 32-bit size for int.</div><div><br>As I look at this generated code, however, I can't see what conventions it's trying to follow.</div><div><br></div><div>The area on the stack prior to the call to printf is:</div><div><br></div><div><font face="monospace">???? ???? ???? ??? ???? ???? 0000 0000 fpfpfpfp</font></div><div>(where "fpfpfpfp" is the old 32-bit value of the frame pointer, and the current frame pointer points to it.)</div><div><br></div><div>And the parameter to printf is in both a0 and a1.</div><div><br></div><div>The code seems to think a return value from printf is in d0, judging by the moveml instruction.</div><div><br></div><div>This all is fine, albeit woefully inefficient, if your calling convention sometimes passes function arguments in registers. Does it?</div><div><br></div><div>Separately, please consider using the link and unlk instructions, always. All the production compilers used these instructions, even when optimization was off; the advanced compilers could avoid them in certain cases such as "leaf" routines, but that was rare. They're efficient and make code shorter and easier to read.</div></div><div><br></div><div>And again, thanks for doing this!</div><div><br></div><div>-- Jorg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 25, 2020 at 3:02 PM John Paul Adrian Glaubitz via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Chris!<br>
<br>
On 9/25/20 11:16 PM, Chris Hanson wrote:<br>
> I know it's really early in the project's life, but another question I had:<br>
> How does the generated 68K code perform, at least compared to modern GCC?<br>
<br>
I compiled a simple "Hello World" source in C both with a gcc-10 cross-compiler<br>
for m68k and LLVM/m68k with the default optimization settings.<br>
<br>
I'm attaching the original C source as well as the disassembled binary source<br>
for both compiler outputs.<br>
<br>
Adrian<br>
<br>
-- <br>
.''`. John Paul Adrian Glaubitz<br>
: :' : Debian Developer - <a href="mailto:glaubitz@debian.org" target="_blank">glaubitz@debian.org</a><br>
`. `' Freie Universitaet Berlin - <a href="mailto:glaubitz@physik.fu-berlin.de" target="_blank">glaubitz@physik.fu-berlin.de</a><br>
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>