--- Stephen Williams <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Karthik Parashar wrote: > > --- Stephen Williams <[EMAIL PROTECTED]> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Karthik Parashar wrote: > >>> Hi, > >>> > >>> I have one interesting observation when it comes > >> to > >>> iverilog's vvp assembly instructions. Which is > as > >>> follows: > >>> > >>> "Between the thread activities, there is no > >> dependecy > >>> on the threads 2^16 bit-wise registers." > >> I think what you are saying is that the thread > >> bit-wise > >> registers are not accessible to other threads. > That > >> is > >> a true statement. Threads only interact through > >> variables > >> and events. > >> > >> For example, it would be completely reasonable to > >> swap out > >> all the thread bits/registers when switching to > >> another > >> thread. > > > > I'm sorry for the confusion! > > > > What i want to know is, when a "%delay" is > encountered > > in the vvp assembly, the thread's bit-wise > registers > > dont seem to be having any dependency. > > > > Which means, in case, i try to save the thread > context > > when a delay occurs, i dont have to keep a backup > of > > these thread wise registers. Is this true? > > Maybe it depends on what you consider the "thread's > bit-wise > registers". I am assuming you mean the things in the > thread > structure, and *not* the .net and .var declared > variables. > > The machine does preserve all thread bit (and word) > registers even > across %delay statements, so a switched machine > needs to save/restore > the thread registers. In may not quite look like > that in the code > you are seeing, because the code generator knows > that while a > thread %delays (or %waits) other threads may change > the variables > external to the thread; and since most of the > contents of the > thread bits are copies of shared variables or > expressions of the > shared variables, they mostly get reloaded when > returning from > %delay. > > That's not a requirement, though, and I may well add > optimizations > where I detect that is not necessary and will skip > the reload. Thanks for the clarification. I do have one request in this regard, when you plan to add optimized vvp code generation, introduce it with a optimization flag, where "no-optimization" allows for compatibility with the current version of vvp-engines. Regards, ~Karthik. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com