General Category > LisaList2

Prevalence of Lisa Workshop C?

<< < (2/2)

stepleton:

--- Quote ---Would be nice to have a C compiler for the Lisa itself.
--- End quote ---

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. 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.

rayarachelian:

--- Quote from: stepleton on June 22, 2022, 05:39:36 pm ---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.

--- End quote ---

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...

D.Finni:

--- Quote from: stepleton on June 22, 2022, 01:05:17 pm ---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?

--- End quote ---
Inconclusive. My single disk has a handwritten label and it says it's version 0.9.6. Here's the directory listing.

The most recent date is 14 Mar 85, whereas the two disks on Bitsavers, if I recall, were dated from September 1985.

claunia:
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.


--- Quote from: stepleton on June 22, 2022, 05:39:36 pm ---
--- Quote ---Would be nice to have a C compiler for the Lisa itself.
--- End quote ---

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. 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.

--- End quote ---

rayarachelian:

--- Quote from: claunia on July 21, 2022, 08:06:29 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[*] Previous page

Go to full version