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
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,
> >
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,
>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
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
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
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 accurate on
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, sparc64,
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
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,
hundreds maybe,
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
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?
>
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?
LAAETTR.
>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
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
>>
>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
>>
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
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
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
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
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 difference.
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
the entire design of
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 eventually.
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
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
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:
> 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,
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
32 matches
Mail list logo
