[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: About support for rtVAX300
> *(int *)vax_map_physmem(0x201ffffc,1)=(int)(0xf-7)<<16;
Shouldn't that be
((int *)vax_map_physmem(0x201ffffc&~511,1))[(0x201ffffc&511)/sizeof(int)] = ...
? Or, likely, a mask appropriate to whatever NetBSD's software
pagesize is on the VAX, rather than 511? (I think NetBSD has used a
larger pagesize than the hardware for quite a while.) See below.
> 0x800002bc Xtransl_v
> ...Translation invalid or something..
Translation not valid fault, I think it is (perhaps abbreviated by the
code that prints it).
> [...] what could be wrong with that vax_map_physmem() call?
My remarks above are based on the assumption that vax_map_physmem deals
with page-aligned values, which 0x201ffffc isn't. What I wrote above
page-aligns the argument to vax_map_physmem and then offsets from the
result appropriately. (The division by sizeof(int) inside the
subscript is because the returned pointer is cast to int *; C
subscripting works in units of the pointed-to type. It could also work
*(int *)(((char *)vax_map_physmem(0x201ffffc&~mask,1))+(0x201ffffc&mask)) = ...
(where mask is pagesize-1) instead, that is, compute the address using
pointer-to-char and cast it to pointer-to-int only after that's done.
Which you prefer depends on how you prefer to think of it; they amount
to the same thing. The version using subscripting does have the
arguable disadvantage that it blindly assumes 0x201ffffc is correctly
aligned for an int. In VAX-specific code I don't see this as an issue.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Main Index |
Thread Index |