<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>There likely are no gcc-isms in the code.<BR>The C code that is in there has been compiled with Visual C++ (partly), Digital cc, Sun cc, maybe others that I'm forgetting (bundled K&R HP-UX cc? a weirdo SGI cc I found.. VMS cc?). Sun cc definitely. Tru64 cc fairly recently.<BR> <BR> <BR>It is just that someone needs to have already ported the gcc backend to the target.<BR>We carry a form of the gcc backend with us. At least for now, and for a very long time (10+ years).<BR>I have a C-generating backend, in very good shape, but nobody else uses it yet. It can compile the entire system and has a better debugging experience on systems with no m3gdb support (e.g. MacOSX).<BR> <BR> <BR> > Are you saying you have CM3 running on it?<BR> <BR> <BR>I don't currently. I haven't powered on those machines in over a year now.<BR>But I was working on it. The point is though, it is generally pretty easy.<BR> <BR> <BR>OpenBSD is a slight challenge because mainline gcc no longer supports it.<BR>But they have ports. You get to merge a little the ports to our fork of mainline.<BR>But most of the diffs are not in the backend anyway. Mostly OpenBSD/mips is the same Linux/mips, etc. They generally all share calling conventions and assembler syntax, and that is mostly all the backend cares about.<BR> <BR> <BR>Occasionally a small problem is found.<BR>For example we over-use bitfields and that showed up as a problem on MIPS.<BR>I was also working on Irix.<BR> <BR> <BR>The system is very portable and has been shown to run with little additional effort on a number of systems.<BR> <BR> <BR>It used to be the biggest part of a port was rewriting /usr/include in Modula-3.<BR>It was tedious and error prone. But I fixed that. We now have our own C to bridge that safely once and done.<BR> <BR> <BR> - Jay<br> <BR><div>> Date: Tue, 27 Aug 2013 07:51:46 +0000<br>> From: microcode@zoho.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] 64-bit big endian?<br>> <br>> On Tue, Aug 27, 2013 at 07:35:28AM +0000, Jay K wrote:<br>> > > There are a little-endian MIPS64 boxes also,<br>> > <br>> > OpenBSD/loongson? I was running on that.<br>> <br>> Yes, that's what I was thinking of. Are you saying you have CM3 running on<br>> it?<br>> <br>> > We are extremely portable. Endianness is of almost no concern. Processor<br>> > is of almost no concern. <br>> > We use the gcc backend and pthreads for portability. Or Windows.<br>> > The gcc requirement will be relaxed to any C or C++ compiler.<br>> <br>> That will really be great. A lot of times I want to run something and it has<br>> gcc-isms and doesn't build with other compilers.<br>> <br>> > The system was implemented to be about that portable and I believe I<br>> > fairly well proved it succeeded. I got it to run on several similar<br>> > systems that it hadn't run on or hadn't recently run on, and I got close<br>> > on still others. Give just a bit of time and hardware, I'm<br>> > IA64/HPUX/Irix/VMS/AIX/Tru64 whatever you can muster, we'll work with<br>> > it. But most of these systems people don't use anyway. <br>> <br>> I have friends with a lot more hardware than me and they seem to just accept<br>> the fact they can only run software X on boxes a and b and not c, d or e. I<br>> don't like to get stuck not being able to run something on the few different<br>> boxes I have so I tend not to look too hard at stuff that won't run<br>> everywhere. I've been so busy with other projects that I haven't had time to<br>> look at Modula-3 (not just CM3) but it's definitely on my list since I do<br>> appreciate good language design. I was impressed on all the platform support<br>> I saw on the homepage and I've been lurking on the mailing list to see what<br>> you guys are up to.<br>> <br></div> </div></body>
</html>