Hi fokls, particularly ARM folks. I've noticed a couple things about how ARM manages being in 32 vs 64 bit mode. First, this is tracked as part of the PC state. This sort of arrangement was (at least originally) intended to hold information that might change often and which could be reasonably predicted by a branch predictor. Whether you're in thumb mode or not makes a lot of sense here, since it could change across a branch and is something the branch predictor could reasonably try to predict. It might also change frequently and essentially just affects decode, and so would realistically not cause a pipeline flush.
The second thing is the idea of a rename mode, and how that's managed. In the O3 CPU, it will occasionally (I think when there's a squash?) check to see what the rename mode is based on the state of the ISA. If the rename mode has changed, it will migrate physical registers around to collect them into larger addressable chunks if that's necessary for the next mode. I would imagine this check will not do anything most of the time, and so is primarily unnecessary overhead which occasionally does something which is necessary for functional correctness. What I think would make more sense would be to take the AArch64-ness out of the PCState, make the decoder stateful so that it is either in 64 bit or 32 bit mode (x86 does something like this), and have an explicit mechanism which fires to translate between modes. That seems to only be at exception/interrupt boundaries. When that happens, you'd switch the decoder mode, and also syncrhonize SIMD registers from the per-element register file to the per-vector register file which would otherwise be separate and treated as two wholly independent register files. This could be a utility function which accepts a ThreadContext as a parameter, and per the usual O3 semantics would flush the pipeline when called, clearing any instructions which were decoded in the wrong context, etc. Does this make sense, and/or seem reasonable? Gabe
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
