Re: new sim: Visium

[Joel Brobecker <brobecker at adacore dot com>]

Hi Mike,

[sorry for the late answer, crazy week...]

> > I see that many of the small differences are comments and formatting,
> > so I will work towards normalizing. But there seems to be an important
> > difference in:
> > 
> >      const sim_fpu sim_fpu_qnan = {
> >     -  sim_fpu_class_qnan, 0, 0, 0
> >     +  sim_fpu_class_qnan, 1, 1152921367167893504, 1986400654
> > 
> > I am not sure what to do for that one...
> > 
> > I was hoping we could start with visium having its own copy for now,
> > with the understanding that we should find a solution to avoid it
> > in the future.
> 
> is this the only difference ?  iiuc, it's not unheard of for arches (either
> in the hardware or the ABI) to define different values for NaN.  as such,
> letting a target override this makes sense.
> 
> maybe for now introduce a define like:
> #ifndef SIM_FPU_QNAN_VALUE
> # define SIM_FPU_QNAN_VALUE 0, 0, 0
> #endif
> const sim_fpu sim_fpu_qnan = {
>   sim_fpu_class_qnan, SIM_FPU_QNAN_VALUE
> };
> 
> and then in your sim-main.h do:
> #define SIM_FPU_QNAN_VALUE 1, UNSIGNED64(0xfffffe000000000), 0x7666118e
> 
> while you're at it, use hex values to make it more readable :)

That works.

I also had a change to look at the differences more closely,
and there are more; but I haven't really had much time to check
how significant those changes actually are. I'll keep you posted,
of course.

> you can get to the state from the cpu:
>   SIM_DESC sd = CPU_STATE (cpu);
> 
> so i don't think you need to do any structure shuffling

Ah, good! I will make that change.

> > > this looks hairy and will require a good bit of unwinding.  you shouldn't
> > > be defining your own sim_read/sim_write anymore.  if you want memory, you
> > > should be using the common memory functions to attach it.  if you want to
> > > simulate hardware, you should be using the WITH_HW framework.
> > 
> > For the read/write functions, we have a feature read-before-write
> > feature which I don't think the current sim provides.
> 
> i don't know what this feature is.  could you elaborate ?

We can configure the simulator to raise a warning/error when
a region of memory which hasn't been written/initialized yet
is being read.

I think this is a debugging aid, to detect access to uninitialized
memory.

> > There is
> > also a pre-initialization feature of the RAM to a certain value
> > to make execution more reliable when the program reads undefined
> > memory.  What would you suggest we do?
> 
> when you attach memory, the default is to be zero filled.  we do this
> for all ports.  that sounds pretty reliable to me :).
> 
> if you want to use a diff value, you can do this from the command line:
> $ run --memory-fill 0xff --memory-size 10Mb ...
> 
> did you need something else ?

I think "need" is a slight overstatement in our context, but perhaps
we could have a to specify what byte value a port wants to use for
pre-filling the memory? I could see a #define that to provide a
common default which each sim could override for their own default;
and then, if people want, a configure option to force whatever value
they want, irrespective of the default chosen by the architecture.

The people who first implemented this visium simulator chose 0xff,
which is just as arbitrary as zero, but it just so happens that using
this value made me realize, when I wrote a test, that I was making an
invalid assumption, and that the test might actually bomb on me anytime.
At the time, I didn't see the problem because my memory region happened
to be initialized to zero, which is the assumption I was making.

> currently the sim-trace module does not have output formats.  i'm open
> to extending this so ports can add custom hooks to control it.  can you
> provide a few sample lines ?  would hooking at trace_generic be all you
> needed ?

For that part, I discussed with Olivier Hainque, who is a lot more
familiar with the traces than I am; the outcome of the discussion
is that it's going to be easier to separate that feature from this
submission, so we'll simply ignore that part for now, because we are
both a bit short on time at the moment.

Thanks!
-- 
Joel