|RFC: project directions... email@example.com (BGB / cr88192) (2009-09-14)|
|Re: RFC: project directions... firstname.lastname@example.org (2009-09-19)|
|Re: RFC: project directions... email@example.com (BGB / cr88192) (2009-09-21)|
|Re: RFC: project directions... firstname.lastname@example.org (2009-09-26)|
|Re: RFC: project directions... email@example.com (BGB / cr88192) (2009-09-26)|
|Re: RFC: project directions... firstname.lastname@example.org (2009-10-03)|
|Re: RFC: project directions... email@example.com (BGB / cr88192) (2009-10-03)|
|Date:||Sat, 26 Sep 2009 04:43:44 -0500|
|Posted-Date:||26 Sep 2009 08:33:35 EDT|
firstname.lastname@example.org (BGB / cr88192) wrote:
> > I'd expect that using your own calling convention, while it may
> > offer up-front savings in effort, will become a millstone with
> > time. It's probably going to be best to bite the bullet now, and
> > save the effort of switching at a later date.
> the problem is that this would not allow compiling code in a form
> which would work on both Win64 and Linux x86-64, meaning that
> everything would need to be compiled fresh for each platform.
Yes. Is that such a big problem? It's the way C and C++ usually work at
It's only one example, but my main employment is in maintaining build
systems for large apps on a wide range of platforms, and being able to
build Linux x86-64 on Windows x64, or vice-versa, wouldn't be especially
useful to me. If a single platform could also build 32-bit x86 Windows
and Linux, ditto 32-bit and 64-bit Mac OS X, plus AIX/POWER,
Solaris/SPARC, and HP-UX/PA-RISC+Itanium, then it would be worth
considering. But it still wouldn't be an automatic choice by any means:
running the testing still has to be done on all the individual
platforms, and machines powerful enough to do that can do the builds with
conventional tools quite quickly.
> I may as well almost go to the extreme of full-on bytecode while I am
> at it, so that I could use the same code for x86 and x86-64.
Seems like a better option to me. Still have to test it separately on
all the platforms, though.
John Dallman, email@example.com, HTML mail is treated as probable spam.
Return to the
Search the comp.compilers archives again.