Slashdot Mirror
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."
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) - 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 natureQuidquid latine dictum sit, altum videtur
I'm waiting for a Parrot chip.
Now that would be exciting.
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 is even simpler - which is what I'm working on now).
Parrot is too complex, period.Quidquid latine dictum sit, altum videtur
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
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.
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.
It's been a long time.
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, 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...
This has been available for a long time with open access to the design from Sun as the picoJava CPU core. It was not an economically viable CPU and I think this's one of the reasons why Sun released it.
Banu
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).
42.
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
So "used" cases that used "unused" could break, though older compilers in essence used "unused" to mean both "used" and
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 .Net SDK's, and a lot of internal application programming seems to be moving that way also. .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).
.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) ;).
:)
A lot of the products I have seen (both data collection and warehouse-type) are moving to
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"
A lot of internal app's get written in
Ok, enough rambling
-T
Whee signature.
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.
http://www.arm.com/products/solutions/Jazelle.html
s or s/ns9775.jsp
/ 61 0041
.net follow java everywhere without any own original ideas?
http://www.netsilicon.com/products/netarmproces
http://www.developer.com/java/other/article.php
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
Read this paper 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.
Quidquid latine dictum sit, altum videtur
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"?
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..
.NET chip....
* 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
* 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
it was funnier than *any* of your posts modded funny
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
TINI
Its been around for a while.
Enjoy,
It's just the normal noises in here.
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.
Read about it and some other Java chips here.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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.