Ben Harris <bjh21@netbsd.org> writes:

[...]

> > One exists already. The __SetCPSR is just a simpler primitive -
> > i.e. no worrying about bitmasks etc.
> 
> Hrm.  So SetCPSR should really be called SetSomeOfCPSR? *grin* 

IMHO it is a bad primitive.

> I think it needs to be made clear that __SetCPSR is an internal
> function, and things shouldn't call it directly.

Why not? It's handy first thing in bootstrap where you don't care what
the CPSR was before. It is also handy for the set_stackptr stuff.

Is the current assembly SetCPSR even valid? It can clobber a bunch of
registers on mode change. Are all these registers caller save in the
abi?

> > > > Would this patch be accepted?
> > >
> > > Probably.  I really need to overhaul cpufunc properly one day, but
> > > patches to make it nicer are always helpful.
> >
> > Here is the patch. After it is merged and explicit extern decls are
> > fixed, the assembly files implementing the stackptr and CPSR routines
> > can be removed. Note that the psionw port is not yet able to usefully
> > test these routines, so they might be doing completely the wrong
> > thing, and because I renamed the __?et_stack_pointer functions the
> > patch might not even compile :-)
> 
> Hmm.  I don't like the idea of splitting up the stack-pointer
> setting functions.  GCC is entitled to bugger around with the stack
> in between the mode change and setting the stack pointer, and this
> could mess up an entirely different stack from the one it's meant to
> be running on.

Good point. You could avoid that by making everything into macros.

> I'm also slightly dubious about large-scale use of GCC extensions,
> but if they stay in header files where we can find them, I shan't
> mutter too loudly.

At the moment they are spread all over the place in a disorganised
way. The notion that NetBSD/arm is in any way portable to another
compiler is quite frankly ridiculous.

-- 

	http://ape.n3.net