Subject: MS VC++ compiler / MIPS

From: "Alexander Voropay" <[email-masked]>
Date: Wed, 14 Jul 2004 17:53:11 +0400

Hi!

 Is it possible to use it for the something useful ??
(to compie a kernel 8-))

 As it is known, MS provides eMbedded Visual Tools 3.0
for free download. It contains a free C++ MIPS cross compiler .

evt2002web_min.exe [210485 KB]

========================
C:\...ft eMbedded Tools\EVC\WCE300\BIN>CLMIPS.EXE /help 
Microsoft (R) 32-bit/16-bit C/C++ Optimizing Compiler Version 12.01.8667
for MIPS R-Series
Copyright (C) Microsoft Corp 1984-1999. All rights reserved.

[....]
                             -CODE GENERATION-

/QMRWCE optimize for WinCE (Default)     /QMOb<n> basic block threshold
/QMR3900 optimize for r3900              /QMOu<n> unroll n loop
iterations
/QMR4100 optimize for r4100              /QMFPE[-] FP emulation
(default)
/QMR4200 optimize for r4200              /Gd __cdecl calling convention
/QMR4300 optimize for r4300              /GA optimize for Windows
Application
/QMmips16 code for MIPS16 ASE            /GD optimize for Windows DLL
/QMmips1 MIPS1 ISA                       /Gr __fastcall calling
convention
/QMmips2 MIPS2 ISA (default)             /Gf enable string pooling
/QMNoDivCheck no divide by zero check    /GF enable read-only string
pooling
/QMNoUnalign no LWL,LWR,SWL,SWR          /Gh enable hook function call
/QMNoULoad do not generate LWL,LWR       /GR[-] enable C++ RTTI
/QMNoUStore do not generate SWL,SWR      /Gy separate functions for
linker
/QMOC use old float comparison helpers

[....]

--
-=AV=-

---

From: [email-masked] (H.Heinold)
Date: Wed, 14 Jul 2004 16:05:26 +0200

Hi,

look at which prozessors are supported, mainly embbeded devices and why
should it useful for linux.
-- 

Bye Henning

---

From: Geert Uytterhoeven <[email-masked]>
Date: Wed, 14 Jul 2004 16:10:01 +0200 (MEST)

>  Is it possible to use it for the something useful ??

If `kernel' stands for `Linux kernel', most probably not.

> for free download. It contains a free C++ MIPS cross compiler .

Whether it's `free' or not, depends on your definition of `free'...

> evt2002web_min.exe [210485 KB]

A filename that ends in `*.exe'.... What's that?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

---

From: "Kevin D. Kissell" <[email-masked]>
Date: Wed, 14 Jul 2004 17:07:06 +0200

If I recall correctly, the MS compiler uses a subltly different
calling convention/ABI than the "o32" gcc conventions assumed
by MIPS Linux, and certainly the assembler directives will be
different from those assumed by the Linux sources.  It *might*
be possible to hack up a MIPS Linux kernel source tree to
build with the MS tool kit, but it would be a lot of work, 
some of it subtle.

            Regards,

            Kevin K.

---

From: "Alexander Voropay" <[email-masked]>
Date: Wed, 14 Jul 2004 21:32:23 +0400

Kevin D. Kissell [mailto:[email-masked]] wrote:

>If I recall correctly, the MS compiler uses a subltly different calling
convention/ABI
>than the "o32" gcc conventions assumed by MIPS Linux,

 The ABI is identical if the number of the int arguments <=4
(n1-> $4, n2 -> $5, n3 -> $6, n4 -> $7)
(return value --> $2)
 It should be enought for simply functions.

 Otherwise, the MSVC/MIPS does not use $fp, so stack frame structure
seems different.

 MSVC/MIPS supports 2 calling conventions (/Gd __cdecl calling
convention;
/Gr __fastcall calling convention) but I can't grok a difference.

> and certainly the assembler directives will be different from those
assumed by the Linux sources.

 Yes.

 It sems, it is impossible to build a full Linux toolcain at the MSVC
base. The MS linker
(LINK.EXE) is weak (comparing to `ld` monster) and can produce only COFF
.EXE (a.out)
MIPS executables.

>  It *might* be possible to hack up a MIPS Linux kernel source tree to
build with the MS
>tool kit, but it would be a lot of work,  some of it subtle.

 I have no plans to do it, I'm not a MIPS guru :)

--
-=AV=-

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 15 Jul 2004 02:24:54 +0200

> /Gr __fastcall calling convention) but I can't grok a difference.

Probably more argument registers etc.  I'd expect something along the
NABI callign conventions.

> (LINK.EXE) is weak (comparing to `ld` monster) and can produce only COFF

PECOFF, Microsoft's ECOFF variant which basically is ECOFF plus an MSDOS
executable header.  Yes, we all run MSDOS on our MIPS boxes so that's
and important feature ;-)

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 15 Jul 2004 02:39:14 +0200

> build with the MS tool kit, but it would be a lot of work, 

A few years ago we got SGI's IA-64 kernel to compile with their Pro64
compiler.  Despite the usually rather dramatic superiority of Pro64's
code generation compared to the gcc of that time - half the time to
generate twice as fast application code was common - the huge effort
it took was essentially wasted time to achieve a hard to meassure amount
of extra performance.  Most of the kernel code is well optimized, was
written with being compiled by gcc in mind and performance is more
limited by the hardware and kernel algorithms than by the compiler's
code generation.  So I wouldn't invest any time into trying to get the
kernel working on yet another non-gcc compiler ...

  Ralf