@ Ron : Thanks for the test.c code. That's currently beyond what it's capable of -
Starting a Spin object (TvText) within C and using it - That's likely not to be possible. It would either need the TvText re-writing in C (*) or being started within Spin as now with Spin calling the C routine which returns data for display. That's supported but waiting for and getting a return value from a called C function isn't implemented yet.
Starting another C method in its own Cog - That will work just as you've used it but the library code for CogNew/CogInit isn't complete yet.
What you have is an advanced form of a serial-to-TV program and that's quite a good demonstration of Spin and C co-operation. What I'll do is get such a program working, as a plain keyin without a second cog and no buffering then with. I'll probably start with a serial echo which buffers input in a second cog.
(*) I hadn't checked how the OBEX TvText for C worked with what I have but that seems to compile okay after a few tweaks; removing #include<> for header files I don't have and asm(). Looks promising.
Ron Sutcliffe said...
Ok well I will re work my modified version of Steve's TV_text.c to run under your system. I don't think it will be too difficult.
It should be doable but don't go expecting it to work at present because the libraries will need to be written first.
Getting CogNew working is up at the top end of priorities but there could be some challenges and debugging effort for that.
Hippy, you've provided LIB_CogNew and LIB_WaitCnt ... a wordfill and wordmove could be easily created in a user function. Seems like that's about all you need to modify in the tv_text.c file and I'm sure Ron can do this. ... headers should work as is. What else might be missing?
jazzed said...
you've provided LIB_CogNew ... What else might be missing?
The code which actually does a CogNew
At the moment it just pulls the data from stack then returns. It's all doable but I just have to get my thinking cap on to work out how to set a parameter block to re-call the LccVm so it starts running in another Cog executing the right bytecode.
At the moment CogNew tries to run C bytecode as if it was PASM.
Hippy: How I do it is that my VM has it's PC initialized to some code which does a "POP pc". Thusly, PAR is the stack pointer
Edit: Since you seem to be the defacto reference on Spin, which way round does it push parameters? I'm modifying the "standard" assembly bootstrapper slightly and need to know which 0 is which
Just for the record, MyEditor.c was my first attempt at a C# program. When I realized that I could not add the SdCard code and still it squeeze it into the code Limited version of Imagecraft’s ICC7 I dropped the idea.
I am only interested in pursuing stuff which is of interest to Prop enthusiasts and non for profit. I have used Forth some years ago, so when Carl came up with his JDForth I started to port MyEditor across to JDForth.
Each time I go back to my C# version for reference I realize, what a mess it is, and it begs to be re-written. That being the case I might has well write the Forth and C# version at the same time. I am sure that I can work around what you doing to make it work. I do realize that not all the libraries are available to implement this sort of code ATM, but I have no doubt it will happen.
The idea of being able to run code from SDcard at some stage is looking like a real possibility.
Anyway for me it’s just for fun now. [noparse]:)[/noparse]
As I've said before, I don't have a downer on C# as such but it disturbs me to see people writing free and basically open source software that they are proud to give to the world that is tied to a closed, proprietary operating/platform and possibly encumbered with patents. This does not make much sense to me.
So, C# is fine as long as it will run on other VMs on other operating systems, just like Python or whatever. At the moment I think we only have mono for Linux and then only on Intel processors. Unless I've missed some progress in that area.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
C# itself is not closed. It's a standards controlled language just like C/C++ and others.
The CLR that Microsoft provides may fall into the area of "closed, proprietary operating/platform and possibly encumbered with patents", but the language C# does not.
Also, if I recall correctly, the IL and CLR concepts and specifications are open as well. Which is why Mono exists, and they do have a Mac OSX flavor of Mono now too.
I know of other smaller porting efforts to consoles (like the PSP) too. So it's expanding.
Well the good news is if you know Java then C# is "a piece of cake" vis-a-vis. So, much of that C# app code you have can be copy/pasted into a Java application. Some of the application framework and the GUI components follow different conventions, but they're not off by much.
Last time I tried mono some years ago when it was first released, it was a disaster; all that downloading for nothing. Surely it works now.
Mono runs System.Windows.Forms apps fine, according to http://www.mono-project.com/WinForms . WPF apps are probably much more dodgy. In any case, it's reccomended you use Gtk#, which (with a download for Windows) runs on all platforms and looks decent (S.W.F looks like Win9x on Linux/OS X)
Gtk# ... doesn't Gnome use this for most of it's windowing? What does KDE use? I once worked with John Ousterhout (tcl/tk inventor) wife Rita. Tcl is an ok language, but it has too many curly braces [noparse]:)[/noparse] Given the amount of attention received by Tcl/Tk variants now, John and Rita must be very comfotable.
GNOME and XFCE use Gtk+ as their widget toolkit. Gtk# is the binding to .net (Since everything .net must be XX.net or XX# :P). KDE uses Qt (KDE's major version matches the Qt major version it uses - 3 uses Qt 3, 4 uses Qt 4. Everyone is slowly shifting to KDE4 now)
Tcl is among my favorite languages. It's very Lisp, but without some of the annoyances of Lisps. My one complaint with it, however, is it's lack of support for closures. It's very multi-padagrim, which in a way reminds me of C++ (Another of my favorite languages - template metaprograming rules! :P )
STL used to be not very portable in a similar way as varargs ... many machine dependencies. Has this changed recently? I prefer Java over C++ beyond the VM aspect.
I didn't mean to "dis" Tcl ... it is nice once you get into it's "groove" ... at least it uses many common ideas. I consider knowing Tcl/Expect as a Linux professional software engineering requirement. I'm not very fond of expect's intolerance of comments in expect input processing constructs though.
The STL now pretty much just works everywhere, with a few minor differences mainly surrounding the SGI extensions such as rope and hash_map. Visual C++ 7 and up license the Dinkumware library, G++'s libstdc++ is very complete (and now includes the C++ TR1/TR2 extensions), all the Unixes have good STL implementations, and everywhere else (Which is pretty much nowhere) theres STLPort.
I personally prefer C++ over Java. I think it's because C++'s templating is much more powerful, and I miss true structs terribly (That is, ones you can just fwrite to a file)
It was a right PITA and I won't bore you with details ... suffice to say Propeller C can now launch separate C functions in their own cogs. Check DualCog.c which shows one cog running as a serial receiver another cog running as a serial transmitter ( and yes, I know that adds up to three cogs in total ).
I've used TaskNew() rather than CogNew() because they need different parameters, I don't currently do parameter checking ( that info is not in the compiler output file ) and we all know where using the same name function with different parameters and no error checking is going to get us ! I have an idea for not having to specify the stack size so it will become CogNew as per Spin but you'll have to wait for that.
You cannot pass parameters into the function to run within TaskNew() but I may be able to find a way to do that. Use global vars for parameter passing. Not perfect but better than nothing.
TaskInit(), the equivalent of CogInit() isn't working. More debugging needed there.
Oops : You'll need the PropLcc.h file as well. Sorry about that; been a long night and day.
In all mine and jazzed's discussion about Tcl/C++/C#/stuff (sorry 'bout that), it seems my question got lost: which order are parameters passed to coginit on the Spin stack? I.E, in the following code
This is a secondary advantage to my pass it via the stack pointer method: cognews are framed like normal function calls. For example, if you did cognew(myMethod, stack, a, b, c);, it would generate the stack
.long c
.long b
.long a
.long @myMethod
The VM, at startup, pops myMethod into the PC, which jumps to it, from where it functions like a normal function call (with the provisio that returning is inadvisable - I could probably add an item so that returning would do a cogstop though)
Yes, sorry I missed the stack pushing question; it's first parameter is first pushed so -
CogNew( first, second, third )
Push first
Push second
Push third
Call CogNew
Interesting idea for the way of passing parameters and it may well be a quite efficient way of doing things. I've got to study the code generated to see what's best for me, but thanks for the suggestion.
To handle falling off the end of program I keep PC at the top of stack frame and artificially push a zero on starting the VM which is easy to catch when doing a return.
I got·my version of·tv_text.c to this stage with comments before I saw your lastest contribution·. Looks like you have covered most of the issues(as usual). I will modify my file to·reflex the upgrades. ·I was going to suggest that·bytemove, bytefill are not really required because most of this sort of thing could be handled by users who could build their own·routines·providing they have access to an extern asm("pasm")· and given the Cognew, Cognative and Cogstop where addressed.
Beginning to look like my·code·could be and running·much earlier than I expected.
@Ron: An interesting note re spin and the move commands.
Chip's Interpreter code shows that if the move is upwards the move is reversed (i.e. works backwards from the top of the source). This is to do with overlapping fields, but the manual mentions nothing of this. I have not had time to trace this yet, and I am not sure whether this needs to be duplicated or not.
Chip's code... (also handles FILL)
' BYTEMOVE(to,from,count)
' WORDMOVE(to,from,count)
' LONGMOVE(to,from,count)
'
j6
j7 call #popayx 'fill/move/wait, pop parameters
if_c_and_nz jmp #waitpin 'waitpeq/waitpne?
tjz a,#loop 'if count=0, done
test op,#%100 wc,wz 'fill or move?
and op,#%11 'isolate size bits
if_z mov t1,y 'if fill, set value
if_nz cmp y,x wc 'if upward move, modify pointers
if_nz_and_c mov t2,a
if_nz_and_c sub t2,#1
if_nz_and_c shl t2,op
if_nz_and_c add y,t2
if_nz_and_c add x,t2
negc t2,#1 'set inc/dec
shl t2,op
shl op,#3 'set word size
movi fill,op
or op,#%000000_001
movi move,op
maskword long $0000FFFF 'nop/constant
move if_nz rdlong t1,y 'move/fill loop
if_nz add y,t2
fill wrlong t1,x
add x,t2
djnz a,#move
jmp #loop
My code... (also handles FILL)
' ┌──────────────────────────────────────────────────────────────────────────┐
' │ $1C BYTEMOVE(to,from,count) │
' │ $1D WORDMOVE(to,from,count) │
' │ $1E LONGMOVE(to,from,count) │
' │ │
' └──────────────────────────────────────────────────────────────────────────┘
'fill (start,value,count) byte/word/long
j6_012 mov t1,y 'set fill value
movs f_djnz,#fill 'modify the djnz loop (djnz a,#fill)
'fall thru'
'move (to,from,count) byte/word/long
j7_012 tjz a,#loop 'skip if count=0
shr vector,#9 'shift to 3rd vector
movi fill,vector 'modify the fill instruction to wrbyte/word/long
test op,#%100 wz 'fill or move ?
and op,#$03 'isolate size bits
if_z jmp #:incdec 'if fill, skip next few instructions
or vector,#1 'change wrbyte/word/long to rdbyte/word/long
movi move,vector 'modify the move instruction to rdbyte/wrd/long
movs f_djnz,#move 'modify the djnz loop (djnz a,#move)
cmp y,x wc 'if upward move, modify pointers to move backwards
if_c mov t2,a
if_c sub t2,#1
if_c shl t2,op
if_c add y,t2
if_c add x,t2
:incdec negc t2,#1 'set inc/dec
shl t2,op 'scale inc/dec
move if_nz rdlong t1,y 'move loop (rdbyte/word/long)
if_nz add y,t2
fill wrlong t1,x 'fill loop (wrbyte/word/long)
add x,t2
f_djnz djnz a,#0-0 'djnz to #move/#fill
jmp #loop
You are welcome to use any of my code if you wish.
It has·a ·binary that extracts the DAT section from a spin RAM binary and creates a C array ... it automatically handles offsets as long as the DAT section containing PASM is the first one in the file.·The application·is compiled for 32bit windows and should work without problems .... let me know if you have issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stuipid question there is atleast one inteligent answer If you dont ask you wont know
Ok, here's the source.·It is a·Visual Studio C/C++ Express 2008·solution. I didn't bother to create a Linux Makefile build yet. I have also not taken UNICODE characters/strings into account. The spinc.cpp does not contain any C++ despite the extention name. Comments are somewhat limited. I have not attached a liscense, but may do that later.
Comments
Starting a Spin object (TvText) within C and using it - That's likely not to be possible. It would either need the TvText re-writing in C (*) or being started within Spin as now with Spin calling the C routine which returns data for display. That's supported but waiting for and getting a return value from a called C function isn't implemented yet.
Starting another C method in its own Cog - That will work just as you've used it but the library code for CogNew/CogInit isn't complete yet.
What you have is an advanced form of a serial-to-TV program and that's quite a good demonstration of Spin and C co-operation. What I'll do is get such a program working, as a plain keyin without a second cog and no buffering then with. I'll probably start with a serial echo which buffers input in a second cog.
(*) I hadn't checked how the OBEX TvText for C worked with what I have but that seems to compile okay after a few tweaks; removing #include<> for header files I don't have and asm(). Looks promising.
Ok well I will re work my modified version of Steve's TV_text.c to run under your system.
I don't think it will be too difficult.
Yep, I could not figure out how to deal with a repeat Esc sequence
without using another Cog. I will be very interested to see what you come up with.
Don't get too bogged down though [noparse]:)[/noparse]
Regards
Ron
Keep up the good work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Getting CogNew working is up at the top end of priorities but there could be some challenges and debugging effort for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Here is my mountain to climb [noparse]:)[/noparse]
I will knock of what can be done now and ·see what we need from·you in the·way of Libs·as·I go along.
Who knows, it might happen.·Might not, we will find out.
Ron
The code which actually does a CogNew
At the moment it just pulls the data from stack then returns. It's all doable but I just have to get my thinking cap on to work out how to set a parameter block to re-call the LccVm so it starts running in another Cog executing the right bytecode.
At the moment CogNew tries to run C bytecode as if it was PASM.
Post Edited (hippy) : 9/13/2008 5:50:27 PM GMT
Edit: Since you seem to be the defacto reference on Spin, which way round does it push parameters? I'm modifying the "standard" assembly bootstrapper slightly and need to know which 0 is which
Post Edited (OwenS) : 9/13/2008 9:19:45 PM GMT
Just for the record, MyEditor.c was my first attempt at a C# program. When I realized that I could not add the SdCard code and still it squeeze it into the code Limited version of Imagecraft’s ICC7 I dropped the idea.
I am only interested in pursuing stuff which is of interest to Prop enthusiasts and non for profit. I have used Forth some years ago, so when Carl came up with his JDForth I started to port MyEditor across to JDForth.
Each time I go back to my C# version for reference I realize, what a mess it is, and it begs to be re-written. That being the case I might has well write the Forth and C# version at the same time. I am sure that I can work around what you doing to make it work. I do realize that not all the libraries are available to implement this sort of code ATM, but I have no doubt it will happen.
The idea of being able to run code from SDcard at some stage is looking like a real possibility.
Anyway for me it’s just for fun now. [noparse]:)[/noparse]
I will keep you posted on my progress.
Ron
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Michael Park
PS, BTW, and FYI:
To search the forum, use search.parallax.com (do not use the Search button).
Check out the Propeller Wiki: propeller.wikispaces.com/
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Hey, I'm having to much fun as it is !
ron
So, C# is fine as long as it will run on other VMs on other operating systems, just like Python or whatever. At the moment I think we only have mono for Linux and then only on Intel processors. Unless I've missed some progress in that area.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The CLR that Microsoft provides may fall into the area of "closed, proprietary operating/platform and possibly encumbered with patents", but the language C# does not.
Also, if I recall correctly, the IL and CLR concepts and specifications are open as well. Which is why Mono exists, and they do have a Mac OSX flavor of Mono now too.
I know of other smaller porting efforts to consoles (like the PSP) too. So it's expanding.
Is it now possible to write GUI apps in C# that will run under Windows and Mono or are we still at the command line level under Mono?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Last time I tried mono some years ago when it was first released, it was a disaster; all that downloading for nothing. Surely it works now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Tcl is among my favorite languages. It's very Lisp, but without some of the annoyances of Lisps. My one complaint with it, however, is it's lack of support for closures. It's very multi-padagrim, which in a way reminds me of C++ (Another of my favorite languages - template metaprograming rules! :P )
I didn't mean to "dis" Tcl ... it is nice once you get into it's "groove" ... at least it uses many common ideas. I consider knowing Tcl/Expect as a Linux professional software engineering requirement. I'm not very fond of expect's intolerance of comments in expect input processing constructs though.
Way OT [noparse]:)[/noparse] Sorry about that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
I personally prefer C++ over Java. I think it's because C++'s templating is much more powerful, and I miss true structs terribly (That is, ones you can just fwrite to a file)
Wow, this is way off topic [noparse]:)[/noparse]
Whoot !
It was a right PITA and I won't bore you with details ... suffice to say Propeller C can now launch separate C functions in their own cogs. Check DualCog.c which shows one cog running as a serial receiver another cog running as a serial transmitter ( and yes, I know that adds up to three cogs in total
I've used TaskNew() rather than CogNew() because they need different parameters, I don't currently do parameter checking ( that info is not in the compiler output file ) and we all know where using the same name function with different parameters and no error checking is going to get us ! I have an idea for not having to specify the stack size so it will become CogNew as per Spin but you'll have to wait for that.
You cannot pass parameters into the function to run within TaskNew() but I may be able to find a way to do that. Use global vars for parameter passing. Not perfect but better than nothing.
TaskInit(), the equivalent of CogInit() isn't working. More debugging needed there.
Oops : You'll need the PropLcc.h file as well. Sorry about that; been a long night and day.
Post Edited (hippy) : 9/14/2008 10:09:43 PM GMT
.byte $35 ' push #0 .byte $37, $04 ' push #$20 .byte $35 ' push #0 .byte $2C ' coginit(0, $20, 0)which 0 is which?
Now, back to "TaskNew":
This is a secondary advantage to my pass it via the stack pointer method: cognews are framed like normal function calls. For example, if you did cognew(myMethod, stack, a, b, c);, it would generate the stack
.long c
.long b
.long a
.long @myMethod
The VM, at startup, pops myMethod into the PC, which jumps to it, from where it functions like a normal function call (with the provisio that returning is inadvisable - I could probably add an item so that returning would do a cogstop though)
Post Edited (OwenS) : 9/14/2008 10:28:03 PM GMT
CogNew( first, second, third )
Push first
Push second
Push third
Call CogNew
Interesting idea for the way of passing parameters and it may well be a quite efficient way of doing things. I've got to study the code generated to see what's best for me, but thanks for the suggestion.
To handle falling off the end of program I keep PC at the top of stack frame and artificially push a zero on starting the VM which is easy to catch when doing a return.
I got·my version of·tv_text.c to this stage with comments before I saw your lastest contribution·. Looks like you have covered most of the issues(as usual). I will modify my file to·reflex the upgrades. ·I was going to suggest that·bytemove, bytefill are not really required because most of this sort of thing could be handled by users who could build their own·routines·providing they have access to an extern asm("pasm")· and given the Cognew, Cognative and Cogstop where addressed.
Beginning to look like my·code·could be and running·much earlier than I expected.
Regards
Ron
Chip's Interpreter code shows that if the move is upwards the move is reversed (i.e. works backwards from the top of the source). This is to do with overlapping fields, but the manual mentions nothing of this. I have not had time to trace this yet, and I am not sure whether this needs to be duplicated or not.
Chip's code... (also handles FILL)
' BYTEMOVE(to,from,count) ' WORDMOVE(to,from,count) ' LONGMOVE(to,from,count) ' j6 j7 call #popayx 'fill/move/wait, pop parameters if_c_and_nz jmp #waitpin 'waitpeq/waitpne? tjz a,#loop 'if count=0, done test op,#%100 wc,wz 'fill or move? and op,#%11 'isolate size bits if_z mov t1,y 'if fill, set value if_nz cmp y,x wc 'if upward move, modify pointers if_nz_and_c mov t2,a if_nz_and_c sub t2,#1 if_nz_and_c shl t2,op if_nz_and_c add y,t2 if_nz_and_c add x,t2 negc t2,#1 'set inc/dec shl t2,op shl op,#3 'set word size movi fill,op or op,#%000000_001 movi move,op maskword long $0000FFFF 'nop/constant move if_nz rdlong t1,y 'move/fill loop if_nz add y,t2 fill wrlong t1,x add x,t2 djnz a,#move jmp #loopMy code... (also handles FILL)
' ┌──────────────────────────────────────────────────────────────────────────┐ ' │ $1C BYTEMOVE(to,from,count) │ ' │ $1D WORDMOVE(to,from,count) │ ' │ $1E LONGMOVE(to,from,count) │ ' │ │ ' └──────────────────────────────────────────────────────────────────────────┘ 'fill (start,value,count) byte/word/long j6_012 mov t1,y 'set fill value movs f_djnz,#fill 'modify the djnz loop (djnz a,#fill) 'fall thru' 'move (to,from,count) byte/word/long j7_012 tjz a,#loop 'skip if count=0 shr vector,#9 'shift to 3rd vector movi fill,vector 'modify the fill instruction to wrbyte/word/long test op,#%100 wz 'fill or move ? and op,#$03 'isolate size bits if_z jmp #:incdec 'if fill, skip next few instructions or vector,#1 'change wrbyte/word/long to rdbyte/word/long movi move,vector 'modify the move instruction to rdbyte/wrd/long movs f_djnz,#move 'modify the djnz loop (djnz a,#move) cmp y,x wc 'if upward move, modify pointers to move backwards if_c mov t2,a if_c sub t2,#1 if_c shl t2,op if_c add y,t2 if_c add x,t2 :incdec negc t2,#1 'set inc/dec shl t2,op 'scale inc/dec move if_nz rdlong t1,y 'move loop (rdbyte/word/long) if_nz add y,t2 fill wrlong t1,x 'fill loop (wrbyte/word/long) add x,t2 f_djnz djnz a,#0-0 'djnz to #move/#fill jmp #loopYou are welcome to use any of my code if you wish.
See this post http://forums.parallax.com/showthread.php?p=747635
It has·a ·binary that extracts the DAT section from a spin RAM binary and creates a C array ... it automatically handles offsets as long as the DAT section containing PASM is the first one in the file.·The application·is compiled for 32bit windows and should work without problems .... let me know if you have issues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
My XP SP3 Swedish edition cant run spinc.exe
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stuipid question there is atleast one inteligent answer
If you dont ask you wont know
Sapieha
Ok, here's the source.·It is a·Visual Studio C/C++ Express 2008·solution. I didn't bother to create a Linux Makefile build yet. I have also not taken UNICODE characters/strings into account. The spinc.cpp does not contain any C++ despite the extention name. Comments are somewhat limited. I have not attached a liscense, but may do that later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve