On Sat, 5 Jan 2002, Emmanuel Dreyfus wrote:

> 1) in sys/arch/mips/mips/locore_mips3.S
> mips3_ld and mips3_sd need an adjustement. It seems that thoses two
> routines need to disable and re-enable the interrupts, and that this is
> not done the same way for O32 and N32/LP64.
>
> Where can I find information about this? I've got a MIPS assembly
> manual, but I found nothing about interrupts in it.
>
> Here is the offending code:
>
>         mfc0    t0, MIPS_COP_0_STATUS           # turn off interrupts
>         and     t1, t0, ~(MIPS_SR_INT_IE)
>         mtc0    t1, MIPS_COP_0_STATUS
>         COP0_SYNC
>         nop
>         nop
>         nop
>
>         ...
>
>         mtc0    t0, MIPS_COP_0_STATUS           # restore intr status.
>         COP0_SYNC
>         nop

The way I see it, the function is for atomic read and writes of 64bit
values.

Interrupts are disabled because we are using 64 bit register ops (ld/sd)
but with an O32 API's we are only preserving the lower 32 bits of data in
the interrupt handler.
If we get an interrupt during the instruction sequence there is a chance
the upper 32bits of data will be destroyed.
If we are using N32 or LP64 API then 64 bits will be preserverd, therefore
we can safely let interrupts occur during the sequence.  The logic appears
correct.

Now why won't this work with N32 etc?   To use mips3_ld as an example the
function will return a 63 bit datatype.   For O32 which can only return
32bits of data in a register half is loaded into v0 and the other into v1

For N32 and LP64 the sequence would possibly optimise down to the single
ld/sd instruction.

>
> Speaking about this, what are mips3_ld and mips3_sd for?

Check the cvs log comment for rev 1.55 of the file.   AFAICT there are no
references to it in kernel at present.

It may have something to do with GCC magic (libgcc functionality?).  If
Chris has some time he may want to comment further.

> 2) in sys/arch/mips/include/stdarg.h
> There is an #error which says that the whole file is unsuitable for
> N32/LP64. Anyone can give me information about it? How is this file
> made? In IRIX's stdarg.h, I can read that 64 bit ABI uses the ANSI
> stdarg.h. Standard? Cool, I'll be able to copy it from somewhere else!
> :o) But where from?

stdarg(3) will break big time under N32.   The current header assumes data
is layed out in 32bit strides.   I may be wrong, but there needs to be a
certaion amount of compiler assistance for stdarg(3) support as well.

N32 also changed (and made more complicated) the rules for passing
variable.   See section 10.8 of "See Mips Run"

> N32 stdarg.h could be a problem, but as I understand, we only need this
> to build N32 binaries, not to run them, right?

Correct - it is only required when building N32 binaries.   Perhaps only
change the API if _KERNEL && COMPAT_IRIX at this stage.

> 3) in sys/kern/exec_elf32.c
> When incuding this from sys/kern/exec_elf64.c, I get some troubles with
> this:
> epp->ep_taddr = epp->ep_tsize = ELFDEFNNAME(NO_ADDR);
> This triggers a warning: large integer implicitely truncated to unsigned
> type. Probably a bad ELFSIZE somewhere, but I fail to see where. This is
> probably a minor problem, even if I'll spend a lot of time finding where
> is the typo that caused it ;o)

ELFDEFNNAME(NO_ADDR) -> ELF64_NO_ADDR -> (~(Elf64_Addr)0) -> (long long)-1
Will loose the upper bits when assigned in a 32bit int

Not sure if it is a critical problem or not.  Sounds like a topic for
tech_kern and/or port-sparc64.

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org