Question about some gray area...
asterick
Posts: 158
I've only recently come in contact with the propeller chip, and I just need some perspective on a mini-project.
I know that the Propeller's init / interpreter rom is encrypted. I understand the reasoning behind this, but it puts somewhat of a damper on realistic emulation of a propeller.
I've mapped out how most of the interpreter works (3 voids in the main bytecode, and ~70 in the 'inplace' opcodes), and I was just wondering where the dev's stand about creating a work a-like boot/interpreter rom for emulation purposes.
I've considered writing an emulator that just natively interprets the bytecode, but it would make it harder to get a general idea of the rate that the cogs would run at, etc.
I've not started writting the roms, and would just like to know how mad people would get at me.
Post Edited (asterick) : 1/3/2007 5:09:15 AM GMT
I know that the Propeller's init / interpreter rom is encrypted. I understand the reasoning behind this, but it puts somewhat of a damper on realistic emulation of a propeller.
I've mapped out how most of the interpreter works (3 voids in the main bytecode, and ~70 in the 'inplace' opcodes), and I was just wondering where the dev's stand about creating a work a-like boot/interpreter rom for emulation purposes.
I've considered writing an emulator that just natively interprets the bytecode, but it would make it harder to get a general idea of the rate that the cogs would run at, etc.
I've not started writting the roms, and would just like to know how mad people would get at me.
Post Edited (asterick) : 1/3/2007 5:09:15 AM GMT
Comments
I've not spent too much time on it yet, because I'm not sure I'll have the time to complete it or support it.
But a linux spin compiler would give us a bunch of options not currently available yet, such as the use of
macros, etc.
It also seems to me that the existing bytecode that is generated could benefit from a peephole optimizer.
Anyway, I'd love to compare notes with you.
The syntax it outputs isn't intended to be read by anyone but me, but if you have any questions about what things do, you're more than welcome to ask.
Like I said, there are a few 'voids' in the bytecode, which I've marked. I've never been able to construct a statement that uses them.
The main bytecode ones look like they may be used, the 'effect' codes are probably complete, with room for expansion.
Oh, and my checksum code is broken. I had it working for awhile, and then I some how managed to cause it to stop verifying.
The checksum is intel hex based ( for each byte, you subtract the byte + 1 from a counter ), but I can't for the life of me remember how I got it working.
Also some of the header names are wrong. The values seem mostly propriatary.
Oh, and object offsets come in a word pair, one being an offset from the start of the object block, the second is completely unknown to me. I called it a stack offset for no particular reason.
There is one statement that does stuff that I don't understand, which is COGINIT( cog_id, spin_funct, stack_base )
It produces some major crazyness after the MARK_INTERPRETED bytecode. It appears to write to a proprietary cog register that is exclusive to the interpreter itself.
Oh, and the cog memory operations (INDEX_MEM_OP and MEMORY_OP) contain some void space.
also packed literals have unknown space as well.
Other than that, I think it's complete. More than enough to make a spin compiler at least.