[M3devel] small problems bring up new node
Jay K
jay.krell at cornell.edu
Wed Oct 27 11:28:14 CEST 2010
Hm. I think most of the code is outside of Hudson by now, but I'll poke around.
We would generate highly portable C/C++.
We wouldn't depend on gcc. gcc just isn't, in my experience, so much better/different
than any other C/C++ compiler -- partly because I mostly use Microsoft Visual C++ and
that compiler has fairly few extensions. Perhaps if I used gcc more I'd be lulled into using
its many unique extensions.
#ifdef linux would generally suffice for Linux on all processors.
No need for the ppc/sparc/etc. machines.
#ifdef freebsd ditto.
No need for the ppc/sparc/etc. machines.
As well, autoconf might subsume some of that.
We might still try to have some 32bit and 64bit machines, some sparc, mips, etc., but
no need for the full cross product.
endian and wordsize would be separate factors
We may or may not need to know them statically.
i.e. we would either typedef integer like in m3core.h, or use autoconf.
I think if m3cg had a notion of a field reference, the front end would no longer
care about endian. I think it only uses it to layout bitfields within bytes/integers.
Heck -- given that we have no bitfields used between C and Modula-3, I think this
dependency can be removed already, just do the layout arbitrarily!
- Jay
----------------------------------------
> Date: Wed, 27 Oct 2010 11:19:49 +0200
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] small problems bring up new node
>
> Quoting Jay K :
>
> > Olaf, bringing up new nodes I think finds small problems in the automation.
> >
> > new node: jaws1 which is Linux/x86
> > (Rename it if you don't like it.)
> >
> > initial install worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-initial-install-LINUXLIBC6/4/
> >
> > building cm3cg worked in one attempt, good:
> > http://hudson.modula3.com:8080/job/cm3-current-m3cc-LINUXLIBC6/67/
> >
> > but building the rest failed, for lack of "last ok" build:
> > http://hudson.modula3.com:8080/job/cm3-current-build-LINUXLIBC6/147/consoleFull
>
> That hasn't been realluy automated in a generic fashion yet.
> I always had to perform several steps more or less manually due to
> different environments etc. If you can write a general boot or init
> job that will be great.
>
> The build and test jobs all expect valid cm3 package pool setups
> in current and lastok. That at least should be easy to automate.
>
> > I'm sure if I just copy stuff around it'll work.
> > Unless we need to start with a newer release,
> > which is a different matter if so.
> >
> > This node was cloned from xlinux and I just changed the node
> > name and node to ssh to.
>
> There are different variants of init jobs for different platforms.
> Maybe you just were unlucky to pick a rather old one :-/
>
> > (The great thing about a C backend is all this testing
> > across every architecture would all but disappear..)
>
> No, it wouldn't. We could neither be sure that the generated C code
> compiles with a native compiler (unless we require the same version
> of gcc everywhere) nor that it would perform in the same way on all
> platforms. That doesn't mean that a C backend wouldn't be a great
> extension, of course.
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>
More information about the M3devel
mailing list