On Sun, 9 Jun 2002, NISHIMURA, Toru wrote:

> Some more for program portability issues of MIPS processors.
>
>  > I guess it would make no porting trouble if s_lock.c had
>  > special statements like asm (".set mips2") inside.
>
> As one of most successful RISC porcessors of the world, MIPS
> processors do have instruction variations across range of
> implementations.  Unfornately, the notion of instruction set
> group (ISA, Instruction Set Architecture) which was originally
> intended to categorize application program binary _natures_
> are not useful nor even practical since processor
> implementation diversity goes far beyond ISA category.  So,
> ISA is a marketing term to name the products.
>
> In this specific issue on LL/SC, program to use them should
> have specific statements (pseudo assembler instructions)
> to make clear some codes are extended instructions. It's
> a simple practice for ease of portability, I believe in.

	Presumably the kernel can determine at runtime whether the
	current CPU supports the atomic TAS instructions?

	If it exported this information via a machdep sysctl then we could
	have 'MIPS1' and 'LL/SC' versions of the operations in separate
	libraries and then select between them in ld.so.conf (similar to
	i386 with libm387.so.0).

-- 
		David/absolute		-- www.netbsd.org: No hype required --