new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20040306.tar.bz2

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20040313.tar.bz2

[patch][rfa] SID --trace-semantics output

Hi,

A client of ours, for whom we're developing a SID port, requested that 
SID's semantic trace show the actual value stored, accounting for 
read-only fields and other side effects, rather than showing the value 
which was attempted to be stored. For example, if a 32 bit register has 
the value 0x12345678 and is readonly in the 16 most significant bits, 
then storing the value zero actually results in 0x12340000 being stored. 
SID currently shows that the register has been set to zero.

The most obvious idea I considered was to have the trace code re-read 
the stored value; This has problems with potential side effects of doing 
the read (caching statistics, control registers with side effects on 
read, etc.).

I eventually came up with the notion that the write/set methods of SID's 
busses, control registers, memory access methods and hardware write 
handers could return the actual value written. Current code which does 
not make use of this can remain unchanged and simply ignore the return 
value. This allows the tracing code generated by CGEN for sid in the 
sem.cxx file to work with only a slight modification: For example, these 
extracts from xstormy16-sem.cxx.

-----------------------

Index: sid/component/cgen-cpu/xstormy16/xstormy16-sem.cxx
===================================================================
RCS file: /cvs/src/src/sid/component/cgen-cpu/xstormy16/xstormy16-sem.cxx,v
retrieving revision 1.7
diff -c -p -r1.7 xstormy16-sem.cxx

Re: [patch][rfa] SID --trace-semantics output

brolley wrote:

> A client of ours, for whom we're developing a SID port, requested
> that SID's semantic trace show the actual value stored, accounting
> for read-only fields and other side effects, rather than showing the
> value which was attempted to be stored. [...]

Especially for bits outside the CPU, this has the potential to
mislead, in that the disassembly trace would not represent the actions
of the CPU.

> I eventually came up with the notion that the write/set methods of
> SID's busses, control registers, memory access methods and hardware
> write handers could return the actual value written. [...]

I am quite unfond of this approach.  It is a messy and limited way of
providing just one more level of tracing.  Have you considered instead
of all this the addition of tracing flags in the various devices that
thusly mutilate their data?  That way, when they detect an incoming
write (from whatever source), they can print the final afterimage.
With carefully arranged tracing code in cgen_cpu, the additional
messages from those peripherals could appear properly intermingled.

The same technique could also handle the more general cases of control
registers with read side effects, or accesses that span multiple
different devices.

- FChE

Re: [patch][rfa] SID --trace-semantics output

Frank Ch. Eigler wrote:

>brolley wrote:
>
>  
>
>>A client of ours, for whom we're developing a SID port, requested
>>that SID's semantic trace show the actual value stored, accounting
>>for read-only fields and other side effects, rather than showing the
>>value which was attempted to be stored. [...]
>>    
>>
>
>Especially for bits outside the CPU, this has the potential to
>mislead, in that the disassembly trace would not represent the actions
>of the CPU.
>
but it would represent the actual result of the operation, which is what 
they want. Makes sense to me too, FWIW.

>>I eventually came up with the notion that the write/set methods of
>>SID's busses, control registers, memory access methods and hardware
>>write handers could return the actual value written. [...]
>>    
>>
>
>I am quite unfond of this approach.  It is a messy and limited way of
>providing just one more level of tracing.  Have you considered instead
>of all this the addition of tracing flags in the various devices that

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20040320.tar.bz2

[patch][rfa] SID cpu tracing -- attempt #2

Hi,

Reponding to Frank's concerns about my previous patch, here is an 
implementation along the lines he suggested. The idea is that each CGEN 
'set' handler and each component which is the target of a store 
operation is responsible to annotating the cpu trace with the actual 
value stored, if desired. In order to accomplish this, two changes were 
necessary.

1) The tracing code generated by CGEN is now generated before the code 
for the semantic operation. That way any annotation appears after the 
original cpu trace.

2) basic_cpu now has a "trace" pin for use by other components. Each 
value driven on the pin will be echoed as a character into the cpu's 
trace_stream. This way annotation by other components are merged 
properly with the cpu trace whether it be to cout or to a file.

I've attached sid-trace-cgen.patch.txt which shows the CGEN changes and 
a partial diff of the resulting changes to xstormy16-sem.cxx. I've also 
attached sid-trace.patch.txt which shows the changes to basic_cpu.

Tested on an internal port which requirs this functionality.

OK to commit?

Dave

Index: cgen/sid.scm

Re: [patch][rfa] SID cpu tracing -- attempt #2

Approved by fche and committed.

Dave Brolley wrote:

> Hi,
>
> Reponding to Frank's concerns about my previous patch, here is an 
> implementation along the lines he suggested. The idea is that each 
> CGEN 'set' handler and each component which is the target of a store 
> operation is responsible to annotating the cpu trace with the actual 
> value stored, if desired. In order to accomplish this, two changes 
> were necessary.
>
> 1) The tracing code generated by CGEN is now generated before the code 
> for the semantic operation. That way any annotation appears after the 
> original cpu trace.
>
> 2) basic_cpu now has a "trace" pin for use by other components. Each 
> value driven on the pin will be echoed as a character into the cpu's 
> trace_stream. This way annotation by other components are merged 
> properly with the cpu trace whether it be to cout or to a file.
>
> I've attached sid-trace-cgen.patch.txt which shows the CGEN changes 
> and a partial diff of the resulting changes to xstormy16-sem.cxx. I've 
> also attached sid-trace.patch.txt which shows the changes to basic_cpu.
>
> Tested on an internal port which requirs this functionality.
>
> OK to commit?
>

new cgen snapshot available

A new automated cgen CVS snapshot is available.
ftp://sources.redhat.com/pub/cgen/snapshots/snapshot-20040327.tar.bz2

[PATCH] m32r-*-as bad instruction 'seth r0, #shigh(0xffff8000)'

Hello,

This is a patch to fix the following bug.

Command line:
m32r-linux-as -o tt.o tt.s
or
m32r-elf-as -o tt.o tt.s

pattern is:
	.section .text
	seth r0, #shigh(0xffff8000)
	.end

Error log is:
tt.s: Assembler messages:
tt.s:2: Error: bad instruction 'seth r0,#shigh(0xffff8000)'

Please commit it and regenerate opcodes/m32r-asm.c.

Regards,

Kazuhiro Inaoka

ChangeLog:
2004-03-29  Kazuhiro Inaoka < inaoka dot kazuhiro at renesas dot com >

	* cpu/m32r.opc (parse_hi16): Fixed shigh(0xffff8000) bug.