Re: new sim: Visium

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4622 bytes --]

On 17 Jan 2016 13:24, Joel Brobecker wrote:
> > > > 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.

this sounds like a useful feature we can add to the common core :)

> > > 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 default should be the same across architectures imo, and that default
today is zero-filled memory.  having a configure flag might be useful, but
i'm not sure how many people would actually leverage it.  especially when
there are flags already (that i showed above) that do what they want.

to clarify some background in case it helps: i see the simulator core as a
bunch of generic building blocks.  the arch port itself only adds support
for the ISA (insns & registers) to the equation.  once you get beyond that
(e.g. the memory or devices), now you're talking about more building blocks
than stuff that should be baked in/architecture defaults.  so even if today
all of the systems that have a visium cpu also initialize the system mem in
a specific way, the visium arch core should not be doing any of that.  this
makes it very easy to take just the visium ISA and construct a new cpu from
scratch that has new/different behavior and play around with things.  when
you do want behavior that matches an existing board, that's where the model
framework comes into play.  you can define specific cpu/system combinations
that match existing products and users can pick those via the --model flag.

does that make sense ?

> 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.

this can easily be dangerous when you write asm code, but i feel like this
doesn't translate (that much) across to C code.  static/uninitialized vars
(i.e. bss) are required to be zero-initialized.  people often run into
trouble with uninitialized stack values, but you'd get same behavior there
i think in the sim today as you would on a real system.

> > 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.

i've started a wiki page here:
  https://sourceware.org/gdb/wiki/Sim/TODO

feel free to add a bullet point there with sub points that outline your
requirements.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]