Putting your version on GitHub sounds like great idea.
Guess that would be a fork.
But @n_ermosh did post a few months ago …. Maybe he would take pull request. If can figure that out…
Yeah was waiting to see if he's lurking about. Might have to figure out GitHub again - been ages since I pushed stuff there.
BTW am now adding AUGD and AUGS constant value printing (where consumed) so we can see the full 32 bit values after augmenting. We can't show the full AUG values in the AUGD/AUGS statements themselves because the instruction that consumes it follows later and has not been processed yet. I also still want to show the original unaugmented value so this code can be re-assembled if you generate it without the addresses and that's why the final augmented value is shown only after the comment starts. Hopefully we can ultimately lookup any matching symbol names at these address values too. That can help to figure out some data variable accesses when memory is read or written there.
Update: there is just one more missing item that the decoding of AUGS/AUGD stuff will also assist. The special augmented and unaugmented hub memory accesses using PTRx pointer index operations like: mov r0, ptra[##$2A332] and mov r0, ptra[123]
Right now these are not yet handled at all, either with augmented constants or without. I should add these which I think will complete the P2LLVM parser to accept all standard P2 instructions and aliases, although compile time expressions for calculating constants may still be limited - I've not looked into that.
The special SPIN2 language control directives like ORGH, FIT, RES etc won't be implemented though, as this assembler already uses its own (primarily GNU GAS compatible) directives.
@rogloh,
To put your changes up and make a pull request would mean you have to fork a copy, do a pull request against that copy, do the submodule updates, copy the changes in, do a push. That would make a version that we could pull down and test.
@iseries said:
@rogloh,
To put your changes up and make a pull request would mean you have to fork a copy, do a pull request against that copy, do the submodule updates, copy the changes in, do a push. That would make a version that we could pull down and test.
Mike
Thanks @iseries for the refresher. I'll probably do exactly that in the end. I just want to complete the last part to parse which is the pointer indexing stuff. Then I should try the pull request. One good thing is that nothing seems to have changed since I dragged my tree down in the first place so no additional merging needs to be done at this stage.
@rogloh glad thinking about putting on GitHub later…
Would be nice to have build instructions for Linux if possible. Guess my problem might be that Linux people are so used building stuff they don’t need much help whereas I’m mostly lost…
Also, don’t know if it can work here but some GitHub stuff appears to be automagically compiled be them if set up (?)
Comments
Yeah was waiting to see if he's lurking about. Might have to figure out GitHub again - been ages since I pushed stuff there.
BTW am now adding AUGD and AUGS constant value printing (where consumed) so we can see the full 32 bit values after augmenting. We can't show the full AUG values in the AUGD/AUGS statements themselves because the instruction that consumes it follows later and has not been processed yet. I also still want to show the original unaugmented value so this code can be re-assembled if you generate it without the addresses and that's why the final augmented value is shown only after the comment starts. Hopefully we can ultimately lookup any matching symbol names at these address values too. That can help to figure out some data variable accesses when memory is read or written there.
9c: 80 03 00 ff augs #$70000 >> 9 a0: 00 f0 07 f6 mov ptra, #0 ' ##$70000 a4: 0c 03 00 ff augs #$61800 >> 9 a8: 34 a1 07 f6 mov r0, #$134 ' ##$61934 ac: d0 a5 1b f2 cmp r2, r0 wcz b0: 04 00 90 cd if_c jmp #$4 ' <$b8> b4: 0c 00 90 fd jmp #$c ' <$c4>Update: there is just one more missing item that the decoding of AUGS/AUGD stuff will also assist. The special augmented and unaugmented hub memory accesses using PTRx pointer index operations like:
mov r0, ptra[##$2A332]andmov r0, ptra[123]Right now these are not yet handled at all, either with augmented constants or without. I should add these which I think will complete the P2LLVM parser to accept all standard P2 instructions and aliases, although compile time expressions for calculating constants may still be limited - I've not looked into that.
The special SPIN2 language control directives like ORGH, FIT, RES etc won't be implemented though, as this assembler already uses its own (primarily GNU GAS compatible) directives.
@rogloh,
To put your changes up and make a pull request would mean you have to fork a copy, do a pull request against that copy, do the submodule updates, copy the changes in, do a push. That would make a version that we could pull down and test.
Mike
Thanks @iseries for the refresher. I'll probably do exactly that in the end. I just want to complete the last part to parse which is the pointer indexing stuff. Then I should try the pull request. One good thing is that nothing seems to have changed since I dragged my tree down in the first place so no additional merging needs to be done at this stage.
@rogloh glad thinking about putting on GitHub later…
Would be nice to have build instructions for Linux if possible. Guess my problem might be that Linux people are so used building stuff they don’t need much help whereas I’m mostly lost…
Also, don’t know if it can work here but some GitHub stuff appears to be automagically compiled be them if set up (?)