[M3devel] possible cygwin createprocess/fork cost measurements..

[Tony Hosking]

On Mar 24, 2008, at 4:38 PM, Jay wrote:
> The NT386 compiler is ROUGHLY 4 times the speed of NT386GNU.

It doesn't pass through the 4 stages of IR that the gcc backend uses:  
m3cg => .mo => gcc trees => gcc rtl => .s => .o.  Hence the speed.   
The integrated backend compiler does m3cg => .o.

> That must be coming from SOMEWHERE, though I don't really know where.
> It could be that cm3cg merely spends a lot of CPU trying to improve  
> the code
> and hardly achieving anything.
>
>  - Jay
>
> CC: wagner at elegosoft.com; m3devel at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3devel] possible cygwin createprocess/fork cost	 
> measurements..
> Date: Mon, 24 Mar 2008 16:05:51 -0400
>
> Blurg!  Tools should do well what they are supposed to do and do no  
> more than necessary.  Assemblers are good at assembling, so why  
> reinvent the wheel?
>
> See: http://linux.oreillynet.com/lpt/a/302
>
> The counterpoint to this argument is Windoze...
>
> On Mar 24, 2008, at 3:25 PM, Jay wrote:
> I understand, but it need not be this way.
>
> http://gcc.gnu.org/ml/gcc/2004-05/msg00318.html
>
> GCC is the last compiler I'm using that doesn't have an integrated  
> object file generator. It's way past
> time to integrate BFD, opcodes, etc. or whatever other solution to  
> replace this generate-text-and-pipe-it-to-the-assembler '70s  
> technology.
> That means one less thing on the host that may not match GCC's  
> expectations. (e.g. AltiVec register names and the host assemblers)
>
> - Jay
>
>
> CC: wagner at elegosoft.com; m3devel at elegosoft.com
> [snip]
> gcc itself is a top-level driver program that generates as and forks  
> an as.   I don't think it's possible to do what you suggest.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080324/8178e7ef/attachment-0002.html>