From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Stafford Horne <shorne@gmail.com>
Cc: GDB patches <gdb-patches@sourceware.org>,
GNU Binutils <binutils@sourceware.org>,
Andrey Bacherov <bandvig@mail.ru>,
Openrisc <openrisc@lists.librecores.org>
Subject: Re: [PATCH v2 5/6] sim/or1k: Add test for 64-bit fpu operations
Date: Sat, 13 Apr 2019 21:36:00 -0000 [thread overview]
Message-ID: <20190413213606.GI2737@embecosm.com> (raw)
In-Reply-To: <20190409213925.32699-6-shorne@gmail.com>
* Stafford Horne <shorne@gmail.com> [2019-04-10 06:39:24 +0900]:
> This is a very basic test but it ensure the machine is wired up
> correctly and that the assembler works.
>
> sim/testsuite/sim/or1k/ChangeLog:
>
> * fpu64a32.S: New file.
This is fine.
Thanks,
Andrew
> ---
> sim/testsuite/sim/or1k/fpu64a32.S | 172 ++++++++++++++++++++++++++++++
> 1 file changed, 172 insertions(+)
> create mode 100644 sim/testsuite/sim/or1k/fpu64a32.S
>
> diff --git a/sim/testsuite/sim/or1k/fpu64a32.S b/sim/testsuite/sim/or1k/fpu64a32.S
> new file mode 100644
> index 0000000000..6c40170854
> --- /dev/null
> +++ b/sim/testsuite/sim/or1k/fpu64a32.S
> @@ -0,0 +1,172 @@
> +/* Tests some basic fpu instructions.
> +
> + Copyright (C) 2017-2019 Free Software Foundation, Inc.
> +
> + This program is free software; you can redistribute it and/or modify
> + it under the terms of the GNU General Public License as published by
> + the Free Software Foundation; either version 3 of the License, or
> + (at your option) any later version.
> +
> + This program is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + GNU General Public License for more details.
> +
> + You should have received a copy of the GNU General Public License
> + along with this program. If not, see <http://www.gnu.org/licenses/>. */
> +
> +# mach: or1k
> +# output: report(0x400921f9);\n
> +# output: report(0xf01b866e);\n
> +# output: report(0x4005bf09);\n
> +# output: report(0x95aaf790);\n
> +# output: report(0x00000000);\n
> +# output: report(0x00001234);\n
> +# output: \n
> +# output: report(0x40b23400);\n
> +# output: report(0x00000000);\n
> +# output: report(0x40b23400);\n
> +# output: report(0x00000000);\n
> +# output: \n
> +# output: report(0x40177081);\n
> +# output: report(0xc2e33eff);\n
> +# output: report(0x400921f9);\n
> +# output: report(0xf01b866e);\n
> +# output: \n
> +# output: report(0x40211456);\n
> +# output: report(0x587dfabf);\n
> +# output: report(0x400921f9);\n
> +# output: report(0xf01b866d);\n
> +# output: \n
> +# output: report(0x00000001);\n
> +# output: \n
> +# output: WARNING: ignoring fpu error caught in fast mode.\n
> +# output: report(0x00000000);\n
> +# output: \n
> +# output: exit(0)\n
> +
> +#include "or1k-asm-test-helpers.h"
> +
> + STANDARD_TEST_ENVIRONMENT
> +
> + .section .exception_vectors
> +
> + /* Floating point exception. */
> + .org 0xd00
> +
> + /* The handling is a bit dubious at present. We just patch the
> + instruction with l.nop and restart. This will go wrong in branch
> + delay slots. But we don't have those in this test. */
> + l.addi r1, r1, -EXCEPTION_STACK_SKIP_SIZE
> + PUSH r2
> + PUSH r3
> + /* Save the address of the instruction that caused the problem. */
> + MOVE_FROM_SPR r2, SPR_EPCR_BASE
> + LOAD_IMMEDIATE r3, 0x15000000 /* Opcode for l.nop */
> + l.sw -4(r2), r3
> + POP r3
> + POP r2
> + l.addi r1, r1, EXCEPTION_STACK_SKIP_SIZE
> + l.rfe
> +
> + .section .data
> + .align 4
> + .type pi, @object
> + .size pi, 8
> +anchor:
> +pi:
> + .double 3.14159
> +
> + .type e, @object
> + .size e, 8
> +e:
> + .double 2.71828
> +
> + .type large, @object
> + .size large, 8
> +large:
> + .long 0
> + .long 0x1234
> +
> + .section .text
> +start_tests:
> + PUSH LINK_REGISTER_R9
> +
> + /* Test lf.itof.d int to double conversion. Setting up:
> + * r11 pointer to data
> + * r12,r13 pi as double
> + * r14,r15 e as double
> + * r16,r17 a long long
> + */
> + l.ori r11, r0, ha(anchor)
> + l.addi r11, r11, lo(anchor)
> + l.lwz r12, 0(r11)
> + l.lwz r13, 4(r11)
> +
> + l.lwz r14, 8(r11)
> + l.lwz r15, 12(r11)
> +
> + l.lwz r16, 16(r11)
> + l.lwz r18, 20(r11)
> +
> + /* Output to ensure we loaded it correctly. */
> + REPORT_REG_TO_CONSOLE r12
> + REPORT_REG_TO_CONSOLE r13
> +
> + REPORT_REG_TO_CONSOLE r14
> + REPORT_REG_TO_CONSOLE r15
> +
> + REPORT_REG_TO_CONSOLE r16
> + REPORT_REG_TO_CONSOLE r18
> + PRINT_NEWLINE_TO_CONSOLE
> +
> + /* Convert the big long to a double. */
> + lf.itof.d r16, r16
> + REPORT_REG_TO_CONSOLE r16
> + REPORT_REG_TO_CONSOLE r18
> +
> + /* Convert the double back to a long, it should match before. */
> + lf.ftoi.d r16, r16
> + lf.itof.d r16, r16
> +
> + REPORT_REG_TO_CONSOLE r16
> + REPORT_REG_TO_CONSOLE r18
> +
> + PRINT_NEWLINE_TO_CONSOLE
> +
> + /* Add and subtract some double values. */
> + lf.add.d r12, r12, r14
> + REPORT_REG_TO_CONSOLE r12
> + REPORT_REG_TO_CONSOLE r13
> +
> + lf.sub.d r12, r12, r14
> + REPORT_REG_TO_CONSOLE r12
> + REPORT_REG_TO_CONSOLE r13
> + PRINT_NEWLINE_TO_CONSOLE
> +
> + /* Multiply and divide double values. */
> + lf.mul.d r12, r12, r14
> + REPORT_REG_TO_CONSOLE r12
> + REPORT_REG_TO_CONSOLE r13
> +
> + lf.div.d r12, r12, r14
> + REPORT_REG_TO_CONSOLE r12
> + REPORT_REG_TO_CONSOLE r13
> + PRINT_NEWLINE_TO_CONSOLE
> +
> + /* Test lf.sfge.s set flag if r6 >= r10. */
> + lf.sfge.d r12, r14
> + MOVE_FROM_SPR r2, SPR_SR
> + REPORT_BIT_TO_CONSOLE r2, SPR_SR_F
> + PRINT_NEWLINE_TO_CONSOLE
> +
> + /* Test raising an exception by dividing by 0. */
> + MOVE_FROM_SPR r2, SPR_FPCSR
> + l.ori r2, r2, 0x1
> + MOVE_TO_SPR SPR_FPCSR, r2
> +div0: lf.div.d r2, r12, r0
> + REPORT_EXCEPTION div0
> + PRINT_NEWLINE_TO_CONSOLE
> +
> + POP LINK_REGISTER_R9
> + RETURN_TO_LINK_REGISTER_R9
> --
> 2.19.1
>
next prev parent reply other threads:[~2019-04-13 21:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-09 21:39 [PATCH v2 0/6] OpenRISC orfpx64a32 support Stafford Horne
2019-04-09 21:39 ` [PATCH v2 4/6] sim/common: Wire in df/di conversion Stafford Horne
2019-04-13 21:59 ` Andrew Burgess
2019-04-09 21:39 ` [PATCH v2 1/6] cpu: Add support for orfp64a32 spec Stafford Horne
2019-04-09 21:40 ` [PATCH v2 6/6] sim/common: Fix issue with wrong byte order on BE targets Stafford Horne
2019-04-11 22:27 ` Andrew Burgess
2019-04-12 20:21 ` Stafford Horne
2019-04-13 21:30 ` Andrew Burgess
2019-04-09 21:40 ` [PATCH v2 2/6] opcodes: Regenerate opcodes for orfp64a32 spec Stafford Horne
2019-04-11 8:45 ` Nick Clifton
2019-04-09 21:40 ` [PATCH v2 5/6] sim/or1k: Add test for 64-bit fpu operations Stafford Horne
2019-04-13 21:36 ` Andrew Burgess [this message]
2019-04-09 21:40 ` [PATCH v2 3/6] sim/or1k: Regenerate sim for orfp64a32 spec Stafford Horne
2019-04-13 21:40 ` Andrew Burgess
2019-04-14 6:44 ` Stafford Horne
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=20190413213606.GI2737@embecosm.com \
--to=andrew.burgess@embecosm.com \
--cc=bandvig@mail.ru \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=openrisc@lists.librecores.org \
--cc=shorne@gmail.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 read-only IMAP folder(s) and NNTP newsgroup(s).