Nathan Matthews a écrit :
> 
> Wrong, depends on what flavour of x86
> 
> i386, i486, pentium, pentiumII pentiumIII athlon cyrix etc
> 
> There are even subtle differences between 486s and pentiums RTDSC register
> for instance,
> Even if the processors share the same instruction set the way you optimise
> for them may be different, instruction pairing for pipelines etc.
> 
> The Pentium has extra instructions than a 486.
> 
> These days processors are so complex and compilers so advanced you have to 'really'  know what you are doing to beat the compiler unless you want to access processor specific functions, (SSE for the Pentium III for example).
> 

Hum, no in fact beat compiler is very easy ! I have use C to write integer matrix multiplication (usual 3 loop algorithme compare to a cpu-specific hand optimise code) my average gain was 4, the best was x25 (yes 25 it's not a typo !) on a 1.2 Ghz Athlon on 512*512 matrix.

I used gcc and in my asm statement, i didn't used any SIMD code (MMX code for multiplication aren't useful at all), just prefetching.

nicO

> "jacob navia" <jacob@jacob.remcomp.fr> wrote in message news:9m5cff$1o6g$1@digitaldaemon.com...
> >
> > > Using asm is obviously inherently non-portable,
> >
> > What?
> > X86 assembly is more portable than C :-)
> >
> > It will run in:
> > Windows
> > Linux
> > Solaris
> > Be
> > FreeBSD
> >
> > And ALL SYSTEMS that use an X86 processor! This includes even the
> Macintosh
> > with its emulator.
> >
> >
> > ASSEMBLY LIVES!
> > :-)
> >
> >
> >
> >
> >

> 2. IMHO, a major flaw in C, and its successors, is the absence of nested functions. People who have never worked in languages that support them always belittle them, but IMHO they are extremely valuable tools. Obviously, like any tool, they can be abused, but when used effectively they can greatly simplify and clarify code. Nested functions are simply about scope. By providing a tool for managing scope more effectively, they can often eliminate the need for some global variables, or long, awkward parameter sequences and they can replace uses of macros that are often used as stand-ins for nested functions. They can eliminate a lot of code duplication that occurs in C simply because there is no convenient tool for encapsulating such code.

Actually I'd take nested classes over nested functions...

John.

Walter wrote:
> "Peter Curran" <pcurran@acm.gov> wrote in message
> news:3B857C48.64D774DB@acm.gov...
> 
>>Here are a few more comments on D:
>>1. The "->" operator is unnecessary, and IMHO should be discarded.
...
> I agree. It's on its way out.

...
>>3. IMHO, the "asm" statement should be eliminated from the language
>...
> 
> Using asm is obviously inherently non-portable, but since D is
> for systems apps, those apps will need asm from time to time. I specified the form it should take primarilly because I detest
>  the way it's done in gcc.
> 
...
Including an inline asm encourages keeping non-portable code in small pieces.  It makes it easier to get back into the language level code. Even if there is a small performance penalty, this is well justifiec.

John Carney wrote in message <9m5khh$1sgl$1@digitaldaemon.com>...
>Actually I'd take nested classes over nested functions...


D does have nested classes, but not "inner" classes ala Java.

"Peter Curran" <pcurran@acm.gov> wrote in message news:3B857C48.64D774DB@acm.gov...
> Here are a few more comments on D:
>
>
> 2. IMHO, a major flaw in C, and its successors, is the absence of nested functions.

You can have C with nested functions *today*.  They're a GCC feature.

--
Richard Krehbiel, Arlington, VA, USA
rich@kastle.com (work) or krehbiel3@home.com (personal)

Nathan Matthews wrote:
> 
> Just a little thought, I've used both inline asm and external asm, I have to say I think external asm with linkage is preferable.
> 
> I assume the reasoning for inline asm is speed, but on very small routines this may actually cause a slowdown.  All registers used must be pushed only the stack and then popped, people have no idea about what the compiler has been doing such as instruction pairing, using inline asm forces the compiler to abandon any optimisation it may have been doing.  You effectively lose the benefits of 'inlining' in which case why not make it a function call and write an external asm function thats linked in anyway.

If you can accomplish your objective any other way, you don't use inline asm. However, there are a few idioms I see inline asm used for:

- Accessing high performance timer/counter registers in the CPU.
Can't be done portably. Calling out to the OS is more of a
time hit than you want when you're trying to instrument speed-
critical code (like a game's rendering system) to figure out
where the slowdowns are.

- Inserting a break instruction in debugging code. Performance
isn't important here, and many OSes have a DebugBreak() or
equivalent, but in an embedded system without an OS, you have
to write your own break(). Performance isn't important at
all in this case, so outline asm is usually okay here, but
for some reason it's often done inline.

-Russell B

It isn't as bad as that. The DMC inline asm, for example, tracks register
usage, and so doesn't push/pop all the registers. It is also integrated with
the optimizer which means that worst case code isn't always
generated. -Walter

Nathan Matthews wrote in message <9m5dhv$1ohv$1@digitaldaemon.com>...
>Just a little thought, I've used both inline asm and external asm, I have
to
>say I think external asm with linkage is preferable.
>
>I assume the reasoning for inline asm is speed, but on very small routines this may actually cause a slowdown.  All registers used must be pushed only the stack and then popped, people have no idea about what the compiler has been doing such as instruction pairing, using inline asm forces the
compiler
>to abandon any optimisation it may have been doing.  You effectively lose the benefits of 'inlining' in which case why not make it a function call
and
>write an external asm function thats linked in anyway.
>
>I have a feeling allowing inline asm may lead to an equivalent horrible mightmare of #ifdefs we have today.
>
>Just a few thoughts.
>
>"Walter" <walter@digitalmars.com> wrote in message news:9m4rfe$1d5c$3@digitaldaemon.com...
>>
>>
>> Jim Eberle wrote in message <9m48up$1t4$1@digitaldaemon.com>...
>> >This would eliminate the #define brackets:
>> >asm(x86) {
>> >}
>> >
>> >asm(ppc) {
>> >}
>> >
>> >asm(sparc) {
>> >}
>> >
>> >You could then keep your asm blurbs together in the same file, and emit
>the
>> >right code based on the target hw.
>>
>>
>> That is an interesting idea!
>>
>>
>
>

Walter wrote:
> 
> It isn't as bad as that. The DMC inline asm, for example, tracks register
> usage, and so doesn't push/pop all the registers. It is also integrated with
> the optimizer which means that worst case code isn't always
> generated. -Walter

	btw, what did gcc get wrong?  Just curious.

Dan

Dan Hursh wrote in message <3B88A6DB.FD1D001D@infonet.isl.net>...
>Walter wrote:
>>
>> It isn't as bad as that. The DMC inline asm, for example, tracks register usage, and so doesn't push/pop all the registers. It is also integrated
with
>> the optimizer which means that worst case code isn't always generated. -Walter
>
> btw, what did gcc get wrong?  Just curious.


From my brief look at it, gcc doesn't actually implement an inline assembler. It just collects random strings and blindly passes them to the assembler.