[MUSL] microMIPS32R2 O32 port

[MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

[-- Attachment #1.1: Type: text/plain, Size: 1027 bytes --]

Hi Rich,

Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 for microMIPS32R2 O32 port. I have also attached the patch (microMIPS32R2_v1_port.patch) for your reference.
Could you please review it?

Test result:

FAIL ./src/api/main.exe [status 1]
FAIL ./src/math/acosh.exe [status 1]
FAIL ./src/math/acoshl.exe [status 1]
FAIL ./src/math/asinh.exe [status 1]
FAIL ./src/math/asinhl.exe [status 1]
FAIL ./src/math/j0.exe [status 1]
FAIL ./src/math/jn.exe [status 1]
FAIL ./src/math/jnf.exe [status 1]
FAIL ./src/math/lgamma.exe [status 1]
FAIL ./src/math/lgamma_r.exe [status 1]
FAIL ./src/math/lgammaf.exe [status 1]
FAIL ./src/math/lgammaf_r.exe [status 1]
FAIL ./src/math/lgammal.exe [status 1]
FAIL ./src/math/sinh.exe [status 1]
FAIL ./src/math/sinhl.exe [status 1]
FAIL ./src/math/tgamma.exe [status 1]
FAIL ./src/math/tgammal.exe [status 1]
FAIL ./src/math/y0.exe [status 1]
FAIL ./src/math/y0f.exe [status 1]
FAIL ./src/math/ynf.exe [status 1]

Thanks,
Jaydeep



[-- Attachment #1.2: Type: text/html, Size: 3893 bytes --]

[-- Attachment #2: microMIPS32R2_v1_port.patch --]
[-- Type: application/octet-stream, Size: 10018 bytes --]

diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h
index 9fc50d7..c95db06 100644
--- a/arch/mips/crt_arch.h
+++ b/arch/mips/crt_arch.h
@@ -8,13 +8,39 @@ __asm__(
 ".type   " START ", @function\n"
 "_" START ":\n"
 "" START ":\n"
+#if __mips_isa_rev < 6
+#ifdef __mips_micromips
+"	move $fp, $0 \n"
+"	.align 2 \n"
+"	bal32 1f \n"
+"	nop32 \n"
+#else
 "	bal 1f \n"
 "	 move $fp, $0 \n"
+#endif
+#else
+"	move $fp, $0 \n"
+"	.align 2 \n"
+"	balc 1f \n"
+#endif
 "	.gpword . \n"
 "	.gpword " START "_c \n"
 ".weak _DYNAMIC \n"
 ".hidden _DYNAMIC \n"
 "	.gpword _DYNAMIC \n"
+
+#ifdef __mips_micromips
+"1:	ins $ra, $0, 0, 1 \n"
+"	lw $gp, 0($ra) \n"
+"	subu $gp, $ra, $gp \n"
+"	move $4, $sp \n"
+"	lw $5, 8($ra) \n"
+"	addu $5, $5, $gp \n"
+"	lw $25, 4($ra) \n"
+"	addu $25, $25, $gp \n"
+"	ori $25, $25, 1 \n"
+"	and $sp, $sp, -8 \n"
+#else
 "1:	lw $gp, 0($ra) \n"
 "	subu $gp, $ra, $gp \n"
 "	move $4, $sp \n"
@@ -23,7 +49,14 @@ __asm__(
 "	lw $25, 4($ra) \n"
 "	addu $25, $25, $gp \n"
 "	and $sp, $sp, -8 \n"
+#endif
+
+#if __mips_isa_rev < 6
 "	jalr $25 \n"
 "	 subu $sp, $sp, 16 \n"
+#else
+"	subu $sp, $sp, 16 \n"
+"	jalrc $25 \n"
+#endif
 ".set pop \n"
 );
diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h
index b3d59a4..9b5a4d7 100644
--- a/arch/mips/reloc.h
+++ b/arch/mips/reloc.h
@@ -36,6 +36,26 @@
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
 	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
 
+#if __mips_isa_rev < 6
+#ifdef __mips_micromips
+#define GETFUNCSYM(fp, sym, got) __asm__ ( \
+	".hidden " #sym "\n" \
+	".set push \n" \
+	".set noreorder \n" \
+	"	.align 2 \n" \
+	"	bal32 1f \n" \
+	"	 nop32 \n" \
+	"	.gpword . \n" \
+	"	.gpword " #sym " \n" \
+	"1:	ins $ra, $0, 0, 1 \n" \
+	"	lw %0, ($ra) \n" \
+	"	subu %0, $ra, %0 \n" \
+	"	lw $ra, 4($ra) \n" \
+	"	addu %0, %0, $ra \n" \
+	"	ori %0, %0, 1 \n" \
+	".set pop \n" \
+	: "=r"(*(fp)) : : "memory", "ra" )
+#else
 #define GETFUNCSYM(fp, sym, got) __asm__ ( \
 	".hidden " #sym "\n" \
 	".set push \n" \
@@ -50,3 +70,38 @@
 	"	addu %0, %0, $ra \n" \
 	".set pop \n" \
 	: "=r"(*(fp)) : : "memory", "ra" )
+#endif
+#else
+#ifdef __mips_micromips
+#define GETFUNCSYM(fp, sym, got) __asm__ ( \
+	".hidden " #sym "\n" \
+	".set push \n" \
+	".set noreorder \n" \
+	"	.align 2 \n" \
+	"	balc32 1f \n" \
+	"	.gpword . \n" \
+	"	.gpword " #sym " \n" \
+	"1:	ins $ra, $0, 0, 1 \n" \
+	"	lw %0, ($ra) \n" \
+	"	subu %0, $ra, %0 \n" \
+	"	lw $ra, 4($ra) \n" \
+	"	addu %0, %0, $ra \n" \
+	"	ori %0, %0, 1 \n" \
+	".set pop \n" \
+	: "=r"(*(fp)) : : "memory", "ra" )
+#else
+#define GETFUNCSYM(fp, sym, got) __asm__ ( \
+	".hidden " #sym "\n" \
+	".set push \n" \
+	".set noreorder \n" \
+	"	balc 1f \n" \
+	"	.gpword . \n" \
+	"	.gpword " #sym " \n" \
+	"1:	lw %0, ($ra) \n" \
+	"	subu %0, $ra, %0 \n" \
+	"	lw $ra, 4($ra) \n" \
+	"	addu %0, %0, $ra \n" \
+	".set pop \n" \
+	: "=r"(*(fp)) : : "memory", "ra" )
+#endif
+#endif
diff --git a/crt/mips/crtn.s b/crt/mips/crtn.s
index 506a04b..10bfaa1 100644
--- a/crt/mips/crtn.s
+++ b/crt/mips/crtn.s
@@ -3,11 +3,13 @@
 .section .init
 	lw $gp,24($sp)
 	lw $ra,28($sp)
-	j $ra
 	addu $sp,$sp,32
+	j $ra
+	nop
 
 .section .fini
 	lw $gp,24($sp)
 	lw $ra,28($sp)
-	j $ra
 	addu $sp,$sp,32
+	j $ra
+	nop
diff --git a/src/fenv/mips/fenv.S b/src/fenv/mips/fenv.S
index a5cb1f5..b0548ac 100644
--- a/src/fenv/mips/fenv.S
+++ b/src/fenv/mips/fenv.S
@@ -10,8 +10,9 @@ feclearexcept:
 	or      $5, $5, $4
 	xor     $5, $5, $4
 	ctc1    $5, $31
-	jr      $ra
 	li      $2, 0
+	jr      $ra
+	nop
 
 .global feraiseexcept
 .type  feraiseexcept,@function
@@ -20,23 +21,26 @@ feraiseexcept:
 	cfc1    $5, $31
 	or      $5, $5, $4
 	ctc1    $5, $31
-	jr      $ra
 	li      $2, 0
+	jr      $ra
+	nop
 
 .global fetestexcept
 .type  fetestexcept,@function
 fetestexcept:
 	and     $4, $4, 0x7c
 	cfc1    $2, $31
-	jr      $ra
 	and     $2, $2, $4
+	jr      $ra
+	nop
 
 .global fegetround
 .type  fegetround,@function
 fegetround:
 	cfc1    $2, $31
-	jr      $ra
 	andi    $2, $2, 3
+	jr      $ra
+	nop
 
 .global __fesetround
 .type __fesetround,@function
@@ -46,16 +50,18 @@ __fesetround:
 	and     $5, $5, $6
 	or      $5, $5, $4
 	ctc1    $5, $31
-	jr      $ra
 	li      $2, 0
+	jr      $ra
+	nop
 
 .global fegetenv
 .type  fegetenv,@function
 fegetenv:
 	cfc1    $5, $31
 	sw      $5, 0($4)
-	jr      $ra
 	li      $2, 0
+	jr      $ra
+	nop
 
 .global fesetenv
 .type  fesetenv,@function
@@ -65,7 +71,8 @@ fesetenv:
 	 nop
 	lw      $5, 0($4)
 1:	ctc1    $5, $31
-	jr      $ra
 	li      $2, 0
+	jr      $ra
+	nop
 
 #endif
diff --git a/src/internal/mips/syscall.s b/src/internal/mips/syscall.s
index 5d0def5..e6cb8fb 100644
--- a/src/internal/mips/syscall.s
+++ b/src/internal/mips/syscall.s
@@ -19,8 +19,9 @@ __syscall:
 	sw      $2 ,28($sp)
 	lw      $2, 28($sp)
 	syscall
-	beq     $7, $0, 1f
 	addu    $sp, $sp, 32
+	beq     $7, $0, 1f
+	nop
 	subu    $2, $0, $2
 1:	jr      $ra
 	nop
diff --git a/src/ldso/mips/dlsym.s b/src/ldso/mips/dlsym.s
index 1573e51..dd68a8f 100644
--- a/src/ldso/mips/dlsym.s
+++ b/src/ldso/mips/dlsym.s
@@ -13,5 +13,6 @@ dlsym:
 	jalr $25
 	nop
 	lw $ra, 12($sp)
-	jr $ra
 	addiu $sp, $sp, 16
+	jr $ra
+	nop
diff --git a/src/setjmp/mips/longjmp.S b/src/setjmp/mips/longjmp.S
index fdb6c95..b1572c3 100644
--- a/src/setjmp/mips/longjmp.S
+++ b/src/setjmp/mips/longjmp.S
@@ -36,5 +36,6 @@ longjmp:
 	lw      $22, 32($4)
 	lw      $23, 36($4)
 	lw      $30, 40($4)
-	jr      $ra
 	lw      $28, 44($4)
+	jr      $ra
+	nop
diff --git a/src/setjmp/mips/setjmp.S b/src/setjmp/mips/setjmp.S
index 501d526..e45c77d 100644
--- a/src/setjmp/mips/setjmp.S
+++ b/src/setjmp/mips/setjmp.S
@@ -35,5 +35,6 @@ setjmp:
 	swc1    $30, 96($4)
 	swc1    $31, 100($4)
 #endif
-	jr      $ra
 	li      $2, 0
+	jr      $ra
+	nop
diff --git a/src/signal/mips/sigsetjmp.s b/src/signal/mips/sigsetjmp.s
index 74b65ff..6d7b605 100644
--- a/src/signal/mips/sigsetjmp.s
+++ b/src/signal/mips/sigsetjmp.s
@@ -8,15 +8,17 @@ sigsetjmp:
 __sigsetjmp:
 	lui $gp, %hi(_gp_disp)
 	addiu $gp, %lo(_gp_disp)
+	addu $gp, $gp, $25
 	beq $5, $0, 1f
-	 addu $gp, $gp, $25
+	 nop
 
 	sw $ra, 104($4)
 	sw $16, 104+4+16($4)
 
 	lw $25, %call16(setjmp)($gp)
+	move $16, $4
 	jalr $25
-	 move $16, $4
+	 nop
 
 	move $5,$2
 	move $4,$16
diff --git a/src/thread/mips/clone.s b/src/thread/mips/clone.s
index 37dddf5..8e83626 100644
--- a/src/thread/mips/clone.s
+++ b/src/thread/mips/clone.s
@@ -4,7 +4,7 @@
 __clone:
 	# Save function pointer and argument pointer on new thread stack
 	and $5, $5, -8
-	subu $5, $5, 16
+	subu $5, $5, 32
 	sw $4, 0($5)
 	sw $7, 4($5)
 	# Shuffle (fn,sp,fl,arg,ptid,tls,ctid) to (fl,sp,ptid,tls,ctid)
@@ -19,8 +19,9 @@ __clone:
 	beq $7, $0, 1f
 	nop
 	addu $sp, $sp, 16
-	jr $ra
 	subu $2, $0, $2
+	jr $ra
+	nop
 1:	beq $2, $0, 1f
 	nop
 	addu $sp, $sp, 16
diff --git a/src/thread/mips/syscall_cp.S b/src/thread/mips/syscall_cp.S
new file mode 100644
index 0000000..c593bcf
--- /dev/null
+++ b/src/thread/mips/syscall_cp.S
@@ -0,0 +1,85 @@
+.set    noreorder
+
+.global __cp_begin
+.hidden __cp_begin
+.type   __cp_begin,@function
+.global __cp_end
+.hidden __cp_end
+.type   __cp_end,@function
+.global __cp_cancel
+.hidden __cp_cancel
+.type   __cp_cancel,@function
+.hidden __cancel
+.global __syscall_cp_asm
+.hidden __syscall_cp_asm
+.type   __syscall_cp_asm,@function
+__syscall_cp_asm:
+	subu    $sp, $sp, 32
+__cp_begin:
+	lw      $4, 0($4)
+	move    $2, $5
+	bne     $4, $0, __cp_cancel
+	nop
+	move    $4, $6
+	move    $5, $7
+	lw      $6, 48($sp)
+	lw      $7, 52($sp)
+	lw      $8, 56($sp)
+	lw      $9, 60($sp)
+	lw      $10,64($sp)
+	sw      $8, 16($sp)
+	sw      $9, 20($sp)
+	sw      $10,24($sp)
+	sw      $2, 28($sp)
+	lw      $2, 28($sp)
+	syscall
+__cp_end:
+	addu    $sp, $sp, 32
+	beq     $7, $0, 1f
+	nop
+	subu    $2, $0, $2
+1:	jr      $ra
+	nop
+
+__cp_cancel:
+	move    $2, $ra
+
+#if __mips_isa_rev < 6
+#ifdef __mips_micromips
+	addu    $sp, $sp, 32
+	.align  2
+	bal32   1f
+	nop32
+#else
+	bal     1f
+	addu    $sp, $sp, 32
+#endif
+#else
+#ifdef __mips_micromips
+	addu    $sp, $sp, 32
+	.align  2
+	balc32  1f
+#else
+	addu    $sp, $sp, 32
+	balc    1f
+#endif
+#endif
+	.gpword .
+	.gpword __cancel
+#ifdef __mips_micromips
+1:	ins     $ra, $0, 0, 1
+	lw      $3, ($ra)
+	subu    $3, $ra, $3
+	lw      $25, 4($ra)
+	addu    $25, $25, $3
+	ori     $25, $25, 1
+#else
+1:	lw      $3, ($ra)
+	subu    $3, $ra, $3
+	lw      $25, 4($ra)
+	addu    $25, $25, $3
+#endif
+	move    $ra, $2
+	jr      $25
+
+	nop
diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.s
deleted file mode 100644
index d284626..0000000
--- a/src/thread/mips/syscall_cp.s
+++ /dev/null
@@ -1,53 +0,0 @@
-.set    noreorder
-
-.global __cp_begin
-.hidden __cp_begin
-.type   __cp_begin,@function
-.global __cp_end
-.hidden __cp_end
-.type   __cp_end,@function
-.global __cp_cancel
-.hidden __cp_cancel
-.type   __cp_cancel,@function
-.hidden __cancel
-.global __syscall_cp_asm
-.hidden __syscall_cp_asm
-.type   __syscall_cp_asm,@function
-__syscall_cp_asm:
-	subu    $sp, $sp, 32
-__cp_begin:
-	lw      $4, 0($4)
-	bne     $4, $0, __cp_cancel
-	move    $2, $5
-	move    $4, $6
-	move    $5, $7
-	lw      $6, 48($sp)
-	lw      $7, 52($sp)
-	lw      $8, 56($sp)
-	lw      $9, 60($sp)
-	lw      $10,64($sp)
-	sw      $8, 16($sp)
-	sw      $9, 20($sp)
-	sw      $10,24($sp)
-	sw      $2, 28($sp)
-	lw      $2, 28($sp)
-	syscall
-__cp_end:
-	beq     $7, $0, 1f
-	addu    $sp, $sp, 32
-	subu    $2, $0, $2
-1:	jr      $ra
-	nop
-
-__cp_cancel:
-	move    $2, $ra
-	bal     1f
-	addu    $sp, $sp, 32
-	.gpword .
-	.gpword __cancel
-1:	lw      $3, ($ra)
-	subu    $3, $ra, $3
-	lw      $25, 4($ra)
-	addu    $25, $25, $3
-	jr      $25
-	move    $ra, $2
diff --git a/src/unistd/mips/pipe.s b/src/unistd/mips/pipe.s
index ba2c39a..e60912b 100644
--- a/src/unistd/mips/pipe.s
+++ b/src/unistd/mips/pipe.s
@@ -11,8 +11,9 @@ pipe:
 	beq $7, $0, 1f
 	nop
 	lw $25, %call16(__syscall_ret)($gp)
-	jr $25
 	subu $4, $0, $2
+	jr $25
+	nop
 1:	sw $2, 0($4)
 	sw $3, 4($4)
 	move $2, $0

Re: [MUSL] microMIPS32R2 O32 port

[dalias]

On Wed, Apr 05, 2017 at 06:33:01AM +0000, Jaydeep Patil wrote:
> Hi Rich,
> 
> Please refer to
> https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 for
> microMIPS32R2 O32 port. I have also attached the patch
> (microMIPS32R2_v1_port.patch) for your reference.
> Could you please review it?

Some important first questions:

Is micromips an ISA level or a new ISA? This is the same question as
last time with MIPS r6 and the answer was not obvious and seemingly
intentionally obscured by the official documentation. The answer is
important to how we approach supporting it. Do cpus that support
micromips also support plain mips? Is it like thumb where arm/thumb
code can be linked together and call into one another in the same
process, or are they different modes?

Once we answer those questions, can you provide justifications for the
proposed changes? From your patches it looks like branch delay slots
don't exist in micromips mode. There may be other differences too; I
didn't read it in detail. Rather than add a bunch of ifdefs I'd rather
figure out how we can generalize the code so that it's compatible with
both. This is what was done on arm when making it so the asm can be
compiled as thumb2.

Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Rich,

microMIPS is an Application Specific Extension (ASE) to MIPS cores. Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS and vice-versa.
microMIPS is a compressed ISA and contains both 16 and 32-bit instructions for code size benefit. 

microMIPS revision R2 to R5 contains branch instructions with delay slot, however microMIPS revision R6 does not contain delay slots (B changed to BC). 
Assembler converts a B+NOP to BC when assembled for R6. Thus we have removed non-NOP instructions from the delay slot so that same code can be used for R6.

Regards,
Jaydeep

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of dalias@libc.org
>Sent: 06 April 2017 PM 09:48
>To: musl@lists.openwall.com
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Wed, Apr 05, 2017 at 06:33:01AM +0000, Jaydeep Patil wrote:
>> Hi Rich,
>>
>> Please refer to
>> https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v1 for
>> microMIPS32R2 O32 port. I have also attached the patch
>> (microMIPS32R2_v1_port.patch) for your reference.
>> Could you please review it?
>
>Some important first questions:
>
>Is micromips an ISA level or a new ISA? This is the same question as last time
>with MIPS r6 and the answer was not obvious and seemingly intentionally
>obscured by the official documentation. The answer is important to how we
>approach supporting it. Do cpus that support micromips also support plain
>mips? Is it like thumb where arm/thumb code can be linked together and call
>into one another in the same process, or are they different modes?
>
>Once we answer those questions, can you provide justifications for the
>proposed changes? From your patches it looks like branch delay slots don't
>exist in micromips mode. There may be other differences too; I didn't read it
>in detail. Rather than add a bunch of ifdefs I'd rather figure out how we can
>generalize the code so that it's compatible with both. This is what was done on
>arm when making it so the asm can be compiled as thumb2.
>
>Rich

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Fri, Apr 07, 2017 at 06:47:57AM +0000, Jaydeep Patil wrote:
> Hi Rich,
> 
> microMIPS is an Application Specific Extension (ASE) to MIPS cores.
> Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS
> and vice-versa. microMIPS is a compressed ISA and contains both 16
> and 32-bit instructions for code size benefit.

In that case I'm confused what the benefit of compiling the asm files
as micromips rather than plain mips is. Is it just to save 10 bytes
here and there?

Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Rich,

We can reuse existing MIPS code for microMIPS. There are places where we read from $ra must be compiled for MIPS.
Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 for modifications.

Thanks,
Jaydeep

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>Sent: 07 April 2017 PM 07:50
>To: musl@lists.openwall.com
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Fri, Apr 07, 2017 at 06:47:57AM +0000, Jaydeep Patil wrote:
>> Hi Rich,
>>
>> microMIPS is an Application Specific Extension (ASE) to MIPS cores.
>> Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS and
>> vice-versa. microMIPS is a compressed ISA and contains both 16 and
>> 32-bit instructions for code size benefit.
>
>In that case I'm confused what the benefit of compiling the asm files as
>micromips rather than plain mips is. Is it just to save 10 bytes here and there?
>
>Rich

Re: [MUSL] microMIPS32R2 O32 port

[Szabolcs Nagy]

* Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10 +0000]:
> Hi Rich,
> 
> We can reuse existing MIPS code for microMIPS. There are places where we read from $ra must be compiled for MIPS.
> Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 for modifications.
> 

is micromips a different encoding for mips instructions
that works on some cpus but not others?

does it require musl changes because micromips does not
support all mips instructions just a subset?

> Thanks,
> Jaydeep
> 
> >-----Original Message-----
> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
> >Sent: 07 April 2017 PM 07:50
> >To: musl@lists.openwall.com
> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
> >
> >On Fri, Apr 07, 2017 at 06:47:57AM +0000, Jaydeep Patil wrote:
> >> Hi Rich,
> >>
> >> microMIPS is an Application Specific Extension (ASE) to MIPS cores.
> >> Both microMIPS and MIPS can co-exist. MIPS code can call microMIPS and
> >> vice-versa. microMIPS is a compressed ISA and contains both 16 and
> >> 32-bit instructions for code size benefit.
> >
> >In that case I'm confused what the benefit of compiling the asm files as
> >micromips rather than plain mips is. Is it just to save 10 bytes here and there?
> >
> >Rich

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10 +0000]:
> > Hi Rich,
> > 
> > We can reuse existing MIPS code for microMIPS. There are places where we read from $ra must be compiled for MIPS.
> > Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 for modifications.
> > 
> 
> is micromips a different encoding for mips instructions
> that works on some cpus but not others?

Yes, it's something like thumb or thumb2 on arm, or the riscv
compressed isa. What I'm not clear on is whether there are
micromips-only cpu models that can't execute normal mips.

If so we probably need the ability to build musl as micromips, but as
long as cpus which support both support interworking (calls between
the two type of code in the same process) reasonably, I don't think
there's any reason to consider it a different subarch.

If not (that is, if all cpus that support micromips also support the
normal mips isa) then I fail to see why there's any need to compile
musl's asm files as micromips. They're not size or performance
bottlenecks.

Rich

Re: [MUSL] microMIPS32R2 O32 port

[Andre McCurdy]

On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker <dalias@libc.org> wrote:
> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
>> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10 +0000]:
>> > Hi Rich,
>> >
>> > We can reuse existing MIPS code for microMIPS. There are places where we read from $ra must be compiled for MIPS.
>> > Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 for modifications.
>> >
>>
>> is micromips a different encoding for mips instructions
>> that works on some cpus but not others?
>
> Yes, it's something like thumb or thumb2 on arm, or the riscv
> compressed isa. What I'm not clear on is whether there are
> micromips-only cpu models that can't execute normal mips.

According to:

  https://imagination-technologies-cloudfront-assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS32_InstructionSet_AFP_P_MD00582_06.04.pdf

"microMIPS is also an alternative to the MIPS® instruction encoding
and can be implemented in parallel or stand-alone."

"If only one ISA mode exists (either MIPS or microMIPS) then this mode
switch mechanism does not exist"

> If so we probably need the ability to build musl as micromips, but as
> long as cpus which support both support interworking (calls between
> the two type of code in the same process) reasonably, I don't think
> there's any reason to consider it a different subarch.
>
> If not (that is, if all cpus that support micromips also support the
> normal mips isa) then I fail to see why there's any need to compile
> musl's asm files as micromips. They're not size or performance
> bottlenecks.
>
> Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi,

With this branch (micromips32r2_v2) we are supporting microMIPS cores that co-exist with MIPS. The MUSL library must be built with -minterlink-compressed option as there are couple of hand-written MIPS only functions. For microMIPS only cores we will create a different subarch.

Thanks,
Jaydeep

>-----Original Message-----
>From: Andre McCurdy [mailto:armccurdy@gmail.com]
>Sent: 13 April 2017 AM 03:17
>To: musl@lists.openwall.com
>Cc: Jaydeep Patil
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker <dalias@libc.org> wrote:
>> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
>>> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10 +0000]:
>>> > Hi Rich,
>>> >
>>> > We can reuse existing MIPS code for microMIPS. There are places where
>we read from $ra must be compiled for MIPS.
>>> > Please refer to https://github.com/JaydeepIMG/musl-
>1/tree/micromips32r2_v2 for modifications.
>>> >
>>>
>>> is micromips a different encoding for mips instructions that works on
>>> some cpus but not others?
>>
>> Yes, it's something like thumb or thumb2 on arm, or the riscv
>> compressed isa. What I'm not clear on is whether there are
>> micromips-only cpu models that can't execute normal mips.
>
>According to:
>
>  https://imagination-technologies-cloudfront-
>assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS32
>_InstructionSet_AFP_P_MD00582_06.04.pdf
>
>"microMIPS is also an alternative to the MIPS® instruction encoding and can
>be implemented in parallel or stand-alone."
>
>"If only one ISA mode exists (either MIPS or microMIPS) then this mode
>switch mechanism does not exist"
>
>> If so we probably need the ability to build musl as micromips, but as
>> long as cpus which support both support interworking (calls between
>> the two type of code in the same process) reasonably, I don't think
>> there's any reason to consider it a different subarch.
>>
>> If not (that is, if all cpus that support micromips also support the
>> normal mips isa) then I fail to see why there's any need to compile
>> musl's asm files as micromips. They're not size or performance
>> bottlenecks.
>>
>> Rich

Re: [MUSL] microMIPS32R2 O32 port

[Szabolcs Nagy]

* Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-13 04:29:10 +0000]:
> With this branch (micromips32r2_v2) we are supporting microMIPS cores that co-exist with MIPS. The MUSL library must be built with -minterlink-compressed option as there are couple of hand-written MIPS only functions. For microMIPS only cores we will create a different subarch.
> 

ok the _v2 branch makes sense to me
(the patch is sufficiently small that
you can send it to the list)

i think i was looking at _v1 before

> >-----Original Message-----
> >From: Andre McCurdy [mailto:armccurdy@gmail.com]
> >Sent: 13 April 2017 AM 03:17
> >To: musl@lists.openwall.com
> >Cc: Jaydeep Patil
> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
> >
> >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker <dalias@libc.org> wrote:
> >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
> >>> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10 +0000]:
> >>> > Hi Rich,
> >>> >
> >>> > We can reuse existing MIPS code for microMIPS. There are places where
> >we read from $ra must be compiled for MIPS.
> >>> > Please refer to https://github.com/JaydeepIMG/musl-
> >1/tree/micromips32r2_v2 for modifications.
> >>> >
> >>>
> >>> is micromips a different encoding for mips instructions that works on
> >>> some cpus but not others?
> >>
> >> Yes, it's something like thumb or thumb2 on arm, or the riscv
> >> compressed isa. What I'm not clear on is whether there are
> >> micromips-only cpu models that can't execute normal mips.
> >
> >According to:
> >
> >  https://imagination-technologies-cloudfront-
> >assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS32
> >_InstructionSet_AFP_P_MD00582_06.04.pdf
> >
> >"microMIPS is also an alternative to the MIPS® instruction encoding and can
> >be implemented in parallel or stand-alone."
> >
> >"If only one ISA mode exists (either MIPS or microMIPS) then this mode
> >switch mechanism does not exist"
> >
> >> If so we probably need the ability to build musl as micromips, but as
> >> long as cpus which support both support interworking (calls between
> >> the two type of code in the same process) reasonably, I don't think
> >> there's any reason to consider it a different subarch.
> >>
> >> If not (that is, if all cpus that support micromips also support the
> >> normal mips isa) then I fail to see why there's any need to compile
> >> musl's asm files as micromips. They're not size or performance
> >> bottlenecks.
> >>
> >> Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

[-- Attachment #1: Type: text/plain, Size: 2926 bytes --]

Hi Szabolcs,

Please find the attached patch.

Thanks,
Jaydeep

>-----Original Message-----
>From: Szabolcs Nagy [mailto:nsz@port70.net]
>Sent: 13 April 2017 PM 02:31
>To: musl@lists.openwall.com
>Cc: Andre McCurdy; Jaydeep Patil
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>* Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-13 04:29:10 +0000]:
>> With this branch (micromips32r2_v2) we are supporting microMIPS cores
>that co-exist with MIPS. The MUSL library must be built with -minterlink-
>compressed option as there are couple of hand-written MIPS only functions.
>For microMIPS only cores we will create a different subarch.
>>
>
>ok the _v2 branch makes sense to me
>(the patch is sufficiently small that
>you can send it to the list)
>
>i think i was looking at _v1 before
>
>> >-----Original Message-----
>> >From: Andre McCurdy [mailto:armccurdy@gmail.com]
>> >Sent: 13 April 2017 AM 03:17
>> >To: musl@lists.openwall.com
>> >Cc: Jaydeep Patil
>> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>> >
>> >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker <dalias@libc.org> wrote:
>> >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
>> >>> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10
>+0000]:
>> >>> > Hi Rich,
>> >>> >
>> >>> > We can reuse existing MIPS code for microMIPS. There are places
>> >>> > where
>> >we read from $ra must be compiled for MIPS.
>> >>> > Please refer to https://github.com/JaydeepIMG/musl-
>> >1/tree/micromips32r2_v2 for modifications.
>> >>> >
>> >>>
>> >>> is micromips a different encoding for mips instructions that works
>> >>> on some cpus but not others?
>> >>
>> >> Yes, it's something like thumb or thumb2 on arm, or the riscv
>> >> compressed isa. What I'm not clear on is whether there are
>> >> micromips-only cpu models that can't execute normal mips.
>> >
>> >According to:
>> >
>> >  https://imagination-technologies-cloudfront-
>>
>>assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS3
>2
>> >_InstructionSet_AFP_P_MD00582_06.04.pdf
>> >
>> >"microMIPS is also an alternative to the MIPS(r) instruction encoding
>> >and can be implemented in parallel or stand-alone."
>> >
>> >"If only one ISA mode exists (either MIPS or microMIPS) then this
>> >mode switch mechanism does not exist"
>> >
>> >> If so we probably need the ability to build musl as micromips, but
>> >> as long as cpus which support both support interworking (calls
>> >> between the two type of code in the same process) reasonably, I
>> >> don't think there's any reason to consider it a different subarch.
>> >>
>> >> If not (that is, if all cpus that support micromips also support
>> >> the normal mips isa) then I fail to see why there's any need to
>> >> compile musl's asm files as micromips. They're not size or
>> >> performance bottlenecks.
>> >>
>> >> Rich

[-- Attachment #2: microMIPS_32R2_v2.patch --]
[-- Type: application/octet-stream, Size: 1468 bytes --]

diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h
index 9fc50d7..78832b0 100644
--- a/arch/mips/crt_arch.h
+++ b/arch/mips/crt_arch.h
@@ -1,6 +1,7 @@
 __asm__(
 ".set push\n"
 ".set noreorder\n"
+".set nomicromips\n"
 ".text \n"
 ".global _" START "\n"
 ".global " START "\n"
diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h
index b3d59a4..772b3aa 100644
--- a/arch/mips/reloc.h
+++ b/arch/mips/reloc.h
@@ -36,15 +36,23 @@
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
 	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
 
+/*
+ * When compiled for microMIPS, .align makes sure that .gpword
+ * is placed at word boundary. $ra must point to first .gpword.
+ * ISA bit of $ra must be cleared for microMIPS before using it
+ * as a base address. For MIPS, ISA bit is always zero.
+*/
 #define GETFUNCSYM(fp, sym, got) __asm__ ( \
 	".hidden " #sym "\n" \
 	".set push \n" \
 	".set noreorder \n" \
+	"	.align 2 \n" \
 	"	bal 1f \n" \
 	"	 nop \n" \
 	"	.gpword . \n" \
 	"	.gpword " #sym " \n" \
-	"1:	lw %0, ($ra) \n" \
+	"1:	ins $ra, $0, 0, 1 \n" \
+	"	lw %0, ($ra) \n" \
 	"	subu %0, $ra, %0 \n" \
 	"	lw $ra, 4($ra) \n" \
 	"	addu %0, %0, $ra \n" \
diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.s
index d284626..9c5f55e 100644
--- a/src/thread/mips/syscall_cp.s
+++ b/src/thread/mips/syscall_cp.s
@@ -1,5 +1,5 @@
 .set    noreorder
-
+.set    nomicromips
 .global __cp_begin
 .hidden __cp_begin
 .type   __cp_begin,@function

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Szabolcs,

Could you please commit this patch?

Thanks,
Jaydeep

>-----Original Message-----
>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>Sent: 13 April 2017 PM 04:07
>To: Szabolcs Nagy; musl@lists.openwall.com
>Cc: Andre McCurdy
>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>
>Hi Szabolcs,
>
>Please find the attached patch.
>
>Thanks,
>Jaydeep
>
>>-----Original Message-----
>>From: Szabolcs Nagy [mailto:nsz@port70.net]
>>Sent: 13 April 2017 PM 02:31
>>To: musl@lists.openwall.com
>>Cc: Andre McCurdy; Jaydeep Patil
>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>>
>>* Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-13 04:29:10 +0000]:
>>> With this branch (micromips32r2_v2) we are supporting microMIPS cores
>>that co-exist with MIPS. The MUSL library must be built with
>>-minterlink- compressed option as there are couple of hand-written MIPS
>only functions.
>>For microMIPS only cores we will create a different subarch.
>>>
>>
>>ok the _v2 branch makes sense to me
>>(the patch is sufficiently small that
>>you can send it to the list)
>>
>>i think i was looking at _v1 before
>>
>>> >-----Original Message-----
>>> >From: Andre McCurdy [mailto:armccurdy@gmail.com]
>>> >Sent: 13 April 2017 AM 03:17
>>> >To: musl@lists.openwall.com
>>> >Cc: Jaydeep Patil
>>> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>>> >
>>> >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker <dalias@libc.org> wrote:
>>> >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
>>> >>> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10
>>+0000]:
>>> >>> > Hi Rich,
>>> >>> >
>>> >>> > We can reuse existing MIPS code for microMIPS. There are places
>>> >>> > where
>>> >we read from $ra must be compiled for MIPS.
>>> >>> > Please refer to https://github.com/JaydeepIMG/musl-
>>> >1/tree/micromips32r2_v2 for modifications.
>>> >>> >
>>> >>>
>>> >>> is micromips a different encoding for mips instructions that
>>> >>> works on some cpus but not others?
>>> >>
>>> >> Yes, it's something like thumb or thumb2 on arm, or the riscv
>>> >> compressed isa. What I'm not clear on is whether there are
>>> >> micromips-only cpu models that can't execute normal mips.
>>> >
>>> >According to:
>>> >
>>> >  https://imagination-technologies-cloudfront-
>>>
>>>assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS
>3
>>2
>>> >_InstructionSet_AFP_P_MD00582_06.04.pdf
>>> >
>>> >"microMIPS is also an alternative to the MIPS(r) instruction
>>> >encoding and can be implemented in parallel or stand-alone."
>>> >
>>> >"If only one ISA mode exists (either MIPS or microMIPS) then this
>>> >mode switch mechanism does not exist"
>>> >
>>> >> If so we probably need the ability to build musl as micromips, but
>>> >> as long as cpus which support both support interworking (calls
>>> >> between the two type of code in the same process) reasonably, I
>>> >> don't think there's any reason to consider it a different subarch.
>>> >>
>>> >> If not (that is, if all cpus that support micromips also support
>>> >> the normal mips isa) then I fail to see why there's any need to
>>> >> compile musl's asm files as micromips. They're not size or
>>> >> performance bottlenecks.
>>> >>
>>> >> Rich

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote:
> Hi Szabolcs,
> 
> Please find the attached patch.

I still don't follow the motivation of all the changes in this patch.
See comments below:

> [...]
> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h
> index 9fc50d7..78832b0 100644
> --- a/arch/mips/crt_arch.h
> +++ b/arch/mips/crt_arch.h
> @@ -1,6 +1,7 @@
>  __asm__(
>  ".set push\n"
>  ".set noreorder\n"
> +".set nomicromips\n"
>  ".text \n"
>  ".global _" START "\n"
>  ".global " START "\n"

Is there a need for crt1.o (or other users of this file like
dlstart/rcrt1) to be built as plain mips rather than micromips? If so,
please explain. Arbitrary changes like this without an explanation of
why they're being made (what was broken before, and why this is the
correct fix) are not acceptable.

> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h
> index b3d59a4..772b3aa 100644
> --- a/arch/mips/reloc.h
> +++ b/arch/mips/reloc.h
> @@ -36,15 +36,23 @@
>  #define CRTJMP(pc,sp) __asm__ __volatile__( \
>  	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
>  
> +/*
> + * When compiled for microMIPS, .align makes sure that .gpword
> + * is placed at word boundary. $ra must point to first .gpword.
> + * ISA bit of $ra must be cleared for microMIPS before using it
> + * as a base address. For MIPS, ISA bit is always zero.
> +*/
>  #define GETFUNCSYM(fp, sym, got) __asm__ ( \
>  	".hidden " #sym "\n" \
>  	".set push \n" \
>  	".set noreorder \n" \
> +	"	.align 2 \n" \
>  	"	bal 1f \n" \
>  	"	 nop \n" \
>  	"	.gpword . \n" \
>  	"	.gpword " #sym " \n" \
> -	"1:	lw %0, ($ra) \n" \
> +	"1:	ins $ra, $0, 0, 1 \n" \
> +	"	lw %0, ($ra) \n" \
>  	"	subu %0, $ra, %0 \n" \
>  	"	lw $ra, 4($ra) \n" \
>  	"	addu %0, %0, $ra \n" \

By this, do you mean that .gpword is producing a value that's relative
to the actual byte position of the directive rather than the logical
(ISA bit set) value of "." at the point of .gpword?

> diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.s
> index d284626..9c5f55e 100644
> --- a/src/thread/mips/syscall_cp.s
> +++ b/src/thread/mips/syscall_cp.s
> @@ -1,5 +1,5 @@
>  .set    noreorder
> -
> +.set    nomicromips
>  .global __cp_begin
>  .hidden __cp_begin
>  .type   __cp_begin,@function

I'm also unclear on the motivation of this one. Before (v1) you had a
lot of changes to replace .s files with something micromips-compatible
(removing branch delay slots); now (v2) those changes are not
included. So are .s files even being built as micromips at all? If
not, why is the above needed? If so, how do the files with delay slots
work?

Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>Sent: 21 April 2017 PM 07:03
>To: Jaydeep Patil
>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote:
>> Hi Szabolcs,
>>
>> Please find the attached patch.
>
>I still don't follow the motivation of all the changes in this patch.
>See comments below:
>
>> [...]
>> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index
>> 9fc50d7..78832b0 100644
>> --- a/arch/mips/crt_arch.h
>> +++ b/arch/mips/crt_arch.h
>> @@ -1,6 +1,7 @@
>>  __asm__(
>>  ".set push\n"
>>  ".set noreorder\n"
>> +".set nomicromips\n"
>>  ".text \n"
>>  ".global _" START "\n"
>>  ".global " START "\n"
>
>Is there a need for crt1.o (or other users of this file like
>dlstart/rcrt1) to be built as plain mips rather than micromips? If so, please
>explain. Arbitrary changes like this without an explanation of why they're
>being made (what was broken before, and why this is the correct fix) are not
>acceptable.

The crt1.o and __cp_begin are built as pure MIPS functions rather than microMIPS as they are reading data using $ra register (with ISA bit set).
We can clear the ISA bit (using INS) and choose to compile these functions as microMIPS.


>> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index
>> b3d59a4..772b3aa 100644
>> --- a/arch/mips/reloc.h
>> +++ b/arch/mips/reloc.h
>> @@ -36,15 +36,23 @@
>>  #define CRTJMP(pc,sp) __asm__ __volatile__( \
>>  	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
>>
>> +/*
>> + * When compiled for microMIPS, .align makes sure that .gpword
>> + * is placed at word boundary. $ra must point to first .gpword.
>> + * ISA bit of $ra must be cleared for microMIPS before using it
>> + * as a base address. For MIPS, ISA bit is always zero.
>> +*/
>>  #define GETFUNCSYM(fp, sym, got) __asm__ ( \
>>  	".hidden " #sym "\n" \
>>  	".set push \n" \
>>  	".set noreorder \n" \
>> +	"	.align 2 \n" \
>>  	"	bal 1f \n" \
>>  	"	 nop \n" \
>>  	"	.gpword . \n" \
>>  	"	.gpword " #sym " \n" \
>> -	"1:	lw %0, ($ra) \n" \
>> +	"1:	ins $ra, $0, 0, 1 \n" \
>> +	"	lw %0, ($ra) \n" \
>>  	"	subu %0, $ra, %0 \n" \
>>  	"	lw $ra, 4($ra) \n" \
>>  	"	addu %0, %0, $ra \n" \
>
>By this, do you mean that .gpword is producing a value that's relative to the
>actual byte position of the directive rather than the logical (ISA bit set) value
>of "." at the point of .gpword?

ISA bit is set for all microMIPS symbols (including the dot symbol). The GETFUNCSYM macro cannot be compiled as pure MIPS code as it might be expanded in a microMIPS function.
We need to clear the ISA bit of $ra before using it as a base address in load/store instructions.


>> diff --git a/src/thread/mips/syscall_cp.s
>> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
>> --- a/src/thread/mips/syscall_cp.s
>> +++ b/src/thread/mips/syscall_cp.s
>> @@ -1,5 +1,5 @@
>>  .set    noreorder
>> -
>> +.set    nomicromips
>>  .global __cp_begin
>>  .hidden __cp_begin
>>  .type   __cp_begin,@function
>
>I'm also unclear on the motivation of this one. Before (v1) you had a lot of
>changes to replace .s files with something micromips-compatible (removing
>branch delay slots); now (v2) those changes are not included. So are .s files
>even being built as micromips at all? If not, why is the above needed? If so,
>how do the files with delay slots work?

Branch delay slots are removed (called as compact instructions) in the newer MIPS/microMIPS cores (in development). 
The MIPS/microMIPS R2-R6 still support instructions with delay slot.
Assembler takes care of converting a BRANCH + NOP to its appropriate compact instruction (BEQ + NOP to BEQC). 
With the v1 branch I was trying to create generic hand-written assembly which can be used for newer cores with the compact instructions.
However I realized that it would appropriate to create a new arch instead of creating generic assembly.
Thus in v2 branch I modified only those functions which would create issues when compiled with interlinking on.


>Rich

Thanks,
Jaydeep

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Mon, Apr 24, 2017 at 05:30:34AM +0000, Jaydeep Patil wrote:
> >-----Original Message-----
> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
> >Sent: 21 April 2017 PM 07:03
> >To: Jaydeep Patil
> >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
> >
> >On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote:
> >> Hi Szabolcs,
> >>
> >> Please find the attached patch.
> >
> >I still don't follow the motivation of all the changes in this patch.
> >See comments below:
> >
> >> [...]
> >> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index
> >> 9fc50d7..78832b0 100644
> >> --- a/arch/mips/crt_arch.h
> >> +++ b/arch/mips/crt_arch.h
> >> @@ -1,6 +1,7 @@
> >>  __asm__(
> >>  ".set push\n"
> >>  ".set noreorder\n"
> >> +".set nomicromips\n"
> >>  ".text \n"
> >>  ".global _" START "\n"
> >>  ".global " START "\n"
> >
> >Is there a need for crt1.o (or other users of this file like
> >dlstart/rcrt1) to be built as plain mips rather than micromips? If so, please
> >explain. Arbitrary changes like this without an explanation of why they're
> >being made (what was broken before, and why this is the correct fix) are not
> >acceptable.
> 
> The crt1.o and __cp_begin are built as pure MIPS functions rather
> than microMIPS as they are reading data using $ra register (with ISA
> bit set). We can clear the ISA bit (using INS) and choose to compile
> these functions as microMIPS.

I see. So all the .s files are assembled as plain (32-bit) MIPS, and
these files are just affected because the asm is included in .c files
that might be compiled in microMIPS mode. That makes sense. I think
it's probably just better to make the code microMIPS-compatible though
by clearing the low bits. But syscall_cp.s needs some care because
saved instruction pointer values are compared against these labels. In
micromips mode, do the labels evaluate with the +1 low bit offset?

> >> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index
> >> b3d59a4..772b3aa 100644
> >> --- a/arch/mips/reloc.h
> >> +++ b/arch/mips/reloc.h
> >> @@ -36,15 +36,23 @@
> >>  #define CRTJMP(pc,sp) __asm__ __volatile__( \
> >>  	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
> >>
> >> +/*
> >> + * When compiled for microMIPS, .align makes sure that .gpword
> >> + * is placed at word boundary. $ra must point to first .gpword.
> >> + * ISA bit of $ra must be cleared for microMIPS before using it
> >> + * as a base address. For MIPS, ISA bit is always zero.
> >> +*/
> >>  #define GETFUNCSYM(fp, sym, got) __asm__ ( \
> >>  	".hidden " #sym "\n" \
> >>  	".set push \n" \
> >>  	".set noreorder \n" \
> >> +	"	.align 2 \n" \
> >>  	"	bal 1f \n" \
> >>  	"	 nop \n" \
> >>  	"	.gpword . \n" \
> >>  	"	.gpword " #sym " \n" \
> >> -	"1:	lw %0, ($ra) \n" \
> >> +	"1:	ins $ra, $0, 0, 1 \n" \
> >> +	"	lw %0, ($ra) \n" \
> >>  	"	subu %0, $ra, %0 \n" \
> >>  	"	lw $ra, 4($ra) \n" \
> >>  	"	addu %0, %0, $ra \n" \
> >
> >By this, do you mean that .gpword is producing a value that's relative to the
> >actual byte position of the directive rather than the logical (ISA bit set) value
> >of "." at the point of .gpword?
> 
> ISA bit is set for all microMIPS symbols (including the dot symbol).
> The GETFUNCSYM macro cannot be compiled as pure MIPS code as it
> might be expanded in a microMIPS function. We need to clear the ISA
> bit of $ra before using it as a base address in load/store
> instructions.

OK. And the same appproach would work for crt_arch.h and other places,
right?

> >> diff --git a/src/thread/mips/syscall_cp.s
> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
> >> --- a/src/thread/mips/syscall_cp.s
> >> +++ b/src/thread/mips/syscall_cp.s
> >> @@ -1,5 +1,5 @@
> >>  .set    noreorder
> >> -
> >> +.set    nomicromips
> >>  .global __cp_begin
> >>  .hidden __cp_begin
> >>  .type   __cp_begin,@function
> >
> >I'm also unclear on the motivation of this one. Before (v1) you had a lot of
> >changes to replace .s files with something micromips-compatible (removing
> >branch delay slots); now (v2) those changes are not included. So are .s files
> >even being built as micromips at all? If not, why is the above needed? If so,
> >how do the files with delay slots work?
> 
> Branch delay slots are removed (called as compact instructions) in
> the newer MIPS/microMIPS cores (in development).
> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
> Assembler takes care of converting a BRANCH + NOP to its appropriate
> compact instruction (BEQ + NOP to BEQC).
> With the v1 branch I was trying to create generic hand-written
> assembly which can be used for newer cores with the compact
> instructions.
> However I realized that it would appropriate to create a new arch
> instead of creating generic assembly.
> Thus in v2 branch I modified only those functions which would create
> issues when compiled with interlinking on.

Based on the discussions so far, I don't think pure-micromips
qualifies as a new arch. If it would be possible to take a program
compiled as micromips-only, and run it with the libc.so/ldso built for
plain mips on a machine that supports both forms of code, then it's
not a separate arch, and as I understand it this should be possible.

Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>Sent: 24 April 2017 PM 07:18
>To: Jaydeep Patil
>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Mon, Apr 24, 2017 at 05:30:34AM +0000, Jaydeep Patil wrote:
>> >-----Original Message-----
>> >From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>> >Sent: 21 April 2017 PM 07:03
>> >To: Jaydeep Patil
>> >Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>> >
>> >On Thu, Apr 13, 2017 at 10:37:05AM +0000, Jaydeep Patil wrote:
>> >> Hi Szabolcs,
>> >>
>> >> Please find the attached patch.
>> >
>> >I still don't follow the motivation of all the changes in this patch.
>> >See comments below:
>> >
>> >> [...]
>> >> diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h index
>> >> 9fc50d7..78832b0 100644
>> >> --- a/arch/mips/crt_arch.h
>> >> +++ b/arch/mips/crt_arch.h
>> >> @@ -1,6 +1,7 @@
>> >>  __asm__(
>> >>  ".set push\n"
>> >>  ".set noreorder\n"
>> >> +".set nomicromips\n"
>> >>  ".text \n"
>> >>  ".global _" START "\n"
>> >>  ".global " START "\n"
>> >
>> >Is there a need for crt1.o (or other users of this file like
>> >dlstart/rcrt1) to be built as plain mips rather than micromips? If
>> >so, please explain. Arbitrary changes like this without an
>> >explanation of why they're being made (what was broken before, and
>> >why this is the correct fix) are not acceptable.
>>
>> The crt1.o and __cp_begin are built as pure MIPS functions rather than
>> microMIPS as they are reading data using $ra register (with ISA bit
>> set). We can clear the ISA bit (using INS) and choose to compile these
>> functions as microMIPS.
>
>I see. So all the .s files are assembled as plain (32-bit) MIPS, and these files are
>just affected because the asm is included in .c files that might be compiled in
>microMIPS mode. That makes sense. I think it's probably just better to make
>the code microMIPS-compatible though by clearing the low bits. 

Ok, I will remove the  "nomicromips" restriction and clear the ISA bit instead.

> But syscall_cp.s needs some care because saved instruction pointer values are
>compared against these labels. In micromips mode, do the labels evaluate
>with the +1 low bit offset?

Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However I don't see any issue with following comparison

pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end

The ISA bit will be set even for PC in the saved context.

>> >> diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h index
>> >> b3d59a4..772b3aa 100644
>> >> --- a/arch/mips/reloc.h
>> >> +++ b/arch/mips/reloc.h
>> >> @@ -36,15 +36,23 @@
>> >>  #define CRTJMP(pc,sp) __asm__ __volatile__( \
>> >>  	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
>> >>
>> >> +/*
>> >> + * When compiled for microMIPS, .align makes sure that .gpword
>> >> + * is placed at word boundary. $ra must point to first .gpword.
>> >> + * ISA bit of $ra must be cleared for microMIPS before using it
>> >> + * as a base address. For MIPS, ISA bit is always zero.
>> >> +*/
>> >>  #define GETFUNCSYM(fp, sym, got) __asm__ ( \
>> >>  	".hidden " #sym "\n" \
>> >>  	".set push \n" \
>> >>  	".set noreorder \n" \
>> >> +	"	.align 2 \n" \
>> >>  	"	bal 1f \n" \
>> >>  	"	 nop \n" \
>> >>  	"	.gpword . \n" \
>> >>  	"	.gpword " #sym " \n" \
>> >> -	"1:	lw %0, ($ra) \n" \
>> >> +	"1:	ins $ra, $0, 0, 1 \n" \
>> >> +	"	lw %0, ($ra) \n" \
>> >>  	"	subu %0, $ra, %0 \n" \
>> >>  	"	lw $ra, 4($ra) \n" \
>> >>  	"	addu %0, %0, $ra \n" \
>> >
>> >By this, do you mean that .gpword is producing a value that's
>> >relative to the actual byte position of the directive rather than the
>> >logical (ISA bit set) value of "." at the point of .gpword?
>>
>> ISA bit is set for all microMIPS symbols (including the dot symbol).
>> The GETFUNCSYM macro cannot be compiled as pure MIPS code as it might
>> be expanded in a microMIPS function. We need to clear the ISA bit of
>> $ra before using it as a base address in load/store instructions.
>
>OK. And the same appproach would work for crt_arch.h and other places,
>right?

Yes.

>> >> diff --git a/src/thread/mips/syscall_cp.s
>> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
>> >> --- a/src/thread/mips/syscall_cp.s
>> >> +++ b/src/thread/mips/syscall_cp.s
>> >> @@ -1,5 +1,5 @@
>> >>  .set    noreorder
>> >> -
>> >> +.set    nomicromips
>> >>  .global __cp_begin
>> >>  .hidden __cp_begin
>> >>  .type   __cp_begin,@function
>> >
>> >I'm also unclear on the motivation of this one. Before (v1) you had a
>> >lot of changes to replace .s files with something
>> >micromips-compatible (removing branch delay slots); now (v2) those
>> >changes are not included. So are .s files even being built as
>> >micromips at all? If not, why is the above needed? If so, how do the files
>with delay slots work?
>>
>> Branch delay slots are removed (called as compact instructions) in the
>> newer MIPS/microMIPS cores (in development).
>> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
>> Assembler takes care of converting a BRANCH + NOP to its appropriate
>> compact instruction (BEQ + NOP to BEQC).
>> With the v1 branch I was trying to create generic hand-written
>> assembly which can be used for newer cores with the compact
>> instructions.
>> However I realized that it would appropriate to create a new arch
>> instead of creating generic assembly.
>> Thus in v2 branch I modified only those functions which would create
>> issues when compiled with interlinking on.
>
>Based on the discussions so far, I don't think pure-micromips qualifies as a
>new arch. If it would be possible to take a program compiled as micromips-
>only, and run it with the libc.so/ldso built for plain mips on a machine that
>supports both forms of code, then it's not a separate arch, and as I
>understand it this should be possible.

Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch.

>Rich

I will create v3 if you are OK with this approach.

Thanks,
Jaydeep

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
> > But syscall_cp.s needs some care because saved instruction pointer values are
> >compared against these labels. In micromips mode, do the labels evaluate
> >with the +1 low bit offset?
> 
> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However
> I don't see any issue with following comparison
> 
> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
> 
> The ISA bit will be set even for PC in the saved context.

Agreed, I think it should work as expected.

> >> >> diff --git a/src/thread/mips/syscall_cp.s
> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
> >> >> --- a/src/thread/mips/syscall_cp.s
> >> >> +++ b/src/thread/mips/syscall_cp.s
> >> >> @@ -1,5 +1,5 @@
> >> >>  .set    noreorder
> >> >> -
> >> >> +.set    nomicromips
> >> >>  .global __cp_begin
> >> >>  .hidden __cp_begin
> >> >>  .type   __cp_begin,@function
> >> >
> >> >I'm also unclear on the motivation of this one. Before (v1) you had a
> >> >lot of changes to replace .s files with something
> >> >micromips-compatible (removing branch delay slots); now (v2) those
> >> >changes are not included. So are .s files even being built as
> >> >micromips at all? If not, why is the above needed? If so, how do the files
> >with delay slots work?
> >>
> >> Branch delay slots are removed (called as compact instructions) in the
> >> newer MIPS/microMIPS cores (in development).
> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
> >> Assembler takes care of converting a BRANCH + NOP to its appropriate
> >> compact instruction (BEQ + NOP to BEQC).
> >> With the v1 branch I was trying to create generic hand-written
> >> assembly which can be used for newer cores with the compact
> >> instructions.
> >> However I realized that it would appropriate to create a new arch
> >> instead of creating generic assembly.
> >> Thus in v2 branch I modified only those functions which would create
> >> issues when compiled with interlinking on.
> >
> >Based on the discussions so far, I don't think pure-micromips qualifies as a
> >new arch. If it would be possible to take a program compiled as micromips-
> >only, and run it with the libc.so/ldso built for plain mips on a machine that
> >supports both forms of code, then it's not a separate arch, and as I
> >understand it this should be possible.
> 
> Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch.
> 
> >Rich
> 
> I will create v3 if you are OK with this approach.

OK. Can you factor it as one patch that's the minimal needed to make
the .c files (including ones that include the crt_arch.h/reloc.h asm
code) build correctly in micromips mode, which should be quick to
review/accept, and a second (if you want to do this phase now; if not
you can leave it til later) that makes the .s files
micromips-compatible?

Rich

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>Sent: 25 April 2017 PM 10:23
>To: Jaydeep Patil
>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
>> > But syscall_cp.s needs some care because saved instruction pointer
>> >values are compared against these labels. In micromips mode, do the
>> >labels evaluate with the +1 low bit offset?
>>
>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However I
>> don't see any issue with following comparison
>>
>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
>>
>> The ISA bit will be set even for PC in the saved context.
>
>Agreed, I think it should work as expected.
>
>> >> >> diff --git a/src/thread/mips/syscall_cp.s
>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
>> >> >> --- a/src/thread/mips/syscall_cp.s
>> >> >> +++ b/src/thread/mips/syscall_cp.s
>> >> >> @@ -1,5 +1,5 @@
>> >> >>  .set    noreorder
>> >> >> -
>> >> >> +.set    nomicromips
>> >> >>  .global __cp_begin
>> >> >>  .hidden __cp_begin
>> >> >>  .type   __cp_begin,@function
>> >> >
>> >> >I'm also unclear on the motivation of this one. Before (v1) you
>> >> >had a lot of changes to replace .s files with something
>> >> >micromips-compatible (removing branch delay slots); now (v2) those
>> >> >changes are not included. So are .s files even being built as
>> >> >micromips at all? If not, why is the above needed? If so, how do
>> >> >the files
>> >with delay slots work?
>> >>
>> >> Branch delay slots are removed (called as compact instructions) in
>> >> the newer MIPS/microMIPS cores (in development).
>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
>> >> Assembler takes care of converting a BRANCH + NOP to its
>> >> appropriate compact instruction (BEQ + NOP to BEQC).
>> >> With the v1 branch I was trying to create generic hand-written
>> >> assembly which can be used for newer cores with the compact
>> >> instructions.
>> >> However I realized that it would appropriate to create a new arch
>> >> instead of creating generic assembly.
>> >> Thus in v2 branch I modified only those functions which would
>> >> create issues when compiled with interlinking on.
>> >
>> >Based on the discussions so far, I don't think pure-micromips
>> >qualifies as a new arch. If it would be possible to take a program
>> >compiled as micromips- only, and run it with the libc.so/ldso built
>> >for plain mips on a machine that supports both forms of code, then
>> >it's not a separate arch, and as I understand it this should be possible.
>>
>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch.
>>
>> >Rich
>>
>> I will create v3 if you are OK with this approach.
>
>OK. Can you factor it as one patch that's the minimal needed to make the .c
>files (including ones that include the crt_arch.h/reloc.h asm
>code) build correctly in micromips mode, which should be quick to
>review/accept, and a second (if you want to do this phase now; if not you can
>leave it til later) that makes the .s files micromips-compatible?

Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 for changes (also attached as a patch). 
I will push a separate patch to make .s file microMIPS-only compatible.

>Rich

Thanks,
Jaydeep


[-- Attachment #2: microMIPS_32R2_v3.patch --]
[-- Type: application/octet-stream, Size: 1866 bytes --]

diff --git a/arch/mips/crt_arch.h b/arch/mips/crt_arch.h
index 9fc50d7..a7ba0e6 100644
--- a/arch/mips/crt_arch.h
+++ b/arch/mips/crt_arch.h
@@ -8,6 +8,7 @@ __asm__(
 ".type   " START ", @function\n"
 "_" START ":\n"
 "" START ":\n"
+"	.align 2 \n"
 "	bal 1f \n"
 "	 move $fp, $0 \n"
 "	.gpword . \n"
@@ -15,7 +16,8 @@ __asm__(
 ".weak _DYNAMIC \n"
 ".hidden _DYNAMIC \n"
 "	.gpword _DYNAMIC \n"
-"1:	lw $gp, 0($ra) \n"
+"1:	ins $ra, $0, 0, 1 \n"
+"	lw $gp, 0($ra) \n"
 "	subu $gp, $ra, $gp \n"
 "	move $4, $sp \n"
 "	lw $5, 8($ra) \n"
diff --git a/arch/mips/reloc.h b/arch/mips/reloc.h
index b3d59a4..772b3aa 100644
--- a/arch/mips/reloc.h
+++ b/arch/mips/reloc.h
@@ -36,15 +36,23 @@
 #define CRTJMP(pc,sp) __asm__ __volatile__( \
 	"move $sp,%1 ; jr %0" : : "r"(pc), "r"(sp) : "memory" )
 
+/*
+ * When compiled for microMIPS, .align makes sure that .gpword
+ * is placed at word boundary. $ra must point to first .gpword.
+ * ISA bit of $ra must be cleared for microMIPS before using it
+ * as a base address. For MIPS, ISA bit is always zero.
+*/
 #define GETFUNCSYM(fp, sym, got) __asm__ ( \
 	".hidden " #sym "\n" \
 	".set push \n" \
 	".set noreorder \n" \
+	"	.align 2 \n" \
 	"	bal 1f \n" \
 	"	 nop \n" \
 	"	.gpword . \n" \
 	"	.gpword " #sym " \n" \
-	"1:	lw %0, ($ra) \n" \
+	"1:	ins $ra, $0, 0, 1 \n" \
+	"	lw %0, ($ra) \n" \
 	"	subu %0, $ra, %0 \n" \
 	"	lw $ra, 4($ra) \n" \
 	"	addu %0, %0, $ra \n" \
diff --git a/src/thread/mips/syscall_cp.s b/src/thread/mips/syscall_cp.s
index d284626..c648cc4 100644
--- a/src/thread/mips/syscall_cp.s
+++ b/src/thread/mips/syscall_cp.s
@@ -41,11 +41,13 @@ __cp_end:
 
 __cp_cancel:
 	move    $2, $ra
+	.align	2
 	bal     1f
 	addu    $sp, $sp, 32
 	.gpword .
 	.gpword __cancel
-1:	lw      $3, ($ra)
+1:	ins $ra, $0, 0, 1
+	lw      $3, ($ra)
 	subu    $3, $ra, $3
 	lw      $25, 4($ra)
 	addu    $25, $25, $3

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Rich,

Could you please find some time to review https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch?

Thanks,
Jaydeep

>-----Original Message-----
>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>Sent: 26 April 2017 PM 12:44
>To: Rich Felker
>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>
>>-----Original Message-----
>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>>Sent: 25 April 2017 PM 10:23
>>To: Jaydeep Patil
>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>>
>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
>>> > But syscall_cp.s needs some care because saved instruction pointer
>>> >values are compared against these labels. In micromips mode, do the
>>> >labels evaluate with the +1 low bit offset?
>>>
>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However
>>> I don't see any issue with following comparison
>>>
>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
>>>
>>> The ISA bit will be set even for PC in the saved context.
>>
>>Agreed, I think it should work as expected.
>>
>>> >> >> diff --git a/src/thread/mips/syscall_cp.s
>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
>>> >> >> --- a/src/thread/mips/syscall_cp.s
>>> >> >> +++ b/src/thread/mips/syscall_cp.s
>>> >> >> @@ -1,5 +1,5 @@
>>> >> >>  .set    noreorder
>>> >> >> -
>>> >> >> +.set    nomicromips
>>> >> >>  .global __cp_begin
>>> >> >>  .hidden __cp_begin
>>> >> >>  .type   __cp_begin,@function
>>> >> >
>>> >> >I'm also unclear on the motivation of this one. Before (v1) you
>>> >> >had a lot of changes to replace .s files with something
>>> >> >micromips-compatible (removing branch delay slots); now (v2)
>>> >> >those changes are not included. So are .s files even being built
>>> >> >as micromips at all? If not, why is the above needed? If so, how
>>> >> >do the files
>>> >with delay slots work?
>>> >>
>>> >> Branch delay slots are removed (called as compact instructions) in
>>> >> the newer MIPS/microMIPS cores (in development).
>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
>>> >> Assembler takes care of converting a BRANCH + NOP to its
>>> >> appropriate compact instruction (BEQ + NOP to BEQC).
>>> >> With the v1 branch I was trying to create generic hand-written
>>> >> assembly which can be used for newer cores with the compact
>>> >> instructions.
>>> >> However I realized that it would appropriate to create a new arch
>>> >> instead of creating generic assembly.
>>> >> Thus in v2 branch I modified only those functions which would
>>> >> create issues when compiled with interlinking on.
>>> >
>>> >Based on the discussions so far, I don't think pure-micromips
>>> >qualifies as a new arch. If it would be possible to take a program
>>> >compiled as micromips- only, and run it with the libc.so/ldso built
>>> >for plain mips on a machine that supports both forms of code, then
>>> >it's not a separate arch, and as I understand it this should be possible.
>>>
>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new arch.
>>>
>>> >Rich
>>>
>>> I will create v3 if you are OK with this approach.
>>
>>OK. Can you factor it as one patch that's the minimal needed to make
>>the .c files (including ones that include the crt_arch.h/reloc.h asm
>>code) build correctly in micromips mode, which should be quick to
>>review/accept, and a second (if you want to do this phase now; if not
>>you can leave it til later) that makes the .s files micromips-compatible?
>
>Please refer to https://github.com/JaydeepIMG/musl-
>1/tree/micromips32r2_v3 for changes (also attached as a patch).
>I will push a separate patch to make .s file microMIPS-only compatible.
>
>>Rich
>
>Thanks,
>Jaydeep

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Rich,

Could you please find some time to review
https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch ?

Thanks,
Jaydeep

>-----Original Message-----
>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>Sent: 11 May 2017 AM 08:56
>To: musl@lists.openwall.com; Rich Felker
>Cc: Szabolcs Nagy; Andre McCurdy
>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>
>Hi Rich,
>
>Could you please find some time to review
>https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch?
>
>Thanks,
>Jaydeep
>
>>-----Original Message-----
>>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>>Sent: 26 April 2017 PM 12:44
>>To: Rich Felker
>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>>
>>>-----Original Message-----
>>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>>>Sent: 25 April 2017 PM 10:23
>>>To: Jaydeep Patil
>>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>>>
>>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
>>>> > But syscall_cp.s needs some care because saved instruction pointer
>>>> >values are compared against these labels. In micromips mode, do the
>>>> >labels evaluate with the +1 low bit offset?
>>>>
>>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However
>>>> I don't see any issue with following comparison
>>>>
>>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
>>>>
>>>> The ISA bit will be set even for PC in the saved context.
>>>
>>>Agreed, I think it should work as expected.
>>>
>>>> >> >> diff --git a/src/thread/mips/syscall_cp.s
>>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
>>>> >> >> --- a/src/thread/mips/syscall_cp.s
>>>> >> >> +++ b/src/thread/mips/syscall_cp.s
>>>> >> >> @@ -1,5 +1,5 @@
>>>> >> >>  .set    noreorder
>>>> >> >> -
>>>> >> >> +.set    nomicromips
>>>> >> >>  .global __cp_begin
>>>> >> >>  .hidden __cp_begin
>>>> >> >>  .type   __cp_begin,@function
>>>> >> >
>>>> >> >I'm also unclear on the motivation of this one. Before (v1) you
>>>> >> >had a lot of changes to replace .s files with something
>>>> >> >micromips-compatible (removing branch delay slots); now (v2)
>>>> >> >those changes are not included. So are .s files even being built
>>>> >> >as micromips at all? If not, why is the above needed? If so, how
>>>> >> >do the files
>>>> >with delay slots work?
>>>> >>
>>>> >> Branch delay slots are removed (called as compact instructions)
>>>> >> in the newer MIPS/microMIPS cores (in development).
>>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
>>>> >> Assembler takes care of converting a BRANCH + NOP to its
>>>> >> appropriate compact instruction (BEQ + NOP to BEQC).
>>>> >> With the v1 branch I was trying to create generic hand-written
>>>> >> assembly which can be used for newer cores with the compact
>>>> >> instructions.
>>>> >> However I realized that it would appropriate to create a new arch
>>>> >> instead of creating generic assembly.
>>>> >> Thus in v2 branch I modified only those functions which would
>>>> >> create issues when compiled with interlinking on.
>>>> >
>>>> >Based on the discussions so far, I don't think pure-micromips
>>>> >qualifies as a new arch. If it would be possible to take a program
>>>> >compiled as micromips- only, and run it with the libc.so/ldso built
>>>> >for plain mips on a machine that supports both forms of code, then
>>>> >it's not a separate arch, and as I understand it this should be possible.
>>>>
>>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new
>arch.
>>>>
>>>> >Rich
>>>>
>>>> I will create v3 if you are OK with this approach.
>>>
>>>OK. Can you factor it as one patch that's the minimal needed to make
>>>the .c files (including ones that include the crt_arch.h/reloc.h asm
>>>code) build correctly in micromips mode, which should be quick to
>>>review/accept, and a second (if you want to do this phase now; if not
>>>you can leave it til later) that makes the .s files micromips-compatible?
>>
>>Please refer to https://github.com/JaydeepIMG/musl-
>>1/tree/micromips32r2_v3 for changes (also attached as a patch).
>>I will push a separate patch to make .s file microMIPS-only compatible.
>>
>>>Rich
>>
>>Thanks,
>>Jaydeep

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Rich,

Could you please find some time to review this?

Thanks,
Jaydeep

>-----Original Message-----
>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>Sent: 11 May 2017 AM 08:56
>To: musl@lists.openwall.com; Rich Felker
>Cc: Szabolcs Nagy; Andre McCurdy
>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>
>Hi Rich,
>
>Could you please find some time to review
>https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch?
>
>Thanks,
>Jaydeep
>
>>-----Original Message-----
>>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>>Sent: 26 April 2017 PM 12:44
>>To: Rich Felker
>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>>
>>>-----Original Message-----
>>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>>>Sent: 25 April 2017 PM 10:23
>>>To: Jaydeep Patil
>>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>>>
>>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
>>>> > But syscall_cp.s needs some care because saved instruction pointer
>>>> >values are compared against these labels. In micromips mode, do the
>>>> >labels evaluate with the +1 low bit offset?
>>>>
>>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However
>>>> I don't see any issue with following comparison
>>>>
>>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
>>>>
>>>> The ISA bit will be set even for PC in the saved context.
>>>
>>>Agreed, I think it should work as expected.
>>>
>>>> >> >> diff --git a/src/thread/mips/syscall_cp.s
>>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
>>>> >> >> --- a/src/thread/mips/syscall_cp.s
>>>> >> >> +++ b/src/thread/mips/syscall_cp.s
>>>> >> >> @@ -1,5 +1,5 @@
>>>> >> >>  .set    noreorder
>>>> >> >> -
>>>> >> >> +.set    nomicromips
>>>> >> >>  .global __cp_begin
>>>> >> >>  .hidden __cp_begin
>>>> >> >>  .type   __cp_begin,@function
>>>> >> >
>>>> >> >I'm also unclear on the motivation of this one. Before (v1) you
>>>> >> >had a lot of changes to replace .s files with something
>>>> >> >micromips-compatible (removing branch delay slots); now (v2)
>>>> >> >those changes are not included. So are .s files even being built
>>>> >> >as micromips at all? If not, why is the above needed? If so, how
>>>> >> >do the files
>>>> >with delay slots work?
>>>> >>
>>>> >> Branch delay slots are removed (called as compact instructions)
>>>> >> in the newer MIPS/microMIPS cores (in development).
>>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot.
>>>> >> Assembler takes care of converting a BRANCH + NOP to its
>>>> >> appropriate compact instruction (BEQ + NOP to BEQC).
>>>> >> With the v1 branch I was trying to create generic hand-written
>>>> >> assembly which can be used for newer cores with the compact
>>>> >> instructions.
>>>> >> However I realized that it would appropriate to create a new arch
>>>> >> instead of creating generic assembly.
>>>> >> Thus in v2 branch I modified only those functions which would
>>>> >> create issues when compiled with interlinking on.
>>>> >
>>>> >Based on the discussions so far, I don't think pure-micromips
>>>> >qualifies as a new arch. If it would be possible to take a program
>>>> >compiled as micromips- only, and run it with the libc.so/ldso built
>>>> >for plain mips on a machine that supports both forms of code, then
>>>> >it's not a separate arch, and as I understand it this should be possible.
>>>>
>>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new
>arch.
>>>>
>>>> >Rich
>>>>
>>>> I will create v3 if you are OK with this approach.
>>>
>>>OK. Can you factor it as one patch that's the minimal needed to make
>>>the .c files (including ones that include the crt_arch.h/reloc.h asm
>>>code) build correctly in micromips mode, which should be quick to
>>>review/accept, and a second (if you want to do this phase now; if not
>>>you can leave it til later) that makes the .s files micromips-compatible?
>>
>>Please refer to https://github.com/JaydeepIMG/musl-
>>1/tree/micromips32r2_v3 for changes (also attached as a patch).
>>I will push a separate patch to make .s file microMIPS-only compatible.
>>
>>>Rich
>>
>>Thanks,
>>Jaydeep

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote:
> Hi Rich,
> 
> Could you please find some time to review this?

I'm trying to catch up now. Sorry I've been behind on this.

Rich

> >-----Original Message-----
> >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
> >Sent: 11 May 2017 AM 08:56
> >To: musl@lists.openwall.com; Rich Felker
> >Cc: Szabolcs Nagy; Andre McCurdy
> >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
> >
> >Hi Rich,
> >
> >Could you please find some time to review
> >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch?
> >
> >Thanks,
> >Jaydeep
> >
> >>-----Original Message-----
> >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
> >>Sent: 26 April 2017 PM 12:44
> >>To: Rich Felker
> >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
> >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
> >>
> >>>-----Original Message-----
> >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
> >>>Sent: 25 April 2017 PM 10:23
> >>>To: Jaydeep Patil
> >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
> >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
> >>>
> >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
> >>>> > But syscall_cp.s needs some care because saved instruction pointer
> >>>> >values are compared against these labels. In micromips mode, do the
> >>>> >labels evaluate with the +1 low bit offset?
> >>>>
> >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However
> >>>> I don't see any issue with following comparison
> >>>>
> >>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
> >>>>
> >>>> The ISA bit will be set even for PC in the saved context.
> >>>
> >>>Agreed, I think it should work as expected.
> >>>
> >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s
> >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
> >>>> >> >> --- a/src/thread/mips/syscall_cp.s
> >>>> >> >> +++ b/src/thread/mips/syscall_cp.s
> >>>> >> >> @@ -1,5 +1,5 @@
> >>>> >> >>  .set    noreorder
> >>>> >> >> -
> >>>> >> >> +.set    nomicromips
> >>>> >> >>  .global __cp_begin
> >>>> >> >>  .hidden __cp_begin
> >>>> >> >>  .type   __cp_begin,@function
> >>>> >> >
> >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you
> >>>> >> >had a lot of changes to replace .s files with something
> >>>> >> >micromips-compatible (removing branch delay slots); now (v2)
> >>>> >> >those changes are not included. So are .s files even being built
> >>>> >> >as micromips at all? If not, why is the above needed? If so, how
> >>>> >> >do the files
> >>>> >with delay slots work?
> >>>> >>
> >>>> >> Branch delay slots are removed (called as compact instructions)
> >>>> >> in the newer MIPS/microMIPS cores (in development).
> >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot..
> >>>> >> Assembler takes care of converting a BRANCH + NOP to its
> >>>> >> appropriate compact instruction (BEQ + NOP to BEQC).
> >>>> >> With the v1 branch I was trying to create generic hand-written
> >>>> >> assembly which can be used for newer cores with the compact
> >>>> >> instructions.
> >>>> >> However I realized that it would appropriate to create a new arch
> >>>> >> instead of creating generic assembly.
> >>>> >> Thus in v2 branch I modified only those functions which would
> >>>> >> create issues when compiled with interlinking on.
> >>>> >
> >>>> >Based on the discussions so far, I don't think pure-micromips
> >>>> >qualifies as a new arch. If it would be possible to take a program
> >>>> >compiled as micromips- only, and run it with the libc.so/ldso built
> >>>> >for plain mips on a machine that supports both forms of code, then
> >>>> >it's not a separate arch, and as I understand it this should be possible.
> >>>>
> >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new
> >arch.
> >>>>
> >>>> >Rich
> >>>>
> >>>> I will create v3 if you are OK with this approach.
> >>>
> >>>OK. Can you factor it as one patch that's the minimal needed to make
> >>>the .c files (including ones that include the crt_arch.h/reloc.h asm
> >>>code) build correctly in micromips mode, which should be quick to
> >>>review/accept, and a second (if you want to do this phase now; if not
> >>>you can leave it til later) that makes the .s files micromips-compatible?
> >>
> >>Please refer to https://github.com/JaydeepIMG/musl-
> >>1/tree/micromips32r2_v3 for changes (also attached as a patch).
> >>I will push a separate patch to make .s file microMIPS-only compatible.
> >>
> >>>Rich
> >>
> >>Thanks,
> >>Jaydeep

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Sat, May 27, 2017 at 10:00:57PM -0400, Rich Felker wrote:
> On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote:
> > Hi Rich,
> > 
> > Could you please find some time to review this?
> 
> I'm trying to catch up now. Sorry I've been behind on this.

OK. The only question I have is why the syscall_cp.s portion is needed
at this stage. As long as all .s files are built as plain mips still
(with support for building them as micromips to come in the future) it
looks like this change belongs as part of that future patch.

Rich


> > >-----Original Message-----
> > >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
> > >Sent: 11 May 2017 AM 08:56
> > >To: musl@lists.openwall.com; Rich Felker
> > >Cc: Szabolcs Nagy; Andre McCurdy
> > >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
> > >
> > >Hi Rich,
> > >
> > >Could you please find some time to review
> > >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3 branch?
> > >
> > >Thanks,
> > >Jaydeep
> > >
> > >>-----Original Message-----
> > >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
> > >>Sent: 26 April 2017 PM 12:44
> > >>To: Rich Felker
> > >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
> > >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
> > >>
> > >>>-----Original Message-----
> > >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
> > >>>Sent: 25 April 2017 PM 10:23
> > >>>To: Jaydeep Patil
> > >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
> > >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
> > >>>
> > >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
> > >>>> > But syscall_cp.s needs some care because saved instruction pointer
> > >>>> >values are compared against these labels. In micromips mode, do the
> > >>>> >labels evaluate with the +1 low bit offset?
> > >>>>
> > >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels. However
> > >>>> I don't see any issue with following comparison
> > >>>>
> > >>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
> > >>>>
> > >>>> The ISA bit will be set even for PC in the saved context.
> > >>>
> > >>>Agreed, I think it should work as expected.
> > >>>
> > >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s
> > >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e 100644
> > >>>> >> >> --- a/src/thread/mips/syscall_cp.s
> > >>>> >> >> +++ b/src/thread/mips/syscall_cp.s
> > >>>> >> >> @@ -1,5 +1,5 @@
> > >>>> >> >>  .set    noreorder
> > >>>> >> >> -
> > >>>> >> >> +.set    nomicromips
> > >>>> >> >>  .global __cp_begin
> > >>>> >> >>  .hidden __cp_begin
> > >>>> >> >>  .type   __cp_begin,@function
> > >>>> >> >
> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1) you
> > >>>> >> >had a lot of changes to replace .s files with something
> > >>>> >> >micromips-compatible (removing branch delay slots); now (v2)
> > >>>> >> >those changes are not included. So are .s files even being built
> > >>>> >> >as micromips at all? If not, why is the above needed? If so, how
> > >>>> >> >do the files
> > >>>> >with delay slots work?
> > >>>> >>
> > >>>> >> Branch delay slots are removed (called as compact instructions)
> > >>>> >> in the newer MIPS/microMIPS cores (in development).
> > >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay slot..
> > >>>> >> Assembler takes care of converting a BRANCH + NOP to its
> > >>>> >> appropriate compact instruction (BEQ + NOP to BEQC).
> > >>>> >> With the v1 branch I was trying to create generic hand-written
> > >>>> >> assembly which can be used for newer cores with the compact
> > >>>> >> instructions.
> > >>>> >> However I realized that it would appropriate to create a new arch
> > >>>> >> instead of creating generic assembly.
> > >>>> >> Thus in v2 branch I modified only those functions which would
> > >>>> >> create issues when compiled with interlinking on.
> > >>>> >
> > >>>> >Based on the discussions so far, I don't think pure-micromips
> > >>>> >qualifies as a new arch. If it would be possible to take a program
> > >>>> >compiled as micromips- only, and run it with the libc.so/ldso built
> > >>>> >for plain mips on a machine that supports both forms of code, then
> > >>>> >it's not a separate arch, and as I understand it this should be possible.
> > >>>>
> > >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a new
> > >arch.
> > >>>>
> > >>>> >Rich
> > >>>>
> > >>>> I will create v3 if you are OK with this approach.
> > >>>
> > >>>OK. Can you factor it as one patch that's the minimal needed to make
> > >>>the .c files (including ones that include the crt_arch.h/reloc.h asm
> > >>>code) build correctly in micromips mode, which should be quick to
> > >>>review/accept, and a second (if you want to do this phase now; if not
> > >>>you can leave it til later) that makes the .s files micromips-compatible?
> > >>
> > >>Please refer to https://github.com/JaydeepIMG/musl-
> > >>1/tree/micromips32r2_v3 for changes (also attached as a patch).
> > >>I will push a separate patch to make .s file microMIPS-only compatible.
> > >>
> > >>>Rich
> > >>
> > >>Thanks,
> > >>Jaydeep

RE: [MUSL] microMIPS32R2 O32 port

[Jaydeep Patil]

Hi Rich,

In the previous version of this patch (micromips32r2_v2), I had suggested to build the .s files as pure MIPS code (using ".set nomicromips" directive).
However change in reloc.h is still required as it could be inlined in a micromips function.

Please refer to https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v2 instead. 

Thanks,
Jaydeep

>-----Original Message-----
>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
>Sent: 31 May 2017 PM 06:42
>To: musl@lists.openwall.com
>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>
>On Sat, May 27, 2017 at 10:00:57PM -0400, Rich Felker wrote:
>> On Fri, May 26, 2017 at 03:46:49AM +0000, Jaydeep Patil wrote:
>> > Hi Rich,
>> >
>> > Could you please find some time to review this?
>>
>> I'm trying to catch up now. Sorry I've been behind on this.
>
>OK. The only question I have is why the syscall_cp.s portion is needed at this
>stage. As long as all .s files are built as plain mips still (with support for building
>them as micromips to come in the future) it looks like this change belongs as
>part of that future patch.
>
>Rich
>
>
>> > >-----Original Message-----
>> > >From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>> > >Sent: 11 May 2017 AM 08:56
>> > >To: musl@lists.openwall.com; Rich Felker
>> > >Cc: Szabolcs Nagy; Andre McCurdy
>> > >Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>> > >
>> > >Hi Rich,
>> > >
>> > >Could you please find some time to review
>> > >https://github.com/JaydeepIMG/musl-1/tree/micromips32r2_v3
>branch?
>> > >
>> > >Thanks,
>> > >Jaydeep
>> > >
>> > >>-----Original Message-----
>> > >>From: Jaydeep Patil [mailto:Jaydeep.Patil@imgtec.com]
>> > >>Sent: 26 April 2017 PM 12:44
>> > >>To: Rich Felker
>> > >>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>> > >>Subject: RE: [musl] [MUSL] microMIPS32R2 O32 port
>> > >>
>> > >>>-----Original Message-----
>> > >>>From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich
>> > >>>Felker
>> > >>>Sent: 25 April 2017 PM 10:23
>> > >>>To: Jaydeep Patil
>> > >>>Cc: Szabolcs Nagy; musl@lists.openwall.com; Andre McCurdy
>> > >>>Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
>> > >>>
>> > >>>On Tue, Apr 25, 2017 at 04:45:29AM +0000, Jaydeep Patil wrote:
>> > >>>> > But syscall_cp.s needs some care because saved instruction
>> > >>>> >pointer values are compared against these labels. In micromips
>> > >>>> >mode, do the labels evaluate with the +1 low bit offset?
>> > >>>>
>> > >>>> Yes, in microMIPS mode, ISA bit (0th bit) is set for labels.
>> > >>>> However I don't see any issue with following comparison
>> > >>>>
>> > >>>> pc >= (uintptr_t)__cp_begin && pc < (uintptr_t)__cp_end
>> > >>>>
>> > >>>> The ISA bit will be set even for PC in the saved context.
>> > >>>
>> > >>>Agreed, I think it should work as expected.
>> > >>>
>> > >>>> >> >> diff --git a/src/thread/mips/syscall_cp.s
>> > >>>> >> >> b/src/thread/mips/syscall_cp.s index d284626..9c5f55e
>> > >>>> >> >> 100644
>> > >>>> >> >> --- a/src/thread/mips/syscall_cp.s
>> > >>>> >> >> +++ b/src/thread/mips/syscall_cp.s
>> > >>>> >> >> @@ -1,5 +1,5 @@
>> > >>>> >> >>  .set    noreorder
>> > >>>> >> >> -
>> > >>>> >> >> +.set    nomicromips
>> > >>>> >> >>  .global __cp_begin
>> > >>>> >> >>  .hidden __cp_begin
>> > >>>> >> >>  .type   __cp_begin,@function
>> > >>>> >> >
>> > >>>> >> >I'm also unclear on the motivation of this one. Before (v1)
>> > >>>> >> >you had a lot of changes to replace .s files with something
>> > >>>> >> >micromips-compatible (removing branch delay slots); now
>> > >>>> >> >(v2) those changes are not included. So are .s files even
>> > >>>> >> >being built as micromips at all? If not, why is the above
>> > >>>> >> >needed? If so, how do the files
>> > >>>> >with delay slots work?
>> > >>>> >>
>> > >>>> >> Branch delay slots are removed (called as compact
>> > >>>> >> instructions) in the newer MIPS/microMIPS cores (in
>development).
>> > >>>> >> The MIPS/microMIPS R2-R6 still support instructions with delay
>slot..
>> > >>>> >> Assembler takes care of converting a BRANCH + NOP to its
>> > >>>> >> appropriate compact instruction (BEQ + NOP to BEQC).
>> > >>>> >> With the v1 branch I was trying to create generic
>> > >>>> >> hand-written assembly which can be used for newer cores with
>> > >>>> >> the compact instructions.
>> > >>>> >> However I realized that it would appropriate to create a new
>> > >>>> >> arch instead of creating generic assembly.
>> > >>>> >> Thus in v2 branch I modified only those functions which
>> > >>>> >> would create issues when compiled with interlinking on.
>> > >>>> >
>> > >>>> >Based on the discussions so far, I don't think pure-micromips
>> > >>>> >qualifies as a new arch. If it would be possible to take a
>> > >>>> >program compiled as micromips- only, and run it with the
>> > >>>> >libc.so/ldso built for plain mips on a machine that supports
>> > >>>> >both forms of code, then it's not a separate arch, and as I
>understand it this should be possible.
>> > >>>>
>> > >>>> Yes, in the context of miroMIPSR2-R5, we don't need to create a
>> > >>>> new
>> > >arch.
>> > >>>>
>> > >>>> >Rich
>> > >>>>
>> > >>>> I will create v3 if you are OK with this approach.
>> > >>>
>> > >>>OK. Can you factor it as one patch that's the minimal needed to
>> > >>>make the .c files (including ones that include the
>> > >>>crt_arch.h/reloc.h asm
>> > >>>code) build correctly in micromips mode, which should be quick to
>> > >>>review/accept, and a second (if you want to do this phase now; if
>> > >>>not you can leave it til later) that makes the .s files micromips-
>compatible?
>> > >>
>> > >>Please refer to https://github.com/JaydeepIMG/musl-
>> > >>1/tree/micromips32r2_v3 for changes (also attached as a patch).
>> > >>I will push a separate patch to make .s file microMIPS-only compatible.
>> > >>
>> > >>>Rich
>> > >>
>> > >>Thanks,
>> > >>Jaydeep

Re: [MUSL] microMIPS32R2 O32 port

[Rich Felker]

On Thu, Apr 13, 2017 at 04:29:10AM +0000, Jaydeep Patil wrote:
> Hi,
> 
> With this branch (micromips32r2_v2) we are supporting microMIPS
> cores that co-exist with MIPS. The MUSL library must be built with
> -minterlink-compressed option as there are couple of hand-written
> MIPS only functions. For microMIPS only cores we will create a
> different subarch.

I don't think there's any indication yet that a different subarch is
appropriate for micromips-only cores. This would only be the case if
they are somehow ABI-incompatible with normal mips. If it would be
possible to run binaries that were built for micromips only on a cpu
core that supports both, using a libc.so that was built either for
plain mips or micromips or a mix, then for our purposes it's the same
arch, just a different ISA level/profile.

Rich


> >-----Original Message-----
> >From: Andre McCurdy [mailto:armccurdy@gmail.com]
> >Sent: 13 April 2017 AM 03:17
> >To: musl@lists.openwall.com
> >Cc: Jaydeep Patil
> >Subject: Re: [musl] [MUSL] microMIPS32R2 O32 port
> >
> >On Wed, Apr 12, 2017 at 1:27 PM, Rich Felker <dalias@libc.org> wrote:
> >> On Wed, Apr 12, 2017 at 09:25:35PM +0200, Szabolcs Nagy wrote:
> >>> * Jaydeep Patil <Jaydeep.Patil@imgtec.com> [2017-04-12 11:54:10 +0000]:
> >>> > Hi Rich,
> >>> >
> >>> > We can reuse existing MIPS code for microMIPS. There are places where
> >we read from $ra must be compiled for MIPS.
> >>> > Please refer to https://github.com/JaydeepIMG/musl-
> >1/tree/micromips32r2_v2 for modifications.
> >>> >
> >>>
> >>> is micromips a different encoding for mips instructions that works on
> >>> some cpus but not others?
> >>
> >> Yes, it's something like thumb or thumb2 on arm, or the riscv
> >> compressed isa. What I'm not clear on is whether there are
> >> micromips-only cpu models that can't execute normal mips.
> >
> >According to:
> >
> >  https://imagination-technologies-cloudfront-
> >assets.s3.amazonaws.com/documentation/MIPS_Architecture_microMIPS32
> >_InstructionSet_AFP_P_MD00582_06.04.pdf
> >
> >"microMIPS is also an alternative to the MIPS® instruction encoding and can
> >be implemented in parallel or stand-alone."
> >
> >"If only one ISA mode exists (either MIPS or microMIPS) then this mode
> >switch mechanism does not exist"
> >
> >> If so we probably need the ability to build musl as micromips, but as
> >> long as cpus which support both support interworking (calls between
> >> the two type of code in the same process) reasonably, I don't think
> >> there's any reason to consider it a different subarch.
> >>
> >> If not (that is, if all cpus that support micromips also support the
> >> normal mips isa) then I fail to see why there's any need to compile
> >> musl's asm files as micromips. They're not size or performance
> >> bottlenecks.
> >>
> >> Rich