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. _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel