Yes, absolutely: I'd much much rather have an embedded forth than any other language.
Reasons:
1) forth traditionally has a very small core and produces very small executables, perfect for this type of environment
2) easily extensible, so anything that wasn't built-in can be made to appear as if it was (thus alleviating the pain of having the interpreter hard-coded in a ROM)
3) as a side-effect of 2, forth also lends itself very nicely to be a meta language to build other languages on top of itself, thus allowing others their favored choices
We did start on a spin compiler but it never got finished. It was starting to parse code and then Propellant was released and I think that it killed some of the enthusiasm. Also, there was really only dfletcher doing the coding for it and I think that he got busy with other stuff...
There is a thread on it somewhere in the forums and the code for it is on sourceforge under "spinc".
The spin interpreter was released and there is also some info about spin and object format on the propeller wiki.
Took me _forever_ to gather all the libraries and ocx required to get it to run under WINE, then of course the font defaults to about 0.05 point.. but once I got it set up and running...
Do you mind posting a list of names you are using for the opcodes ?. I'm integrating full disassembler of spin and using the real interpreter for spin into my pPropellerSim (for full development but without real spin compiler) Actually if you post your source... even better I'd implement it in java anyways.
@ BradC : Welcome to Windows with VB6 thrown on top for good measure
@ Ale : List of Spin opcodes attached. I'm hesitant to release the source because it's such a mess but I could. I'm not really sure how useful it would be though. I'd rewrite from scratch knowing what I do now and wouldn't recommend anyone following the way I did it.
@ Ale : I think you'll get a better grasp of image format from what Cluso99 and others have posted than my code. There was a posting recently which described the way .eeprom files are put together. Perhaps the main missing information is what the parameters to Spin bytecode opodes are. It's all somewhere on the forum from myself and others just not consolidated.
Source is attached, the bytecode.txt and mainspec.txt are perhaps of most interest. Probably not as accurate or as 'true' as they could be today. E&OE as they say.
The big mistake I made in disassembly was not realising how "RES" worked in PASM. I'd now parse Spin then PASM. I'd also walk the method/object links better than I did previously ( a recent post pointed out that the number of PRI/PUB/OBJ is held in the first link of each object which looks correct.
The big problem ( apart from poor PASM identification and not finding all methods ) I ran into was non-standard images, for booting PASM/Forth/etc and hacked images, and ( related to those ), whether to continue or stop disassembly after a CogInit. How I disassemble CogNew/CogInit to launch a Spin method is I'm sure wrong.
I'd merge that to my next revision of the simulator and try to simulate something to see if a proper simulation can be achieved. I wanted to have something sort of working to better develop LMM, but without support to load to HUB and so on... the simulator is sort of limited usefulness. (Besides pure and normal cog assembler). Let's see how much can I do, now the ball is on my side !
I took the deep breath and have started to re-code the bytecode disassembler. As expected it's much easier this time round. The code will be a PowerBasic command line utility so just one 32-bit .exe which is hopefully easier to use than VB6 stuff. I'll probably re-write the VB6 as a visual wrapper.
The new version will still be 'thrown together', few if any comments, but should be simpler to follow and work better. I've split the code into four parts, the main wrapper and utility code, the disassembly traversal, traversed code dumping and instruction folding for displaying. That should make it a lot easier to understand and port to other languages.
I'm also aiming to have it intelligent enough to be able to handle the case where the image has been patched post PropTool generation and properly handle where it's really a wrapper for booting PASM. This will eventually include LMM-C disassembly. There is also an option to generate 'bytecode assembler' which can be optimised and re-assembled.
I'm doing it incrementally and no timeline planned put can release alpha's and beta's if people are interested. So far header decoding, object traversal, method detection and quite a lot of bytecode disassembly works. Variables and stack variable use needs doing and there's no PASM disassembly yet. The core of it all is however there.
I used your disassembler the other day before I got busy and i gave me a great insight into what I am interpreting - thanks heaps.
I only used a short test pin program. I must say I was surprised that the spin complier doesn't evaluate constants before compiling (no optimisation)
e.g.·· repeat i from 0 * 4 to 10 *·4 step 4
The compiler emits pushes 0, pushes 4, multiplies them, pushes the result, etc...
I have a suggestion (maybe you had a reason) but it seems you use LSET instead of the two bytecodes push and pop.
By the way, if you want to PM me I can send you the LMM debugger I am using in the RamInterpreter (it's too crude to publish, but well documented). It can test the cog it is running in and pass over (still retains control though) if it is not the cog you want. I needed this as I have the RamInterpreter running in cog 0 and 2 concurrently which I forgot about and it took ages to realise the problem!
AFAIR there's no dead code removal either, so put an explicit 'return' at the end of a method and the compiler will add another anyway, and it doesn't reduce 'if false' etc either.
As to "LET"; that's probably down to one of the 'fold' options under the 'view' menu. I have realised in revisiting the folding operations ( really just a peephole optimiser ) it would be possible to do constant folding and dead code removal with a few additions so that could simplify optimisation and code compaction.
I'll leave you with the LMM debugger for the time being or I'll just get side-tracked again
A new version (0.00) of the Spin Disassembler attached. I've called it PropList to avoid confusion with previous versions. This is a Windows command line utility, "PROPLIST PropTest" will load PropTest.eeprom/.binary and generate a PropTest.Lst text file. It's a standalone .Exe so nothing else needed. Don't know if it will run under WINE etc or not.
No switch options for controlling output format yet, all hard-wired constants. Source included is PowerBasic Console Compiler. Hopefully much more understandable than the VB version but still quite thrown together; at least the functionality is better divided up across the include files.
Quite a few changes included which improve things such as marking self-modified PASM code with the familiar '0-0'. It is also better at guessing where Spin bytecode and PASM is even if it's not explicitly referenced. As with the previous versions I'll probably modify the code to fix bugs and shortcomings as I run into them.
Included is PropTest.spin which gives most of the Spin language a good workout. Should be useful for people writing Spin compilers etc. Some stuff isn't disassembling at present and a few things need to be done but this is the bulk of the work out of the way.
@Hippy - Fantastic. I will download when I am on my development laptop. I had already noticed on your previous download that you had some code testing various options.
I am also writing validation code as you will see on the other thread. Done $EF-$FF bytecodes but waiting for results - I expect it will take day(s) to run the validation and seem to have a problem which may be stack related as it seems to crash but it may just be PST - unsure at this time.
Latest version of the command line disassembler ( /? for options ). Finally made it to a usable Version 1.0 and will probably remain as is for a while unless any critical bugs turn up.
It's not perfect, occasionally trips itself up, but is good enough for simple code and better than the earlier Windows version.
Discovered a bug in PropView 1.03#0101 while tying to figure out how to launch the RamInterpreter in just one cog without disturbing the rest of what is running (for debugging my Interpreter). Thought you may like a sample. The PRI PriSpinCode source is lower down the page than the actual bytecode.
I'm not likely to fix anything in that, PropList is what I'd now recommend. Eventually the new PropView will simply be a GUI wrapper for PropList.
PropList did't fare any better not showing any source code at all ! Seems it doesn't like unicode text files. Here's a latest version of PropList.Exe which should tolerate it.
Thanks Hippy, but I have not been able to get PropList to work. Just pops up a window with a black background and closes immediately.
Is there anything I need to do? (Note no version number in properties). I am using Vista.
I am trying to find out how to launch the RamInterpreter in just one cog and have it run a spin object so that I can debug it. So far I have been unsuccessful - any ideas?? The reason I need this is that I have to have a good version of the Intepreter (Ram or Rom) running to do the debugging, while testing an unknown version.
I guess that I am trying to replace "coginit (0,@RamInterpreter,$0004)" with coginit(4,@RamInterpreter2,$xxxx) where $xxxx point to load another spin routine, but I cannot determine how to find the $xxxx. It's probably staring me in the face and just have a mental block. :-(
I tested it with Win 95, Win 98, Win XP, Windows Server 2003, Windows XP Embedded and Windows XP PE, so I think it's a safe bet to say it's a problem related to Vista. I don't have access to Vista so it's unlikely to get fixed in the short term. Long term I'll have to port it to something which does work; as you're running PropView it seems VB6 is still compatible so not all bad news.
Cluso99 said...
I guess that I am trying to replace "coginit (0,@RamInterpreter,$0004)" with coginit(4,@RamInterpreter2,$xxxx) where $xxxx point to load another spin routine, but I cannot determine how to find the $xxxx. It's probably staring me in the face and just have a mental block. :-(
The $xxxx can be anywhere, it just needs to be set as $0004-$000F would be. So you can use "VAR byte params[noparse][[/noparse]$0010]", use just $0004 to $000F, then "CogInit(4,@RamInterpreter,@params+$0004).
Vista·· (I have VB6 SP6·and VB2008 Express Installed)
I'll check PropList·on my other XP laptop later and let you know.
As for the coginit, I didn't explain it well. I am trying to load 2 versions of the RamInterpreter (one working and one being tested). Anyway, I have figured out a way: I'll modify the working version to check if it is loading cog 7 and if so it will launch the new RamInterpreterTest and it's spin code.
Aha ! Yes, that's the way I'd do it as well. A test in the Interpreter itself before it calls CogInit.
Is it a good idea to use the RAM interpreter for testing itself ? A safer bet would be to use ROM interpreter to test the RAM Interpreter but that might not suit what you need to do in your tests.
I have two versions of the RamInterpreter running. The one in cog 7 is the one I am testing - now to add the zero footprint debugger and some debugging for the bytecodes and I am away. Once I have a trace I know there will be an easer way to just launch the cog 7 test version, but who cares.
By the way - I hacked out the sqrt function (saves more code) and put back everything including your coginit hack and waitcnt hack. I had already saved a number of bytes with simple decoding. The range hack needed to be taken out as it is used in tv and fdx.hex(...).
Hopefully I will have some preliminary timing test over the weekend.
Cluso99 ... If you ( or anyone else with Vista for that matter or even Wine etc ) could spare a few moments to run the two test.exe programs attached at a command line under Vista and report back it would be appreciated. They both print up simple block-matrix messages then finish.
Comments
Yes, absolutely: I'd much much rather have an embedded forth than any other language.
Reasons:
1) forth traditionally has a very small core and produces very small executables, perfect for this type of environment
2) easily extensible, so anything that wasn't built-in can be made to appear as if it was (thus alleviating the pain of having the interpreter hard-coded in a ROM)
3) as a side-effect of 2, forth also lends itself very nicely to be a meta language to build other languages on top of itself, thus allowing others their favored choices
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
Jo
There is a thread on it somewhere in the forums and the code for it is on sourceforge under "spinc".
The spin interpreter was released and there is also some info about spin and object format on the propeller wiki.
_nice_ work... really nice..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Do you mind posting a list of names you are using for the opcodes ?. I'm integrating full disassembler of spin and using the real interpreter for spin into my pPropellerSim (for full development but without real spin compiler) Actually if you post your source... even better
Thanks !
@ Ale : List of Spin opcodes attached. I'm hesitant to release the source because it's such a mess but I could. I'm not really sure how useful it would be though. I'd rewrite from scratch knowing what I do now and wouldn't recommend anyone following the way I did it.
Is it possible to allow an option to turn off message boxes (including bad checksum) at startup ?
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
File -> Inhibit Warning messages
I must admit that the "PropTool is running" warning was starting to tee me off as well
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
@Ale I am not sure if this is what you are looking for.
You may also find this link useful http://propeller.wikispaces.com/Spin+Byte+Code
Post Edited (Cluso99) : 7/21/2008 12:06:57 PM GMT
Source is attached, the bytecode.txt and mainspec.txt are perhaps of most interest. Probably not as accurate or as 'true' as they could be today. E&OE as they say.
The big mistake I made in disassembly was not realising how "RES" worked in PASM. I'd now parse Spin then PASM. I'd also walk the method/object links better than I did previously ( a recent post pointed out that the number of PRI/PUB/OBJ is held in the first link of each object which looks correct.
The big problem ( apart from poor PASM identification and not finding all methods ) I ran into was non-standard images, for booting PASM/Forth/etc and hacked images, and ( related to those ), whether to continue or stop disassembly after a CogInit. How I disassemble CogNew/CogInit to launch a Spin method is I'm sure wrong.
I'd merge that to my next revision of the simulator and try to simulate something to see if a proper simulation can be achieved. I wanted to have something sort of working to better develop LMM, but without support to load to HUB and so on... the simulator is sort of limited usefulness. (Besides pure and normal cog assembler). Let's see how much can I do, now the ball is on my side !
The new version will still be 'thrown together', few if any comments, but should be simpler to follow and work better. I've split the code into four parts, the main wrapper and utility code, the disassembly traversal, traversed code dumping and instruction folding for displaying. That should make it a lot easier to understand and port to other languages.
I'm also aiming to have it intelligent enough to be able to handle the case where the image has been patched post PropTool generation and properly handle where it's really a wrapper for booting PASM. This will eventually include LMM-C disassembly. There is also an option to generate 'bytecode assembler' which can be optimised and re-assembled.
I'm doing it incrementally and no timeline planned put can release alpha's and beta's if people are interested. So far header decoding, object traversal, method detection and quite a lot of bytecode disassembly works. Variables and stack variable use needs doing and there's no PASM disassembly yet. The core of it all is however there.
I used your disassembler the other day before I got busy and i gave me a great insight into what I am interpreting - thanks heaps.
I only used a short test pin program. I must say I was surprised that the spin complier doesn't evaluate constants before compiling (no optimisation)
e.g.·· repeat i from 0 * 4 to 10 *·4 step 4
The compiler emits pushes 0, pushes 4, multiplies them, pushes the result, etc...
I have a suggestion (maybe you had a reason) but it seems you use LSET instead of the two bytecodes push and pop.
By the way, if you want to PM me I can send you the LMM debugger I am using in the RamInterpreter (it's too crude to publish, but well documented). It can test the cog it is running in and pass over (still retains control though) if it is not the cog you want. I needed this as I have the RamInterpreter running in cog 0 and 2 concurrently which I forgot about and it took ages to realise the problem!
As to "LET"; that's probably down to one of the 'fold' options under the 'view' menu. I have realised in revisiting the folding operations ( really just a peephole optimiser ) it would be possible to do constant folding and dead code removal with a few additions so that could simplify optimisation and code compaction.
I'll leave you with the LMM debugger for the time being or I'll just get side-tracked again
No switch options for controlling output format yet, all hard-wired constants. Source included is PowerBasic Console Compiler. Hopefully much more understandable than the VB version but still quite thrown together; at least the functionality is better divided up across the include files.
Quite a few changes included which improve things such as marking self-modified PASM code with the familiar '0-0'. It is also better at guessing where Spin bytecode and PASM is even if it's not explicitly referenced. As with the previous versions I'll probably modify the code to fix bugs and shortcomings as I run into them.
Included is PropTest.spin which gives most of the Spin language a good workout. Should be useful for people writing Spin compilers etc. Some stuff isn't disassembling at present and a few things need to be done but this is the bulk of the work out of the way.
I am also writing validation code as you will see on the other thread. Done $EF-$FF bytecodes but waiting for results - I expect it will take day(s) to run the validation and seem to have a problem which may be stack related as it seems to crash but it may just be PST - unsure at this time.
It's not perfect, occasionally trips itself up, but is good enough for simple code and better than the earlier Windows version.
Discovered a bug in PropView 1.03#0101 while tying to figure out how to launch the RamInterpreter in just one cog without disturbing the rest of what is running (for debugging my Interpreter). Thought you may like a sample. The PRI PriSpinCode source is lower down the page than the actual bytecode.
I'm not likely to fix anything in that, PropList is what I'd now recommend. Eventually the new PropView will simply be a GUI wrapper for PropList.
PropList did't fare any better not showing any source code at all ! Seems it doesn't like unicode text files. Here's a latest version of PropList.Exe which should tolerate it.
Is there anything I need to do? (Note no version number in properties). I am using Vista.
I am trying to find out how to launch the RamInterpreter in just one cog and have it run a spin object so that I can debug it. So far I have been unsuccessful - any ideas?? The reason I need this is that I have to have a good version of the Intepreter (Ram or Rom) running to do the debugging, while testing an unknown version.
I guess that I am trying to replace "coginit (0,@RamInterpreter,$0004)" with coginit(4,@RamInterpreter2,$xxxx) where $xxxx point to load another spin routine, but I cannot determine how to find the $xxxx. It's probably staring me in the face and just have a mental block. :-(
That's probably the bug.
I tested it with Win 95, Win 98, Win XP, Windows Server 2003, Windows XP Embedded and Windows XP PE, so I think it's a safe bet to say it's a problem related to Vista. I don't have access to Vista so it's unlikely to get fixed in the short term. Long term I'll have to port it to something which does work; as you're running PropView it seems VB6 is still compatible so not all bad news.
The $xxxx can be anywhere, it just needs to be set as $0004-$000F would be. So you can use "VAR byte params[noparse][[/noparse]$0010]", use just $0004 to $000F, then "CogInit(4,@RamInterpreter,@params+$0004).
Vista·
I'll check PropList·on my other XP laptop later and let you know.
As for the coginit, I didn't explain it well. I am trying to load 2 versions of the RamInterpreter (one working and one being tested). Anyway, I have figured out a way: I'll modify the working version to check if it is loading cog 7 and if so it will launch the new RamInterpreterTest and it's spin code.
Thanks again
Is it a good idea to use the RAM interpreter for testing itself ? A safer bet would be to use ROM interpreter to test the RAM Interpreter but that might not suit what you need to do in your tests.
I have two versions of the RamInterpreter running. The one in cog 7 is the one I am testing - now to add the zero footprint debugger and some debugging for the bytecodes and I am away. Once I have a trace I know there will be an easer way to just launch the cog 7 test version, but who cares.
By the way - I hacked out the sqrt function (saves more code) and put back everything including your coginit hack and waitcnt hack. I had already saved a number of bytes with simple decoding. The range hack needed to be taken out as it is used in tv and fdx.hex(...).
Hopefully I will have some preliminary timing test over the weekend.
Code works on Vista Business, results below [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·