Yes, I would like to program the prop in C# too. I like the idea of writing code in C# on a PC, debugging it on a PC and then copying it to a propeller. Even if it is a limited set of C# instructions, even if it is only the C89 instructions, I still think it would be useful.
How much do you know about Z80 opcodes and the efforts a little while ago to emulate CP/M on the propeller?
Attached is the emulation code. Complex I know, but it is a framework to start with.
This is the bit that pushes a value onto the stack.
'***************************************************************************************************************
' Push a register from alu and jump to fetch
'
push_reg
movs push_reg_ret, #fetch
' fall through
'***************************************************************************************************************
'
' Push a word to the stack
'
push_alu
sub SP, #2
and SP, low_word
mov ea, SP
'***************************************************************************************************************
'
' Write a word from alu to address [ea]
'
wr_word
call #wr_byte
add ea, #1
and ea, low_word
shr alu, #8
call #wr_byte
wr_word_ret
push_alu_ret
push_reg_ret
ret
Get the value. Decrement the stack pointer. Write a byte to memory, do a shift, and then write another byte.
That could be even quicker if you have the stack in cog rather than in hub ram, and cache it out to hub if it gets near the top or bottom of the small cog cache. Possibly 10 or 12 pasm instructions to do a CIL instruction. Move a value to the location of the stack. Subtract one off the stack pointer. Do it again. Repeat n times depending on word/long. There will be some increments and decrements of pointers and some mov instructions. Then when finished, collect the next instruction and do a jump based on the opcode value (same as the Z80 code does).
I wonder if you can answer some more questions about CIL?
For instance, that code fragment you posted earlier had an array in it. Yet the program itself did not include this array. The array is declared in
IL_0005: newarr [mscorlib]System.Int32
What does this actually mean? Do we need to translate "newarr" into an allocation of bytes in hub ram? How does it work with two arrays - do these need different names or something?
Also, there seem to be system calls and other calls. Are these calling code that can also be interpreted by a CIL interpreter?
I think I'm missing something. How much actual debugging can you do on the PC of a propeller program without accurate simulation of the I/O pins, multi-COG structure and simulated peripherals? I relatively language agnostic - I program equally poorly in ANY language - but this seems like a lot of effort to go through to get to be able to use C# to program the Propeller. I'm not being combative, I'm just trying to understand how it would be done.
...I would like to program the prop in C# too. I like the idea of writing code in C# on a PC, debugging it on a PC and then copying it to a propeller. Even if it is a limited set of C# instructions, even if it is only the C89 instructions, I still think it would be useful.
I don't understand this. If it is a limited C# or CIL then it is not C# or CIL. If it's pruned back to the C89 level then why not just use C89? Why would you want all the bloat and slowness of an interpreted language to do that. What is it offering you? Why not use Catalina?
In fact why not use ZOG and the gcczpu compiler:) It would work about as well if not better.
It has been quite a common activity over the years for me to develop code in C on the PC. Debug it there as best I can with a test harness that provides simulated I/O then compile the finished code for the target embedded system and download.
As has been pointed out there is a problem testing embedded system code on a PC if you don't have an accurate simulation of your hardware, timing and all. To a large extent this can be mitigated by separating code into logical units that operate independently of you hardware and can be tested thoroughly on a PC in simple test harnesses, Then you have the units that interact with the hardware that will need to be verified on the real metal.
Heater,
Two reasons come to mind why I would like this: the first is I enjoy the language and can fly through a program(rapid development), the other reason is I believe that others want to program in c#.
Worse comes to worse I spend a couple of weeks playing with the idea of converting CIL to pasm. If I can't get anything working at least my knowledge of pasm will increase and I will have enjoyed it. If I can get something working then maybe I can inspire someone new to join the Propeller world.
I agree with Jesse - and maybe could add two more reasons, one is the ability to code vb.net, and the second is that this may be able to take the propeller from a text based to a GUI interface.
Specifically, I want a richtextbox, and GCC and Catalina and Zog cannot give me that
Some CIL commands look pretty easy and might come down to 10 pasm instructions or less. First job is to get that "for" loop working without the array bit, and then the next thing might be to get the array working.
When CIL describes numbers like when pushing a number onto the stack, are they "little endian" or "big endian"? ie is 100 stored in bytecode as 00 64 or 64 00?
The language itself is not at all bad, I like it. I just wonder if it is any more useful than C/C++ on an embedded system where it does not have the huge .NET framework, garbage collection etc etc to go with it.
Doing for the sake of doing I appreciate. You can learn a lot along the way which is a good result whatever happens to the end product.
Dr_A,
Specifically, I want a richtextbox, and GCC and Catalina and Zog cannot give me that
I'm not sure that C# can give you a rich text box on a Propeller either.
Sophisticated widgets like that exist in all manner of languages and tool kits. For C/C++ programmers there is GTK, QT, whatever Windows has, etc etc.
C# on Linux running under mono uses the same GTK for it's windows/widgets as programmers working in C/C++ in the gnome environment.
Problem is all of those GUI tool kits/libraries are huge. No way they are comming to the Propeller. So C# ends up in the same boat as C/C++, GCC, Catalina or Zog in that respect. You would have to create your own mini-toolkit for the Prop.
I agree Heater, once you take garbage collection out of the picture C# starts to look more like C/C++. I'll say this again... I think that .NET developers want the editor features like intellisense.
hello...anyone here could help me in C programming pic16f887 with accelerometer hitachi H48C for creating a interface that can display the 3-axis values..i wish u guys could help me in this project of mine...i am really a noob in C programming..thanks~
If there were a gui like VS that had the intellisense and drop down functions and mass commenting, as well as the ability to step through the code line by line when debugging, it would greatly increase my ability to pick up spin.
I know some (most) of you have worked with other uC's and this language comes pretty easy to you, but for someone that is coming to this out of the blue, sans some c# programming, it is very difficult to learn the quirks of spin, especially without the nice debugging features. I would definitely pay for a nice VS debugger because it would save me hours and hours of time beating my head against the wall trying to figure out said quirks through attrition.
I agree Heater, once you take garbage collection out of the picture C# starts to look more like C/C++. I'll say this again... I think that .NET developers want the editor features like intellisense.
I agree with Jesse - and maybe could add two more reasons, one is the ability to code vb.net, and the second is that this may be able to take the propeller from a text based to a GUI interface.
Specifically, I want a richtextbox, and GCC and Catalina and Zog cannot give me that
Some CIL commands look pretty easy and might come down to 10 pasm instructions or less. First job is to get that "for" loop working without the array bit, and then the next thing might be to get the array working.
When CIL describes numbers like when pushing a number onto the stack, are they "little endian" or "big endian"? ie is 100 stored in bytecode as 00 64 or 64 00?
Heater,
Two reasons come to mind why I would like this: the first is I enjoy the language and can fly through a program(rapid development), the other reason is I believe that others want to program in c#.
Worse comes to worse I spend a couple of weeks playing with the idea of converting CIL to pasm. If I can't get anything working at least my knowledge of pasm will increase and I will have enjoyed it. If I can get something working then maybe I can inspire someone new to join the Propeller world.
Comments
Yes, I would like to program the prop in C# too. I like the idea of writing code in C# on a PC, debugging it on a PC and then copying it to a propeller. Even if it is a limited set of C# instructions, even if it is only the C89 instructions, I still think it would be useful.
How much do you know about Z80 opcodes and the efforts a little while ago to emulate CP/M on the propeller?
These are the opcodes http://nemesis.lonestar.org/computers/tandy/software/apps/m4/qd/opcodes.html
Lots more than the CIL opcodes.
Attached is the emulation code. Complex I know, but it is a framework to start with.
This is the bit that pushes a value onto the stack.
'*************************************************************************************************************** ' Push a register from alu and jump to fetch ' push_reg movs push_reg_ret, #fetch ' fall through '*************************************************************************************************************** ' ' Push a word to the stack ' push_alu sub SP, #2 and SP, low_word mov ea, SP '*************************************************************************************************************** ' ' Write a word from alu to address [ea] ' wr_word call #wr_byte add ea, #1 and ea, low_word shr alu, #8 call #wr_byte wr_word_ret push_alu_ret push_reg_ret retGet the value. Decrement the stack pointer. Write a byte to memory, do a shift, and then write another byte.
That could be even quicker if you have the stack in cog rather than in hub ram, and cache it out to hub if it gets near the top or bottom of the small cog cache. Possibly 10 or 12 pasm instructions to do a CIL instruction. Move a value to the location of the stack. Subtract one off the stack pointer. Do it again. Repeat n times depending on word/long. There will be some increments and decrements of pointers and some mov instructions. Then when finished, collect the next instruction and do a jump based on the opcode value (same as the Z80 code does).
I wonder if you can answer some more questions about CIL?
For instance, that code fragment you posted earlier had an array in it. Yet the program itself did not include this array. The array is declared in
What does this actually mean? Do we need to translate "newarr" into an allocation of bytes in hub ram? How does it work with two arrays - do these need different names or something?
Also, there seem to be system calls and other calls. Are these calling code that can also be interpreted by a CIL interpreter?
I don't understand this. If it is a limited C# or CIL then it is not C# or CIL. If it's pruned back to the C89 level then why not just use C89? Why would you want all the bloat and slowness of an interpreted language to do that. What is it offering you? Why not use Catalina?
In fact why not use ZOG and the gcczpu compiler:) It would work about as well if not better.
It has been quite a common activity over the years for me to develop code in C on the PC. Debug it there as best I can with a test harness that provides simulated I/O then compile the finished code for the target embedded system and download.
As has been pointed out there is a problem testing embedded system code on a PC if you don't have an accurate simulation of your hardware, timing and all. To a large extent this can be mitigated by separating code into logical units that operate independently of you hardware and can be tested thoroughly on a PC in simple test harnesses, Then you have the units that interact with the hardware that will need to be verified on the real metal.
Two reasons come to mind why I would like this: the first is I enjoy the language and can fly through a program(rapid development), the other reason is I believe that others want to program in c#.
Worse comes to worse I spend a couple of weeks playing with the idea of converting CIL to pasm. If I can't get anything working at least my knowledge of pasm will increase and I will have enjoyed it. If I can get something working then maybe I can inspire someone new to join the Propeller world.
Specifically, I want a richtextbox, and GCC and Catalina and Zog cannot give me that
Some CIL commands look pretty easy and might come down to 10 pasm instructions or less. First job is to get that "for" loop working without the array bit, and then the next thing might be to get the array working.
When CIL describes numbers like when pushing a number onto the stack, are they "little endian" or "big endian"? ie is 100 stored in bytecode as 00 64 or 64 00?
The language itself is not at all bad, I like it. I just wonder if it is any more useful than C/C++ on an embedded system where it does not have the huge .NET framework, garbage collection etc etc to go with it.
Doing for the sake of doing I appreciate. You can learn a lot along the way which is a good result whatever happens to the end product.
Dr_A,
I'm not sure that C# can give you a rich text box on a Propeller either.
Sophisticated widgets like that exist in all manner of languages and tool kits. For C/C++ programmers there is GTK, QT, whatever Windows has, etc etc.
C# on Linux running under mono uses the same GTK for it's windows/widgets as programmers working in C/C++ in the gnome environment.
Problem is all of those GUI tool kits/libraries are huge. No way they are comming to the Propeller. So C# ends up in the same boat as C/C++, GCC, Catalina or Zog in that respect. You would have to create your own mini-toolkit for the Prop.
I would approach this as creating Spin.NET.
If there were a gui like VS that had the intellisense and drop down functions and mass commenting, as well as the ability to step through the code line by line when debugging, it would greatly increase my ability to pick up spin.
I know some (most) of you have worked with other uC's and this language comes pretty easy to you, but for someone that is coming to this out of the blue, sans some c# programming, it is very difficult to learn the quirks of spin, especially without the nice debugging features. I would definitely pay for a nice VS debugger because it would save me hours and hours of time beating my head against the wall trying to figure out said quirks through attrition.
Anyone, how much?