Re: ASM vs HLL : absurd war

From: J.Mo (u935607910_at_spawnkill.ip-mobilphone.net)
Date: 07/11/04 

Date: Sun, 11 Jul 2004 03:47:46 GMT

> some example?
> windoze-itself, all it's DLLs and all M$-programs,
> and all HLL-created applications I ever looked at in detail.

Well I don't know exactly how Microsoft programs their apps, but it
could very well be that they have to have multiple code sets to
support different processors. Also, I'm quite sure that most if not
all of those DLLs are there for a reason, so don't immediately think
that a program is "bloated" because of the number of DLLs it uses.

>
> Just take any small (large ones even got a more worse ratio)
> PE-file compiled with C++ and look at it with any disassemler.
> You'll find many detouring procedures, useless stack-pollution,
> never used 'included' library-functions and an absolutely
> brainless coding style (compilers are far away from being smart).

I'm sorry, but I simply don't see any of this with the Visual Studio
.net 2003 Compiler. If anything, the compiler is generating LESS code
than I would expect since it is performing dead code elimination. Of
course if you're using some inferior embedded compiler that doesn't
perform those optimizations, then I can understand why assembly might
be a good idea. But for the case of desktop applications, I still
don't see any reason to not use them. Again, if you actually have any
*evidence* that the VS.net or Intel compilers are generating bad code,
by all means show me.

>
> Be sure I could reduce code size and memory image to half at least,
> and speed would increase drastically too.
> Of course all windoze-API will remain as slow as they are,
> therefore I wrote KESYS, but that's another story anyway

Sorry but I highly doubt this. If you have an example of C/C++ code
to back up your claims I'd like to see it.
  

-- 
Sent by karsh from  aussiemail included in com  within area au
This is a spam protected message. Please answer with reference header.
Posted via http://www.usenet-replayer.com

Relevant Pages

  • Re: Free FAT16 Filesystem
    ... being an honourable reason. ... Dave, I made every effort 3 weeks ago to have you understand that if you ... >>Murray did not mention Keil in his correspondence to you. ... >>both your compiler AND under Keil's, ...
    (comp.arch.embedded)
  • compiler and metadata, request opinions...
    ... a lot of the upper/middle compiler machinery is still lacking (such as ... embed the metadata directly into the object modules (the reason being that ... request for a particular piece of information is embedded in a symbol (sort ... it will be loaded into an in-memory version of the database. ...
    (comp.compilers)
  • misc: compiler and metadata...
    ... a lot of the upper/middle compiler machinery is still lacking (such as ... embed the metadata directly into the object modules (the reason being that ... request for a particular piece of information is embedded in a symbol (sort ... it will be loaded into an in-memory version of the database. ...
    (comp.lang.misc)
  • Re: "Sorting" assignment
    ... issue on some ancient compiler doesn't make a lot of sense. ... to his on a few commonly used platforms and compilers, ...  Be sure and call the swap ... reason to find algorithms which operate independent of it. ...
    (comp.programming)
  • Re: IMPLICIT NONE (F2k8+/-)
    ... >convention that has served Fortran for 50 years, is itself, no good ... >reason for change. ... >done, using implicit typing. ... The IBM 1130 compiler could do ...
    (comp.lang.fortran)