<div dir="ltr"><div dir="ltr">Please stay on devel@. You get more help that way. I moved this back.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020 at 10:31 AM Ayush Dwivedi <<a href="mailto:21cencturyayush@gmail.com">21cencturyayush@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Thank you Joel.</div><div dir="auto">I will add my name to the page you pointed out and start building my proposal as well. I think my first priority should be researching in depth about the floating point support (the registers and the FPU support) for the processors based on ARM. I think collecting the various BSD implementations sources for fenv is needed first. I found this FreeBSD implementation for the ARM architecture: </div><a href="https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h" rel="noreferrer" target="_blank">https://github.com/freebsd/freebsd/blob/master/lib/msun/arm/fenv.h</a><div dir="auto">Thanks a lot for sharing the NetBSD implementation it's thorough :) </div></div></blockquote><div><br></div><div>It may turn out they are the same code or close for a given architecture. </div><div>FreeBSD is #1 choice. NetBSD likely has more architectures.</div><div><br></div><div>Another place I remembered is <a href="https://musl.libc.org/">https://musl.libc.org/</a>. They appear to have</div><div>a lot of architectures.</div><div><br></div><div>I spot checked a few other projects that I could think of but they either also</div><div>used the FreeBSD code or only supported x86 and arm. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">About proposal should I be building it starting today? Also can I send patches if I happen to implement anything irrespective of the fact that POSIX Compliance is a GSoC open project of RTEMS(as in contributing patches independently would they be taken in consideration for a review?)<br></div></div></blockquote><div><br></div><div>Working on your proposal should be a top priority. If we don't get accepted</div><div>as a project or you don't finish your proposal, then we can accept you. :)</div><div><br></div><div>With that said, there are things to do as you work on the proposal. </div><div><br></div><div>Being able to build newlib independently is critical on this project. Vaibhav </div><div>and I have scripts to ease that.</div><div><br></div><div>Eventually you will have to have a toolchain for each architecture you want to address.</div><div><br></div><div>You should also consider that after the first couple of these, they will get easier so</div><div>pick some other POSIX Compliance tickets that are interesting. This is AFAIK the</div><div>only one that is per architecture though. The rest will be port/implement some code</div><div>and write tests.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div dir="auto">I will start looking into PowerPC and MIPS implementations later on. If you have more implementations links and resources please share them with me if possible. </div></div></div></blockquote><div><br></div><div>Look as you work on your proposal. </div><div><br></div><div>--joel</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Ayush Dwivedi</div><div dir="auto"><div dir="auto"> <br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon 17 Feb, 2020, 9:06 PM Joel Sherrill, <<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Ayush please add yourself to
<a href="https://devel.rtems.org/wiki/GSoC/2020" rel="noreferrer noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2020</a>.<div><br></div><div>Vaibhav.. we haven't asked others to add themselves to the table. </div><div>Please ping anyone we missed.</div><div><br></div><div>On the fenv.h side, there are some basic guidelines on how to provide </div><div>the fenv functionality and subtleties from the POSIX requirements.</div><div><br></div><div>First, the preferred origin of the implementation is another open source</div><div>project with FreeBSD and NetBSD being at the top of the list. For example,</div><div>here is the NetBSD implementation for the m68k:</div><div><br></div><div><a href="https://github.com/NetBSD/src/blob/trunk/sys/arch/m68k/include/fenv.h" rel="noreferrer noreferrer" target="_blank">https://github.com/NetBSD/src/blob/trunk/sys/arch/m68k/include/fenv.h</a> </div><div><br></div><div>But there are differences between vanilla m68k and coldfire so that may</div><div>not support all CPU variations. Would have to be determined.</div><div><br></div><div>I have not found a SPARC implementation with an appropriate license.</div><div>Jiri may have a better source.<br></div><div><br></div><div>I would put ARM, PowerPC, and MIPS at the top of the desired list that we</div><div>should be able to find BSD implementations for. We don't have an aarch64</div><div>port yet but I wouldn't stop a GSoC student from adding it to newlib. Just can't</div><div>be tested with RTEMS yet. Beyond that, architectures like the m68k where it</div><div>is porting, not writing from scratch are priorities. Covering as many architectures</div><div>that are popular with RTEMS is the goal. SPARC64 would be down the list</div><div>based on that.</div><div><br></div><div>Next POSIX allows an implementation to not support much if it isn't there </div><div>in hardware.</div><div><br></div><div><a href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html#tag_13_12" rel="noreferrer noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html#tag_13_12</a> <br></div><div><br></div><div>The fact that an architecture may not support a feature is challenging to testing.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020 at 5:54 AM Jiri Gaisler <<a href="mailto:jiri@gaisler.se" rel="noreferrer noreferrer" target="_blank">jiri@gaisler.se</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p><br>
</p>
<div>On 2/17/20 11:16 AM, Vaibhav Gupta
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020, 3:07
PM Ayush Dwivedi <<a href="mailto:21cencturyayush@gmail.com" rel="noreferrer noreferrer" target="_blank">21cencturyayush@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Hello Joel,<br>
</div>
<div dir="auto">This is regarding the open project #2966
POSIX-Compliance #2971( Add fenv.h to newlib). The
task is about adding the floating point environment
header to the newlib library but the source code of
the library already has the header with the listed
function declarations and data struct as needed. The
implementations for the following architectures are
available in the newlib-cygwin repository:</div>
<div>>RISCV</div>
<div>>i386</div>
<div>>x86_64</div>
<div>As pointed out in the POSIX Compliance project
sub-task page the implementations for following
architectures are yet to be added:<br>
</div>
<div>>ARM(software float implementation for this
exists but no fenv implementation)</div>
<div>>AArch64(software float implementation for this
exists but no fenv implementation)<br>
</div>
<div>>SPARC and SPARC64(directories for these
architectures are missing from libm/machine/ so no
implementation of any sort) </div>
<div><br>
</div>
<div>I would like to try and implement the functions
declared in the header using BSD libc of FreeBSD as
reference for the ARM and SPARC architectures.<br>
</div>
<div><br>
</div>
<div>Following is the output after running test for
posix fenv header(psxfenv01.exe) for SPARC using
sparc-rtems5-sis and sparc-rtems5-gdb.(The Test
failed)<br>
</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto">Yes because testsuite needs modifications and
moreover fenv on SPARC is not yet supported. Since the support
for RISCV and x86_64 is present, you can make a testsuite for
them. You can use qemu for running riscv files.</div>
</div>
</blockquote>
<p>Note that sis (riscv-rtems5-sis) also supports RISCV32 using the
griscv BSP in RTEMS.</p>
<p>Jiri.<br>
</p>
<br>
</div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" rel="noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div>
</blockquote></div></div></div></div></div>
</blockquote></div></div>