Dear Jerry,
In message 492DD314.7070700@gmail.com you wrote:
How would xlat know which direction it is to translate?
From the argument that is passed to it:
xlat 1234 or xlat 0x1234
are taken as VA's (see discussion about default address interpretation), so "xlat" will print the PA.
xlat 1234.p or xlat 0x1234.p
has a PA as argument, so it prints the VA.
Multiple arguments (even mixed) might be allowed, too, for example:
xlat 1234 1234.p 5678 5678.p
Thoughts: vtop(virtual) returns physical ptov(physical) returns virtual or (see below thought on 0v / 0p) xlat(0p1234) returns virtual xlat(0v1234) returns physical xlat(0x1234) returns physical (per convention from snipped discussion)
Seems too complex for a simple mind like mine ;-)
Question: Do we need a translation function?
Define "need". It is certainly very useful, especially if things don;t work as expected and you want to check address translation.
See the "xlat" command in the BDI2000 - how often did you use that?
[Right, I didn't invent that name. I'm recycling used bits. Hope this is OK.]
Thought: 0v6789ABCD is a virtual address (the value is interpreted as hex) 0p6789ABCD is a physical address
Of course "v" and "p" should be accepted in either case.
Kinda ugly, but fits into the 0x style conventions.
I tend to allow for suffixes, i. e. "6789ABCD" or "6789ABCD.v" are VAs, while "6789ABCD.p" is a PA.
To me, that is easier to read.
I haven't looked at the number parsing code to see how hard it would be to squeeze this into it.
Not really difficult.
Stuff face, write code. Does it get any better than that? ;-)
I'm an optimist, to yes, of course it does. The amount of code that needs to get written grows and grows. Enough work for all of us :-)
Best regards,
Wolfgang Denk