simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] [PATCH] use static callbacks instead of template pa


From: panic
Subject: Re: [Simulavr-devel] [PATCH] use static callbacks instead of template param for IOReg
Date: Fri, 30 Jun 2017 20:29:00 +0000

Hi Klaus,

(no need to CC me, I'm subscribed to the list)

Klaus Rudolph:
> I personally dislike any solution which needs macros, cast-operators and 
> other things. I believe that it is ever possible to write code without such 
> kind of coding.

The version with macros has already been rejected. Hence my new
proposal. At the moment, there is only one cast operator, i.e.
dynamic_cast<IOReg*>(rw[...]). This could be avoided by splitting the
rw[] in AvrDevice (in CPU registers, bitaccessible IO registers, IO
registers, SRAM). However, to keep the incremental changes small, I'd
suggest to keep the dynamic_cast.

> The next thing is that I believe to add any kind of run time switch for 
> special kind of avr instruction behavior change slows again down the 
> simulation. It is slowed down over the years a lot.

It is not a run-time switch. I have not run a benchmark, but IMO the
change should be constant time anyway (calling std::function instead of
member pointer). In my applications I did not obsererve any speed
difference. For improving/reducing simulation speed I think it would
actually be better to have the RWMemoryMember also contain the actual
data/register value and remove all the (duplicate) get/set methods (e.g.
in GPIOReg, SpecialReg, OSCALReg, XDivReg, ...). The only callback to
the peripheral would then be an "OnWrite"/"OnUpdate" or "OnRead",
without parameter. But again, I believe small incremental changes are
better. (*)

> I would prefer a solution which generates the executing object in instruction 
> decoding phase while reading flash. So there is no need to redo every 
> decoding while executing. For SBI instruction everything is known in decoding 
> stage, so I see no need to do anything in the execution phase of the 
> instruction.

Hmm, I'm not sure I understand you. dynamic_cast<> will query the RTTI
of the object for every CBI/SBI instruction (and only for them). I can
only see a constant cost per CBI/SBI instuction here.

In general I prefer a solution that provides correct simulation and
tracing of registers instead of a wrong and fast one.

> And yes, I see no need to replace CRTP to static callbacks. I would not apply 
> any patch which moves in this direction.

Indeed, no static callbacks. That proposal has already been rejected
long ago -- for valid reasons.

Cheers,
panic

(*)
Another thing probably worth to consider could be to have some
peripherals implementes in, e.g., VHDL directly and use the GHDL runtime
to simulate them. Might improve readability of some parts.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]