I replied to davem at length but I think I forgot to "reply to all
recipients". The gist of it is Forth code density is so high on Forth
hardware that things like icaches aren't as important, and the factors
involved are entirely different. Like high-performance Forth engines
are tiny and draw neg
Followup to: <[EMAIL PROTECTED]>
By author:"David S. Miller" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Rick Hohensee writes:
> > Forth chips aren't modern in the true-multi-user sense, but if an
> > individual were to design such a beast they could get several of them,
> > hun
Yes, that was not easy to miss. I was simply being clear. The plan9
compiler, thus its take on inline asm, doesn't run on ia64 and alpha as far
as I can see from the latest release.
} NONE of my examples were about the x86.
}
} I gave the alpha as a specific example. The same issues are true
In article <[EMAIL PROTECTED]>,
Cort Dougan <[EMAIL PROTECTED]> wrote:
>I'm talking about _modern_ processors, not processors that dominate the
>modern age. This isn't x86.
NONE of my examples were about the x86.
I gave the alpha as a specific example. The same issues are true on
ia64, sparc6
>Cort Dougan writes:
> > I'm talking about _modern_ processors, not processors that dominate
>the
> > modern age. This isn't x86.
>
>Linus mentioned Alpha specifically. I don't see how any of the things
>he said were x86-centric in any way shape or form.
>
>All of his examples are entirely accur
I'm talking about _modern_ processors, not processors that dominate the
modern age. This isn't x86. I don't believe that even aggressive
re-ordering will cause a serious hit in performance on function calls.
Unconditional branches are definitely predictable so icache pre-fetches are
not more com
On Wed, Jul 04, 2001 at 09:54:05PM -0400, Rick Hohensee wrote:
> >
> > On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> > > That's with the GNU tools, without asm(), and without proper declaration
> > > of printf, as is my tendency. I don't actually return an int either, do I?
> >
>Now, you could probably argue that instead of inline asms we should have
>more flexibility in doing a per-callee calling convention. That would be
>good too, no question about it.
>
>Linus
>
Today's flamebait has been postponed. Happy July 4th. Peace.
Rick Hohensee
>
> On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> > That's with the GNU tools, without asm(), and without proper declaration
> > of printf, as is my tendency. I don't actually return an int either, do I?
> > LAAETTR.
>
> Under ISO C rules, this is illegal, since you must have
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> That's with the GNU tools, without asm(), and without proper declaration
> of printf, as is my tendency. I don't actually return an int either, do I?
> LAAETTR.
Under ISO C rules, this is illegal, since you must have a proper protot
In article <[EMAIL PROTECTED]>,
Cort Dougan <[EMAIL PROTECTED]> wrote:
>
>There isn't such a crippling difference between straight-line and code with
>unconditional branches in it with modern processors. In fact, there's very
>little measurable difference.
Oh, the small details get to you event
>>
>Cort Dugan
>> There isn't such a crippling difference between straight-line and code
>>with>
>> unconditional branches in it with modern processors. In fact, there's>
>>very
>> little measurable difference.
>>
>> If you're looking for something to blame hurd performance on I'd
>>suggest
>> th
Followup to: <[EMAIL PROTECTED]>
By author:Cort Dougan <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> There isn't such a crippling difference between straight-line and code with
> unconditional branches in it with modern processors. In fact, there's very
> little measurable differenc
What are advantages of this approach
--
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
PGP signature
There isn't such a crippling difference between straight-line and code with
unconditional branches in it with modern processors. In fact, there's very
little measurable difference.
If you're looking for something to blame hurd performance on I'd suggest
the entire design of Mach, not inline asm
On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> In other words, if you know the push sequence of your C compiler's
> function calls, you don't need asm("");.
You are very much forgetting _inline_ asm. And if you think that's
unimportant for performance, well, as Al would say, go
Because it's messy and unnecessary. Break this into asmlinkbuild,
asmlink.c, asmlink.h and asmlink.S, chmod +x asmlinkbuild, run it, and
behold a 6.
__
#..
# asmlinkbuild
gcc
17 matches
Mail list logo
