One exception to that are the PCState structs I'm in the process of adding. These each overload << to print themselves as (X1=>X2=>X3).(Y1=>Y2) where the X*s are as many architecture level PCs as are needed and the Y*s are microPCs. This is in the middle where it's too complex for a single built in data type but still simple enough to be printed as a unit. This also allows ISA independent code to do things like:

DPRINTF(Fetch, "The PC is %s.\n", pc);

without having to know what's in the pc or how to print its components.

Generally, though, I agree with Steve that there's a pretty narrow window where this sort of thing makes sense and meshes at least stylistically with the rest of M5.

Gabe

Quoting Steve Reinhardt <[email protected]>:

I think part of the confusion is that we don't typically overload
operator<< in M5 because we don't typically define complex types that
have standard ways of printing themselves out.  So for example simple
M5 types like Tick and Addr are just typedefs for uint64_t (or
something like that), so << just works on them.  More complex objects
are just too complex to have simple string representations, or at
least we haven't felt the need to standardize them, so we just have
ad-hoc DPRINTFs that print out the relevant scalar fields as needed.

So I guess the upshot is that if there are complex Ruby types (not
just typedefs of builtin types) that want to have standard ways of
printing themselves out, that's kind of inconsistent with M5 right
there :-), but if you want to keep that behavior then overloading
operator<< is the way to do it.

Steve
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev



_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to