hi,

> > actually, there's some benefits.
> > 	- low cost to maintain.  (by sharing code with amd64 eventually)
> > 	- a step to support PAE.
> 
> Even with AMD64, "PD" and "PT" are still officially used. Only "PDP" is
> added for PAE and 64-bit virtual-physical address translation. Why do you
> want to replace the official terms with non-official ones? In other words,
> why can't amd64 pmap changed so it shares more code with i386 and better
> meets the techdocs?

the point is designating pte levels by numbers, not by names.
in this way we can more easily deal with arbitrary numbers of pte levels.

> > > - why is a single leal instruction replaced with two movl/addl
> > >   instructions? There are a couple more places with similar changes.
> > 
> > to be similar with amd64 version.
> > these code isn't worth to optimize, IMHO.
> 
> Those are not worth deoptimizing, either, IMHO. The same question can be
> raised here as well: why can't amd64 code changed instead?
> 
> In fact, I don't know if a single leal is faster than a movl/addl pair.
> But you should make a more reasonable argument if you want to modify the
> code that way.

- why do you claim that the change is deoptimizing,
  while you don't know which is effective? :-)
- i'm not sure why amd64 version is changed to that style.  ask fvdl.
- talking about i386, "low cost to maintain" is reasonable enough, IMHO.
- it's harder for me to modify amd64 code because i don't have any amd64 box.

> Could you give a brief description on why the following change is needed?
> 
>       9 -#define        KERNBASE        ((u_long)KERNBASE_LOCORE)
>      10 +#define        KERNBASE        (1UL * KERNBASE_LOCORE)

i vaguely remember that i changed it because u_long needs more headers for
its definition.  note that the file is included directly by .S files.

i have an impression that KERNBASE_LOCORE shouldn't have been
introduced at first place.  it's appropriate to use genassym.cf.
although i don't want to change it at this point.

YAMAMOTO Takashi