This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: [patch] H8300 simulator and H8S extensions

Hi Kazu,

Now I perform yours suggestions. So I think you could test it (as I
understand maintainer of h8300 part is you? ). 

Here short descriptions of this patches (its applied for

1) stage0_misc
	changing constants in switches to defines,  removed stale WIN32 in
get_now () (sim/h8300/compile.c) and
	fixing error in tick counting in sim_resume() (sim/h8300/compile.c).

2) stage1_ccr
	added absented flags ( u, ui, h, i ) in ccr.

3) stage2_ccr_opcodes
	fixing bugs in ccr, exr opcodes (smb. forget set DST and SRC in ldc,
stc, andc .... ), 
	fixing time field in eepmov ( it's not 50(???) ticks, it's 2*n+4
ticks, so when n =0 it must be 4)
	fixing time field in divu, divs ( it's 13 and 21 ticks for byte and
word accordingly)

4) stage3_h8s_target
	making h8300s alone target, not synonym of h8300h

5) stage4_exr
	adding EXR register end exr depended code.

6) stage5_add_opcodes
	adding missing opcodes (eepmov, ldc, stc, tas) in

And I think, in gdb must be added option which tell it about target
processor configuration (something like -m <target_chip_id>), for TRAPA
implementation in sim, and inspecting peripheral registers in gdb and sim.
Also how about interrupts emulation in simulator? I think this
implementations will not so painful, but I need help for this job,
especially in user interface.


> -----Original Message-----
> From: Kazu Hirata []
> Sent: Saturday, November 03, 2001 4:59 AM
> To: 'Andrew Volkov';
> Cc:
> Subject: RE: [patch] H8300 simulator and H8S extensions
> Hi Andrew,
> > I added some fixes: 
> > 1) H8/S is new target (no more synonym of H8/300H)
> > 2) insert H8/S mnemonics: eepmov, ldc, stc, tas in simulator
> > 3) add EXR for H8/S in all places, where I think it needed.
> > 4) correct all control regs opcodes in opcode/h8300.h
> Great!
> I am not in the position of approving anything, but I think the patch
> contains so many things that the maintainer would have hard time
> reviewing it.  Why don't you separate the patch into several stages?
> For example, you could first submit a patch that replaces literals
> with appropriate macros like:
> -    case 8:
> +    case CCR_REGNUM:
> The GNU projects might prefer to have a little more spaces like
> "foo (a, b + c)" instead of "foo(a,b+c)".
> If I can be of some help, please let me know.
> Kazu Hirata







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]