[M3devel] main in C or not?

[Jay K]

Randy, yes, that is my same understanding, from fairly recent experience.
 
 
They ship the kernel as a bunch of static libraries, and one C source file with just tunable data:
  extern const int max_this = 100;
  extern const int max_that = 200;
  etc.
 
 
Certain updates involve changes to that file, recompile it, relink.
As such, not much of a C compiler is needed.
 
 
On Itanium they do give you an ANSI compiler.
 
 
The K&R compiler is enough of a compile to compile some gcc 3.x, from which you can compile current gcc (or just stick with 3.x I guess).
I was able to do that.
 
 
The K&R compiler I think is also enough to do 64bit work, but I think offers no shared libraries and no optimization.
 
 
I haven't booted my HP-UX/hppa in months now, I doubt anyone cares much, and if anyone did, we could probably require either the ANSI compiler or gcc. Perhaps perhaps perhaps I'll bring the system back up and make sure our stuff all compiles ok K&R.  Perhaps. It kind of muddies the code and even e.g. gcc 4.x can't be compiled with a K&R compiler, not even with the ansi2kr build-time conversion thingy -- which, btw, I'd 
be willing to try to use as a compromise.
 
 
Anyway, while supporting HP-UX/hppa/itanium is on some "list", it might never make it to the top.
Nobody seems interested in it.
 
 
The great thing about a C generating backend if you can fairly honestly claim to support "all" systems while doing "zero" work.
You know, consider:
 
#include <stdio.h>
int main() { printf("hello\n"); return 0; }
 
 
What does it work on? Pretty much "everything" -- everything with a C compiler and stdio. How much porting work? Pretty much "zero".
 
 
I say "fairly honestly" because there is still a small amount of #ifdef in the C code.
  Though the amount of #ifdef we have at present is fairly small and the number of systems it supports is fairly large.
 
And even the generated C code might have some system-dependencies to be smushed out perhaps.
autoconf might help.
 
 
The C-generating backend would theoretically and really probably for real work with HP-UX, AIX, Irix, Android, iPhone, VMS, etc. besides the usual assortment of NT (including AMD64, IA64), Linux, Solaris, FreeBSD, NetBSD, OpenBSD (modulo the threading/context problems), Darwin.
  (iPhone has a problem with the signal headers perhaps).
 
 
 - Jay
 


From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Mon, 23 Aug 2010 18:10:15 -0400
Subject: Re: [M3devel] main in C or not?






Jay,
 
My recollection on HPUX  is that the K&R cc was provided mainly just to rebuild the kernel and that if you wanted to do any real C development, HP stood ready to sell you an ANSI C compiler.  We purchased the ANSI C, but still had to use the K&R for kernel adjustments.  But, this was many years ago (circa HPUX v9).
 
Regards,
Randy
 


From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Monday, August 23, 2010 5:52 PM
To: Olaf; m3devel
Subject: Re: [M3devel] main in C or not?
 
Hm. Interesting subtle angle you point out.
I have seen very few systems with ld but not cc. e.g. OLPC default install.
My HP-UX/hppa machine came with only a K&R cc.
Irix might have come with no official cc, but hunting around I found one that worked well enough to build gcc.
AIX maybe also.
We could potentially call ld directly.
  But in general I don't write the configuration files that way, they run cc for linking.
*.c is used a bunch in m3core but not much else.


On the other hand:
  cc is fairly ubiquitous.
  We have a "plan" for a "new distribution format" that will require cc -- users will build more of the
   system. Though we'll still provide binaries for some systems.


I'm *really* interested in a C-generating backend, which will subsume this.
Except perhaps systems like NT386, and maybe we'll expand that set.
I'm becoming increasingly frustrated with the gcc backend.


I can compromise and leave the code in m3linker, but I still like the change in cm3 where the configuration
is ignored.


I'll still go ahead and make the C code typesafe via ANSI prototypes.
  (potentially breaking HP-UX/hppa, but when I get back to that system I'll probably #ifdef
all the breakage, or require an ANSI compiler such as gcc; I assume nobody really
cares about K&R).


 Generating main in C seems to help some platforms, e.g. SOLgnu, SOLsun, SPARC32_LINUX,
but I admit I didn't fully debug these. And then, removing variations among configurations, I like.
But that can be achieved via the small change for now and leaving the support in.


 - Jay

> Date: Mon, 23 Aug 2010 13:57:01 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] main in C or not?
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > There has long been a configuration variable: MAIN_IN_C.
> >
> > I propose that main always be in C. I made that so already, a small change.
> >
> > I further propose that the support for main to not be in C be removed.
> >
> > "Not in C" is "generating it via the backend", directly an .obj for NT386, or
> > going through the gcc backend for Posix.
> >
> > Furthermore, I'll cleanup the C to be more typesafe by using ANSI C.
> >
> > I have this change about ready.
> >
> > I don't think avoiding C is valuable and I'd rather have fewer 
> > configuration variables.
> > Pick one approach that works reasonably always.
> 
> This requires that every user must have a C compiler in addition to
> cm3. I thought the default was not to generate C, and just require
> a C compiler for special runtime support.
> 
> I'm not sure if this really a valid argument for the systems we support
> though, as we also need a system linker, and that is probably bundled with
> the C compiler in a development package.
> 
> 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
>  		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100824/7548c177/attachment-0002.html>