From: David Boddie <david@boddie.org.uk>
To: inferno-os@googlegroups.com
Cc: 9fans@9fans.net
Subject: [9fans] Thumb compiler oddity
Date: Sun, 24 Sep 2023 22:26:14 +0200 [thread overview]
Message-ID: <3345904.YYNtgTSHRZ@aurora> (raw)
I'm using the Inferno Thumb compiler, tc, to compile Inferno (unsurprisingly)
and encountered a problem. Since 9front appears to have the same compiler, I
thought that I should mention it on both 9fans and Inferno mailing lists.
The problem is with the libmath/fdlibm/e_exp.c when compiled using tc,
5c (arm), 0c (spim), and maybe others. The relevant chunk of code is the
first branch of this:
if(k >= -1021) {
__HI(y) += (k<<20); /* add k to y's exponent */
return y;
} else {
__HI(y) += ((k+1000)<<20);/* add k to y's exponent */
return y*twom1000;
}
where __HI is defined as
#define __HI(x) *(1+(int*)&x)
for little-endian doubles.
The code generated by tc for the k >= -1021 branch is this, which I've
annotated:
MOVD F0,F3 y
CMP $-1021,R4, compare k to -1021
BLT ,9(PC) k < -1021, skip past RET below
MOVW R4,R1
SLL $20,R1 k << 20
MOVW y-4(SP),R2 load the high word of y in memory
ADD R1,R2 add k << 20 to it
MOVW R2,y-4(SP) store the result back to memory
MOVD F3,F0 the unmodified y is the return value
RET ,
So, the compiler operates on the value in memory without updating the value
in register F3.
Turning off registerization results in this code instead:
MOVD F0,y-8(SP) update y in memory
MOVW k-44(SP),R1 load k
CMP $-1021,R1, compare k to -1021
BLT ,10(PC) k < -1021, skip past RET below
MOVW k-44(SP),R1
SLL $20,R1 k << 20
MOVW y-4(SP),R2 load the high word of y in memory
ADD R1,R2 add k << 20 to it
MOVW R2,y-4(SP) store the result back to memory
MOVD y-8(SP),F0 load the modified y to be returned
NOP ,R0
RET ,
Is the problem with the compiler or with the C code? Although I get the
feeling that the compiler should figure out that the value of y is being
modified, I don't know if it's being done in a valid way, or a way that
compilers are expected to handle.
It could be an endianness-related thing: vc appears to do the right thing.
Having said that, so does 8c, as far as I can tell.
Any thoughts?
David
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tf0ca316e4ef39fda-M6139e88f459a94c80f155e6b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
next reply other threads:[~2023-09-24 20:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-24 20:26 David Boddie [this message]
2023-09-27 12:32 ` Richard Miller
2023-10-01 21:17 David Boddie
2023-10-02 9:07 ` Richard Miller
2023-10-11 20:30 David Boddie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3345904.YYNtgTSHRZ@aurora \
--to=david@boddie.org.uk \
--cc=9fans@9fans.net \
--cc=inferno-os@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).