flat assembler
Message board for the users of flat assembler.

Index > Heap > Best C Compiler (no C++/IDE)

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
silkodyssey



Joined: 02 Oct 2003
Posts: 198
Location: St.Vincent & the Grenadines
silkodyssey
Quote:

I'm doing the same for the Express editions and burning all to CD!


When I downloaded it I had to use their download tool to download and install. Where can I find the setup files if I to burn them to a cd?

_________________
silkodyssey
Post 18 May 2006, 04:39
View user's profile Send private message MSN Messenger Reply with quote
OzzY



Joined: 19 Sep 2003
Posts: 1029
Location: Everywhere
OzzY
You should download the ISO, and burn to the CD.
The version that comes inside the ISO doesn't require registration and have full MSDN help files.
Get it here: http://msdn.microsoft.com/vstudio/express/support/install/
Post 18 May 2006, 15:54
View user's profile Send private message Reply with quote
RedGhost



Joined: 18 May 2005
Posts: 443
Location: BC, Canada
RedGhost
i use pellesC, optimized LCC compiler with all the MSVS style linker commands supported like #pragma, but for MSVS or anything generally i use the Intel C/C++ compiler, which has better code generation than the MSVS or LCC compilers

_________________
redghost.ca
Post 19 May 2006, 20:37
View user's profile Send private message AIM Address MSN Messenger Reply with quote
f0dder



Joined: 19 Feb 2004
Posts: 3170
Location: Denmark
f0dder
Quote:

but for MSVS or anything generally i use the Intel C/C++ compiler, which has better code generation than the MSVS or LCC compilers

Actually for MS vs. Intel, the results vary a lot! For some things, intel is ahead, for some things, microsoft is ahead. For some things it's a lot, for most things it's very minor. For a few things every now and then, GCC does better... but it's not very often Smile
Post 19 May 2006, 20:49
View user's profile Send private message Visit poster's website Reply with quote
Reverend



Joined: 24 Aug 2004
Posts: 408
Location: Poland
Reverend
I like LCC very much. For small windows' exes it's really good. Also it generates quite decent code for loops, switches, etc. as I saw it on the disassembly.
Post 25 May 2006, 17:38
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Okay, anyone want to selectively download parts of the latest OpenWatcom 1.6 like you used to be able to do for versions 1.3 and older? Well, you're (finally) in luck, thanks to Arkady V. Belousov!

EDIT: Here's a quick FreeDOS announcement page of what you probably need/don't need.

OW 1.6 .ZIPs -- files @ ibiblio.org

OW 1.6 DESCRIPT.ION -- (describe what files are needed for what host/target)

OW 1.6 README.TXT -- (general environment setup info)

OW 1.6 LICENSE.TXT -- (license)


Last edited by rugxulo on 28 Dec 2006, 20:32; edited 3 times in total
Post 11 Jul 2006, 03:29
View user's profile Send private message Visit poster's website Reply with quote
0x4e71



Joined: 25 Feb 2004
Posts: 50
0x4e71
In terms of code quality you are probably better of with Microsoft's and Intel's ones. VectorC (by codeplay) makes bold claims about super fast code and auto vectorization, have never tried it though.

Worthy "underdogs": Digital Mars, CC386, Watcom and LCC-win32?

GCC is GCC, love it or hate it. I absolutely detest their inline assembler syntax (constraints etc.) but I guess it's a matter of getting used to it.
Post 14 Jul 2006, 22:29
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
Well, these answers kinda assume Windows or Linux. For other OSes (OS/2, Win16, DOS) you're probably better off using OpenWatcom, IMO.
Post 16 Jul 2006, 04:39
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
OpenWatcom 1.6 has been released! (install .EXE/.ZIP SFX for C/C++ or Fortran77 are available for Win32 and OS/2).

EDIT: See here for separate .ZIPs (i.e, selective install).

Quote:

List of changes in C/C++ 1.6

  • The C compiler has been modified to use the underlying bit-field type and not signed/unsigned int as the type of operand which is a bit-field. This is consistent with the C++ compiler and fixes some problems when bit-fields larger than int are used.
  • Processing of #pragma aux has been corrected in the C compiler. This fixes problems when using the mmintrin.h header, among others.
  • The C compiler now accepts __declspec modifiers specifying calling conventions applied to variables, not just functions. The new behavior is consistent with the C++ compiler, and also with the fact that ordinary calling convention type modifiers can be used with variables.
  • The C and C++ compilers have been fixed to properly declare variable names based on calling convention specifiers. This fixes problems with building code using IBM SOM. Note that the current behavior is the same as in Open Watcom 1.3 and earlier.
  • The C compiler's preprocessor has been modified to allow use of macros with large number of arguments (255 or more).
  • The C compiler no longer generates internal errors when options -ri and -oe are specified at the same time.
  • The C++ compiler has been fixed to inline intrinsic functions.
  • The 386 compilers have been changed to default to tuning code for P6 architecture instead of Pentium. Optimizing for P6 typically results in slightly more compact and faster code.
  • The 386 C compiler has been fixed to properly convert between flat and __far16 pointers, especially pointers to functions. Its behavior should now be compatible with the C++ compiler. The problem was most likely affecting OS/2 users who wrote mixed 16-bit and 32-bit code.
  • The C compiler has been changed to allow redeclaration of functions in rare cases where initial declaration did not specify a calling convention and the subsequent declaration specified a calling convention which matched the default.
  • A new -zwf switch has been added to the C and C++ compilers. This switch is off by default and enables generation of FWAIT instructions on 386 and later CPUs. It is only needed in unusual situations.
  • The C compiler now correctly converts 64-bit integer constants to floating-point constants.
  • The code generator no longer merges memory accesses when volatile variables are involved.
  • The code generator now correctly const folds 64-bit right shifts.
  • The code generator now properly converts between far pointers and 64-bit integers. Attempts to convert a 48-bit far pointer to 64-bit integer no longer cause a crash.
  • The code generator has been modified to slightly decrease code size when optimizing for size (-os).
  • The non-standard alloca.h header has been added for compatibility with other compilers.
  • The strftime() library function has been extended to support date formats introduced in C99.
  • The file pointer type used with lseek() and tell() has been changed to off_t (from long) for compatibility with POSIX.
  • The 386 versions of _clear87() and _status87() functions have been modified to use the no-wait form of FPU control instructions. This allows these functions to be used in exception handlers when there are pending unmasked floating-point exceptions.
  • The 16-bit 8087 emulator has been fixed to correctly evaluate multiplies as infinity instead of zero in rare overflow situations.
  • The resource compiler (wrc) has been fixed to store long integer constants as 32-bit quantities in RCDATA or user data resource statements. This behavior applies to Win16, Win32, and OS/2 targets. Integers without the 'L' suffix are stored as 16-bit and potentially truncated.
  • The OS/2 specific part of the resource compiler has been corrected to process RCDATA statements properly.
  • The assembler (wasm) now supports external absolute symbols. The SIZE, SIZEOF, LENGTH, and LENGTHOF operators have been corrected for structures.
  • Classification of privileged instructions in the assembler has been updated to match MASM.
  • The assembler now evaluates expressions in return instructions correctly. Previously, code such as 'ret 28+4' would be sometimes erroneously assembled as 'ret 28' instead of 'ret 32'.
  • The linker has been changed to only recognize segments of class 'STACK' as stack segment. Previously, any segment with class name ending with 'STACK' (eg. 'FSTACK') was recognized.
  • Several minor problems related to creating DOS executables have been fixed in the linker.
  • The RUNTIME linker directive has been extended to allow ELF ABI type and version specification. This functionality is similar to the brandelf utility. See the Linker Guide for details.
  • The wmake utility has been modified such that in native wmake mode, a symbolic target with no command list is always considered to have had its command list executed. That will cause any targets that are dependent on this symbolic target to be considered out of date.
  • The Win32 trap file is now able to determine the full pathname of debuggee's loaded DLLs. This may ease debugging in some cases as the debugger will be more likely to find debugging information for DLLs.
  • The Win16 debugger trap file (std.dll) has been modified to allow 16-bit wdw to run on Windows NT platforms without reporting a spurious error message on exit.
  • Numerous problems with the Win386 extender support have been fixed so that Win386 now works again.
  • The dmpobj utility has been ehnanced to support additional OMF records, and new command line options have been added.



Last edited by rugxulo on 28 Dec 2006, 20:34; edited 1 time in total
Post 19 Dec 2006, 04:39
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Quote:
Several minor problems related to creating DOS executables have been fixed in the linker.


The DOS version host/target of OW 1.5 was reported as "terribly buggy" Sad

Maybe I'll have a look occasionally ...

But now I prefer CC386 (Version: 3.27, Release Date: Nov 30, 2006).

CC386 generates much less noise than WATCOM ... but maybe it IS
better (works for me, but I am NOT a "C" expert).
Post 19 Dec 2006, 14:34
View user's profile Send private message Reply with quote
Raedwulf



Joined: 13 Jul 2005
Posts: 375
Location: United Kingdom
Raedwulf
f0dder wrote:

Intel's C++ compiler is also VERY good, and sometimes generates better code than the Microsoft compiler... but it's not available for free.


Intel C++ for Linux is free for non-commercial purposes.

f0dder wrote:

GCC is okay; worse code generation than MS and Intel, but still pretty language conforming. Unfortunately GCC4 isn't included in the MingW distribution yet.


GCC4 is quite good, if you search for various custom builds MINGW e.g.
http://www.thisiscool.com/gcc_mingw.htm

... you can get it working in windows.

The main advantage at the moment for Intel is its Vectorisation code which is much better than MSVC+ GCC.

Cheers.

_________________
Raedwulf
Post 20 Dec 2006, 11:04
View user's profile Send private message MSN Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.