That's a lot of mess to use movq and movl to populate the on-stack register image. Using pushq would save a lot of code and significantly reduce register shuffling.
A quick Google search suggests that SPARC lacks push/pop instructions. My guess is that the person who wrote this was well versed in SPARC assembly and did in x86 what he would do in SPARC.
push/pop would make this code better, but I would not expect a measurable improvement in system performance from using it here. The improvement should be too small relative to all of the other things that happen in system call code paths. The time spent improving this would probably be better spent improving another area.
It's been a long time since Solaris worked well on a 32-bit CPU. UltraSPARC replaced SPARC in the 90s, and Solaris on x86 was not a very common thing then. It wasn't until Solaris 10/OpenSolaris (around 2005) that the x86 port was really viable, and then 64-bit CPUs were really recommended (especially after ZFS came out in Update 1)
Even so, the syscall handler would have been written early in the development of the x86 port, well before it was "viable" for customers. Relying on quad-word instructions in hand-written assembly for such a crucial part of the OS would have meant no 32-bit support at all. That's probably not a good product decision even today, but at the time, it would have been crazy.
If there is going to be a debate over how mov performs versus push/pop, someone should just go ahead and change it. The time talking about it would be better spent on other things.
You might want to try booting without graphics and accessing it via a serial port, to see if that makes a difference. See this e-mail thread for a discussion:
