{"id":1277,"date":"2019-08-24T19:57:35","date_gmt":"2019-08-24T19:57:35","guid":{"rendered":"http:\/\/retroramblings.net\/?p=1277"},"modified":"2019-08-24T20:47:06","modified_gmt":"2019-08-24T20:47:06","slug":"assembly-language-is-all-very-well","status":"publish","type":"post","link":"http:\/\/retroramblings.net\/?p=1277","title":{"rendered":"Assembly language is all very well…"},"content":{"rendered":"\n

The EightThirtyTwo ISA – Part 5 – 2019-08-24<\/strong><\/p>\n\n\n\n

Before proceeding very much further with the EightThirtyTwo design I wanted to have some way of generating code for it from a higher-level language, just to get a better feel for which instructions are useful for compilers, which will be pretty much unused and where I might find any gaps that make the generated code unneccessarily clumsy. The most obvious route to this goal is to find a C compiler that can be easily retargetted to a new architecture. (Anyone who’s attempted this before is probably laughing now at my use of the word ‘easily’!)<\/p>\n\n\n\n\n\n\n\n

My preconceptions when starting were that I had two options, GCC and LLVM (this turned out to be very far from the truth) – and that the latter would be the easier to work with. While in an ideal world I would have GCC support, I know from having worked with the ZPU toolchain that it’s a rapidly moving target, and if an architecture’s support isn’t updated it tends to suffer bitrot and become difficult to build as the ecosystem evolves. So for now I’ve discounted GCC.<\/p>\n\n\n\n

I haven’t yet explored LLVM at all – but this may well end up being the long-term solution. For now I wanted something simpler, however. It turns out there are in fact a number of other C compilers out there – some that I’d never heard of, some that I know of old – and there may well be more that I haven’t yet found. I am genuinely surprised by just how many options there are!<\/p>\n\n\n\n