I mean, come on, I for one would just stop doing "C" at all if I had to develop systems software and only do rust, without any discussion about C vs rust anymore, because that train, my dear Dr Watson, has already passed - rust is here to stay, better ...
-
I mean, come on, I for one would just stop doing "C" at all if I had to develop systems software and only do rust, without any discussion about C vs rust anymore, because that train, my dear Dr Watson, has already passed - rust is here to stay, better you get on board and climb down from C for any new work.
Just sayin'...
-
Riley S. Faelanreplied to imdat celeste :v_tg: :v_nb: :v_genderfluid: :verifiedomnisexual: [witchzard] last edited by
@ics I dabble in #retrocomputing. There's C translators available for most of the machinery that I dabble in, even ones that weren't really friendly to C. Rust compilers generally don't seem to want to touch anything below 32 bits per machine word.
Which is really unfortunate, because Rust is a great language.
-
imdat celeste :v_tg: :v_nb: :v_genderfluid: :verifiedomnisexual: [witchzard]replied to Riley S. Faelan last edited by
@riley That is really sad, I'd love to see rust running on those machines, but I guess that would overload the rust team working on the compiler.
But afaik, the C-compilers for retro computers were a very special breed - I have the manual here for Atari ST C programming, and it is very rudimentary compared with C nowadays...
-
Riley S. Faelanreplied to imdat celeste :v_tg: :v_nb: :v_genderfluid: :verifiedomnisexual: [witchzard] last edited by
@ics The ancient C limitations are for four main reasons. Only one of them really matters nowadays.
First, by the late seventies, there was a general expectation that a translator should run on the machine that it translated for, which often led to applying the limitations of the recently invented 'microcomputers' to the translators themselves. Nowadays, we care much less about this, because running a compiler in, say, some sort of multi-gigahertz system atop Linux is fairly cheap.
Second, some of these processors were designed well before the ideas about C-friendly processors became popular, so they aren't (at least directly) C-friendly. This issue still applies, but there's advanced techniques that lessen its impacts now.
Third, many advanced optimisation techniques, quite a number of which could be useful for the tiny and cute machines, only became popular after the rise of the IBM PC. This isn't really an issue anymore, in that now that the ideas are out there, a translator targetting a small system could just as well use them as a translator targetting a modern fancy system.
And fourth, the C language itself hadn't really matured yet in mid-1980s.
C is not really an ideal language for #retrocomputing applications. But it comes in handy when you want to get a thing available in an old platform, but don't have the time to write it in a specialised language: you can generally write and debug your code in C on a modern system, avoid specific things you know that the old C compiler didn't recognise, and if your algorithms are sensible, possibly with a little help of overlay manager, you can get something not-optimal-but-workable out of it. There's very few other languages that could do this. Which I'm inclined to argue is itself a bad development, but, hey, capitalism and the need to "productionalise" all sorts of compilers are so hard to countervene.
-
Zorro Notorious MEB 🪷🪷🪷replied to Riley S. Faelan last edited by
-
Riley S. Faelanreplied to Zorro Notorious MEB 🪷🪷🪷 last edited by
@AlgoCompSynth Why exclude 12-bit ones such as PDP-8 ? @ics