On Tue, 2003-09-30 at 12:10, Maciej W. Rozycki wrote: > On 30 Sep 2003, Michael Uhler wrote: > > > > What you want really is a 64-bit kernel. On a 64-bit kernel even for > > > processes running in 32-bit address spaces (o32, N32) the processor > > > will run with the UX bit enabled. o32 userspace still lives in the > > > assumption that registers are 32-bit so only those bits will be restored > > > in function calls etc. N32 (where userspace isn't ready for prime time > > > yet) does guarantee that. And N64 (userspace similarly not ready for > > > prime time) obviously is fully 64-bit everything. > > > > I don't think you want to run o32 processes with the UX bit set. UX not > > only enables 64-bit addressing (which you can, in software, make look > > like 32-bit addressing), it also enables access to the 64-bit opcodes. > > This means that you are going to get unexpected and potentially > > unreproducible results. > > Well, I think this is OK -- 64-bit opcodes are generally useless for > software built for the o32 ABI, so they should not normally happen in > regular code. Perhaps some fancy hand-coded assembly might try to use > them to get unusual results, including an invalid opcode trap handler for > the processors that do not support them at all. But I don't think we > should try to work hard to prevent broken software from shooting into its > foot. I'm not a real fan of architecting software to dismiss broken (or rogue) programs since it tends to open up a whole lot of holes that cause O/S crashes. For instance, an o32 program should never be able to pass a non-sign-extended value thru a GPR to the O/S in a system call. How many places in the O/S implicitly assume this is true? The architecture was never intended to run real 32-bit programs with 64-bit ops enabled, and I would strongly urge you not to do this now. > > And the advantage is we have a single TLB refill handler. This hardly seems compelling given how short the handlers are. Further, since N64 needs the 64-bit address support anyway, setting UX and PX correctly will allow you to run the N32 code with the TLB handler instead of the XTLB handler. That way the XTLB handler is only invoked when a real extended address reference happens. That seems cleaner to me, but I admit I'm not the one that has to write the code. /gmu > > Maciej -- Michael Uhler, Chief Technology Officer MIPS Technologies, Inc. Email: uhler@mips.com Pager:uhler_p@mips.com 1225 Charleston Road Voice: (650)567-5025 FAX: (650)567-5225 Mountain View, CA 94043 Mobile: (650)868-6870 Admin: (650)567-5085
