It is very annoying for us to write assembler programming before we want
to optimize them by switching 386, 486, 586, or 686.
    For example, C/C++ compiler is flexible that it can optimize by choosing
386, 486, 586, or 686.  Linux or Unix are very picky with C/C++ compiler
that it always COERCE us (novice and experienced users) to compile
everything before we can be able to install the software on the proper Intel
processor type.  Microsoft does not like the way how Linux and Unix do with
C/C++ compiler so they always provide pre-binary software such as ELF.  (I
know Linux or Unix do have ELF).
    I realize that if I choose to use Pentium 4 on existing Pentium III, it
will cause Pentium III to be much slower than Pentium 4.  It is interesting
that Pentium 4 can hurt Pentium III.  Pentium III can hurt Pentium 4.  It is
what Matt Taylor quoted.
    Is there a way that we can optimize by writing assembler programming
manually in our own?  It will help that Pentium 4 will run much faster than
Pentium III.  Also, it will help that Pentium III will run much faster than
Pentium Pro and then 486 and so.
    Is there a way that we can study optimization in our own without help
from C/C++ compiler's optimization automatically?  If we are smarter enough,
we have our ability to do optimization without needing help to use the
switch like command line under C/C++ compiler, but I don't know if MASM does
have the switch.  Please advise.

-- 
Bryan Parkoff

"Bryan Parkoff" <nospam@nospam.com> wrote in message
news:xlYob.11843$D87.2061@twister.austin.rr.com...
>     It is very annoying for us to write assembler programming before we
want
> to optimize them by switching 386, 486, 586, or 686.
>     For example, C/C++ compiler is flexible that it can optimize by
choosing
> 386, 486, 586, or 686.  Linux or Unix are very picky with C/C++ compiler
> that it always COERCE us (novice and experienced users) to compile
> everything before we can be able to install the software on the proper
Intel
> processor type.  Microsoft does not like the way how Linux and Unix do
with
> C/C++ compiler so they always provide pre-binary software such as ELF.  (I
> know Linux or Unix do have ELF).

Microsoft distributes binary because they think distributing source allows
people to copy their ideas. Some Unix vendors also distribute only binary,
but there is also a significant pro-open-source community as well.

Also, to be pedantic, Microsoft uses an executable format based on COFF
which they call PE.

>     I realize that if I choose to use Pentium 4 on existing Pentium III,
it
> will cause Pentium III to be much slower than Pentium 4.  It is
interesting
> that Pentium 4 can hurt Pentium III.  Pentium III can hurt Pentium 4.  It
is
> what Matt Taylor quoted.

For most programs, this doesn't matter. If you open cmd.exe on NT and type
"dir", does it matter if the results are displayed in 2 milliseconds or 3?
Tim mentioned this before. It is not possible to obtain a perfectly
optimized program because optimization is NP complete. You get the best
results by optimizing the parts of your program that execute most
frequently.

>     Is there a way that we can optimize by writing assembler programming
> manually in our own?  It will help that Pentium 4 will run much faster
than
> Pentium III.  Also, it will help that Pentium III will run much faster
than
> Pentium Pro and then 486 and so.
>
>     Is there a way that we can study optimization in our own without help
> from C/C++ compiler's optimization automatically?  If we are smarter
enough,
> we have our ability to do optimization without needing help to use the
> switch like command line under C/C++ compiler, but I don't know if MASM
does
> have the switch.  Please advise.

The point of an assembler is that it does not optimize. There is no
assembler that will change the instructions you write to optimize the code.
Many assemblers will do size optimization by using the smallest form of an
instruction, but I'm guessing that you weren't asking about this. Assemblers
are WYSIWIG: what you see is what you get.

If you want your code to be optimized automatically, why would you want to
program in assembly? Optimizing assembly code is more difficult than
optimizing a high-level language.

If you want to learn more about optimization, read books on compilers. Also,
both Intel and AMD publish lengthy manuals that describe how to optimize for
their processors.

-Matt

Matt Taylor wrote:
> The point of an assembler is that it does not optimize. There is no
> assembler that will change the instructions you write to optimize the code.
> Many assemblers will do size optimization by using the smallest form of an
> instruction, but I'm guessing that you weren't asking about this. Assemblers
> are WYSIWIG: what you see is what you get.

There is.  I worked with a RISC-Assembler for a 32-bit 
Fujitsu-Microcontroller which reordered the instructions to fill in the 
delay slot.


-- 
Bernd

"Bryan Parkoff" <nospam@nospam.com> skrev i meddelandet
news:xlYob.11843$D87.2061@twister.austin.rr.com...
>     It is very annoying for us to write assembler programming before
we want
> to optimize them by switching 386, 486, 586, or 686.
>     For example, C/C++ compiler is flexible that it can optimize by
choosing
> 386, 486, 586, or 686.  Linux or Unix are very picky with C/C++
compiler
> that it always COERCE us (novice and experienced users) to compile
> everything before we can be able to install the software on the
proper Intel
> processor type.  Microsoft does not like the way how Linux and Unix
do with
> C/C++ compiler so they always provide pre-binary software such as
ELF.  (I
> know Linux or Unix do have ELF).
>     I realize that if I choose to use Pentium 4 on existing Pentium
III, it
> will cause Pentium III to be much slower than Pentium 4.

A Pentium III is almost always slower than a Pentium 4. :-)

> It is interesting
> that Pentium 4 can hurt Pentium III.  Pentium III can hurt Pentium
4.  It is
> what Matt Taylor quoted.

Intel are nuts!

This is one good reason for writing in a high level language.

>     Is there a way that we can optimize by writing assembler
programming
> manually in our own?  It will help that Pentium 4 will run much
faster than
> Pentium III.  Also, it will help that Pentium III will run much
faster than
> Pentium Pro and then 486 and so.

No, not really.

On the other hand, if your program runs fast enough on a 486 there is
no reason what so ever to optimize it further for a Pentium 4. It will
of course run a 100 times faster anyway.

If there is a good reason to speed optimize by using assembly
language, you are *always* going to target the newest and fastest
processor. Otherwise the effort isn't worth it.

If your program is slow on a 486, just buy a second hand Pentium III
and it's fast again!


Bo Persson

Bryan Parkoff wrote:
>     It is very annoying for us to write assembler programming before we want
> to optimize them by switching 386, 486, 586, or 686.
>     For example, C/C++ compiler is flexible that it can optimize by choosing
> 386, 486, 586, or 686.  Linux or Unix are very picky with C/C++ compiler
> that it always COERCE us (novice and experienced users) to compile
> everything before we can be able to install the software on the proper Intel
> processor type.  Microsoft does not like the way how Linux and Unix do with
> C/C++ compiler so they always provide pre-binary software such as ELF.  (I
> know Linux or Unix do have ELF).
>     I realize that if I choose to use Pentium 4 on existing Pentium III, it
> will cause Pentium III to be much slower than Pentium 4.  It is interesting
> that Pentium 4 can hurt Pentium III.  Pentium III can hurt Pentium 4.  It is
> what Matt Taylor quoted.
>     Is there a way that we can optimize by writing assembler programming
> manually in our own?  It will help that Pentium 4 will run much faster than
> Pentium III.  Also, it will help that Pentium III will run much faster than
> Pentium Pro and then 486 and so.
>     Is there a way that we can study optimization in our own without help
> from C/C++ compiler's optimization automatically?  If we are smarter enough,
> we have our ability to do optimization without needing help to use the
> switch like command line under C/C++ compiler, but I don't know if MASM does
> have the switch.  Please advise.

I advise you not to start any "Windows is superior to Unix" trolls
in a public newsgroup.

Also, people have told you several times that an assembler does not
perform ANY optimization.

"Bo Persson" <bop2@telia.com> wrote in message
news:LZ5pb.32011$mU6.90282@newsb.telia.net...
<snip>
> If there is a good reason to speed optimize by using assembly
> language, you are *always* going to target the newest and fastest
> processor. Otherwise the effort isn't worth it.
>
> If your program is slow on a 486, just buy a second hand Pentium III
> and it's fast again!

Or use a better algorithm. This is very often the right answer and just as
frequently overlooked. Bad algorithms explode just as badly on newer
hardware.

-Matt

Nudge,
> Also, people have told you several times that an assembler does not
> perform ANY optimization.
    I do understand completely that assembler does not do optimization (I
know that MASM, TASM, NASM, etc don't do optimization), but only C/C++
compiler do optimization.  It is good.  I am glad that GCC C/C++ compiler
can optimize inline __asm functions, but Visual C++ 6.0 / 7.1 do not.  I am
disappointed that it seems like Microsoft is abusing by removing inline
__asm functions that will be next version of Visual C++ 8.0.  We will find
this out soon.
    My question is: Is DJGPP similar to GCC C/C++ compiler that it allows me
to optimize my source code by C/C++ compiler and including inline __asm
functions like Matt quoted?
    Do you recommend that I use GCC C/C++ compiler to write my emulator
project including inline __asm functions?  Then, it will be optimized
completely before it will become DLL.  Next, I can put DLL into
Windows\System directory.  I tell Visual C++ 6.0 / 7.1 to import DLL
functions using extern "C" that will be combined with Win32 API and DirectX
9.0.
    Is it very simple solution?  Hint--I don't know if Windows OS will
reject DLL if it does not have Microsoft's definition like dllimport.....

Bryan Parkoff

Bryan Parkoff wrote:
> I do understand completely that assembler does not do
> optimization but only C/C++ compiler do optimization.

Right.

> I am glad that GCC C/C++ compiler can optimize inline __asm
> functions [...]

Stop right there. What makes you think that gcc can "optimize"
inline assembly? What optimization(s) do you have in mind?

http://gcc.gnu.org/onlinedocs/gcc-3.3.2/gcc/Extended-Asm.html

"Bryan Parkoff" <nospam@nospam.com> wrote in message
news:Efcpb.21373$qo4.19326@twister.austin.rr.com...
> Nudge,
> > Also, people have told you several times that an assembler does not
> > perform ANY optimization.
>     I do understand completely that assembler does not do optimization (I
> know that MASM, TASM, NASM, etc don't do optimization), but only C/C++
> compiler do optimization.  It is good.  I am glad that GCC C/C++ compiler
> can optimize inline __asm functions, but Visual C++ 6.0 / 7.1 do not.  I
am
> disappointed that it seems like Microsoft is abusing by removing inline
> __asm functions that will be next version of Visual C++ 8.0.  We will find
> this out soon.

To clarify what I had said, it is not able to optimize the assembly itself;
it is able to optimize around the assembly. For example:

int a, b, c;

a = 2;
b = 3;
_asm
{
 mov eax, [a]
 add eax, [b]
 mov [c], eax
}
return c;

This is going to look like this in VC:

mov [ebp-4], 2 ; a
mov [ebp-8], 3 ; b
mov eax, [ebp-4]
add eax, [ebp-8]
mov [ebp-12], eax
mov eax, [ebp-12]
ret

Obviously this is inefficient. VC has to put variables in memory to transfer
them into or out of an inline assembly block. For comparison, in GCC, we
would write:

int a, b, c;

a = 2;
b = 3;
asm("addl %1, %0" : "=r" (c) : "0" (a), "r" (b));
return c;

Here the compiler can pick any registers for a and b, and it will only have
to re-read the variable a from memory. This is much more optimal. Now the
assembly listing will look something like this (in Intel format):

mov eax, 2
mov ecx, 3
add eax, ecx
ret

GCC gives you a lot of control over where the assembly code looks for its
variables. I forced them into registers in my example, but you can force it
into memory or let GCC pick memory or registers. This data goes into GCC's
register allocation so it can optimize the surrounding code.

>     My question is: Is DJGPP similar to GCC C/C++ compiler that it allows
me
> to optimize my source code by C/C++ compiler and including inline __asm
> functions like Matt quoted?

DJGPP is GCC on top of DOS. If you're working in Windows, you should use
MinGW which is GCC on top of Windows.

>     Do you recommend that I use GCC C/C++ compiler to write my emulator
> project including inline __asm functions?  Then, it will be optimized
> completely before it will become DLL.  Next, I can put DLL into
> Windows\System directory.  I tell Visual C++ 6.0 / 7.1 to import DLL
> functions using extern "C" that will be combined with Win32 API and
DirectX
> 9.0.

VC is usually faster, but the new GCC 3.x series of compilers are very
competitive. You can write your code so that it can be compiled on both GCC
and VC, and then you can pick which one to use based on which one is faster.

>     Is it very simple solution?  Hint--I don't know if Windows OS will
> reject DLL if it does not have Microsoft's definition like dllimport.....

Microsoft's standard for executable files on Windows is called a PE file.
MinGW will produce PE files. You can link these with VC, or you can link
them with the MinGW linker. In either case, the program runs fine.

-Matt

Matt,

    Thank you for explaining.  It helps me to understand better now.  Where
did you get the information that inline __asm function will be removed for
the next version of Visual C++ 8.0?  I have connected to Microsoft's .Net
server and read April 2003 MSDN.  I do see that MASM and inline __asm are
there.  I doubt that Microsoft has intention to remove from MSDN.  If they
do, it will make programmers angry at them.
    Where can I get MinGW software?

-- 
Bryan Parkoff

"Matt Taylor" <para@tampabay.rr.com> wrote in message
news:Bajpb.89639$RP2.45084@twister.tampabay.rr.com...
> "Bryan Parkoff" <nospam@nospam.com> wrote in message
> news:Efcpb.21373$qo4.19326@twister.austin.rr.com...
> > Nudge,
> > > Also, people have told you several times that an assembler does not
> > > perform ANY optimization.
> >     I do understand completely that assembler does not do optimization
(I
> > know that MASM, TASM, NASM, etc don't do optimization), but only C/C++
> > compiler do optimization.  It is good.  I am glad that GCC C/C++
compiler
> > can optimize inline __asm functions, but Visual C++ 6.0 / 7.1 do not.  I
> am
> > disappointed that it seems like Microsoft is abusing by removing inline
> > __asm functions that will be next version of Visual C++ 8.0.  We will
find
> > this out soon.
>
> To clarify what I had said, it is not able to optimize the assembly
itself;
> it is able to optimize around the assembly. For example:
>
> int a, b, c;
>
> a = 2;
> b = 3;
> _asm
> {
>  mov eax, [a]
>  add eax, [b]
>  mov [c], eax
> }
> return c;
>
> This is going to look like this in VC:
>
> mov [ebp-4], 2 ; a
> mov [ebp-8], 3 ; b
> mov eax, [ebp-4]
> add eax, [ebp-8]
> mov [ebp-12], eax
> mov eax, [ebp-12]
> ret
>
> Obviously this is inefficient. VC has to put variables in memory to
transfer
> them into or out of an inline assembly block. For comparison, in GCC, we
> would write:
>
> int a, b, c;
>
> a = 2;
> b = 3;
> asm("addl %1, %0" : "=r" (c) : "0" (a), "r" (b));
> return c;
>
> Here the compiler can pick any registers for a and b, and it will only
have
> to re-read the variable a from memory. This is much more optimal. Now the
> assembly listing will look something like this (in Intel format):
>
> mov eax, 2
> mov ecx, 3
> add eax, ecx
> ret
>
> GCC gives you a lot of control over where the assembly code looks for its
> variables. I forced them into registers in my example, but you can force
it
> into memory or let GCC pick memory or registers. This data goes into GCC's
> register allocation so it can optimize the surrounding code.
>
> >     My question is: Is DJGPP similar to GCC C/C++ compiler that it
allows
> me
> > to optimize my source code by C/C++ compiler and including inline __asm
> > functions like Matt quoted?
>
> DJGPP is GCC on top of DOS. If you're working in Windows, you should use
> MinGW which is GCC on top of Windows.
>
> >     Do you recommend that I use GCC C/C++ compiler to write my emulator
> > project including inline __asm functions?  Then, it will be optimized
> > completely before it will become DLL.  Next, I can put DLL into
> > Windows\System directory.  I tell Visual C++ 6.0 / 7.1 to import DLL
> > functions using extern "C" that will be combined with Win32 API and
> DirectX
> > 9.0.
>
> VC is usually faster, but the new GCC 3.x series of compilers are very
> competitive. You can write your code so that it can be compiled on both
GCC
> and VC, and then you can pick which one to use based on which one is
faster.
>
> >     Is it very simple solution?  Hint--I don't know if Windows OS will
> > reject DLL if it does not have Microsoft's definition like
dllimport.....
>
> Microsoft's standard for executable files on Windows is called a PE file.
> MinGW will produce PE files. You can link these with VC, or you can link
> them with the MinGW linker. In either case, the program runs fine.
>
> -Matt
>
>

"Bryan Parkoff" <nospam@nospam.com> wrote in message
news:Svkpb.21558$qo4.1338@twister.austin.rr.com...
> Matt,
>
>     Thank you for explaining.  It helps me to understand better now.
Where
> did you get the information that inline __asm function will be removed for
> the next version of Visual C++ 8.0?  I have connected to Microsoft's .Net
> server and read April 2003 MSDN.  I do see that MASM and inline __asm are
> there.  I doubt that Microsoft has intention to remove from MSDN.  If they
> do, it will make programmers angry at them.
>     Where can I get MinGW software?
<snip>

1. From conversation with people working on VC 8
2. From AMD K8 docs (VC 8 is the first VC compiler to support AMD-64!)
3. From the PDC (Professional Developer's Conference)

Yes, it is a very bad idea to remove inline assembly, but they're doing it
anyway. I was reading one of C. A. R. Hoare's famous papers on programming
language design
(http://www.cs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf) and he
recommends inclusion of inline assembly.

MinGW can be obtained here: http://www.mingw.org/

-Matt

"Matt Taylor" <para@tampabay.rr.com> wrote in message news:<A0mpb.91065$RP2.74691@twister.tampabay.rr.com>...

> Yes, it is a very bad idea to remove inline assembly, but they're doing it
> anyway. I was reading one of C. A. R. Hoare's famous papers on programming
> language design
> (http://www.cs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf) and he
> recommends inclusion of inline assembly.


I'm sorry, a 30 year old treatise on programming language design, even
by someone as respectable as Hoare, is mostly ignorable.  We have
learned a few things since 1973...  Heck, in 1973 structured
programming was still controversial!

In any event, I personally don't find the lack of inline assembler a
big issue.  First, as a feature it's quite rare in languages other and
C or C++, second, it's hardly difficult to put your assembler code in
a different module (which is probably a good idea in general anyway),
and third, it certainly makes things a pain for the compiler writers
and tends to make a hash out of any attempts at optimization.

On Mon, 03 Nov 2003 05:50:24 GMT, "Matt Taylor" <para@tampabay.rr.com> wrote:

>"Bryan Parkoff" <nospam@nospam.com> wrote in message
>news:Svkpb.21558$qo4.1338@twister.austin.rr.com...
>> Matt,
>>
>>     Thank you for explaining.  It helps me to understand better now.
>Where
>> did you get the information that inline __asm function will be removed for
>> the next version of Visual C++ 8.0?  I have connected to Microsoft's .Net
>> server and read April 2003 MSDN.  I do see that MASM and inline __asm are
>> there.  I doubt that Microsoft has intention to remove from MSDN.  If they
>> do, it will make programmers angry at them.
>>     Where can I get MinGW software?
><snip>
>
>1. From conversation with people working on VC 8
>2. From AMD K8 docs (VC 8 is the first VC compiler to support AMD-64!)
>3. From the PDC (Professional Developer's Conference)
>
>Yes, it is a very bad idea to remove inline assembly, but they're doing it
>anyway.

Has anyone mentioned *why* they would be so presumptuous as to
do such a thing?  Microsoft has been... "funny" about the whole
assembly language issue for some time now, for reasons which... they
don't seem to be terribly forthcoming.  What's it to *them*, if I or anyone
else chooses to program in asm, in whole or in part?  Maybe it's just
me, but... I don't like the smell of it.

Jeff

http://www.jefftturner.com

pH wrote:
> On Mon, 03 Nov 2003 05:50:24 GMT, "Matt Taylor"
> <para@tampabay.rr.com> wrote:
>
>> "Bryan Parkoff" <nospam@nospam.com> wrote in message
>> news:Svkpb.21558$qo4.1338@twister.austin.rr.com...
>>> Matt,
>>>
>>>     Thank you for explaining.  It helps me to understand better
>>> now. Where did you get the information that inline __asm function
>>> will be removed for the next version of Visual C++ 8.0?  I have
>>> connected to Microsoft's .Net server and read April 2003 MSDN.  I
>>> do see that MASM and inline __asm are there.  I doubt that
>>> Microsoft has intention to remove from MSDN.  If they do, it will
>>>     make programmers angry at them. Where can I get MinGW software?
>> <snip>
>>
>> 1. From conversation with people working on VC 8
>> 2. From AMD K8 docs (VC 8 is the first VC compiler to support
>> AMD-64!)
>> 3. From the PDC (Professional Developer's Conference)
>>
>> Yes, it is a very bad idea to remove inline assembly, but they're
>> doing it anyway.
>
> Has anyone mentioned *why* they would be so presumptuous as to
> do such a thing?  Microsoft has been... "funny" about the whole
> assembly language issue for some time now, for reasons which... they
> don't seem to be terribly forthcoming.  What's it to *them*, if I or
> anyone else chooses to program in asm, in whole or in part?  Maybe
> it's just
> me, but... I don't like the smell of it.

I'm guessing it's something to do with the whole .NET thing. Since x86 asm
doesn't really exist in .NET, .NET being Java-style intepreted, (also asm is
completely un-safe-checkable, or whatever it's called, so rarely would be
allowed to run anyhow) there's not so much point to putting it in a .NET
focussed development tool.

If you're into conspiricy theories, then it's part of a giant plan to stop
windows emulation and re-take over the world: as long as they hold patents
on critical parts of .NET, noone can write a (legal) .NET emulator. So every
program they can get compiled to .NET IL is another program that won't run
on anything but the latest version Windows, since the IL will not be
backwards compatible, interpreters will only be available for the latest
versions of Windows, and VS won't produce anything but IL for the most
recent version.




Note for the awareness-impared: most of the above theory is made up :P

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :)
Add michael@ to emboss.co.nz - My inbox is always open

pH <high@cidity.level> wrote:

>On Mon, 03 Nov 2003 05:50:24 GMT, "Matt Taylor" <para@tampabay.rr.com> wrote:
>
>>Yes, it is a very bad idea to remove inline assembly, but they're doing it
>>anyway.

There is precedent for this.  Most of the compilers for Windows CE (which
are derived from VC++) do not support inline assembly.

>Has anyone mentioned *why* they would be so presumptuous as to
>do such a thing?  Microsoft has been... "funny" about the whole
>assembly language issue for some time now, for reasons which... they
>don't seem to be terribly forthcoming.  What's it to *them*, if I or anyone
>else chooses to program in asm, in whole or in part?  Maybe it's just
>me, but... I don't like the smell of it.

It's not such a big secret, and they've been saying it for a decade.
Inline assembler makes it really easy to write crappy, opaque, unreadable,
unoptimizable code.  When people put crappy code in their applications and
drivers, their applications and drivers crash.  When a Windows application
crashes, 90% of the public blames Microsoft and calls Microsoft technical
support.  Microsoft is sick and tired of paying technical support salaries
for the poor code of others.

On a less conspiracy-theory-like note, inline assembly becomes quite
problematic when you are targeting multiple processors.  With the Itanium
and the AMD 64-bit processors, we now have to worry about multiple
processors.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

"pH" <high@cidity.level> wrote in message
news:1t2eqvs3ofr2u1rvbcglst7sj10n119pi5@4ax.com...
> On Mon, 03 Nov 2003 05:50:24 GMT, "Matt Taylor" <para@tampabay.rr.com>
wrote:
<snip>
> >Yes, it is a very bad idea to remove inline assembly, but they're doing
it
> >anyway.
>
> Has anyone mentioned *why* they would be so presumptuous as to
> do such a thing?  Microsoft has been... "funny" about the whole
> assembly language issue for some time now, for reasons which... they
> don't seem to be terribly forthcoming.  What's it to *them*, if I or
anyone
> else chooses to program in asm, in whole or in part?  Maybe it's just
> me, but... I don't like the smell of it.

The answer I was given was that someone with a lot of power didn't like
inline assembly.

I suspect they do not wish to support assembly for x86 and x86-64
side-by-side. They do not support inline assembly on Itanium. Most people I
talk to are convinced that assembly has no usefulness left and that it is
dead, so perhaps Microsoft decided that the feature is no longer worth
supporting.

-Matt

"Michael Brown" <see@signature.below> wrote in message news:<iDEpb.7353$Mn.206263@news.xtra.co.nz>...
> pH wrote:
> I'm guessing it's something to do with the whole .NET thing. Since x86 asm
> doesn't really exist in .NET, .NET being Java-style intepreted, (also asm is
> completely un-safe-checkable, or whatever it's called, so rarely would be
> allowed to run anyhow) there's not so much point to putting it in a .NET
> focussed development tool.
> 
> If you're into conspiricy theories, then it's part of a giant plan to stop
> windows emulation and re-take over the world: as long as they hold patents
> on critical parts of .NET, noone can write a (legal) .NET emulator. So every
> program they can get compiled to .NET IL is another program that won't run
> on anything but the latest version Windows, since the IL will not be
> backwards compatible, interpreters will only be available for the latest
> versions of Windows, and VS won't produce anything but IL for the most
> recent version.
> 
> Note for the awareness-impared: most of the above theory is made up :P


FWIW, there is an open source .NET implementation that MS is
sorta-kinda supporting and/or encouraging.  "Mono".

Bernd Beuster wrote:
> Matt Taylor wrote:
> 
>> The point of an assembler is that it does not optimize. There is no
>> assembler that will change the instructions you write to optimize the 
>> code.
>> Many assemblers will do size optimization by using the smallest form 
>> of an
>> instruction, but I'm guessing that you weren't asking about this. 
>> Assemblers
>> are WYSIWIG: what you see is what you get.
> 
> 
> There is.  I worked with a RISC-Assembler for a 32-bit 
> Fujitsu-Microcontroller which reordered the instructions to fill in the 
> delay slot.
> 
> 

x86 CPUs do not have delay slots. Jumps are immediate. They are not 
delayed by one instruction, like on "Microprocessors without Interlocked 
Pipeline Stages" (MIPS) based processors.
The best an assembler would be able to do is reorder instructions
_for a particular CPU_. But then it'd be doing things behind your back, 
which you don't want happening when you're programming in assembly. You 
use assembly so that you can use your Carbon-Based Optimizer(tm).
Most assemblers can partially optimize instructions for a certain CPU by 
picking the variant of an instruction that would execute the fastest on 
that CPU. They also generally check that the specified instruction 
exists on that particular CPU.

On Mon, 03 Nov 2003 22:54:56 -0800, Tim Roberts <timr@probo.com> wrote:

>pH <high@cidity.level> wrote:
>
>>On Mon, 03 Nov 2003 05:50:24 GMT, "Matt Taylor" <para@tampabay.rr.com> wrote:
>>
>>>Yes, it is a very bad idea to remove inline assembly, but they're doing it
>>>anyway.
>
>There is precedent for this.  Most of the compilers for Windows CE (which
>are derived from VC++) do not support inline assembly.
>
>>Has anyone mentioned *why* they would be so presumptuous as to
>>do such a thing?  Microsoft has been... "funny" about the whole
>>assembly language issue for some time now, for reasons which... they
>>don't seem to be terribly forthcoming.  What's it to *them*, if I or anyone
>>else chooses to program in asm, in whole or in part?  Maybe it's just
>>me, but... I don't like the smell of it.
>
>It's not such a big secret, and they've been saying it for a decade.
>Inline assembler makes it really easy to write crappy, opaque, unreadable,
>unoptimizable code.

Yeah, aside from the "unoptimizable" part... ya sure can't do that with
an HLL.

>  When people put crappy code in their applications and
>drivers, their applications and drivers crash.

Thanks, Tim, for the education.

>  When a Windows application
>crashes, 90% of the public blames Microsoft and calls Microsoft technical
>support.  Microsoft is sick and tired of paying technical support salaries
>for the poor code of others.

Oh for cryin' out loud.  Were you able to maintain a straight face when
you wrote that?  Sure, everybody knows that Microsoft is the world's most
prominent source of blazingly fast, error-free code.  Shining, innovative
examples abound.  So it makes perfect sense that when 90% of the
(computer using) public isn't sure which side of a CD goes "up", that
removing the option for inline assembler would cure the majority of MS's
tech support woes.

Joking aside, crappy code is a symptom of a problem which has nothing
whatsoever to do with assembly language, but... you knew that already.

>On a less conspiracy-theory-like note, inline assembly becomes quite
>problematic when you are targeting multiple processors.  With the Itanium
>and the AMD 64-bit processors, we now have to worry about multiple
>processors.

Sure.  This is not completely new.  But the solution is not to decide for
others.

Hey, I'm no conspiracy nut.  However, this would remove a rather significant
chunk of freedom, and leverage the playing field by a tad.  We're talking
about people who would proudly present entertainment software that's
very good at making a Pentium work every bit as well as a Z80.  Anybody
remember "Arcade"?  How does CFS or *any* of their 3D offerings stack
up against Quake et al?  One word: embarrassingly.  A look in the DirectX
SDK might provide a clue, as we see an 800K demo... of a spinning cube.

On the other hand... how many people are blindly running crap that's
happily feeding <who knows what> to Real Networks' servers?

I don't like having options removed, I don't like being "shielded" from what's
going on under the hood.

Jeff

http://www.jefftturner.com

jetrn@earthlink.net wrote:

>On Mon, 03 Nov 2003 22:54:56 -0800, Tim Roberts <timr@probo.com> wrote:
>
>>  When a Windows application
>>crashes, 90% of the public blames Microsoft and calls Microsoft technical
>>support.  Microsoft is sick and tired of paying technical support salaries
>>for the poor code of others.
>
>Oh for cryin' out loud.  Were you able to maintain a straight face when
>you wrote that?

Absolutely, because even if you find it distasteful, it is true.

Example.  As you probably know, Windows XP now has a feature such that if
your machine blue screens, it will take a minidump and offer to e-mail that
dump to Microsoft.  A lot of people send those in, so they have accumulated
an incredible database of crash reports.  Roughly 30% of those crashes are
caused by display drivers -- drivers which Microsoft did not write, but
clearly gets blamed for.
-- 
- Tim Roberts, timr@probo.com
  Providenza & Boekelheide, Inc.

Tim Roberts <timr@probo.com> writes:
> jetrn@earthlink.net wrote:
> 
> >On Mon, 03 Nov 2003 22:54:56 -0800, Tim Roberts <timr@probo.com> wrote:
> >
> >>  When a Windows application
> >>crashes, 90% of the public blames Microsoft and calls Microsoft technical
> >>support.  Microsoft is sick and tired of paying technical support salaries
> >>for the poor code of others.
> >
> >Oh for cryin' out loud.  Were you able to maintain a straight face when
> >you wrote that?
> 
> Absolutely, because even if you find it distasteful, it is true.
> 
> Example.  As you probably know, Windows XP now has a feature such that if
> your machine blue screens, it will take a minidump and offer to e-mail that
> dump to Microsoft.  A lot of people send those in, so they have accumulated
> an incredible database of crash reports.  Roughly 30% of those crashes are
> caused by display drivers -- drivers which Microsoft did not write, but
> clearly gets blamed for.

XP is of NT heritage, isn't it?
Display drivers were in ring 3 of NT (<=3.51), weren't they?

Who chose to move display drivers from ring 3 to ring 0 back in the late 90s?

Was it the nasty NVidea gnomes? 
The meddlesome Matrox munchkins?
The anarchic ATI elves?

Or was it Microsoft?

Phil
-- 
Unpatched IE vulnerability: Alexa Related Privacy Disclosure
Description: Unintended disclosure of private information when 
             using the Related feature
Reference: http://www.secunia.com/advisories/8955/
Reference: http://www.imilly.com/alexa.htm

"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message
news:87he1h1vq7.fsf@nonospaz.fatphil.org...
> Tim Roberts <timr@probo.com> writes:
<snip>
> > Example.  As you probably know, Windows XP now has a feature such that
if
> > your machine blue screens, it will take a minidump and offer to e-mail
that
> > dump to Microsoft.  A lot of people send those in, so they have
accumulated
> > an incredible database of crash reports.  Roughly 30% of those crashes
are
> > caused by display drivers -- drivers which Microsoft did not write, but
> > clearly gets blamed for.
>
> XP is of NT heritage, isn't it?
> Display drivers were in ring 3 of NT (<=3.51), weren't they?
>
> Who chose to move display drivers from ring 3 to ring 0 back in the late
90s?
>
> Was it the nasty NVidea gnomes?
> The meddlesome Matrox munchkins?
> The anarchic ATI elves?
>
> Or was it Microsoft?

It was done for performance reasons. Business motivation should be obvious;
if your customers dislike your performance, you improve it.

Windows Server 2003 takes a step back toward ring 3 display drivers. I don't
know exactly how it works, but they can recover from many driver crashes
now. Longhorn goes even further. Drivers can be run in ring 3 again, and
they can also be written in .NET. Since .NET avoids the dangling pointer
problem, no .NET driver can corrupt any memory besides its own, so the
kernel need not panic. Normally the kernel simply assumes the worst and blue
screens. Drivers that are not time-critical can be run in ring 3. I'm going
to guess that the Intel UHCI USB driver is one that they had in mind.

Interestingly enough, they also claim Longhorn has hard real-time
capabilities. It will be interesting to see how they harmonize garbage
collection with real-time requirements. My guess is two words: reference
counting.

-Matt

On Wed, 05 Nov 2003 20:12:10 -0800, Tim Roberts <timr@probo.com> wrote:

>jetrn@earthlink.net wrote:
>
>>On Mon, 03 Nov 2003 22:54:56 -0800, Tim Roberts <timr@probo.com> wrote:
>>
>>>  When a Windows application
>>>crashes, 90% of the public blames Microsoft and calls Microsoft technical
>>>support.  Microsoft is sick and tired of paying technical support salaries
>>>for the poor code of others.
>>
>>Oh for cryin' out loud.  Were you able to maintain a straight face when
>>you wrote that?
>
>Absolutely, because even if you find it distasteful, it is true.

No, I don't find it distasteful; rather, a bit of a stretch, or an erroneous
conclusion drawn from incomplete information.

>Example.  As you probably know, Windows XP now has a feature such that if
>your machine blue screens, it will take a minidump and offer to e-mail that
>dump to Microsoft.  A lot of people send those in, so they have accumulated
>an incredible database of crash reports.

I can well imagine...

>  Roughly 30% of those crashes are
>caused by display drivers -- drivers which Microsoft did not write, but
>clearly gets blamed for.

Why "clearly"?  (I ask, because you were talking about the XP feature)

Another thing... if you've spent any time in various hardware related groups
(motherboard, graphics card), it doesn't take very long to realize a common
element in the "problem related" posts.  The overwhelming majority of these
indicate that they're running... well, no point in beating around the bush,
non-Intel hardware.  Virtually *any*one who desires to use their computer
as a digital audio workstation (particularly in a professional studio
environment), has either taken the advice or learned the hard way, that
there are chipsets (and their drivers) to be avoided.

I am not, at this time, afforded the luxury of multiple computers, so... my
system is a "does everything" box (as was the one before it).  It's *packed*
with hardware, and... the number of times it's blue screened, have been
very few.  Of those, Zone Alarm caused two (and ZA went bye byes), and
a recent Rhino3D demo caused one... or two, maybe.

The Rhino incidents may well have been related to the GeForce 3 drivers,
or nVidia's OpenGL implementation, or... who knows what, but... Rhino is
also the only thing which can currently bring my system down, so... (and
it's a shame, too, because Rhino is an absolutely *wonderful* modeler).

Point being - you can be sure that I'm running (and have run) the same
video drivers that _appeared_ to be the cause of BSODs--according to
the "mini dump"--for many of the people who told the error reporting
service to go ahead and email a report to MS.

The same drivers, running the same code, written the same way.

Removing the option to write in asm, is *hardly* a solution to problems
pertaining to tech support issues, but... I can sympathize... with members
on *both* sides of the issue, actually.  For one thing, most people simply
don't know what to do, or who to turn to, when there's a problem.  And I'll
tell ya what... having fielded many tech related "emergencies"... tech support
personnel has my most profound, very deepest sympathies, and I can fully
appreciate the desire for *some*thing... *any*thing, to alleviate.

I can *not*, however, accept that this move with regard to VC 8 has anything
whatsoever to do with it.

Jeff

http://www.jefftturner.com