Shazz writes >>
>> 1 ... but what means the LONG $7d2800d3 between the 2 HUB RAM r/w instructions ?
Having an instruction or two between HUB instructions is common because of the way HUB instructions work.
Having an instruction from a MOVS #addr, #val or MOVD #addr, #val is also common because of the Propeller pipeline.
>> 2 ... for the moment so, if any effect is added to the instruction, I will print all the effects
Most people are used to reading "TEST d, s wz" instead of "AND d, s wz,nr" though it wouldn't matter to an assembler.
>> 3 ... question, would it have sense in the disassembler to replace all source/dest $001, $002... by var1, var2,..
You could do this, but if #$xxx, etc... happens to be a location modified by code, the list will be hard to follow.
>> For the loader, where is the coginit ? and so the hub address ? how do you know it's 0x07 ?
I've explained this in this thread ... ... in great detail the last time through.
As far as the loader goes, i that will be mostly a mystery to me until I run parts in Gear. But I'm too busy for that.
all my apologies Jazzed ! Yep you already answered me with all the details !!! I'm really embarassed !
I guess I learn so much while writing this disassembler that my brains overflow and I cannot sort/tidy/stock everything correctly. So again, all my apologies.
So the inital cog loading is ok now, understood, so long $018 gives all the info needed ($2c353535):
- byte $018 (PUSH #cog) = $35 so PUSH 0 (the long word $00000000 is pushed to the stack)
- byte $019 (PUSH #dst) = $35 so PUSH 0
- byte $01A (PUSH #par) = $35 so PUSH 0
- byte $01B (COGISUB) = $2C so COGISUB (I guess this bytecode opcode calls COGINIT)
So thanks to you & hippy's doc I understood that PUSH and COGISUB are spin bytecode opcodes, so this long contains a spin program... (you're probably laughing (or crying)... but I did not get it before ! (yep you told me : 'First PUB start is important because Spin starts PASM in a COG ....'). I really thought it was possible to do that directly from PASM without using the cog 0 interpreter)
Thanks for the other points... understood too. I was wondering what I can do to have the listing generated easier to read... so every idea is welcome. I'll read again the whole thread in case of something I forgot. (again).
So yes, even if this disassembler is pretty useless to everybody here.... it helps me a lot [noparse]:)[/noparse]
Not to worry [noparse]:)[/noparse] 2AM epiphanies are cousins of 11AM brainfarts.
Added: An old friend of mine once told me he was afraid to learn anything else lest he forget something important.
Shazz said...
For the loader, where is the coginit ? and so the hub address ? how do you know it's 0x07 ? and finished at 0x034 ? Managed by Chip's booloader ? by default coginit(0,0,?,?) ? so all the EEPROM content (at least the beginning) including the header was copied in the cog ? Then cells 0 to 6 are used for storing stuff ?
- the loader is started by the SPIN coginit (coginit(0, 0, 0)).
- so hub 0x0000 - 0x07FF is loaded into cog 0, i.e. the jump at location 0 gives you 0x07 as entry point
- locations 0x02 .. 0x06 are later used for storage
Shazz said...
Turbulence loader :
Disassembling 46 longs from address 0x1c to 0xd4
Address Cell Data Conditions Opcode Destination Source Effects
---------------------------------------------------------------------------------------------------------
$0000002c $0000000b $5c4c0019 IF_NC CALL #$019
$00000090 $00000024 $00000c24 WRBYTE $006 $024
$00000094 $00000025 $7d2800d3 IF_Z MUXNZ $000 $0d3 WC NR
Not all CALLs are CALLs, some of them are just JMPs (depending on the zcri bits). E.g. the instruction at cog 0x0B is a JMP. Also, cog locations 0x024 and 0x025 are data (there is an unconditional JMP at 0x023).
@Jazzed : thanks for your kindness, not sure I deserve it everyday ! [noparse]:D[/noparse]
@kuroneko : thanks too ! Yep I was thinking of the call/jmp/jmpret opcodes, here is the new result, does it looks well ?
Shazz said...
@kuroneko : thanks too ! Yep I was thinking of the call/jmp/jmpret opcodes, here is the new result, does it looks well ?
not sure how to manage cog 0x24-0x25
Don't worry, there will always be ways to fool a disassembler. So there isn't really much point trying too hard. As long as the hex value is available I wouldn't complain.
And yes, that listing looks fine. Can you post the update please?
Comments
>> 1 ... but what means the LONG $7d2800d3 between the 2 HUB RAM r/w instructions ?
Having an instruction or two between HUB instructions is common because of the way HUB instructions work.
Having an instruction from a MOVS #addr, #val or MOVD #addr, #val is also common because of the Propeller pipeline.
>> 2 ... for the moment so, if any effect is added to the instruction, I will print all the effects
Most people are used to reading "TEST d, s wz" instead of "AND d, s wz,nr" though it wouldn't matter to an assembler.
>> 3 ... question, would it have sense in the disassembler to replace all source/dest $001, $002... by var1, var2,..
You could do this, but if #$xxx, etc... happens to be a location modified by code, the list will be hard to follow.
>> For the loader, where is the coginit ? and so the hub address ? how do you know it's 0x07 ?
I've explained this in this thread ... ... in great detail the last time through.
As far as the loader goes, i that will be mostly a mystery to me until I run parts in Gear. But I'm too busy for that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I guess I learn so much while writing this disassembler that my brains overflow and I cannot sort/tidy/stock everything correctly. So again, all my apologies.
So the inital cog loading is ok now, understood, so long $018 gives all the info needed ($2c353535):
- byte $018 (PUSH #cog) = $35 so PUSH 0 (the long word $00000000 is pushed to the stack)
- byte $019 (PUSH #dst) = $35 so PUSH 0
- byte $01A (PUSH #par) = $35 so PUSH 0
- byte $01B (COGISUB) = $2C so COGISUB (I guess this bytecode opcode calls COGINIT)
So thanks to you & hippy's doc I understood that PUSH and COGISUB are spin bytecode opcodes, so this long contains a spin program... (you're probably laughing (or crying)... but I did not get it before ! (yep you told me : 'First PUB start is important because Spin starts PASM in a COG ....'). I really thought it was possible to do that directly from PASM without using the cog 0 interpreter)
Thanks for the other points... understood too. I was wondering what I can do to have the listing generated easier to read... so every idea is welcome. I'll read again the whole thread in case of something I forgot. (again).
So yes, even if this disassembler is pretty useless to everybody here.... it helps me a lot [noparse]:)[/noparse]
Added: An old friend of mine once told me he was afraid to learn anything else lest he forget something important.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 4/23/2009 9:06:18 PM GMT
- so hub 0x0000 - 0x07FF is loaded into cog 0, i.e. the jump at location 0 gives you 0x07 as entry point
- locations 0x02 .. 0x06 are later used for storage
Not all CALLs are CALLs, some of them are just JMPs (depending on the zcri bits). E.g. the instruction at cog 0x0B is a JMP. Also, cog locations 0x024 and 0x025 are data (there is an unconditional JMP at 0x023).
@kuroneko : thanks too ! Yep I was thinking of the call/jmp/jmpret opcodes, here is the new result, does it looks well ?
not sure how to manage cog 0x24-0x25
Post Edited (Shazz) : 4/24/2009 8:02:03 AM GMT
And yes, that listing looks fine. Can you post the update please?
here is the 0.5 :
tmpstore.free.fr/propeller/PASMDisassembler_v0.5.zip
JMP/CALL/JMPRET fixed, header should be ok
ex :
tmpstore.free.fr/propeller/PASMDisassembler_v0.6.zip
tmpstore.free.fr/propeller/PASM.syn.
for free, TextPad editor PASM syntax.
changelog : fixed bug with header, -o implemented.
ex :