how about a LINUX CHIP?

how about a LINUX CHIP?

Post by Fredrik Lundho » Thu, 29 Oct 1998 04:00:00





>    There is one thing that would be _very_ nice: MMU able to keep
>several contexts at the same time. That is, all you get in user mode
>is one of them, but in the priv mode you can use additional commands
>able to address things from any context. That would mean that you
>don't have to reload the context on each c/s, only when you are switching
>to something currently not loaded. Think of 8 contexts simultaneously.

Well this is already implemented in in SPARC-chips!
Different implentations ranges from 4096 (hypersparc - 66)  to 65535
(supersparc) dont know the values for the UltraSPARC.

Quote:>--
>"You're one of those condescending Unix computer users!"
>"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

Fredrik
 
 
 

how about a LINUX CHIP?

Post by H. Peter Anv » Thu, 29 Oct 1998 04:00:00




In newsgroup: comp.os.linux.development.system

Quote:

> [1] I say ``RISC'' chips to exclude x86. What's this
> optimized for? It's anyone's guess ...

8080A/8085 compatibility, and Intel profit.

        -hpa

--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

 
 
 

how about a LINUX CHIP?

Post by H. Peter Anv » Thu, 29 Oct 1998 04:00:00




In newsgroup: comp.os.linux.development.system


> :  There is one thing that would be _very_ nice: MMU able to keep
> : several contexts at the same time. That is, all you get in user mode
> : is one of them, but in the priv mode you can use additional commands
> : able to address things from any context. That would mean that you
> : don't have to reload the context on each c/s, only when you are switching
> : to something currently not loaded. Think of 8 contexts simultaneously.
> [...]

> NO! Fallacy!

> Please read Hennessy & Patterson: ``Computer Architecture -
> A Quantitative Approach'' and rethink your statement. While
> you may well reduce your context switch time to zero, your
> scheme will certainly increase the clock cycle time, resulting
> in an overall increase in runtime for all but the most
> I/O intensive application.

> I wish the well-meaning people doing F-CPU would read this
> book too ...

Actually, this is a very common approach in many architectures.  It
widens your TLB tags somewhat, but the cost is not nearly as
prohibitive as you make it sound.

        -hpa
--
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bah' -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misrables

 
 
 

how about a LINUX CHIP?

Post by Paul Schmi » Thu, 29 Oct 1998 04:00:00





>: A proper VM will execute only slightly slower than a nativce machine. I
>: see no reason to think that hardware will buy much, and the cost of
>: going to new technology for speed is high.

>Not necessarily true.

>Current RISC chips [1] are optimized to run C and C-like
>languages very fast. Of course, that's because C is probably
>the most frequently used language judging by the amount of
>time a chip spends running it. If you believe that Java,
>Smalltalk, Haskell or another language could actually become
>common, then you need to rethink your assumptions and may
>need to add some primitives to optimize, for example,
>garbage collection or functional evaluation or typed
>pointers. This obviously requires a leap of faith - none of
>these languages look like they might overtake C (or C++) any
>time soon, which is a shame :-(

Processors are NOT C based, C is really a close relative to assembler,
which has a direct relation to machine language.  Garbage collection,
functional evaluation, et al, are functions of a specific language, so
including them in the processor, has to be a very careful decision,
processor real-estate is very tight, so if that space can be used for
non-language specific functionality then that is a better idea.

Quote:>[1] I say ``RISC'' chips to exclude x86. What's this
>optimized for? It's anyone's guess ...

The X86 is a CISC class family of chips,  not a RISC class.

--
Paul Schmidt
Your Computer is our Business

web  : www.interlog.com/~pschmidt

 
 
 

how about a LINUX CHIP?

Post by Richard Jone » Fri, 30 Oct 1998 04:00:00




:>: A proper VM will execute only slightly slower than a nativce machine. I
:>: see no reason to think that hardware will buy much, and the cost of
:>: going to new technology for speed is high.
:>
:>Not necessarily true.
:>
:>Current RISC chips [1] are optimized to run C and C-like
:>languages very fast. Of course, that's because C is probably
[...]

: Processors are NOT C based, C is really a close relative to assembler,
: which has a direct relation to machine language.  Garbage collection,
: functional evaluation, et al, are functions of a specific language, so
: including them in the processor, has to be a very careful decision,
: processor real-estate is very tight, so if that space can be used for
: non-language specific functionality then that is a better idea.

I don't believe I said anything about processors being ``C
based''. Please reread what I said.  Clearly current RISC
processors are *optimized to run C-like languages very
fast*. If you don't believe me, go back and read the
original thesis on RISC chips [I'll dig up the reference if
you want it].

Nor did I say anything about including garbage collection,
functional evaluation et al in the chip directly. Please
reread what I said. I merely stated that to support GC
(etc.) and support it well, you would need to quantify the
kind of operations that are commonly generated by the
compiler and optimize for these common cases. If necessary,
iterate the process by changing the compiler to suit the
processor and so on. Make the common case fast, and the
fast case common, as they say ...

As a made up example, it might be that GC is performed 20%
of the time and that triple pointer indirections account for
50% of the time taken to do GC. You could therefore (by
Amdahl's law) get a ~11% speed up (maximum) by introducing a
new instruction which does triple pointer indirections
really fast. All things being equal. In reality, all things
are not equal, and adding such an instruction would add
considerable complexity to the chip and lengthen the clock
cycle. But you get the idea ...

Nothing here about putting full generational GC engines into
the chip ...

Don't take my word for it, however. It turns out that the
next generation of Sun's Java chips will take exactly the
approach I have outlined above. The first generation, you
will recall, attempted to implement a subset of the JVM
directly, which was a daft idea.

:>[1] I say ``RISC'' chips to exclude x86. What's this
:>optimized for? It's anyone's guess ...

: The X86 is a CISC class family of chips,  not a RISC class.

Yes, and the point of saying exactly the same
thing again was ...?

Rich.

--
-      Richard Jones. Linux contractor London and SE areas.        -
-    Very boring homepage at: http://www.annexia.demon.co.uk/      -
- You are currently the 1,991,243,100th visitor to this signature. -
-    Original message content Copyright (C) 1998 Richard Jones.    -

 
 
 

how about a LINUX CHIP?

Post by Paul Schmi » Fri, 30 Oct 1998 04:00:00








>:>: A proper VM will execute only slightly slower than a nativce machine. I
>:>: see no reason to think that hardware will buy much, and the cost of
>:>: going to new technology for speed is high.
>:>
>:>Not necessarily true.
>:>
>:>Current RISC chips [1] are optimized to run C and C-like
>:>languages very fast. Of course, that's because C is probably
>[...]

>: Processors are NOT C based, C is really a close relative to assembler,
>: which has a direct relation to machine language.  Garbage collection,
>: functional evaluation, et al, are functions of a specific language, so
>: including them in the processor, has to be a very careful decision,
>: processor real-estate is very tight, so if that space can be used for
>: non-language specific functionality then that is a better idea.

>I don't believe I said anything about processors being ``C
>based''. Please reread what I said.  Clearly current RISC
>processors are *optimized to run C-like languages very
>fast*. If you don't believe me, go back and read the
>original thesis on RISC chips [I'll dig up the reference if
>you want it].

Semantics, you really ended up saying the same thing, and I still don't
agree, languages are often designed to make use of certain processor
design aspects, for example C makes heavy use of the stack, most
processors have some form of stack based process....

Quote:>Nor did I say anything about including garbage collection,
>functional evaluation et al in the chip directly. Please
>reread what I said. I merely stated that to support GC
>(etc.) and support it well, you would need to quantify the
>kind of operations that are commonly generated by the
>compiler and optimize for these common cases. If necessary,
>iterate the process by changing the compiler to suit the
>processor and so on. Make the common case fast, and the
>fast case common, as they say ...

Okay, but you might as well have said it, because that is the intent
that came across, designing aspects into the processor that make
specific tasks easier.  Unfortunately the garbage collector or function
evaluator for one language, can be very different from the same component
of another language.  For example the GC for Java and the GC for BASIC do
the same function, but do it quite differently.

Quote:>As a made up example, it might be that GC is performed 20%
>of the time and that triple pointer indirections account for
>50% of the time taken to do GC. You could therefore (by
>Amdahl's law) get a ~11% speed up (maximum) by introducing a
>new instruction which does triple pointer indirections
>really fast. All things being equal. In reality, all things
>are not equal, and adding such an instruction would add
>considerable complexity to the chip and lengthen the clock
>cycle. But you get the idea ...

Okay do we optimize for the GC in Java, and watch performance in BASIC go
to hades, or do we optimize for Basic and watch Java performance suffer,
or do we optimize for both, and watch the whole system go down the
loo.

Quote:>Nothing here about putting full generational GC engines into
>the chip ...

Okay, but you implied it originally....

Quote:>Don't take my word for it, however. It turns out that the
>next generation of Sun's Java chips will take exactly the
>approach I have outlined above. The first generation, you
>will recall, attempted to implement a subset of the JVM
>directly, which was a daft idea.

Yeah, but those are designed to run a specific language, Java, running
software written in other languages, isn't a concern here....

--
Paul Schmidt
Your Computer is our Business

web  : www.interlog.com/~pschmidt

 
 
 

how about a LINUX CHIP?

Post by William McBri » Mon, 02 Nov 1998 04:00:00



: It only will "matter" if it can be deployed *IN COMPLETE SYSTEMS* at
: interestingly low prices.

Yes, well, as it said in the original:

  The chip will fit on PC motherboards. (Socket six or seven I think)

My intent in reposting this, BTW, was not to advocate it, but to seek more
information. I've been unable to find any reference to "FreeCPU" on either
AltaVista or Deja News, apart from this very thread. Has anyone else heard
of it? Surely there's a web site?

--
William McBrine    | http://www.clark.net/~wmcbrine/

 
 
 

how about a LINUX CHIP?

Post by Juergen Kreilede » Mon, 02 Nov 1998 04:00:00


Quote:>>>>> William McBrine writes:

    William> My intent in reposting this, BTW, was not to advocate it,
    William> but to seek more information. I've been unable to find
    William> any reference to "FreeCPU" on either AltaVista or Deja
    William> News, apart from this very thread. Has anyone else heard
    William> of it? Surely there's a web site?

http://f-cpu.dyn.ml.org/

        Juergen

--
Juergen Kreileder, Universitaet Dortmund, Lehrstuhl Informatik V
Baroper Strasse 301, D-44221 Dortmund, Germany
Phone: ++49 231/755-5806, Fax: ++49 231/755-5802