Retro68
Retro68 copied to clipboard
autc04
Is it possible to use GoLang instead of C?
To put my question into perspective: I come from mostly web-development background with moderate C knowledge.
Writing vintage software for vintage Macintosh seems like an amazing ground to improve knowledge of system software and system architectures. However I believe it would be more future-proof to invest time into advancing knowledge of GoLang by writing vintage Macintosh software, than advancing my moderate C knowledge (or delving into C++ which I believe I am too late to jump into).
How hard is to replace gcc+ with golang compiler within this toolchain?
I'm not involved with this project in any way, and I'm by no means an expert, but I think that this project is highly specific to C/C++ and old CPUs that were in old Macintoshes.
If you want GoLang to compile to old Macintoshes, you'd have to find a GoLang compiler with a backend for the CPUs involved (68k and/or PPC). Alternatively, you could find a GoLang compiler that compiles to LLVM, and then find something that compiles from LLVM to 68k and/or PPC machine code.
Once you get that out of the way, the libraries in this project would probably help you create similar libraries for Go.
Again, I'm not an expert and hopefully someone can set me straight if I'm wrong in any way!
Speaking strictly for Linux/Debian, the "gccgo" package is available for m68k and powerpc architectures. Someone might still have to write the start-up libraries for Classic though.
The Good News
Go is definitely on the list of "theoretically possible" languages for Retro68, as GCC (the Gnu Compiler Collection, not gcc, the GNU C Compiler) includes gccgo, a Go compiler.
So it's "only" about porting the runtime library and probably some Go standard libraries.
The Bad News
I personally have a very low opinion of the Go programming language. This means I'm not likely to invest much time in this project myself. If someone else wants to tackle it, I'll be glad to integrate any patches into Retro68 and to provide occasional advice.
What would need to be done
(In theory)
- change some build flags, wrestle with GCC's build system to get it to build gccgo
- port the Go runtime library (some 20000 lines of C). It's probably full of assumptions that it's running on a modern UNIX-like system. It needs to schedule threads ("goroutines") and manage the stacks for those, so it will have to contain complicated OS- and processor-specific bits.
- Wade through the 529600 lines of go code that make up the standard library that ships with the compiler and get rid of anything that assumes that it runs on a modern UNIX. Hopefully, they've kept the system dependencies to a minimum.
- Probably wrestle with the build system some more.
All of this is still definitely less work than porting another go compiler (such as the official gc from golang.org), because then you'd need to create the 68K (or 32-bit PPC) backend in addition to the above.
But it's still a major project.
I'm also a web developer and I've been teaching myself vintage mac programming over the last 12 months. I can testify that it's been incredibly difficult learning C, C++ and the Macintosh Toolbox.
Speaking from my experience, these are the resources available to learn old Mac programming:
- Code samples online - virtually all of which are written in C
- The Apple Inside Macintosh books/pdf's - all examples are in Pascal but function definitions are also provided in C
- Reading old Mac programming books - in C
- MacTech.com articles - C
You can probably see the point I'm trying to make - I think throwing a new language into the mix might make things harder.
12 months on and now I'm building Mac apps with (somewhat) confidence - and I think learning C / low-level memory management has made me a better programmer in general.
@antscode mostly because C++ was not strictly adopted by Apple until Carbon, people could and had to choose to use the C++ bindings from Metrowerks (PowerPlant), Symantec (Think Class Libraries) or Apple themselves (MacApp). But afaik, nobody really used MacApp extensively. If you search for PowerPlant or TCL examples you'll find plenty (and PowerPlant is extensively documented).
Adobe Photoshop (early versions) was one notable program that used MacApp. Metrowerks PowerPlant seems to have been released under a BSD license (https://sourceforge.net/projects/open-powerplant/) - I don't know about the others.
In general, C++ frameworks before 1998 predate the C++ standard, so they might need some patches to even compile with gcc, and if they're not under an open-source license, that might be a waste.
Related upstream gcc bug: 46986: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
