A .Net CPU

An anonymous reader writes "Windows for devices has an article about the .Net CPU. The chip is programmed with a subset of the CLR and runs the same software as the SPOT smart watches. Among other things, "[t]he computer module is implemented in the format of a 32-pin "DIP" (dual inline package) chip, allowing the module to conveniently plug into a standard 32-pin DIP socket. In addition, the ".netcpu CPU Module" integrates 4MB of nonvolatile Flash memory (interfaced via an SPI interface on the SoC). It also provides 24 general purpose digital I/O lines, which are multiplexed with other functions including 8 VTU ports, a USB port, two serial ports, and SPI and I2C interfaces." More information about the product can be found at the .netcpu company website."

.Not a .NET CPU

[Gopal.V]

It is really just a CPU on which CLR runs , not a real .NET CPU in hardware. (or so the TFA seems to indicate from the diagram). Also of the more convenient peices of the ECMA 335 spec.

It's an embedded chip which has a CLR on top of it. Nice idea, sorry that Sun thought of it earlier ( The Green Project [java.net]) - Sun seems to be consistently missing the BUS here. They came up with "Network is the computer" and now MS is selling ".NET " :)

I've seen a couple of stack based engines but by its polymorphic nature .NET bytecode is not suitable for a direct CPU (you could do something like dynamic translation [southern-storm.com.au] like the Crusoe chip had). But then it's still a JIT , right ? :)

Parrot

[hey]

I'm waiting for a Parrot [parrotcode.org] chip.
Now that would be exciting.

Never will be a direct chip for Parrot

[Gopal.V]

Parrot is not a very good design to put on a chip, for one single reason.

Too Many opcodes (1500 at my current count and growing).

Morover parrot has opcodes which do very complicated things like "print_nc" which prints a FLOATVAL constant. Compared to that IL opcodes are simpler and JVM is still more simpler (CVM [southern-storm.com.au] is even simpler - which is what I'm working on now).

Parrot is too complex, period.

Maybe its just me but....

[ezelkow1]

this thing seems like an overpriced piece of junk just trying to hawk its .NET and VS support. Most of the microcontrollers out there i have seen can in some way or another be programmed in C and its various forms. 200 dollars just for the cpu seems to be asking a lot when the only advantage i see is that is 4mb of flash, and other MC's can always be expanded to that anyway. Besides the fact that other MC's out there that are cheaper also contain a whole lot more peripherals and features than this one. But maybe thats just me

Another "Innovation" from Microsoft?

[nathanh]

Isn't this exactly like the Java CPU that Sun was selling a few years back? And it was simply a close relative of the Lisp processors from the 80s.

C#, Java. .Net, J2EE. CLR, JVM. .NET CPU, Java CPU. So should we expect Microsoft to simply repeat everything that Sun did with Java? If so, wake me up when they declare they're going to release CLR under an open source license.

Re:So

[Sj0]

What of things I've read saying that .net will be the default api in windows longhorn?

As a former DOS programmer, I can tell you that when Microsoft wants to get rid of an API, they're quite good at it. If they want to do it, win32 will be dead before the end of the decade, just like dos.

Re:Actually, it's an ARM7

[Pemdas]

I assume FBGA is a typo for FPGA.

When referring to packaging, FBGA is usually Fine Ball Grid Array. I really doubt it's a typo. From the programmers point of view, the package virtually never significant.

Overall, this sounds remarkably similar to picoJava [sun.com], which, last I checked, was going nowhere, and for good reason.

Designing bytecode formats for VMs is not really the same as designing opcodes for microprocessors -- shoehorning hardware that way is painful and generally results in less elegant, more expensive designs.

OTOH, the bytecodes in question aren't really significantly worse than, say, x86, and look where that is today...

Re:Virtual Java Virtual Machine

[mukund]

This has been available for a long time with open access to the design from Sun as the picoJava [sun.com] CPU core. It was not an economically viable CPU and I think this's one of the reasons why Sun released it.

Re:Scary (saracasm)

[tchernobog]

Although I agree with you that it isn't the case to troll everything that has "microsoft" into it, I think that an high income isn't the first requirement for someone that foreseek freedom of choice and information (why develop Free Software, else?).

The fact that 85% of the computer world use MS systems doesn't mean that it's the best thing to do. Still, things are (really) slowly changing. Maybe I'll live the day when the market share between MS and *nixes 'll be 50%-50%... and that would mean real competition, not just "smithe the infidel with teh big hammer" as almost everyone on both sides tries to do (often don't understanding really what's right to "fight" for).

Re:So

[cherberos]

It's not like there isn't anything like this for Java. The first that comes to mind is the TINI-board, from Dallas. There was another one with a more arcane Java-implementation, but less resource-overhead (Can't remember the name right now..). And those are just the ones I worked with. There should be others. So nothing unique here, except maybe that this is the first of this kind of firmware for .Net

Re:Maybe its just me but....

[mvdw]

Don't think of it as a product part, think of it more as a BASIC Stamp for people who want something more than a BASIC Stamp can manage.

BASIC Stamps are good for when you only want to do one, and don't want to lay out a board with crystal, peripherals, etc. Although I have a tendency to do my own boards, I can see that BASIC Stamps are good for some projects.

Re:Scary (saracasm)

[Tarwn]

I've seen .Net moving in quite heavily in the manufacturing world. This is one sector that MS has a strong hold on simply because there are so few people that want to sit down and write the hundreds of communications drivers, etc needed to create manufacturing data systems. Or maybe because once you buy a manufacturing system you don't want to switch brands until you get back out of the hole with it :P
A lot of the products I have seen (both data collection and warehouse-type) are moving to .Net SDK's, and a lot of internal application programming seems to be moving that way also.
The last major project I did was:
1 part config client and 1 part server
"please maximize uptime"
"please maximize scanning capabilities"
"please correct our last 9 months of errors and get it on the shelf in 2 months or less" .Net was the available choice (unless you consider VB6 as a valid choice...*shudder*) and despite the fact that the only other competing product was written in C++ (we think) we also managed to turn out a more efficient server (not that I don't think i could have made it even faster in C++, I just expected the other company's to suck that badly :P).

A lot of internal app's get written in .Net, as the valid choices are generally VB6 vs VC++ vs some flavor of .Net vs Excel VBA (you think I'm kidding). The few other languages the make it onto the plate are generally as bad as VB6, so I prefer to leave them unmentioned. About the only time I have seen it go beyond this is the few times I introduced the power of bash scripting something on my laptop's preferred partition (ie, not windows) ;).

Ok, enough rambling :)
-T

Re:So

[dan the person]

It's an ARM CPU, not a .NET CPU.

It loads ".NET Embedded" from firmware.

This is like saying an iPaq has a WindowsCE CPU.

"We are .not copying java"

[Anonymous Coward]

http://www.arm.com/products/solutions/Jazelle.html

http://www.netsilicon.com/products/netarmprocess or s/ns9775.jsp

http://www.developer.com/java/other/article.php/ 61 0041

http://www.ptsc.com/products/images/mpu.pdf

http://www.jopdesign.com/ (GPL'ed FPGA java cpu)

http://www.kiffer.be/k/products.html (?)

So will .net follow java everywhere without any own original ideas?

Duh ! ... It's an exe + bootstrap for JIT

[Gopal.V]

.NET is a JIT engine , it's designed explicitly for JIT'ing ... It does produce a .exe file which has a main which calls the Mscoree.dll with the current file and starts up the VM using the bytecode data. The EXE part is just bootstrap code , the rest is JIT'd .

Read this paper [64.233.167.104] about how many hoops you have to go through to get a decent interpreter for .NET. And it blatantly ignores the _Main() x86 native code that's in the .exe files.

Re:It is not a real CPU , from what I read.

[Anonymous Coward]

Not quite correct, ALL modern CPU's are based on a type of firmware (read Microcode).

Shouldn't you include a disclaimer with that, like "ALL modern CPU's does not include all modern CPU's"?

Re:Hmm, sounds familiar

[sosume]

Yeah riiiiight have you ever seriously looked at the spec of these 'java chips'? They are not as advanced as Sun may have you believe..

* No floating point 16-bit int instead of 32 bits.
* All types (byte, short, char, int and boolean) use 2 bytes,
though byte and short arrays use 1 byte per element.
* Only one-dimensional arrays (can use the index to simulate a 2-D array.)
* Single byte ASCII strings instead of two byte Unicode
* Only a single thread available, though a timer allows for
scheduling of multiple tasks. (Plus the VP objects run independently)
* No interfaces, though sub-classing of an abstract base class is allowed.
* A subset of the core libraries is available. (Remember also that
all linked classes must be downloaded with the program and fit into
the 32kb of memory.)
* No garbage collection. All objects created will last for the
duration of the program.

Compare that to this .NET chip....
* 384K of SRAM, single cycle access
* 27 MHz ARM7TDMI
* FBGA chip form
* ~450,000 instructions per second
* 4MB non volatile flash
* 1.8-volt core, 3.3-volt I/O
* 32768 Hz real-time clock
* 32-pin pinout, including 24 GPIO ports multiplexed with other functions (8 VTU ports, dual serial ports, SPI, and USB port)
* SPI and I2C interfaces

and its multithreaded, too

Re:ctrl-alt-del keys?

[DrSkwid]

it was funnier than *any* of your posts modded funny

Re:jP?

[NullProg]

TINI [ibutton.com]

Its been around for a while.
Enjoy,

Re:Hardware independence?

[hal2814]

Running bytecode will always be somewhat slower than native binary, but Sun has done a good job of getting most of the overhead out of the running code and into the VM startup. Most overhead people experience now with Java isn't from the VM at all but from the constraints Sun puts on the Java language specification (exs. ALL arrays must be bounds-checked, dynamically allocated memory must be garbage collected). C,C++,BASIC,etc. do not have these requirements built into their language specification and therefore their compiled code has a leg up if the user decides not to implementthese features.

With the vast improvements being made over the VM's design in Java's case, I wonder if a chip that natively runs the code would really be "hardware acceleration" vs. a stock chip with a good VM.

Re:Hmm, sounds familiar

[Glock27]

The aj-100 doesn't seem to have most of the limitations you mention, in particular it has floating point and 32 bit ints.

Read about it and some other Java chips here [particle.kth.se].

Re:Security ?

[Anonymous Coward]

From the previously linked page:

The fact that this fix works is only caused by the fact that the instruction fault (and nothing performance-critical) happens to be before the page fault in the IDT. If it hadn't been, Intel would be in some trouble.