[OpenRISC] OR1K FPU Tools

* [OpenRISC] OR1K FPU Tools
       [not found]               ` <CAAfxs754kixej8d--PAuh-=idQ0Lt=_M=SqYqLGKSyjCVvG61w@mail.gmail.com>
@ 2018-12-18 22:52                 ` Stafford Horne
  2018-12-25 11:46                   ` BAndViG
  0 siblings, 1 reply; 10+ messages in thread
From: Stafford Horne @ 2018-12-18 22:52 UTC (permalink / raw)
  To: openrisc

(ccing the list, I want to let everyone know the fpu gcc/mor1kx development
status)

Hello

Just a quick update. I got the gdb simulator working.  There looks to be a
bug in the sim framework which too me a while to track down.  But now all
the basic c and assembly tests are working.

Now that it's working I'll start testing with your test bench.  After that
I'll have a look at getting it working on moracchino. Maybe on verilator
first since we need a good mor1kx regression testbed.

- Stafford

On Fri, Dec 14, 2018, 12:37 AM Stafford Horne <shorne@gmail.com wrote:

> Hello,
>
> Nevermind, I read through the mor1k maraschino code and could see you are
> using register pairs for the integer operands as well.
>
> Example:
> {rD,rD+n} = itof({rA,rA+n})
> {rD,rD+n} = ftoi({rA,rA+n})
>
>
> I needed to fix a bug in the sim and one in GCC and I am seeing better
> results but there are some issues.  Ill keep you posted on progress.
>
> -Stafford
>
>
>
> On Thu, Dec 13, 2018 at 6:37 PM Stafford Horne <shorne@gmail.com> wrote:
>
>> Hello,
>>
>> I have been able to get some simple floating point c code tests to work
>> in the sim.
>>
>> However, there seems to be and issue with the sim running the
>> mdouble-float code.  Question.
>>
>> What are the arguments on orfpx64a32 for instructions.
>>
>> lf.itof.d
>> lf.ftoi.d
>>
>> Are the i's meant to both be single 32bit registers or register pairs?
>>
>> Example
>>
>> {rD,rD+n} = itof(rA)
>> rD = ftoi({rA,rA+n})
>>
>> Is that correct? I think the sim has something different.
>>
>> -stafford
>>
>>
>>
>>
>> On Wed, Dec 12, 2018, 6:38 AM Stafford Horne <shorne@gmail.com wrote:
>>
>>> Hi Andrey,
>>>
>>> I rebased your binutils-gdb changes.  Then I split out the  main.cpu
>>> changes from the regeneration patch.   I also regenerated and compiled the
>>> sim.
>>>
>>> It looks good to me so far.
>>>
>>> Note the change I made to add 1 or 2 to the index of the pair register.
>>> Also, I removed the cgen patch.  In my environment I just symlink cgen
>>> into the binutils-gdb directory.
>>>
>>> You can review here:
>>> https://github.com/stffrdhrn/binutils-gdb/commits/orfpx64a32
>>>
>>> On Mon, Dec 10, 2018 at 3:34 AM BAndViG <bandvig@mail.ru> wrote:
>>>
>>>> Impressive progress, Stafford.
>>>> Unfortunately, I haven't got enough time right now to continue
>>>> advancing my OpenRISC implementation. I hope I’ll be back [image:
>>>> Улыбка] in 1-2 weeks.
>>>>
>>>> WBR
>>>> Andrey
>>>>
>>>>
>>>> *From:* Stafford Horne <shorne@gmail.com>
>>>> *Sent:* Sunday, December 09, 2018 4:47 PM
>>>> *To:* BAndViG <bandvig@mail.ru>
>>>> *Cc:* Richard Henderson <rth@twiddle.net>
>>>> *Subject:* Re: OR1K FPU Tools
>>>>
>>>> Hello,
>>>>
>>>> I just pushed some initial patches for fpu support on baremetal gcc. I
>>>> can compile some simple test programs.  Also this supports the mhard-float
>>>> and mdouble-float flags. You can see here:
>>>>
>>>> https://github.com/stffrdhrn/gcc/commits/or1k-fpu-1
>>>>
>>>>
>>>> Ccing, Richard so he can see what I'm up too.
>>>>
>>>> Hi Richard, Andrey is the main developer who implemented the OpenRISC
>>>> fpu.  He is still sticking with the old compiler for the fpu support, hence
>>>> this is on my to-do list.
>>>>
>>>> His fpu has expiramental support for doubles on 32 bit OpenRISC via
>>>> register pairs.  He will update the core to support the new rN,rN+2 pairing
>>>> supported in the new gcc port once my fpu work is tested. I am planning to
>>>> use gdb sim right now.
>>>>
>>>> See:
>>>> https://openrisc.io/proposals/orfpx64a32
>>>>
>>>> -stafford
>>>>
>>>>
>>>> On Wed, Nov 28, 2018, 6:18 AM Stafford Horne <shorne@gmail.com wrote:
>>>>
>>>>> On Sun, Nov 25, 2018 at 07:16:31PM +0300, BAndViG wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>> > > In the current implementation of GCC we store doubles in reigster
>>>>> pairs
>>>>> > > i.e.
>>>>> > > {r28, r30} allowing them to be preserved across function calls.
>>>>> If we
>>>>> > > could
>>>>> > > change ORFPX64A32 to match that it would give us better
>>>>> performance I
>>>>> > > think.
>>>>> >
>>>>> > I'm not familiar with ABI, so it is quite difficult to me to comment
>>>>> this.
>>>>> > First, if I understand correctly, you mean GCC9 while speaking
>>>>> "current
>>>>> > implementation of GCC." Am I right?
>>>>>
>>>>> Yes.
>>>>>
>>>>> > Second, does your proposal mean that double operands and result
>>>>> should
>>>>> > occupy {rx,rx+2} pairs? If "yes", I agree and will change my hardware
>>>>>
>>>>> Yes, thats what I mean.
>>>>>
>>>>> > implementation as soon as you complete "mdouble-float" option for
>>>>> GCC9.
>>>>> > By the way, binutils also should be updated to support such layout.
>>>>>
>>>>> I agree, the hardware should be updated after GCC and
>>>>> binutils/simulation is
>>>>> available.
>>>>>
>>>>> -Stafford
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20181219/88241cff/attachment.html>

^ permalink raw reply	[flat|nested] 10+ messages in thread