newbie stupid question, a .NET processor?

  • Thread starter Thread starter rosty
  • Start date Start date
R

rosty

as long as there is the MSIL instruction set, why not making a (hardware)
processor fully supporting these instructions? does it make any sense?
 
Hi,

Rosty that was the way the mainframe computer was going.
But the hardware processor became complexer and complexer while the
advantage was not that big.

Therefore people started using the Microprocessor for there Software
(MicroSoft), and did more with a simpler processor and standarised
instruction sets.

Does this make sence?

Cor
 
Hi rosty,

Certainly.
What would be really cool is to have a co-processor for MSIL at the
beginning - going straight to MSIL is just not possible now.
 
The whole point of the PC revolution was to create cheap, generic hardware
that could run different operating systems and application software. If you
go back to tweaking hardware for specific software applications (like .Net)
you immediately reduce the number of vendors that can/will create hardware
for you. This in turn raises the cost.

I realize that some game software is still designed for specific video cards
but that limitation (can't play game X on PC1, game Y on PC2, etc.) is why
we ended up with dedicated game machines (Xbox et al.)

I for one would certainly NOT like to see hardware redesigned for
application code.
 
rosty said:
as long as there is the MSIL instruction set, why not making a (hardware)
processor fully supporting these instructions? does it make any sense?
Click to expand...

Dedicated hardware acceleration can create a tremendous increase in speed. There
could come a time when there are accelerators are built to be 'MSIL compilant'
and do just what you say, much as graphics cards are 'Direct X compliant' and
accelerate 3D rendering. But hardware creation requires a massive fixed cost
investment. Would there be enough demand for it? Will Microsoft someday try to
create this demand and offer a card that you can buy that will 'accelerate
Windows and its applications'?

Nah.

Bob
 
You all missed the boat with this one. The purpose of the MSIL code is
to hand the CLR a common langauge to compile. For example if I create
an app in VB and one in C# that do the same thing the same way the MSIL
code should look the same. You can precompile you app into binary with
the ingen.exe found in the dot net framework. The reason this is not
done at compilation by visual studio is so you can easily distribute the
code to the various machines it runs on the CLR then will compile it
into machine code that is tuned for that particular processor.

Why would you want to limit the hardware when a simple binary
compilation will solve this problem? This is not intended to be a
flame. Just a redirection of the discussion. I hope this helps you
understand the role of MSIL in the over all process.

Wiz
 
Hi Wizy,

Look at the subject.

You gave an answer on another question, was it the right boat you took a
ticket for?.

Cor
 
I appreciate the reallignment but if you read my answer you'll see that
while I didn't say there is no reason to have a processor to read the
MSIL code it could be inferred from the answer that of course you would
not have a new processor for MSIL code. The IL in MSIL is Intermediate
Langauge not final. While you could read this code with a special
processor it would be a waste. The ingen.exe does the final stage of
compilation of writing binary. Which is tuned for a specific processor.
You don't need to tell it which processor or buy one for that processor
it will write binary machine code or "Op" code based on which processor
you are compiling on.

If you dont' want to wait for the JIT you can call ingen directly which
aliviates the need for the special IL processor. It would be akin to
having a processor that read byte code for java which would help Java.
It really not necessary and would be a waiste for .NET. In the case of
Java you can't call the jitter to compile your code to binary. In .NET
you can it's called ingen.

This guy "Rosty" who wrote the original question probably wasn't aware
of ingen he is a "NEWbie". I know that almost three years ago I wasn't
aware of it. So I was just passing along the fact that there is an ingen
that can do what he wants.

I hope this helps you or anyone that was not aware of ingen.


Wiz
 
Wiz,
Did they?

If the chip knew MSIL, the CLR would not need to compile it! Correct?

Rosty is suggesting that "that particular processor" knows MSIL itself.
Bypassing the JIT step.
Why would you want to limit the hardware when a simple binary
compilation will solve this problem?
Click to expand...
I do however agree with this statement! Not so much as I see a need to
compile the MSIL, but that I see value in supporting both MSIL & Java Byte
Code. Having a

Just a thought
Jay
 
Rosty,
I understand there are processors that execute Java Byte Code directly, so I
would think processors that execute MSIL directly would be doable.

However this approaches the RISC (reduced instruction set) verses CISC
(complex instruction set) debate.

The biggest problem with a MSIL chip IMHO is when the MSIL is extended, such
as Generics support in version 2.0. I'm not sure if there are new
instructions per se, however there are changes to the JIT to support
Generics. With the JIT as we have now, just the JIT needs to change, and the
underlying chip stays the same. Also subsequent versions of the JIT can be
optimized to perform better, which means improved performance for existing
applications without requiring an upgrade of the CPU itself.

Hope this helps
Jay
 
Doh! clicked send too soon.
Code. Having a
Click to expand...
That should read: having a chip specific to one, would require the other to
be implemented in terms of the first...

Jay
 
Hi Wizzy,

Sorry but in my opinion you mis the boat by this one.

There have been (are) processors which have been abled to do very complex
things in the hardware from the proces.

In the .Net situation we are dealing with very complex but especialy wide
different situations, so making processors for that will be very complex.
(And as you probably saw with Jay B) gives disadvantages for newer platforms
like the pocket pc and things like that.

The format of the intermidiate language is not important in this question
and also not if it is posible to make code from it that direct fits to the
processor.

The question for me if it is wise to make a processor more near the
intermidatie code.

In my opinion that is a passed station, although companies like Intel will
do that of course in the same way as you get an extra trashbin in your new
model Car as an advantage.

Just my thought about it.

Cor
 
many thanks to all, at least now i know there are no projects on making such
a processor, i asked the question after I bought Tom Archer's book(2nd ed.)
and started to read it,he's going deep into C# and MSIL code, and i thought
that maybe as all CLR compliant languages generate the same IL code,
skipping JITing could increase somehow the overall performance. If that is
possible at all of course. Just a newbie thought.

To put it in other words, given the MSIL, is it possible to produce a
hardware that is executing this particular instruction set. And if the
answer is yes,then does it make any sense doing so? sorry if the question
sounds stupid.

ps. i did i google search, an MSDN search and a search on my hard disk for
'ingen' and didn't find anything except some German text on google
concerning some viruses.
 
Back
Top