On Thu, Aug 20, 2009 at 12:58 PM, nathan binkert<n...@binkert.org> wrote: >> I agree, doing it manually is a reasonable option, though even that >> gets a little more complicated if you're in BCD mode. > Sure, but he's already got a bcdize function. Could always write an > unbcdize function. Actually, what probably makes sense is to keep the > global struct in the proper format for the guest, and write functions > to copy to a temporary binary format version of the struct that can be > operated on. So, before any work, we create a temporary, copy to the > temporary unbcdizing as necessary. Operate on the temporary and copy > back, bcdizing as necessary. Seems like a nice defensive coding > strategy and since performance doesnt matter for this code...
Didn't mean to make it sound hard, just pointing out that there's a little more to it than meets the eye. We need the unbcdize function no matter what to deal with writeData() updates in bcd mode. So I agree with you (this is basically my option #1); the only question is: is the temporary something that looks like clock_data with a handwritten increment routine, or is it a struct tm and then we use existing library functions (unfortunately with the ugly TZ hack) to convert to a time_t, do a simple integer increment, and convert back? I don't think it really matters, and Gabe's already got most of the code in place for the latter. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
