LisaList2
General Category => LisaList2 => Topic started by: D.Finni on June 20, 2022, 03:55:36 pm
-
I'm finishing writing an article for my site on early C compilers for Macintosh, 1984-1986. Among these I have the Lisa Workshop C compiler by Green Hills.
Would like any commentary from the folks here: did you use it yourself? any anecdotal stories? any idea on how widespread its use was in the developer community?
-
I went ahead and published the article (https://macgui.com/news/article.php?t=537) last evening. I read the manual for Workshop C. It's a shame it didn't gain much traction because judging from the manual it was a pretty good compiler.
-
Are the installers for C around anywhere? I've not looked for them specifically, but I've never come across them.
-
Are they in here? http://www.bitsavers.org/bits/Apple/Lisa/c/
This directory snuck onto bitsavers in July 2020. There's a zip with two DC42 disk images inside. I've never attempted to use them.
D.Finni: what do you think the relationship is between the two disks on Bitsavers and the one disk you possess?
-
Are they in here? http://www.bitsavers.org/bits/Apple/Lisa/c/
This directory snuck onto bitsavers in July 2020. There's a zip with two DC42 disk images inside. I've never attempted to use them.
D.Finni: what do you think the relationship is between the two disks on Bitsavers and the one disk you possess?
Ones on bitsavers, I think, came from David T. Craig, there were supposed to have 3 disks, but one is missing because it was unreadable. I'm told it just had demo source code.
This may be a beta, not sure, and sadly it likely doesn't produce Lisa code, but only Mac code.
Would be nice to have a C compiler for the Lisa itself.
-
Would be nice to have a C compiler for the Lisa itself.
Sure would. I've always wanted to write a compiler, but it may have to wait for a while. I've actually got a mostly-complete grammar for Lisa Pascal (including Clascal), so I could parse it, but code generation is another matter. Anyway, we were talking about C :)
We might ordinarily assume that as long as we didn't use the C library (printf, file I/O, etc.), we could use this compiler to write helper functions that we might call from Pascal code. I've worked on projects where the options in Pascal were limited, so I just wrote assembly language routines instead (https://github.com/stepleton-xx/lisabbs/blob/master/LIBASM.ASM.TEXT). As much as I love 68k asm, C would have been better.
Unfortunately, I don't know whether Macintosh calling conventions are compatible with Lisa OS calling conventions, so that may be one incompatibility. Another problem is that the Lisa MMU requires you to test first whether a memory page you need is already mapped, and subroutine calls is a place where that testing happens. I doubt that code compiled for the Macintosh includes this step.
-
Unfortunately, I don't know whether Macintosh calling conventions are compatible with Lisa OS calling conventions, so that may be one incompatibility. Another problem is that the Lisa MMU requires you to test first whether a memory page you need is already mapped, and subroutine calls is a place where that testing happens. I doubt that code compiled for the Macintosh includes this step.
It might be possible to disassemble either the Xenix or UniPlus compilers for this, but yes, calling conventions are going to be an issue as they'll differ from Lisa OS to unix. Another problem is we don't seem to have documentation for the Lisa OS ABI and .obj formats, etc. I think the Lisa OS Guides show the system calls, but not how they're implemented. i.e. just the names. Might be able to reverse these from the Pascal libraries, or perhaps unit files...
-
Are they in here? http://www.bitsavers.org/bits/Apple/Lisa/c/
This directory snuck onto bitsavers in July 2020. There's a zip with two DC42 disk images inside. I've never attempted to use them.
D.Finni: what do you think the relationship is between the two disks on Bitsavers and the one disk you possess?
Inconclusive. My single disk has a handwritten label and it says it's version 0.9.6. Here's the directory listing (https://macgui.com/downloads/?file_id=34897&keywords=workshop).
The most recent date is 14 Mar 85, whereas the two disks on Bitsavers, if I recall, were dated from September 1985.
-
Probably just making Retro68 target LisaOS besides Mac OS would be an easier and faster to achieve target.
I tried them and it's impressive to cross-compile for Mac OS 6 a C++20 application.
Would be nice to have a C compiler for the Lisa itself.
Sure would. I've always wanted to write a compiler, but it may have to wait for a while. I've actually got a mostly-complete grammar for Lisa Pascal (including Clascal), so I could parse it, but code generation is another matter. Anyway, we were talking about C :)
We might ordinarily assume that as long as we didn't use the C library (printf, file I/O, etc.), we could use this compiler to write helper functions that we might call from Pascal code. I've worked on projects where the options in Pascal were limited, so I just wrote assembly language routines instead (https://github.com/stepleton-xx/lisabbs/blob/master/LIBASM.ASM.TEXT). As much as I love 68k asm, C would have been better.
Unfortunately, I don't know whether Macintosh calling conventions are compatible with Lisa OS calling conventions, so that may be one incompatibility. Another problem is that the Lisa MMU requires you to test first whether a memory page you need is already mapped, and subroutine calls is a place where that testing happens. I doubt that code compiled for the Macintosh includes this step.
-
Probably just making Retro68 target LisaOS besides Mac OS would be an easier and faster to achieve target.
I tried them and it's impressive to cross-compile for Mac OS 6 a C++20 application.
Main thing is to figure out the following:
1. ABI of the LOS kernel, this is abstracted out in the Pascal libraries and not fully documented in the developer documentation. The calls themselves are listed in the LOS guides, but not the binary interfaces. There's a lot of weird traps, some are A-Lines, others are TRAP and so on. Hard to say how it all works. Perhaps the header files offer clues, I don't know. Don't know if these differ from LOS 1.x, 2.x to 3.x.
2. The format of the actual binaries themselves. Usually these are .obj, but that extension seems to also be used for the pre-linked .obj outputs of the compilers, so...
LOS source code release might help with this, if not reverse engineering is all we have.
I've had the wild idea (or delusions if you will) that at some point we'll get this resolved, so I could build something like the AMS emulator, but for the Lisa, where we could remove the actual LOS kernel and run native Lisa apps on Linux and other on top of modern OSs - if we can. This would be my goal, for something like LisaEm 4.0 (but, that seems non-possible at this point in time for other reasons.)
Something like Arros or other OS's, and a modern document oriented desktop system on top of something like LXDE or something else.