Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monitor built-in disassembler should convert relative addresses #36

Closed
MJoergen opened this issue Aug 6, 2020 · 9 comments
Closed

Monitor built-in disassembler should convert relative addresses #36

MJoergen opened this issue Aug 6, 2020 · 9 comments
Assignees
Labels

Comments

@MJoergen
Copy link
Collaborator

MJoergen commented Aug 6, 2020

When disassembling code using the Monitor's built-in disassembler, relative addresses are shown as just that: relative.

I would like the disassembler to show the corresponding absolute address. For instance, the command "M S 0000 0060" currently shows:

0000 FFA0 RBRA    005A 1
...
005A FFA0 RBRA    0E88 1
005C 9FB8 AND     00FF R14 

The instruction at 0000 jumps to address 005C. Showing the relative address (005A) makes the output harder to read.

This applies to the instructions RBRA and RSUB. The instructions ABRA and ASUB already show the absolute address. Alternatively, the relative instructions could show both the offset AND the absolute address, to make the distinction more clear.

Tentatively assigned to V1.7 if you agree.

@MJoergen MJoergen added the V1.7 label Aug 6, 2020
@bernd-ulmann
Copy link
Collaborator

I will take care of this☺️

@sy2002
Copy link
Owner

sy2002 commented Aug 6, 2020

@bernd-ulmann As you are currently heavily time-contrained: No worries if this takes a while and if it goes to V1.7 instead of the current V1.6. But if you can do V1.6, it would be awesome :-)

EDIT: In both cases: Please use the branch dev-int for that (and not develop or dev-io-addr). Reason: In dev-int we have the newest monitor version that was created when you teached the disassembler to learn the new interrupt opcodes.

@bernd-ulmann
Copy link
Collaborator

Done. :-) A typical output looks now like this:

QMON> MEMORY/LOAD - ENTER ADDRESS/VALUE PAIRS, TERMINATE WITH CTRL-E
080000FFA00800100000080020FFB0080030FFFC080040F020080050F130
QMON> MEMORY/DISASSEMBLE START ADDRESS=8000 END ADDRESS=8010
8000 FFA0 RBRA 0000 1 (8002)
8002 FFB0 RSUB FFFC 1 (8000)
8004 F020 RBRA R0 1
8005 F130 RSUB R1 1
8006 0000 MOVE R0 R0

The absolute destination address is denoted in parenthesis following an RBRA/RSUB instruction.

@sy2002
Copy link
Owner

sy2002 commented Aug 7, 2020

@bernd-ulmann Thanks for this feature improvement. Can you please merge this it to dev-int? Background: It will make merging much easier later, because we have the the newest monitor version that was created when you teached the disassembler to learn the new interrupt opcodes in dev-int.

@sy2002 sy2002 reopened this Aug 7, 2020
@bernd-ulmann
Copy link
Collaborator

Done. :-)

@sy2002
Copy link
Owner

sy2002 commented Aug 7, 2020

@bernd-ulmann and @MJoergen Important hint: Always, when you change the monitor, then the following steps need to be done:

  1. run /monitor/compile_and_distribute.sh
  2. Read on the command line how large the rom is after the change. Example after Bernd's recent changes: qasm2rom: 6498 ROM lines written.
  3. Go to vhdl/env1_globals.vhd to line 14 and change the variable
constant ROM_SIZE             : natural   := 6523;

So I did this now for this change Bernd did. New value is now: 6498 (strange: @bernd-ulmann it shrinked due to the new feature ?)

I checked in the new file. Additionally also in the vhdl/MEGA65 folder there is a mega65_globals.vhd which needs a similar change.

@MJoergen Maybe we can get smarter and get rid of this manual effort by improving the way the GENERIC of the block_rom.vhd and how it is instantiated...

@sy2002
Copy link
Owner

sy2002 commented Aug 7, 2020

oh: now after Bernd fixed his debug lib: 6548 ROM lines written.

@sy2002
Copy link
Owner

sy2002 commented Aug 7, 2020

updated again

@MJoergen
Copy link
Collaborator Author

MJoergen commented Aug 7, 2020

@MJoergen Maybe we can get smarter and get rid of this manual effort by improving the way the GENERIC of the block_rom.vhd and how it is instantiated...

I've created a new Issue #39 for this purpose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants