hi,

maybe its a stupid question, but still... whats the most important benefint
programming win32 asm in windows rather than C++ or delphi? i have
programmed asm in 486 times but now with 2GHZ speed i can get the point on
programming with asm. maybe somebody can explain in simple form :)

darius

Darius,

Speed, more speed and getting your critical algos even faster. As a
matter of fact, 32 bit assembler is a lot easier and cleaner code than
16 bit dos segmented architecture allowed and with the full API range,
you can deal with the high level aspects a lot easier as well.

Size is a major advantage if it matters to you but to write fast code
in assembler, you need to do enough work to understand it and learn
how to optimise it.

If you are interested in MASM code, have a look at www.masm32.com for
the MASM32 project.

Regards,

hutch at movsd dot com

"Darius" <darius.ram@takas.lt> wrote in message news:<c1d2vv$2r65$1@news.wplus.net>...
> hi,
> 
> maybe its a stupid question, but still... whats the most important benefint
> programming win32 asm in windows rather than C++ or delphi? i have
> programmed asm in 486 times but now with 2GHZ speed i can get the point on
> programming with asm. maybe somebody can explain in simple form :)


If your program:

- Runs fast enough written in your high level language of choice

- Does not need to access some low-level processor construct (for
example, you cannot usually implement setjmp/longjmp, task switching
or port I/O without some assembler someplace)

- Does not need to interface with some code defining an interface not
compatible with your language, for example, an incompatible calling
convention (this is basically a variant of the prior point)

-  Is not too large

- And you aren't doing this as a learning exercise

there's usually not much point in using assembler.

"Darius" <darius.ram@takas.lt> �crivait
news:c1d2vv$2r65$1@news.wplus.net: 

> hi,
> 
> maybe its a stupid question, but still... whats the most important
> benefint programming win32 asm in windows rather than C++ or delphi? i
> have programmed asm in 486 times but now with 2GHZ speed i can get the
> point on programming with asm. maybe somebody can explain in simple
> form :) 
> 
> darius
> 
> 

If the asm benefit was with small size and fast program,
Assembly Prpgramming would be as well kept in its grave.

As you say, nowadays, given the size and the cost of hard
Disks, nobody cares anymore of the size (unless for downloads
through slow phone lines...), and given the actual Processors
speed, any well written C Program is much fast enough (unless
considering a couple of very exceptional cases, like Sound
Computing Routines...).

The interrest of Assembly Programming is with the simplicity
of Assembly Language, and on the fact that, as opposed to
HLLs, Assembly is a Language that _shows_, - not a Language
that _hides_.

This particularity of Assembly Language enables you - way
more than any HLL - with some "direct access to Strategy
Optimization", what is doable, in HLL only if you:

1) Perfectely know Assembly.

2) Perfectely know what your HLL is doing in your back.


Actually, no Assembler package is able to compete with
HLLs like Delphi. But the things are changing. Several
Assembler Package are actually under heavy developements
and will in the coming year, begin to compete serioulsy
with HLLs. See for example:

RosAsm: < http://betov.free.fr/RosAsm.html >

FASM:Fresh: < http://flatassembler.net/ >

Once some Assembler Package will have reached that wishable
stage of competitivity, the question will no more be:

- "Why Assembly?" -

but:

- "Why HLL?" -

So, right _today_, the better answer about why Assembly
could only be:

- "For fun" -

but the soon futur will modify this answer a little bit :)


Betov.

< http://betov.free.fr/RosAsm.html >

The difference?

poon@outech.com

Betov <betov@free.fr> wrote in message news:<XnF9499666B3BF7Bbetovfreefr@212.27.42.73>...
> "Darius" <darius.ram@takas.lt> �crivait
> news:c1d2vv$2r65$1@news.wplus.net: 
> 
> > hi,
> > 
> > maybe its a stupid question, but still... whats the most important
> > benefint programming win32 asm in windows rather than C++ or delphi? i
> > have programmed asm in 486 times but now with 2GHZ speed i can get the
> > point on programming with asm. maybe somebody can explain in simple
> > form :) 
> > 
> > darius
> > 
> > 
> 
> If the asm benefit was with small size and fast program,
> Assembly Prpgramming would be as well kept in its grave.
> 
> As you say, nowadays, given the size and the cost of hard
> Disks, nobody cares anymore of the size (unless for downloads
> through slow phone lines...), and given the actual Processors
> speed, any well written C Program is much fast enough (unless
> considering a couple of very exceptional cases, like Sound
> Computing Routines...).
> 
> The interrest of Assembly Programming is with the simplicity
> of Assembly Language, and on the fact that, as opposed to
> HLLs, Assembly is a Language that _shows_, - not a Language
> that _hides_.
> 
> This particularity of Assembly Language enables you - way
> more than any HLL - with some "direct access to Strategy
> Optimization", what is doable, in HLL only if you:
> 
> 1) Perfectely know Assembly.
> 
> 2) Perfectely know what your HLL is doing in your back.
> 
> 
> Actually, no Assembler package is able to compete with
> HLLs like Delphi. But the things are changing. Several
> Assembler Package are actually under heavy developements
> and will in the coming year, begin to compete serioulsy
> with HLLs. See for example:
> 
> RosAsm: < http://betov.free.fr/RosAsm.html >
> 
> FASM:Fresh: < http://flatassembler.net/ >
> 
> Once some Assembler Package will have reached that wishable
> stage of competitivity, the question will no more be:
> 
> - "Why Assembly?" -
> 
> but:
> 
> - "Why HLL?" -
> 
> So, right _today_, the better answer about why Assembly
> could only be:
> 
> - "For fun" -
> 
> but the soon futur will modify this answer a little bit :)
> 
> 
> Betov.
> 
> < http://betov.free.fr/RosAsm.html >

What I have usually seen with comments about the viability of using
assembler at an application level is assumptions about what asembler
is and what capacity it has. If you are stuck with capacity like GAS
or some of the experimental assemblers you would certainly be better
off using VB.NET or similar but there is a difference when you use
assemblers with professional capacity.

Structures, unions, stack automation, libraries, different calling
conventions and macros and collectively this capacity adds up to being
a lot different to what many assume assembler is. Now at a user level,
build a front end with a code generator in under a second, have access
at a well developed range of libraries and you development time drops
to that approaching high level languages.

Compare a bare C compiler to a bare assembler without libraries and
header files and the advantage disappears and a C compiler is no joy
to have to work with in this manner when you have to write all of your
own header files and your own libraries. An assembler is no better but
at least it is well suited for building the libraries from scratch.

Once you start on the high level paradym, you are competing with
things like drag and drop interface design and massive systems like
..NET where low level tools are no use. At least the linux/bsd/unix
guys are free of that for the moment.

Regards,

hutch at movsd dot com

On Thu, 26 Feb 2004 02:55:22 +0000 (UTC)
hutch@movsd.com (hutch--) wrote:

:Compare a bare C compiler to a bare assembler without libraries and
:header files and the advantage disappears and a C compiler is no joy
:to have to work with

This is indeed the key issue. Other than the fact that an assembler is
inherently platform dependant, it is as fast and easy for an experienced
assembly language programmer with access to a subroutine library to code in
assembler as it is to code in C -- and a lot more fun.

	

Exactly Charles, and when windows reports a problem and you click on
the details button those addresses and code correspond exactly to my
listing and it's 100 times easier to narrow down a problem.

I've also emulated a short sort of Hello world program with the
following comparisons;

1. in MFC  184K
2. not Mfc  92K
3. optimized VC 6.0 not MFC 34K
4. Assembly using Nasmw  3K

Also my map file in Nasmw is 1 page whereas in VC 6.0 its 11 pages

pfhinter@lincsat.com (Tight_Coder_EX) writes:
> Exactly Charles, and when windows reports a problem and you click on
> the details button those addresses and code correspond exactly to my
> listing and it's 100 times easier to narrow down a problem.
> 
> I've also emulated a short sort of Hello world program with the
> following comparisons;
> 
> 1. in MFC  184K
> 2. not Mfc  92K
> 3. optimized VC 6.0 not MFC 34K
> 4. Assembly using Nasmw  3K
> 
> Also my map file in Nasmw is 1 page whereas in VC 6.0 its 11 pages

I'm perturbed by assembly using nasm producing larger executables 
than IBM's CSet C++ compiler does for OS/2, for example.

You really should be aiming at hundreds of bytes, max, even if you
add bells and whistles.

Phil
-- 
1st bug in MS win2k source code found after 20 minutes: scanline.cpp
2nd and 3rd bug found after 10 more minutes: gethost.c
Both non-exploitable. (The 2nd/3rd ones might be, depending on the CRTL)

> 1. in MFC  184K
> 2. not Mfc  92K
> 3. optimized VC 6.0 not MFC 34K
> 4. Assembly using Nasmw  3K

Usually in VC if you specify the entry point and set the file
alignment, you can get close to the size of a MASM exe file, you just
don't have any C libraries or other bloated junk you can use without
blowing the file size out again.

In MASM you can do a 32 bit PE file popping a MessageBox in the
minimum 2 sections which is 1024 bytes. A working window at 1.5k so I
guess the nasm example was not fully optimised.

The file sizes do make the point though.

Regards,

hutch at movsd dot com

"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
news:87smgoyynq.fsf@nonospaz.fatphil.org...
<snip>
> > 1. in MFC  184K
> > 2. not Mfc  92K
> > 3. optimized VC 6.0 not MFC 34K
> > 4. Assembly using Nasmw  3K
> >
> > Also my map file in Nasmw is 1 page whereas in VC 6.0 its 11 pages

It is more difficult under VC to get good output, but I can produce a 1K
Hello World program under VC. I link with:
link /NODEFAULTLIB /OPT:NOREF /OPT:NOICF /OPT:NOWIN98 /ENTRY:"WinMain"
/MERGE:".rdata=.text"

That seems to do the trick.

Also, the poster might have tried to dynamic link to MFC and C runtimes
rather than giving the static sizes. IIRC this would cut the MFC binary down
to 40K-60K, and the VC one would fall to about 6K.

> I'm perturbed by assembly using nasm producing larger executables
> than IBM's CSet C++ compiler does for OS/2, for example.
>
> You really should be aiming at hundreds of bytes, max, even if you
> add bells and whistles.

PE headers are 512 bytes. Each section is an additional 512 bytes at
minimum. Imports can easily be a few KB depending on the size of the
program. Hello world should be 1K total.

I wrote a program in C which queries the system uptime, formats it, and
prints it, and my program fits into 1.5K. If I compile out the path to query
the 64-bit counter on NT (which is rather long), the program easily fits
into 1K.

A few KB isn't that bad when you consider most binaries are hundreds of KB,
and a great number of Windows binaries are even >1MB. OOP is both a blessing
and a curse.

-Matt

>I've also emulated a short sort of Hello world program with the
>following comparisons;

>3. optimized VC 6.0 not MFC 34K

Check the article section of bytegeiz.de - they tell you how to get
down to 1kb

>4. Assembly using Nasmw  3K

Same as above. With some extra tweaking, you can even get below 1k.

I guess I should have been a little more specific.  The sizes I speak
of are actual disk space being used, therefore all the overhead of the
exe is there also.  So the references I make are the resultant file
size on disk on the actual application of MFC etc.

As for NASM, the code I speak of is actually 0x11a bytes and some 0x7c
for data & bss.

I think this might be the sizes your speaking of Phil.