Subject: Re: cpufunc.h
To: Ben Harris <firstname.lastname@example.org>
From: John Fremlin <email@example.com>
Date: 05/29/2001 18:15:26
Ben Harris <firstname.lastname@example.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
> > > > 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.