|
Message
From: Matjaz Breskvar<phoenix@o...>
Date: Mon Mar 28 15:24:29 CEST 2005
Subject: [openrisc] or1ksim patches #34-#67
* György 'nog' Jeney (nog@s...) wrote:
> > I'm also experiencing some differences in behaviour beetwen current cvs
> > tree (which also doesn't compile) and the stable branch. i'll investigate
> > as soon as these patches are commited to cvs.
>
> What's the problem? (It works for me here).
sim-cmd.c: In function im_cmd_pr':
sim-cmd.c:271: warning: implicit declaration of function etsim_reg'
gcc -g -Wall -O2 -DOR32 -o sim -lm toplevel.o sim-config.o
profiler.o mprofiler.o sim-cmd.o cpu/common/libcommon.a cpu/or32/libarch.a
cpu/or1k/libor1k.a support/libsupport.a mmu/libmmu.a
bpb/libbpb.a cache/libcache.a peripheral/libperipheral.a
peripheral/channels/libchannels.a tick/libtick.a pm/libpm.a pic/libpic.a
debug/libdebug.a vapi/libvapi.a cuc/libcuc.a port/libport.a
sim-config.o(.text+0x1a18): In function
arse_args':
/center/opencores/toolchains/tmp/or1ksim-20050328/sim-config.c:232: undefined
reference to arse_dbchs'
sim-cmd.o(.text+0xb9a): In function im_cmd_setdbch':
/center/opencores/toolchains/tmp/or1ksim-20050328/sim-cmd.c:433: undefined
reference to arse_dbchs'
collect2: ld returned 1 exit status
make[2]: *** [sim] Error 1
make[2]: Leaving directory
/center/opencores/toolchains/tmp/or1ksim-20050328'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
/center/opencores/toolchains/tmp/or1ksim-20050328'
make: *** [all] Error 2
> > #45 accepted, please make a comment somewhere appropriate that one shouldn't
> > assume except_handle returns. i might have additional comments later on.
>
> Is the attached patch ok? Or were you thinking about something else?
Attached patch is ok, but i would really like to see
an addon patch documenting except_handle behaviour (that it may no return).
> > #50 accepted. (why is "enabled = 1" line removed. how can one easily disable
> > some device ?)
>
> Don't have the section in the config file. If this is a wanted behaviour then
> I could readd it...
I'd want old behaviour.
> > #59 accepted. We probably need a separation to the 'architectural access
> > (the one that real hw would do)' and the 'simulator internal accesses'. but
> > let it be like this for now. I agree with "I would go asfar as to argue that
> > mfspr() and mtspr() should only be called from
> > the l.mfspr and l.mtspr instructions."
>
> What is not "architectural access (the one that real hw would do)" for the
> mtspr() function? I think all the calls to it in except_handle, etc. the real
> hw does aswell.
architectural access is the one defined by architecure (regardless
of the implementation, which can do it in several ways). so i should
have been more precise above...
for example when you write tlb translation into tlb registers that
is architectual access, but every next cycle hw needs to
make a translation to execute the instruction etc, but
this are not considered architectural accesses.
the rest follows....
best regards,
p.
|
 |
Browse
