Hi,

This adds a reg_sim_reset function, which registers a callback that will be
called when the sim is reset (the sim_reset function). Calling sim_reset is
really broken right now, as the called functions do a register_memory area, thus
you can't call it from the sim command line (asin issue the reset command).

This is not used now, but patch #16 (and what follows) will make use of it...

This patch again shows the ever increasing need to do something about the hughe
number of headers that we have in or1ksim. I was thinking about creating a
`periph.h' header, were we would store all the defines needed to compile all the
peripherals. This would clean up a number of headers, but a more ambitous idea
is needed to clean this mess up for good (which I can't seem to come up with
right now :( ). Ideas?

Oh, one more thing, can we remove the file `cuc/Makefile'? After all it _is_
autogenerated by configure...

ChangeLog:
* Add dynamic hooks to sim_reset.

nog.
-------------- next part --------------
--- toplevel.c 2005-02-03 18:48:40.000000000 +0100
+++ ../or1ksim-ac/toplevel.c 2005-02-03 19:48:31.000000000 +0100
@@ -137,12 +137,42 @@ void version()
PRINTF ("for details see COPYING.\n");
}

-void debugmem (unsigned long from, unsigned long to );
+struct sim_reset_hook {
+ void *dat;
+ void (*reset_hook)(void *);
+ struct sim_reset_hook *next;
+};
+
+struct sim_reset_hook *sim_reset_hooks = NULL;
+
+/* Registers a new reset hook, called when sim_reset below is called */
+void reg_sim_reset(void (*reset_hook)(void *), void *dat)
+{
+ struct sim_reset_hook *new = malloc(sizeof(struct sim_reset_hook));
+
+ if(!new) {
+ fprintf(stderr, "reg_sim_reset: Out-of-memory\n");
+ exit(1);
+ }
+
+ new->dat = dat;
+ new->reset_hook = reset_hook;
+ new->next = sim_reset_hooks;
+ sim_reset_hooks = new;
+}

/* Resets all subunits */
void sim_reset (void)
{
+ struct sim_reset_hook *cur_reset = sim_reset_hooks;
+
SCHED_INIT();
+
+ while(cur_reset) {
+ cur_reset->reset_hook(cur_reset->dat);
+ cur_reset = cur_reset->next;
+ }
+
uart_reset();
dma_reset();
eth_reset();
@@ -445,5 +475,3 @@ int main(argc, argv)
}
sim_done();
}
-
-
--- sim-config.h 2005-02-03 18:48:40.000000000 +0100
+++ ../or1ksim-ac/sim-config.h 2005-02-03 19:47:21.000000000 +0100
@@ -379,6 +373,9 @@ void sim_reset(void);
/* Handle the sim commandline */
void handle_sim_command(void);

+/* Registers a new reset hook, called when sim_reset below is called */
+void reg_sim_reset(void (*reset_hook)(void *), void *dat);
+
union param_val {
char *str_val;
int int_val;

* György 'nog' Jeney (nog@sdf.lonestar.org) wrote:

well, the header files should always be looked upon as
an interface definition (of a module). what we'd need is to define
let's say a general peripheral module where all the common functionality
is confined. i'm thinking like:

or1ksim core peripheral ethernet
[ cpu ] [ general ] uart
...

this way only the general peripheral module would interact
with or1ksim core, and all the actual peripherals (that actually implement
different peripheral devices/functionality) would have to somehow register
to the general module.

then the includeing (interface) is quite obvious. there is the general-peripheral.h
file which defines some registering functions and so on. Let's say that uart
would register itself and pass the peripheral module a function that should be
executed at every cycle. (this would be eqvivalent to the *_clock() functions
we had previously). so at each cycle the general peripheral module would
just call all of the *_clock() functions without having to know anything
about their implementation. (i know we're getting rid of _clock() functions, they are
just as an example here).

of course, the cpu module would also have to provide
some interface for the general-preipheral module to do it's work.

the described approach allows all the peripherals to be treated the same
way, and adding a new peripheral would just mean implementing some
'hook' functions. (this just leads to the shared library approach).

the including is then pretty obvious. general-peripheral.h
includes the cpu.h and all the peripheral devices modules include only
peripheral-general.h...

best regards,
p.