▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 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
@Cluso99, Thanks, but ATM, my test code was posted just to identify
some of the external LIB routines which would be required to run the
standard Tv_text.c, ported to the OBEX by Jazzed.·
(Hippy would be aware of them anyway, but it gives him some code to
play with)
BTW Is that Lady Musgrave reef?· We have lived aboard for eight years or so
and in Penang ATM. I think we would be the only Classic Gaff Rigged Sail vessel
in the world with four Prop's· [noparse]:)[/noparse]
Ron
@Ron: No, it's Yellow Patch - a large (orange) sand blow near Cape Capricon, Curtis Is. Our catamaran is currently on the Gold Coast, and I dare say, the only one with 2 props.
Ron Sutcliffe said...
ATM, my test code was posted just to identify
some of the external LIB routines which would be required to run the
standard Tv_text.c, ported to the OBEX by Jazzed.
(Hippy would be aware of them anyway, but it gives him some code to
play with)
Having looked more closely at TvText there's more to it than I'd considered but it's still looking doable; it does come down to having the right LIB's and a few other things.
I've now got a framework for launching PASM code in its own cog and for getting that PASM
code into the source ( either as a long array or as a PASM function ) and it will also be possible to execute inline PASM within the bytecode. Not that useful for interacting with the bytecode/VM but very handy for high-speed bit-banged I/O. It also allows me to later move library code from the Kernel itself into standard C files.
Can also now call arbitrary C functions from within a Spin program and get a result back which is as simple as ...
OBJ
c : "MyC.Lcc"
PUB Main
result := c.Maximum(10,21)
#include <PropLcc.h>
int Maximum( int a, int b)
{
if ( a > b ) { return a; }
else { return b; }
}
Thanks to Carl Jacobs and JDForth for making me realise it could be this simple.
thank you for the help! The combination of my assembler, linker and virtual machine just executed their first code under GEAR! The assembler assembled everything (The Spin prefix, the PASM of the virtual machine, and the virtual machine bytecode). The assembler is trimodal (PASM-Cog, PASM-LMM and VMM-ASM), the virtual machine is bimodal (LMM and VMM).
Validation & testing is ongoing, and so far looks promising. The only feature I wish the Propeller had that would make writing VMs (and other stuff) easier is register indirect addressing
Excellent news and I know what if feels like to reach that milestone. Now you just have to find the bugs
Register indirect is an on-going bug-bear. Some times I feel its lack more than others. In LccVm I think there's only a couple of places I use any self-modifying code. It seems to depend on which virtual machine instruction set style you choose and some need it a lot.
In-built macros for LMM coding are the things I sorely miss. I can achieve them by pre-processing but I feel much more comfortable being able to compile and run the kernel and test wrapper as is which means everything there has to be PropTool compliant.
I have a separate program now which scans a Spin file and checks for stupid mistakes like forgetting the # for jmp, accidentally using jmp @, and making sure constants such as k_8000_0000 actually contain a matching value - I lost one zero in typing and spent hours trying to find it again
Indeed about instruction styles heavily affecting self modifying code! VMM (As Ive dubbed it, probably means "Virtual Machine Mode", I somehow adopted it because it rhymes with LMM :P ) is a register machine. You would be right if you imagined that almost every instruction is self modifying.
Now a quiz, since my brain can't think it's way through this bug
Hub ram:
7FFC: FFFFFFFF
Cog ram:
00D: 00007FFC
Code:
RDLONG $000, $00D
How is 000 being set to zero?! Is my brain broken, or is something wrong with Gear?!
(The hex of the RDLONG instruction is 08BC000D if that helps)
After staring at my code for ages, I finally realised what it was... and whacked myself promptly with a rubber mallet.
I forgot the delay between the MOVS before it. I shuffled the "ADD pc, #2" before the RDLONG and that fixed it (Moving it before is more logical anyway because then LDI pc, [noparse][[/noparse]sp] works (for example), so I don't know why I didn't do it)
hippy said...
The one which forever trips me up is ...
VAR
long myVar
DAT
rdlong reg,ptr
ptr long @myVar
My assembler assembles that as would be expected! (Though it's never heard of VAR and DAT sections [noparse];)[/noparse] )
myVar long
' or .extern myVar
' ...
rdlong reg, ptr
' ...
ptr .long @myVar
@ is the hub address operator, and the assembler will emit a ".long 0000" with a RELOC_LONG myVar+0 attached. The linker will resolve the symbol.
The linker also supports enlarging VMM and LMM instructions as needed (LMM FJMP can assemble to ADD pc, #xxx; SUB pc, #xxx; or JMP #fjmp; .long xxx. VMM ldl (load literal) can assemble to LDL.w (word) or LDL.l (long))
Cheers Ron. I'm still re-writing the tools at present and testing as I go but there will be a new version coming out soon(ish).
The tool-chain is quite long now but handled by a simple single .Exe wrapper or the component parts can be run individually as per traditional C development -
Compile, Link, Assemble, Optimise, Create a Listing, Create the Spin File, Optimise the PASM in the Spin File, Compile the Spin File, Download the Image to Propeller Chip.
I'm only missing Create the Spin File to get back to where I was.
All intermediate files are in textual "bytecode assembly language" to make processing easier and allowing other components to be dropped into the chain. Linking is really just merging source files, linking to the Kernel is done when the Spin file is created.
Once back to working again I'll be moving library code out from the Kernel into .c files to also match a more traditional C development process and make it easier to use C versions of TV_Text etc.
As end-user I would like to know what the pro's and con's are at the moment.
Is it possible to let the C program interact with SPIN objects?
Is it possible to let the C program run ASM instructions?
I successfully compiled and programmed the FlashLed and DualCog examples.
The serial output is missing a lot of the data though.
Thanks. I'll put my hand-up to having not progressed as much as I'd hoped on the re-write. I'm suffering some burn-out after the quite intensive effort to start with and some real life distractions have arrived, but it's still on the way, just need to get my act together.
Spin can interact with C but not the other way round, except when passing blocks of data between the two as with any multi-Cog configuration.
Spin can CogNew a C program just as it can CogNew a PASM program. It's also possible for C to CogNew another C or PASM program. C using CogNew to launch a Spin method would be possible but the problem is in getting the necessary information about the Spin method into the C program. That's not easily achieved in any usable way, a limitation of Spin and PropTool.
Using Spin objects such as Tv_Text is much the same as with ICC; launch the PASM driver in its own Cog, rewrite the interface routines to it in C. Alternatively, write a Spin program uisng Spin objects and provide a means to allow the C program to pass 'messages' back to allow the Spin to do what's required. Not efficient and not always easy to achieve with the Spin way of way object encapsulation.
The C program can almost run inline PASM; it's limited to LMM-style PASM but that should be enough to do bit-banging and similar. I still need to do work on this to get it into a form which would be most usable. For full speed PASM it's necessary to run that in its own Cog as it is with Spin.
Comments
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
@Cluso99, Thanks, but ATM, my test code was posted just to identify
some of the external LIB routines which would be required to run the
standard Tv_text.c, ported to the OBEX by Jazzed.·
(Hippy would be aware of them anyway, but it gives him some code to
play with)
BTW Is that Lady Musgrave reef?· We have lived aboard for eight years or so
and in Penang ATM. I think we would be the only Classic Gaff Rigged Sail vessel
in the world with four Prop's· [noparse]:)[/noparse]
Ron
I've now got a framework for launching PASM code in its own cog and for getting that PASM
code into the source ( either as a long array or as a PASM function ) and it will also be possible to execute inline PASM within the bytecode. Not that useful for interacting with the bytecode/VM but very handy for high-speed bit-banged I/O. It also allows me to later move library code from the Kernel itself into standard C files.
Can also now call arbitrary C functions from within a Spin program and get a result back which is as simple as ...
#include <PropLcc.h> int Maximum( int a, int b) { if ( a > b ) { return a; } else { return b; } }Thanks to Carl Jacobs and JDForth for making me realise it could be this simple.
Post Edited (hippy) : 9/15/2008 3:12:16 PM GMT
thank you for the help! The combination of my assembler, linker and virtual machine just executed their first code under GEAR! The assembler assembled everything (The Spin prefix, the PASM of the virtual machine, and the virtual machine bytecode). The assembler is trimodal (PASM-Cog, PASM-LMM and VMM-ASM), the virtual machine is bimodal (LMM and VMM).
Validation & testing is ongoing, and so far looks promising. The only feature I wish the Propeller had that would make writing VMs (and other stuff) easier is register indirect addressing
Post Edited (OwenS) : 9/15/2008 7:21:41 PM GMT
Register indirect is an on-going bug-bear. Some times I feel its lack more than others. In LccVm I think there's only a couple of places I use any self-modifying code. It seems to depend on which virtual machine instruction set style you choose and some need it a lot.
In-built macros for LMM coding are the things I sorely miss. I can achieve them by pre-processing but I feel much more comfortable being able to compile and run the kernel and test wrapper as is which means everything there has to be PropTool compliant.
I have a separate program now which scans a Spin file and checks for stupid mistakes like forgetting the # for jmp, accidentally using jmp @, and making sure constants such as k_8000_0000 actually contain a matching value - I lost one zero in typing and spent hours trying to find it again
Now a quiz, since my brain can't think it's way through this bug
Hub ram:
7FFC: FFFFFFFF
Cog ram:
00D: 00007FFC
Code:
RDLONG $000, $00D
How is 000 being set to zero?! Is my brain broken, or is something wrong with Gear?!
(The hex of the RDLONG instruction is 08BC000D if that helps)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
After staring at my code for ages, I finally realised what it was... and whacked myself promptly with a rubber mallet.
I forgot the delay between the MOVS before it. I shuffled the "ADD pc, #2" before the RDLONG and that fixed it (Moving it before is more logical anyway because then LDI pc, [noparse][[/noparse]sp] works (for example), so I don't know why I didn't do it)
VAR long myVar DAT rdlong reg,ptr ptr long @myVar▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Yikes, you can't do that,·who·is going to·provide··intermediate level support for C.·
@hippy my·MyTv_text is close now. See zip file.··A·cogNewNative LIB would get me over the line I think.
I·still have to do a work around for .....typedef struct _tv_text....., I guess
It does compiles with the following error
Kernal Mistake :· Modifying constant after lock ptr··· "mov K_lcc, pc··· ?????
One day·It might even run [noparse]:)[/noparse]
Regards Ron
·Whoops the tv_text_rs.h files·need to be included·in .c file ·
Post Edited (Ron Sutcliffe) : 9/16/2008 3:29:01 AM GMT
For the kernel mistake, around line 890 in Kernel.Spin add an "IF_ALWAYS" ...
' <<IFNOT KERNEL.LIBS>> IF_ALWAYS mov k_LccCode,pc ' <<ELSE>>Post Edited (hippy) : 9/16/2008 8:24:14 AM GMT
My assembler assembles that as would be expected! (Though it's never heard of VAR and DAT sections [noparse];)[/noparse] )
@ is the hub address operator, and the assembler will emit a ".long 0000" with a RELOC_LONG myVar+0 attached. The linker will resolve the symbol.
The linker also supports enlarging VMM and LMM instructions as needed (LMM FJMP can assemble to ADD pc, #xxx; SUB pc, #xxx; or JMP #fjmp; .long xxx. VMM ldl (load literal) can assemble to LDL.w (word) or LDL.l (long))
I just got up with the DIY C news reading the other thread.
great [noparse]:)[/noparse]
The tool-chain is quite long now but handled by a simple single .Exe wrapper or the component parts can be run individually as per traditional C development -
Compile, Link, Assemble, Optimise, Create a Listing, Create the Spin File, Optimise the PASM in the Spin File, Compile the Spin File, Download the Image to Propeller Chip.
I'm only missing Create the Spin File to get back to where I was.
All intermediate files are in textual "bytecode assembly language" to make processing easier and allowing other components to be dropped into the chain. Linking is really just merging source files, linking to the Kernel is done when the Spin file is created.
Once back to working again I'll be moving library code out from the Kernel into .c files to also match a more traditional C development process and make it easier to use C versions of TV_Text etc.
Great progress you made with the C compiler!
As end-user I would like to know what the pro's and con's are at the moment.
Is it possible to let the C program interact with SPIN objects?
Is it possible to let the C program run ASM instructions?
I successfully compiled and programmed the FlashLed and DualCog examples.
The serial output is missing a lot of the data though.
Kind regards,
Robot Freak
Spin can interact with C but not the other way round, except when passing blocks of data between the two as with any multi-Cog configuration.
Spin can CogNew a C program just as it can CogNew a PASM program. It's also possible for C to CogNew another C or PASM program. C using CogNew to launch a Spin method would be possible but the problem is in getting the necessary information about the Spin method into the C program. That's not easily achieved in any usable way, a limitation of Spin and PropTool.
Using Spin objects such as Tv_Text is much the same as with ICC; launch the PASM driver in its own Cog, rewrite the interface routines to it in C. Alternatively, write a Spin program uisng Spin objects and provide a means to allow the C program to pass 'messages' back to allow the Spin to do what's required. Not efficient and not always easy to achieve with the Spin way of way object encapsulation.
The C program can almost run inline PASM; it's limited to LMM-style PASM but that should be enough to do bit-banging and similar. I still need to do work on this to get it into a form which would be most usable. For full speed PASM it's necessary to run that in its own Cog as it is with Spin.