What is this "shared source" of which you speak?...This is not "Open Source" at all.
Heater, after rereading my post, I didn't say it was. I said that the .NET Micro Framework was released under the Apache 2.0 license and I said that Mono was originally based on Rotor which was released under the Shared Source license... but I didn't claim it was open at all.
I'm pretty sure the Apache 2.0 license is considered open, however. :-)
I might add that both the CLI is published an ECMA Standard and the C# Language is both ISO and ECMA standards.
Yes, the micro frame work seems to be open source, I was just having difficulty verifying that for the embedded boards we were looking at. Does the micro frame work use JIT or is it just interpreting byte codes?
Still rotor "shared source" which is definitely not open source and I'm sure was not the basis of mono. In fact studying the rotor code makes you unwelcome as a mono developer as you cannot then make "clean room" contributions.
That only leaves the issue of supposed patents on .Net technology held by MS. Does anyone have any specific details about that.
Does the micro frame work use JIT or is it just interpreting byte codes?
The .NET Micro Framework simply interprets the IL.
As for Mono, it was based on Rotor, however, it was a clean room design. Miguel couldn't use the code, but he could learn from it (which is what the shared source license was about.) Since then, ECMA standardized the language/cli and that is what Mono is targeted for. In fact, Microsoft hosts Miguel's team (or former team) in Redmond quite often to allow them to test their code using the Microsoft designed tests. It's a weird relationship for someone who thinks about Microsoft/Linux being enemies, but in reality they work together quite often and Miguel is often at Microsoft events showing off their great work.
As for the patents, if you base it off the ECMA standards, Microsoft has already documented that they won't pursue any enforcements. In fact, both ISO and ECMA require that any patents held by any member company must be available for a reasonable and non discriminatory basis. However, Microsoft went a step further and stated that they would also be made available at no cost. That was way back in 2003.
As for the patents, that is an old argument that simply doesn't hold water. The ECMA and ISO standardization process requires that the patents in question must be available for a reasonable and non discriminatory basis. However, Microsoft went a step further and stated that they would also be royalty free. That "promise" is attached to the those standard documents and has been since they were submitted in 2003. It's a little too late to start suing companys for infringment due to the time frame involved and the fact that Microsoft is well aware of what Miguel's team have been doing, especially considering that they're often out at Microsoft's testing labs testing their code to insure compatibility. It's unfortunate that Novell just laid off his entire team... but just Yesterday he started a new company to provide a commercial alternative to Microsoft's .NET platform based on the Mono project.
The .NET Micro Framework simply interprets the IL.
I suspected as much. JITing must require a lot more code and data space. This
must reduce the performance of a 72MHz ARM on the FEZ, for example, to about
the equivalent of C code compiled to native code for a 5-7MHz CPU. Makes me want to
buy a FEZ just to see how it fares.
As for Mono, it was based on Rotor, however, it was a clean room design.
This is where life get's confusing. One of the most famous cases of "clean
room" revers engineering was the IBM PC BIOS where Compaq had a team read the
code and write a specification. Another team took the spec and wrote their own
BIOS. Idea being that the second team could never be copying actual code.
It's also odd that on the mono web site they do specifically say that mono devs
should not read rotor code.
As for working with MS and using MS test harnesses that sounds much like the
set up for people developing Java compilers where they had to pass Suns test
criteria. The niggling thing about that being that the tests were not open
source.
As for the patents, if you base it off the ECMA standards, Microsoft has already documented that they won't pursue any enforcements.
Microsoft went a step further and stated that they [c# related patents] would also be royalty free.
I would feel much cozier if you could link us to those actual statements/documents. Besides does that only apply to the C# language and a base set of classes for it? What about all the other .NET stuff you need if you want to create cross-platform apps?.
It's unfortunate that Novel just laid off his entire team... but just Yesterday he started a new company to provide a commercial alternative to Microsoft's .NET platform based on the Mono project.
Yes I just read that somewhere. I wish Miguel and his team all the best.
What will happen now? Novel has a Mono and Miguel has a Mono. Will there be two? Will Novel drop its version?
Yeah, the tests are given to the team... there is nothing propritary about them... they're just there to confirm the code is consistant with the ECMA specs. I was unaware of the the statement on their site about Rotor, but Rotor was a decade ago, before the standardization process started. There is no reason to use Rotor anymore.
As for the patent related stuff, you can go to Mono's FAQ page. It has a link to the ECMA standards with the RAND Promise as well as Miguel's statement on how they've been working with Microsoft and that they have no fear of anything like that happening.
Technically, Novell didn't own Mono. It is an open source projected started and run by Miguel, so it's his baby. Novell was only "supporting" it, and with this, it appears that they've dropped that support, which is unfortunate.
Lastly, I think you'll find that the speed ratio of the interpreter is significantly better than you estimate. I've been running FEZ a Domino driving one of Rayman's 4.3" displays. I'm doing a full 480x272 16bit display with it with no issues, for example.
I would pay for a VS type spin compiler that had a c sharp type interface where I could enumerate objects with the "." or where I could hit the tab key twice and complete a bare example of a function or where I could highlight multiple items and mass indent or mass comment ... and the list could go on and on.
If anyone can get c# running on the prop, that'd be perfect as there would actually be native string handling, and very good string handling at that! Anyone?
If anyone can get c# running on the prop, that'd be perfect as there would actually be native string handling, and very good string handling at that! Anyone?
.NET is managed code. While it might be possible to run some very small piece of the run-time on the prop, it would be really really really slooowww. Besides auto complete is an editor feature not a C# feature.
See the Propeller Manual for information on handling strings (array of bytes). It's very C like.
Isn't that what the MSRoboticStudio with Parallaxs Eddie Robot does? Write code in C# inconjuction with the CCR and DSS library to make more complex programs, and have options to use it with the XNA4.0 and Kinects.
No, Robotics Studio doesn't work that way... it only runs on the actual PC that is controlling everything. There is an application that provides a service interface to that PC running on the Prop. There is also one that is similar for the BasicStamp as well. Any platform that wants to be used by RS will implement an command processor style interface that RS can call into.
Here is an example of that interface running on the prop for the BoeBot using the SpinStamp. http://forums.parallaxinc.com/forums/default.aspx?f=25&p=1&m=240781 You can look at the referenced PDF and see the command structure of the app running on the BasicStamp/Prop.
Thanks for the post wjsteele, good info; C# is great I use it and the .NETMicroFramework. Will there ever be a C# on the Propeller, hmmm, I dont thinks so, the propeller is a unique, great microcontroller; as technology continues to advance there might be more features added to its compiler and hardware. Its use on the Eddie with MSRobotic Studio gives it an edge on helping the new generation of engineers, a solid foundation on microcontrollers, and robots. Yes I'm busy getting back on Basic Stamp, and the Propeller.... just busy, busy, busy... and will be more busy when the next version of .NETMF comes out, i heard its will have VisualBasic support; more programmers into the microcontroller pool.
Its up to Parallax, if they ever do, that will be awsome, but its really up to them. I'm happy just using it with MSRobotic Studio. I couldn't ask for more.
Its up to Parallax, if they ever do, that will be awsome, but its really up to them.
Parallax is very busy all the time, so these kinds of things usually grow from our community here. If .NETMF source was available in C/C++, we could evaluate the possibilities. I found the porting kit and am looking at it.
I wouldn't go into porting, it would be nice to get it to work, but I think Parallax just like any other Company, has the right to manage their business an way they want; services, tech, robots, etc...., I wouln't throw an open source rant, about technicalities, like I said, its really up to Parallax, and if they ever do give one of those options, they should be recieved with open arms.
I thinks theres a code sample on using .NETMF with a Propeller; Propeller used as a Coprocessor through an SPI connection, but thats it, I wouldn't go beyond Coprocessor use.
I have come back to this thread via a somewhat convoluted route.
I was thinking about the restrictions of a 16 bit instruction set (8080) and how it really traps one in a 16 bit address space. For instance, jmp destination can be coded in 3 bytes, one codes for the jump, and two for the destination. If you want a flat memory space bigger than 16 bits, you need a larger instruction. If you want to jump to any 32 bit location, that appears to suggest a 5 byte instruction.
RISC instruction sets often try to squeeze instructions into 32 bits so that caching ends up aligned. But you give up other things. For instance, in 16 bit Z80, you might have "load register, number "
where number is two bytes. And if register is any location in memory, I think that takes 9 bytes to describe that instruction. You can do it in less, but you end up with the 9 bit limitation in pasm for constants, and you have to use another long anyway to describe that constant. And you probably need a further long if you are describing a location in a flat 32 bit memory space rather than an 11 bit memory space of a cog.
Pasm certainly has the ability to move the contents of one register to another and does this with a 4 byte instruction, but I believe it only works within the constrained memory of the 2048 bytes in a cog.
It seems to me that if you want to design a true 32 bit assembly language and you want familiar instructions like move and jump, you need more than one long to define the instruction.
So I started looking at different 32 bit languages that one could emulate on the propeller and which would give you up to 32 bits of memory space. Zog is certainly on the list, and I'd be interested in seeing some examples of code.
using System;
namespace TestCIL
{
class Program
{
static void Main(string[] args)
{
int sizeOfBuf = 100;
var buf = new int[sizeOfBuf];
for (var i = 0; i < sizeOfBuf; i++)
{
buf[0] = i;
}
}
}
}
using System;
namespace TestCIL
{
class Program
{
static void Main(string[] args)
{
var triangle1 = new Triangle();
var hypotenuseOfTriangle1 = triangle1.Hypotenuse;
var triangle2 = new Triangle();
var hypotenuseOfTriangle2 = triangle2.Hypotenuse;
var hyp1And2 = hypotenuseOfTriangle1 + hypotenuseOfTriangle2;
}
}
public class Triangle
{
public double SideA { get; set; }
public double SideB { get; set; }
public double Hypotenuse
{
get
{
return Math.Sqrt((SideA * SideA) + (SideB * SideB));
}
}
}
}
While I'm not saying it is impossible to emulate CIL on the Prop (nothing is impossible on the Propeller!), it would be very difficult. If you look carefully at the CIL instruction set you will see that it uses around 200 of the 256 possible byte values as opcodes. This means that you only have about 2 PASM instructions to implement each CIL opcode. Since implementing each opcode requires at least one "overhead" PASM instruction (i.e. a JMP or a RET) this means you have about 1 PASM instruction to implement each CIL instruction. Obviously this is not possible - so instead of implementing them one-by-one you would have to group the opcodes and try and implement them together (e.g. implement all the stelem instructions using one common function, and all the ldind instuctions using another, etc etc). But this makes decoding and identifying each instruction (and its modes and parameters) quite difficult - and slow!. In fact, almost anything you do is likely to be both too large and too slow to be useful. It would probably be much slower than Spin, for instance.
Perhaps Chip Gracey could do this (he did something quite similar with Spin, after all!) but for mere mortals I think this would be a near impossible task. I looked at it once, but not being in the same class as Chip, I quickly decided against it.
Ross is correct on many counts. Writing a CIL interpreter in PASM would be like writing a Java 6 interpreter. I've written a Java 1.2 PASM interpreter, but haven't had enough motivation to go further than that. From my experience I think it would be about half the speed of SPIN. The problem is regardless of implementation, the current Propeller really doesn't have enough resources to be a single chip solution (2 with EEPROM).
I looked at the .NETMF porting kit. There are some possibilities with that, but I haven't had time to chase them.
Well, you know, when someone says something is impossible on the prop...
Ok, yes, CIL does use almost all the 256 byte codes. Interestingly, so does the Z80 opcode list and that has been possible to code. I think many of the tricks that Juergen and Heater used on the Z80 emulation are going to be relevant here. There are at least two ways one could code that, including LMM (Juergen's solution) or moving some instructions out of the cog (heater used this I think in one of the Zog versions).
I suspect it will be slower than spin, but it will enable larger programs, plus you could run the code on a PC first to debug it, plus you could get a speedup for graphics things like scrolling text by farming things out to dedicated graphics code for sprites.
I'd like to explore the idea a little further before saying it is not practical.
Are there any more detailed examples of how CIL works?
For instance, take an instruction like
0x61 xor Bitwise XOR of integer values, returns an integer.
How many bytes long is that instruction - is it 1 byte or does it contain the two integers as well, making it ? 5 bytes
Are there any more detailed examples of how CIL works?
For instance, take an instruction like
0x61 xor Bitwise XOR of integer values, returns an integer.
How many bytes long is that instruction - is it 1 byte or does it contain the two integers as well, making it ? 5 bytes
I think CIL is stack based, so this instruction is one byte - it would take the top two elements off the stack, xor them together and then push the result back on the stack. Other opcodes would have operands, but not this one.
I still don't see the use of C# for embedded systems. It's irrelevant for those work with 8 and 16 bit micros and even the 32 bitters seem to take a performance hit.
Forth it ain't.
May as well port Wiring to the Prop or even Smalltalk, heck I had Smalltalk replete with GUI running on a 286. Would be a speed demon on the later ARMs or the PropII.
Ok, RPN and stack based Forth language hat on, and wading into that assembly code. It doesn't look too bad. I'm not sure how deep the stack ever needs to be but for small programs it might even fit in a cog rather than hub. Many of those instructions are rather similar to Z80 instructions - eg push and pop. So can possibly reuse some existing code from the other emulations.
It's done all ready.
As far as I know wiring as used on the Arduino is nothing more than C/C++ compiled with GCC and a bunch of class libraries to do the dirty work. Serial I/O, ADC etc.
The Prop now has GCC support. Well, almost ready for alpha testing.
By all accounts it's working very well. Speed is good but program size may be an issue. It wil be great for Prop II.
I suppose one could always run a CIL interpreter in C using GCC or Catalina using http://dotnetanywhere.org/
Not the fastest solution I'm sure, but it could prove the concept of whether you can run vb.net, C# (and Java?) on the propeller.
Though I'm more intrigued by the stack based nature of the CIL code, as it could reduce down to very few pasm instructions. I'm thinking one cog for the common instructions, hand off to another LMM for less used ones, and maybe some cunning caching of the stack between the cog and hub, so that most of the time the stack is being accessed from local cog ram (ie fast).
There are so many clever things that could only be done with the multiple cog nature of the propeller - eg the core program is running from one cog, accessing the 'program' which is cached into hub, and another cog is handling caching from external ram into hub so the first cog minimises cache misses.
What about a CIL compiler? Instead of trying to ram a interpreter into the Prop just let the computer do the heaving lifting and port the CIL directly to pasm.
Comments
Heater, after rereading my post, I didn't say it was. I said that the .NET Micro Framework was released under the Apache 2.0 license and I said that Mono was originally based on Rotor which was released under the Shared Source license... but I didn't claim it was open at all.
I'm pretty sure the Apache 2.0 license is considered open, however. :-)
I might add that both the CLI is published an ECMA Standard and the C# Language is both ISO and ECMA standards.
Bill
Yes, the micro frame work seems to be open source, I was just having difficulty verifying that for the embedded boards we were looking at. Does the micro frame work use JIT or is it just interpreting byte codes?
Still rotor "shared source" which is definitely not open source and I'm sure was not the basis of mono. In fact studying the rotor code makes you unwelcome as a mono developer as you cannot then make "clean room" contributions.
That only leaves the issue of supposed patents on .Net technology held by MS. Does anyone have any specific details about that.
The .NET Micro Framework simply interprets the IL.
As for Mono, it was based on Rotor, however, it was a clean room design. Miguel couldn't use the code, but he could learn from it (which is what the shared source license was about.) Since then, ECMA standardized the language/cli and that is what Mono is targeted for. In fact, Microsoft hosts Miguel's team (or former team) in Redmond quite often to allow them to test their code using the Microsoft designed tests. It's a weird relationship for someone who thinks about Microsoft/Linux being enemies, but in reality they work together quite often and Miguel is often at Microsoft events showing off their great work.
As for the patents, if you base it off the ECMA standards, Microsoft has already documented that they won't pursue any enforcements. In fact, both ISO and ECMA require that any patents held by any member company must be available for a reasonable and non discriminatory basis. However, Microsoft went a step further and stated that they would also be made available at no cost. That was way back in 2003.
As for the patents, that is an old argument that simply doesn't hold water. The ECMA and ISO standardization process requires that the patents in question must be available for a reasonable and non discriminatory basis. However, Microsoft went a step further and stated that they would also be royalty free. That "promise" is attached to the those standard documents and has been since they were submitted in 2003. It's a little too late to start suing companys for infringment due to the time frame involved and the fact that Microsoft is well aware of what Miguel's team have been doing, especially considering that they're often out at Microsoft's testing labs testing their code to insure compatibility. It's unfortunate that Novell just laid off his entire team... but just Yesterday he started a new company to provide a commercial alternative to Microsoft's .NET platform based on the Mono project.
Bill
I suspected as much. JITing must require a lot more code and data space. This
must reduce the performance of a 72MHz ARM on the FEZ, for example, to about
the equivalent of C code compiled to native code for a 5-7MHz CPU. Makes me want to
buy a FEZ just to see how it fares.
This is where life get's confusing. One of the most famous cases of "clean
room" revers engineering was the IBM PC BIOS where Compaq had a team read the
code and write a specification. Another team took the spec and wrote their own
BIOS. Idea being that the second team could never be copying actual code.
It's also odd that on the mono web site they do specifically say that mono devs
should not read rotor code.
As for working with MS and using MS test harnesses that sounds much like the
set up for people developing Java compilers where they had to pass Suns test
criteria. The niggling thing about that being that the tests were not open
source.
I would feel much cozier if you could link us to those actual statements/documents. Besides does that only apply to the C# language and a base set of classes for it? What about all the other .NET stuff you need if you want to create cross-platform apps?.
Yes I just read that somewhere. I wish Miguel and his team all the best.
What will happen now? Novel has a Mono and Miguel has a Mono. Will there be two? Will Novel drop its version?
As for the patent related stuff, you can go to Mono's FAQ page. It has a link to the ECMA standards with the RAND Promise as well as Miguel's statement on how they've been working with Microsoft and that they have no fear of anything like that happening.
Technically, Novell didn't own Mono. It is an open source projected started and run by Miguel, so it's his baby. Novell was only "supporting" it, and with this, it appears that they've dropped that support, which is unfortunate.
Lastly, I think you'll find that the speed ratio of the interpreter is significantly better than you estimate. I've been running FEZ a Domino driving one of Rayman's 4.3" displays. I'm doing a full 480x272 16bit display with it with no issues, for example.
Bill
If anyone can get c# running on the prop, that'd be perfect as there would actually be native string handling, and very good string handling at that! Anyone?
.NET is managed code. While it might be possible to run some very small piece of the run-time on the prop, it would be really really really slooowww. Besides auto complete is an editor feature not a C# feature.
See the Propeller Manual for information on handling strings (array of bytes). It's very C like.
Here is an example of that interface running on the prop for the BoeBot using the SpinStamp. http://forums.parallaxinc.com/forums/default.aspx?f=25&p=1&m=240781 You can look at the referenced PDF and see the command structure of the app running on the BasicStamp/Prop.
Bill
Parallax is very busy all the time, so these kinds of things usually grow from our community here. If .NETMF source was available in C/C++, we could evaluate the possibilities. I found the porting kit and am looking at it.
I thinks theres a code sample on using .NETMF with a Propeller; Propeller used as a Coprocessor through an SPI connection, but thats it, I wouldn't go beyond Coprocessor use.
I was thinking about the restrictions of a 16 bit instruction set (8080) and how it really traps one in a 16 bit address space. For instance, jmp destination can be coded in 3 bytes, one codes for the jump, and two for the destination. If you want a flat memory space bigger than 16 bits, you need a larger instruction. If you want to jump to any 32 bit location, that appears to suggest a 5 byte instruction.
RISC instruction sets often try to squeeze instructions into 32 bits so that caching ends up aligned. But you give up other things. For instance, in 16 bit Z80, you might have "load register, number "
where number is two bytes. And if register is any location in memory, I think that takes 9 bytes to describe that instruction. You can do it in less, but you end up with the 9 bit limitation in pasm for constants, and you have to use another long anyway to describe that constant. And you probably need a further long if you are describing a location in a flat 32 bit memory space rather than an 11 bit memory space of a cog.
Pasm certainly has the ability to move the contents of one register to another and does this with a 4 byte instruction, but I believe it only works within the constrained memory of the 2048 bytes in a cog.
It seems to me that if you want to design a true 32 bit assembly language and you want familiar instructions like move and jump, you need more than one long to define the instruction.
So I started looking at different 32 bit languages that one could emulate on the propeller and which would give you up to 32 bits of memory space. Zog is certainly on the list, and I'd be interested in seeing some examples of code.
Research then led to the Common Intermediate Language. The instruction set is here http://en.wikipedia.org/wiki/List_of_CIL_instructions
Given that the 8080, Z80 and Zylin instruction sets have been emulated, is this one impossible?
The reason this instruction set is interesting is that it is the language that C# and Mono compile into. Do the other .net languages as well?
I'd be interested to see the CIL results of a super simple 'for' loop in C# (maybe in a console application so no graphics overheads).
using System; namespace TestCIL { class Program { static void Main(string[] args) { int sizeOfBuf = 100; var buf = new int[sizeOfBuf]; for (var i = 0; i < sizeOfBuf; i++) { buf[0] = i; } } } }.method private hidebysig static void Main(string[] args) cil managed { .entrypoint // Code size 34 (0x22) .maxstack 3 .locals init ([0] int32 sizeOfBuf, [1] int32[] buf, [2] int32 i, [3] bool CS$4$0000) IL_0000: nop IL_0001: ldc.i4.s 100 IL_0003: stloc.0 IL_0004: ldloc.0 IL_0005: newarr [mscorlib]System.Int32 IL_000a: stloc.1 IL_000b: ldc.i4.0 IL_000c: stloc.2 IL_000d: br.s IL_0019 IL_000f: nop IL_0010: ldloc.1 IL_0011: ldc.i4.0 IL_0012: ldloc.2 IL_0013: stelem.i4 IL_0014: nop IL_0015: ldloc.2 IL_0016: ldc.i4.1 IL_0017: add IL_0018: stloc.2 IL_0019: ldloc.2 IL_001a: ldloc.0 IL_001b: clt IL_001d: stloc.3 IL_001e: ldloc.3 IL_001f: brtrue.s IL_000f IL_0021: ret } // end of method Program::MainThat is a very small program. I was expecting megabytes of bloatware.
Well, I need to go off and study each of those instructions and think about whether they could be emulated on the propeller.
using System; namespace TestCIL { class Program { static void Main(string[] args) { var triangle1 = new Triangle(); var hypotenuseOfTriangle1 = triangle1.Hypotenuse; var triangle2 = new Triangle(); var hypotenuseOfTriangle2 = triangle2.Hypotenuse; var hyp1And2 = hypotenuseOfTriangle1 + hypotenuseOfTriangle2; } } public class Triangle { public double SideA { get; set; } public double SideB { get; set; } public double Hypotenuse { get { return Math.Sqrt((SideA * SideA) + (SideB * SideB)); } } } }.method private hidebysig static void Main(string[] args) cil managed { .entrypoint // Code size 33 (0x21) .maxstack 2 .locals init ([0] class TestCIL.Triangle triangle1, [1] float64 hypotenuseOfTriangle1, [2] class TestCIL.Triangle triangle2, [3] float64 hypotenuseOfTriangle2, [4] float64 hyp1And2) IL_0000: nop IL_0001: newobj instance void TestCIL.Triangle::.ctor() IL_0006: stloc.0 IL_0007: ldloc.0 IL_0008: callvirt instance float64 TestCIL.Triangle::get_Hypotenuse() IL_000d: stloc.1 IL_000e: newobj instance void TestCIL.Triangle::.ctor() IL_0013: stloc.2 IL_0014: ldloc.2 IL_0015: callvirt instance float64 TestCIL.Triangle::get_Hypotenuse() IL_001a: stloc.3 IL_001b: ldloc.1 IL_001c: ldloc.3 IL_001d: add IL_001e: stloc.s hyp1And2 IL_0020: ret } // end of method Program::Main //Triangle .class public auto ansi beforefieldinit TestCIL.Triangle extends [mscorlib]System.Object { } // end of class TestCIL.Triangle .field private float64 '<SideA>k__BackingField' .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) .field private float64 '<SideB>k__BackingField' .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) .method public hidebysig specialname instance float64 get_Hypotenuse() cil managed { // Code size 38 (0x26) .maxstack 3 .locals init ([0] float64 CS$1$0000) IL_0000: nop IL_0001: ldarg.0 IL_0002: call instance float64 TestCIL.Triangle::get_SideA() IL_0007: ldarg.0 IL_0008: call instance float64 TestCIL.Triangle::get_SideA() IL_000d: mul IL_000e: ldarg.0 IL_000f: call instance float64 TestCIL.Triangle::get_SideB() IL_0014: ldarg.0 IL_0015: call instance float64 TestCIL.Triangle::get_SideB() IL_001a: mul IL_001b: add IL_001c: call float64 [mscorlib]System.Math::Sqrt(float64) IL_0021: stloc.0 IL_0022: br.s IL_0024 IL_0024: ldloc.0 IL_0025: ret } // end of method Triangle::get_Hypotenuse .method public hidebysig specialname instance float64 get_SideA() cil managed { .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) // Code size 11 (0xb) .maxstack 1 .locals init (float64 V_0) IL_0000: ldarg.0 IL_0001: ldfld float64 TestCIL.Triangle::'<SideA>k__BackingField' IL_0006: stloc.0 IL_0007: br.s IL_0009 IL_0009: ldloc.0 IL_000a: ret } // end of method Triangle::get_SideA .method public hidebysig specialname instance float64 get_SideB() cil managed { .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) // Code size 11 (0xb) .maxstack 1 .locals init (float64 V_0) IL_0000: ldarg.0 IL_0001: ldfld float64 TestCIL.Triangle::'<SideB>k__BackingField' IL_0006: stloc.0 IL_0007: br.s IL_0009 IL_0009: ldloc.0 IL_000a: ret } // end of method Triangle::get_SideB .method public hidebysig specialname instance void set_SideA(float64 'value') cil managed { .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) // Code size 8 (0x8) .maxstack 8 IL_0000: ldarg.0 IL_0001: ldarg.1 IL_0002: stfld float64 TestCIL.Triangle::'<SideA>k__BackingField' IL_0007: ret } // end of method Triangle::set_SideA .method public hidebysig specialname instance void set_SideB(float64 'value') cil managed { .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) // Code size 8 (0x8) .maxstack 8 IL_0000: ldarg.0 IL_0001: ldarg.1 IL_0002: stfld float64 TestCIL.Triangle::'<SideB>k__BackingField' IL_0007: ret } // end of method Triangle::set_SideB .property instance float64 Hypotenuse() { .get instance float64 TestCIL.Triangle::get_Hypotenuse() } // end of property Triangle::Hypotenuse .property instance float64 SideA() { .get instance float64 TestCIL.Triangle::get_SideA() .set instance void TestCIL.Triangle::set_SideA(float64) } // end of property Triangle::SideA .property instance float64 SideB() { .get instance float64 TestCIL.Triangle::get_SideB() .set instance void TestCIL.Triangle::set_SideB(float64) } // end of property Triangle::SideBhttp://en.csharp-online.net/CIL_Instruction_Set
While I'm not saying it is impossible to emulate CIL on the Prop (nothing is impossible on the Propeller!), it would be very difficult. If you look carefully at the CIL instruction set you will see that it uses around 200 of the 256 possible byte values as opcodes. This means that you only have about 2 PASM instructions to implement each CIL opcode. Since implementing each opcode requires at least one "overhead" PASM instruction (i.e. a JMP or a RET) this means you have about 1 PASM instruction to implement each CIL instruction. Obviously this is not possible - so instead of implementing them one-by-one you would have to group the opcodes and try and implement them together (e.g. implement all the stelem instructions using one common function, and all the ldind instuctions using another, etc etc). But this makes decoding and identifying each instruction (and its modes and parameters) quite difficult - and slow!. In fact, almost anything you do is likely to be both too large and too slow to be useful. It would probably be much slower than Spin, for instance.
Perhaps Chip Gracey could do this (he did something quite similar with Spin, after all!) but for mere mortals I think this would be a near impossible task. I looked at it once, but not being in the same class as Chip, I quickly decided against it.
Ross.
I looked at the .NETMF porting kit. There are some possibilities with that, but I haven't had time to chase them.
Ok, yes, CIL does use almost all the 256 byte codes. Interestingly, so does the Z80 opcode list and that has been possible to code. I think many of the tricks that Juergen and Heater used on the Z80 emulation are going to be relevant here. There are at least two ways one could code that, including LMM (Juergen's solution) or moving some instructions out of the cog (heater used this I think in one of the Zog versions).
I suspect it will be slower than spin, but it will enable larger programs, plus you could run the code on a PC first to debug it, plus you could get a speedup for graphics things like scrolling text by farming things out to dedicated graphics code for sprites.
I'd like to explore the idea a little further before saying it is not practical.
Are there any more detailed examples of how CIL works?
For instance, take an instruction like
How many bytes long is that instruction - is it 1 byte or does it contain the two integers as well, making it ? 5 bytes
Slow to the point of uselessness? probably Yes!
I think CIL is stack based, so this instruction is one byte - it would take the top two elements off the stack, xor them together and then push the result back on the stack. Other opcodes would have operands, but not this one.
Ross.
Forth it ain't.
May as well port Wiring to the Prop or even Smalltalk, heck I had Smalltalk replete with GUI running on a 286. Would be a speed demon on the later ARMs or the PropII.
As far as I know wiring as used on the Arduino is nothing more than C/C++ compiled with GCC and a bunch of class libraries to do the dirty work. Serial I/O, ADC etc.
The Prop now has GCC support. Well, almost ready for alpha testing.
By all accounts it's working very well. Speed is good but program size may be an issue. It wil be great for Prop II.
Not the fastest solution I'm sure, but it could prove the concept of whether you can run vb.net, C# (and Java?) on the propeller.
Though I'm more intrigued by the stack based nature of the CIL code, as it could reduce down to very few pasm instructions. I'm thinking one cog for the common instructions, hand off to another LMM for less used ones, and maybe some cunning caching of the stack between the cog and hub, so that most of the time the stack is being accessed from local cog ram (ie fast).
There are so many clever things that could only be done with the multiple cog nature of the propeller - eg the core program is running from one cog, accessing the 'program' which is cached into hub, and another cog is handling caching from external ram into hub so the first cog minimises cache misses.
I for one would love to program the prop in c#.