Olaf Wagner <wagner@[EMAIL PROTECTED]
> writes:
> There is still active work on CM3/PM3 ongoing; im****tant and substantial
> changes have been committed during the recent months.
i havn't seen any release announcements on this newsgroup...?
> > i switched back to C some years ago, and as much as i'd prefer M3, the
> > fact that there are two incompatible language variants (CM3, PM3) ...
>
> The (more recent) CM3 compiler has been imtegrated into the PM3 code
> distribution quite some time ago; differences between the code
> distributions are not really that great. There has been no official PM3
> release though recently, since Elego uses and concentrates on the CM3
> distribution.
are there any significant users or codebases in PM3 any more? that is,
could we all just declare CM3 "common" or would elegosoft have to merge in
any bits of PM3 to reach that state? and: why did you integrate CM3
changes
into PM3 if your primary work is on CM3? (this is what makes me wonder if
there are still any significant PM3 users or codebases out there.)
> It's not a standard backend because the FSF people never accepted the
> code that cir***vented their license IIRC :-( There's currently a
> working gcc-3.4 backend though, and work is ongoing on a current gcc 4
> backend.
can you say more about the licensing problems? it seems to me that the
GPL
more or less rules the GCC world and that there's no place else you can go
with your CM3 back end than into that community. so either you want a
more
restrictive license (CDDL?) in which case you're trying to prevent people
from using code away from GCC that would be useless away from GCC, or you
want a less restrictive license (BSD?) in which case just put that one on
and deal with the fact that deltas can only flow in one direction between
your repository and FSF's. i don't like the GPL but i respect its power
to
unilaterally set the terms of engagement for the GCC.
> One of the big ****ting problems, system dependencies due to the need for
> memory protection, has been eliminated by extending the code generator
to
> produce hints for the garbage collector for incremental and generational
> collection strategies; so ****ting to a new platform should be
> significantly easier. Indeed it should not need more than a couple of
> days to get the system up on a new target platform if all needed
> information is available.
*wow* that's huge.
> Staying up-to-date with respect to OS releases could still be made much
> easier by abstracting most of the system specific interfaces into a
> standard POSIX layer within the runtime and dealing with some
differences
> in C code. (Any volunteers for this project? :)
i don't know if i'd be qualified to work on that project. can you say
more?
> I can second that. I would also dearly love to see M3 more widely used.
that's effectively not going to happen without leveraging the GCC
community
which means dealing with their GPL unilateralism. and speaking of wide
use,
what does CM3 have or lack with respect to John Polstra's Ezm3?
> We could also try again to contribute the current gcc M3 backend to the
> gcc distribution (which would avoid another M3 implementation), but I
> think we'd need to name a maintainer for that part. I wouldn't dare to
> point at someone for this task :)
what's involved, beyond getting past the licensing issues?
--
Paul Vixie
|
