Eclipse plugin available for download

[Richard Herveille]

We created an Eclipse-CDT plugin for the RISC-V tool chain.
We use it to develop and debug (using GDB) code for our RV implementation.
Check it out: https://github.com/RoaLogic/riscv_gnu_eclipse

Feedback is appreciated.

ToDo:
- documentation
- clean some lingering internal stuff

Richard


Sent from my iPad

[Sober Liu]

Hi Richard,

 

I am not sure how many eclipse CDT user on MS-Window. For me I simply use it to read code.

So maybe you don’t need to check it anyway.

 

For CDT, I like its debug feature to set breakpoint in editor and show variables’ value.

While sometimes it get problem to connect with gdb and report errors in old Indigo version.

Do it become better in Mars.2?

 

I am glad to work on the doc if there are some other peoples interested with the plugin.

I could update doc after I make it work in Linux and during using it.

 

I will try with Eclipse Luna version instead. If still not work, I will contact IT guy for GTK+ help in Linux farm.

 

CC to mail list.

 

Best regards.

Soberl.

 

From: Richard Herveille [mailto:richard....@roalogic.com]
Sent: Tuesday, May 31, 2016 15:21
To: Sober Liu
Cc: Richard Herveille
Subject: Re: Eclipse plugin available for download

 

* PGP - S/MIME Signed by an unverified key: 05/31/2016 at 12:20:30 AM

 

Hi Richard,

I am quite sorry for the delay response. I was interrupted for some other tasks.

 

No problem, I am very excited you’re giving this a go and want to help.

 

I see in MS-windows, both Indigo and Mars.2 works after I uncheck following option.

<image001.png>

Maybe I should spend some hours to find out how to install a toolchain for risk.

 

It looks like the MicroSoft definitions are wrong or missing. When I find the time I will take a look.

 

 

Since there is no document for this plugin, I am not sure what I can do after create a helloworld project with the template.

 

I know, I am serious lacking there. I plan to create a wiki on github for this.

If you’re interested, would you like to work on it??

 

Does the plugin enhance CDT editor, or build/debug follow?

What’s the difference if I create a normal cross-compile project and assign compile as riscv-elf-gcc?

 

Ok, so the plugin basically contains the instructions to build RISC-V code.

It calls GCC, objdump, the linker, etc.

It has a GUI for setting the switches and options for each tool.

Of course you can do this with the normal cross-compile, but then you have to specify it all yourself. The plugin handles all the quirks for you (at least that’s the intention).

 

So if you create a RISC-V project you’ll get a GUI with the tool options.

When you click ‘build’ it will call the RISC-V tools.

 

In debug mode it can link to GDB and debug/step through your code.

 

 

 

For Linux, I see in Indigo there is no new project type entry.

And I cannot run Mars.2 because our GTK+ version is too old. There are copies for most recent GTK+ versions in the server, but active one is 2.10.

I failed to find a way as WAR, e.g., assign a path in eclipse.ini point to later GTK+ version.

Anyway I will find a way later to make it work in Linux as riscv-gnu-toolchains built in Linux.

 

Hmm, I am not sure about that. I compiled the extension on Mars, maybe that’s the limitation?

 

Do u expect this discussion in riscv-sw mail thread, or just point to point before some stage?

 

Maybe riscv-sw is a better place? Then others can chime in on the discussion.

 

Richard

 

 

Thanks.

 

 

From: Richard Herveille [mailto:richard....@roalogic.com] 
Sent: Tuesday, May 31, 2016 03:59
To: Sober Liu
Subject: Re: Eclipse plugin available for download

 

Hi,

 

Did you manage to get it working?

Did you try the install or source?

 

Richard

 

Sent from my iPad

On 25 mei 2016, at 09:45, Sober Liu <sob...@nvidia.com> wrote:

Yes, I am also using CDT. Let me try with 4.5.2.

Have u tried with MS-windows or Linux, or both?

 

Thanks.

 

From: Richard Herveille [mailto:richard....@roalogic.com] 
Sent: Wednesday, May 25, 2016 15:41
To: Sober Liu
Cc: Richard Herveille
Subject: Re: Eclipse plugin available for download

 

> Old - S/MIME Signed by an unverified key: 05/25/2016 at 12:41:14 AM

It’s important that you use Eclipse CDT. Eclipse for C Developers.

 

This is from my “about:"

Eclipse IDE for C/C++ Developers

 

Version: Mars.2 Release (4.5.2)

Build id: 20160218-0600

 

Cheers,

Richard

 

ROA LOGIC

Design Services and Silicon Proven IP

 

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

 

 

 

On 25 May 2016, at 09:31, Sober Liu <sob...@nvidia.com> wrote:

 

OK. Looks like it’s not compatible with Indigo.

Which Eclipse version are u using?

Thanks.

 

From: Richard Herveille [mailto:richard....@roalogic.com] 
Sent: Wednesday, May 25, 2016 15:25
To: Sober Liu
Cc: Richard Herveille
Subject: Re: Eclipse plugin available for download

 

> Old - S/MIME Signed by an unverified key: 05/25/2016 at 12:24:56 AM

Hi,

 

If the plugin is installed correctly, then you should see a new entrance when you select "New->C Project” or “New->C++ Project”. There should be 2 new entrances; “RISC-V Embedded Application” and “RISC-V Embedded Static Library”.

 

Richard

 

 

 

ROA LOGIC

Design Services and Silicon Proven IP

 

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

 

 

 

On 25 May 2016, at 09:09, Sober Liu <sob...@nvidia.com> wrote:

 

Hi Richard,
I tried to install the plugin. I am not sure whether it's working or not.
My eclipse version is: Eclipse IDE for C/C++ Developers, Version: Indigo Service Release 2, Build id: 20120216-1857. 
I see the plugin shown in Help->About Eclipse->Installation Details->Installed Software. But how can I use it?

The problem for me is that I don't find any new project type or new entrance in Preference.

Thanks a lot for share.
Best regards.

-- 
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/2CB4F2A4-5A4F-4766-84A9-A49B6CFC45E7%40roalogic.com.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

 

* <richard....@roalogic.com>
* Issuer: COMODO CA Limited - Unverified

 

* <richard....@roalogic.com>
* Issuer: COMODO CA Limited - Unverified

 

* <richard....@roalogic.com>
* Issuer: COMODO CA Limited - Unverified

 

[Sober Liu]

Hi Richard,

With Eclipse Luna, I can use this plugin in Linux.

 

Let me share what I did to run myHellow project with my local riscv gnu toolchain.

-          Set $PATH to contain path of riscv64-unknown-elf/bin

-          I have to remove -msoft-float option for both CFLAGS and LDFLAGS. Otherwise I see error log like “can't link hard-float modules with soft-float modules”.

-          It reports warning that _start not found. I uses _start/CRT from rocket-chip benchmark currently.

So I also link syscalls.o and crt.o.

Looks like I need to check how I built newlib for riscv.

 

Now I get myHellow.elf.

How can I make it run/debug? E.g., to use spike, or to run some simulator after dump img files?

 

Thanks.

Richard

 

Sent from my iPad

-- 
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/2CB4F2A4-5A4F-4766-84A9-A49B6CFC45E7%40roalogic.com.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

* <richard....@roalogic.com>
* Issuer: COMODO CA Limited - Unverified

* <richard....@roalogic.com>
* Issuer: COMODO CA Limited - Unverified

[Tommy Murphy]

Hi there - can anybody please help/advise?

I have tried the plugins with both Eclipse Luna and Mars on Ubuntu 14.04.4 (all 64 bit) but I still never see any RISC-V options in the new project dialogs.

Is there something else that I need to do?

I can see that the plugins are installed via the Help menu in Eclipse but they don't seem to add anything to the GUI right now.

I have a build of the RISC-V tools (albeit 32 bit not 64 bit - does that matter?) and have added them to my PATH before launching Eclipse from the command line with that PATH in effect.

Thanks a lot

Regards

Tommy Murphy

[Tommy Murphy]

Oh - I just unchecked "Show project types and toolchains only if they are supported on the platform" and now I see the "RISC-V Embedded Application/Static Library" options... in the C Project dialog.

And I just noticed that my RISC-V gcc tools did not build correctly so I guess that it's not finding the tools in order to know that these project targets are supported on my platform.

I guess I need to fix this first... :-)

Regards

Tommy Murphy

[Richard Herveille]

Hi Tommy,

I am working on a few screenshots to help with these matters. But haven’t finished those yet (low on the priority list).

The RISC-V options show up when you do:

- File-New Project-C/C++ Project

In the dialog box that opens select "RISC-V Embedded Application”.

If this doesn’t show up, then make sure the “Show project types and toolchains only …. platform” is checked. If anybody knows how to get around that please let me know.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Thanks for the quick reply Richard.

As I said this was my own mistake here.

I'll see how I get on once I get my tools built properly.

Regards

Tommy Murphy

[Sober Liu]

At my side, when riscv-toolchain in PATH, I can always see new riscv project entry either the “show project types…” checkbox checked or not.

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/b6211ca5-c5b2-4d8b-9e50-f099e0b69093%40groups.riscv.org.

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

[Tommy Murphy]

Hi guys

Just to confirm that I did manage to get the plugin working at my end - thanks for the advice.

A few additional questions...

(1) Is there any way to configure the toolchain bin folder or is it only picked up from the system PATH setting?

(2) Is there any way to tell the plugin to call riscv32-unknown-elf-gcc etc. instead of it always calling the riscv64 tools?

(3) Is it hardcoded that it adds -mArch=RV32I when -m32 is specified? I need to use -mArch=RV32IM but if I specify that in the configuration then it comes before -mArch=RV32I so I presume that the latter takes precedence?

Thanks a lot.

Regards

Tommy

[Richard Herveille]

Hi Tommy,

Just to confirm that I did manage to get the plugin working at my end - thanks for the advice.

Great!

A few additional questions...

(1) Is there any way to configure the toolchain bin folder or is it only picked up from the system PATH setting?

It really only picks up the tools from the PATH variable

(2) Is there any way to tell the plugin to call riscv32-unknown-elf-gcc etc. instead of it always calling the riscv64 tools?

That is fixed in the toolchain description. Currently it always picks riscv64-….

Reasoning behind it that, in my tests, riscv64- with the -m32 switch seems to produce correct code.

Only exception might be ‘newlib’, but it seems that needs a special build for each -march configuration anyways ...

(3) Is it hardcoded that it adds -mArch=RV32I when -m32 is specified? I need to use -mArch=RV32IM but if I specify that in the configuration then it comes before -mArch=RV32I so I presume that the latter takes precedence?

Yes it is.

-m32 is selected when the RV32 is chosen.

-march=… is always generated based on the chosen target (RV32/64) and extensions. If you want -march=RV32IM go to the toolchain properties, select target=RV32, and enable the Hardware Multiply/Divide (RVM) option. This should set -march to march=RV32IM.

Cheers,

Richard

Thanks a lot.

Regards

Tommy

[Tommy Murphy]

Hi Richard - thanks a lot for the info. Much appreciated.

Regards

Tommy

[Tommy Murphy]

I still seem to be having problems...

When I create a new RISC-V Embedded Application Empty Project then RISC-V GCC/Newlib C Compiler > Miscellaneous > Other flags has "-c" and RISC-V GCC/Newlib C Linker > Miscellaneous > Other flags is empty.

If I modify RISC-V GCC/Newlib C Compiler > Miscellaneous > Other flags to add some more flags then the full set of flags here gets replicated into RISC-V GCC/Newlib C Linker > Miscellaneous > Other flags - including the "-c" which then causes the linker NOT to link.

But if I remove "-c" from RISC-V GCC/Newlib C Linker > Miscellaneous > Other flags then it also disappears from RISC-V GCC/Newlib C Compiler > Miscellaneous > Other flags so that individual C files don't get compiled to object only.

It's like once RISC-V GCC/Newlib C Compiler > Miscellaneous > Other flags is edited then it gets mirrored to RISC-V GCC/Newlib C Compiler > Miscellaneous > Other flags and vice versa.

Catch 22?

Is this a known issue with the plugin?

Thanks.

[Tommy Murphy]

To make progress I have to change the RISC-V GCC/Newlib C Linker > Command from riscv64-unknown-elf-gcc to riscv64-unknown-elf-ld and then also add any C or ld specific options not controlled by GUI elements into the command name itself (e.g. RISC-V GCC/Newlib C Compiler Command = riscv64-unknown-elf-gcc -c -fno-jump-tables and RISC-V GCC/Newlib C Linker > Command = riscv64-unknown-elf-ld).

The plugin also seems to insist on adding -msoft-float to the command line but when I try to link I get:

riscv64-unknown-elf-ld: unrecognised emulation mode: soft-float

Supported emulations: elf32lriscv elf64lriscv

make: *** [demo-riscv.elf] Error 1

[Richard Herveille]

On 24 Jun 2016, at 19:05, Tommy Murphy <tommy_...@hotmail.com> wrote:

To make progress I have to change the RISC-V GCC/Newlib C Linker > Command from riscv64-unknown-elf-gcc to riscv64-unknown-elf-ld and then also add any C or ld specific options not controlled by GUI elements into the command name itself (e.g. RISC-V GCC/Newlib C Compiler Command = riscv64-unknown-elf-gcc -c -fno-jump-tables and RISC-V GCC/Newlib C Linker > Command = riscv64-unknown-elf-ld).

Reasoning behind using GCC instead of ld directly is that it gives you the C preprocessor.

Question is, what would be the preferred tool to use?

The plugin also seems to insist on adding -msoft-float to the command line but when I try to link I get:

Yeah … when no hardware floating point option is selected, -msoft-float is automatically added. I guess that can be disabled for the linker. I’ll have to check the source code.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Richard Herveille]

That’s weird … those should be two different variables. I’ll check. Hopefully this isn’t yet another Eclipse quirk. I often can’t get the tool to do what I want. I specify “cmd a b” and it stubbornly does “cmd b a”.

[Tommy Murphy]

Hi Richard

Thanks a lot for the quick reply.

 

Reasoning behind using GCC instead of ld directly is that it gives you the C preprocessor.

Question is, what would be the preferred tool to use?

I guess that calling gcc for *.S/*.asm files and *.c files makes sense for the reason you mention.

But for linking obviously there is no preprocessing so maybe ld makes more sense than gcc?

Ultimately whichever tool is chosen for linking has implications for the passing of parameters - e.g. when I changed the tool name to ld some of the flags passed did not work because they were for gcc rather than ld.

(BTW will the plugin ever support C++?).

Yeah … when no hardware floating point option is selected, -msoft-float is automatically added. I guess that can be disabled for the linker. I’ll have to check the source code.

Thanks - I must look at the sources myself. :-)

Regards

Tommy

[Michael Chapman]

It is better to use gcc for linking as it will select the right paths to find the right version of standard libraries.
Which library should be used for libc for instance, can depend on selected cpu architecture (e.g 32 vs 64 bit, with/without Multiply/Divide etc), whether profiling is enabled, stack checking enabled etc etc.

[Tommy Murphy]

Hi Richard (et. al.) - just a quick (belated!) update to say that I did manage to get things working with the plugins (in Eclipse Luna - haven't moved to Mars or Neon yet) and my RISC-V toolchain even so far as getting debugging working (Eclipse/CDT, gdb, OpenOCD, JTAG to my RISC-V on our FPGA target). So thanks for the assistance earlier. I did have to hack a few project/debug settings and it's not perfect but it's promising looking and getting there.

The only RISC-V plugin specific issue that I have noticed is the one that I mentioned earlier where changing the "Other options" of any build step seems to cause the "Other options" of ALL other steps to be changed. Did you ever get a chance to look into that?

Thanks again.

Regards
Tommy

[Richard Herveille]

Hi Tommy,

I’m glad you got it to work.

I did not have time to look into the ‘Other options’ issue yet. Sounds like a silly mistake somewhere.

Unfortunately I am pretty busy at the moment, so it may take a while before I can look into it. Can you file a bug on GitHub?

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Hi Richard

Apologies for the delay but I was on vacation.

I appreciated your reply and understand that you may not have the bandwidth to look into this just now.

I have logged a bug on github:

https://github.com/RoaLogic/riscv_gnu_eclipse/issues/1

If you have any ideas/suggestions on foot of that please let me know.

Thanks a lot

Regards

Tommy

[Tim Newsome]

I wanted to try out eclipse/openocd integration, so as a first step I installed your plugin so I could get a simple riscv project going.

I don't see any new project options, though. When I select new project, I get separate options for "C Project" and "C++ Project." Both behave the same, regardless of whether I have the "Show project types ..." checkbox checked or not:

The riscv64-unknown-elf-... toolchain is in my PATH.

I'm using Eclipse 3.8.1. Does anybody have suggestions on what to try, or even just a project that I can download somewhere? I've never used Eclipse before. It's possible I'm missing somebody that everybody knows.

Tim

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/21cae052-6ebc-42cf-8f6b-a5ee3034c507%40groups.riscv.org.

[Tommy Murphy]

Hi Tim

Eclipse 3.8.1 is ancient - I wouldn't use it and would be more inclined to use Eclipse Mars (4.5) or Neon (4.6).
Download the Eclipse + CDT (Eclipse IDE for C/C++ developers) package and unzip it.

https://eclipse.org/downloads/eclipse-packages/

Then install the Roa Logic RISC-V Eclipse plugins afresh and try again.
Hope this helps but if not we should be able to get you up and running.
It's all working fine for me. :-)

Good luck
Regards
Tommy

[Tim Newsome]

Thanks, Tommy. I'll try a later version. Unfortunately the installer seems hung downloading files from France and Italy, but hopefully that will sort itself out eventually.

Tim

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/09f3ba06-8be2-46c2-9316-328398e363b0%40groups.riscv.org.

[Tommy Murphy]

Hi Tim

Which installer?
Eclipse/CDT aka Eclipse for C/C++ Developers should just be a zipped download which you unpack.
And the Roa Logic RISC-V Eclipse plugins are another zip that you point Eclipse at to install as per Richard's first post in this thread.
Anyway - when you get back to it post back with progress or otherwise.
I've been using the plugins for a while and they have been working fine for me.

Regards
Tommy

[Tim Newsome]

So now I have Eclipse Neon.1 Release (4.6.1) installed, and when I try to install the plugin I get the following error:

Cannot complete the install because one or more required items could not be found.
  Software being installed: RISC-V GNU Toolchain 2016.2.0.201604221055 (com.riscv.cdt.feature.feature.group 2016.2.0.201604221055)
  Missing requirement: RISC-V GNU Toolchain 2016.2.0.201604221055 (com.riscv.cdt.feature.feature.group 2016.2.0.201604221055) requires 'org.eclipse.cdt.debug.mi.core 0.0.0' but it could not be found

What Eclipse version are you using?

Tim

​

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/156d8f2b-3505-403c-9a63-d47f6523d4b6%40groups.riscv.org.

[Tim Newsome]

OK, with Mars.2 Release (4.5.2) the plugins work. https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg30669.html suggests that org.eclipse.cdt.debug.mi.core is removed from Eclipse from Neon forward.

Tim

On Thu, Oct 6, 2016 at 1:51 PM, Tim Newsome <t...@sifive.com> wrote:

So now I have Eclipse Neon.1 Release (4.6.1) installed, and when I try to install the plugin I get the following error:

Cannot complete the install because one or more required items could not be found.
  Software being installed: RISC-V GNU Toolchain 2016.2.0.201604221055 (com.riscv.cdt.feature.feature.group 2016.2.0.201604221055)
  Missing requirement: RISC-V GNU Toolchain 2016.2.0.201604221055 (com.riscv.cdt.feature.feature.group 2016.2.0.201604221055) requires 'org.eclipse.cdt.debug.mi.core 0.0.0' but it could not be found

What Eclipse version are you using?

Tim

​

On Wed, Oct 5, 2016 at 12:20 PM, Tommy Murphy <tommy_...@hotmail.com> wrote:

Hi Tim

Which installer?
Eclipse/CDT aka Eclipse for C/C++ Developers should just be a zipped download which you unpack.
And the Roa Logic RISC-V Eclipse plugins are another zip that you point Eclipse at to install as per Richard's first post in this thread.
Anyway - when you get back to it post back with progress or otherwise.
I've been using the plugins for a while and they have been working fine for me.

Regards
Tommy

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

[Richard Herveille]

The plug-in probably needs a recompile. I still need to chase up a weird bug that was reported. I can do both at the same time. 

Richard 

Sent from my iPhone

[Tommy Murphy]

On Thursday, 6 October 2016 23:37:14 UTC+1, richard.herveille wrote:

The plug-in probably needs a recompile. I still need to chase up a weird bug that was reported.

Richard 

Hi Richard - apropos of the latter issue which I previously reported I have just updated the issue ticket with some comments that might be useful:

https://github.com/RoaLogic/riscv_gnu_eclipse/issues/1

Regards

Tommy

[Richard Herveille]

Hi Tommy,

I believe I found why this breaks.

Your fix is a workaround and will do. Working on the real fix now.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/96f77967-691c-40d3-8ad9-e71713d15533%40groups.riscv.org.

[Richard Herveille]

I believe I have fixed this issue. Please update the PlugIn.

This was an undocumented feature … some remnant from the Arc code I based this on.

Can you also check if the automatic versioning worked? This is yet another Eclipse feature which is difficult to test.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[A. V]

Hi,

Is there Virtual machine with RISC-V installed on it to download?

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/96f77967-691c-40d3-8ad9-e71713d15533%40groups.riscv.org.

[Tommy Murphy]

Hi Richard - maybe I'm doing something wrong but I still have problems.

See here:

https://github.com/RoaLogic/riscv_gnu_eclipse/issues/1

Are you just addressing the "Other flags" issue here or also the Eclipse Neon incompatibility?

If/when you do address the Neon incompatibility will it still be compatible with Luna/Mars?

Also - why are the default C++ linker Other flags = --specs=nsim.specs while the C linker Other flags are blank?

Thanks a lot.

Regards

Tommy

[Richard Herveille]

Hi Tommy,

Plenty of questions, I will try to address them;

1. Version number. The version ‘qualifier’ is supposed to update automatically, which it didn’t. I am checking why …

2. With the latest zip file, the ‘other flags’ issue should be addressed/fixed. I am not sure Eclipse updated your release, because the version numbers are the same.

3. Why is C++ linker other flags —specs=nsim.specs, while C linker is empty. This is a results of fixing the ‘other flags’ issue. I think the default C++ linker flags should be empty too.

I guess this is a good time to ask what the expected default values should be.

4. “Are you addressing the Neon incompatibility”? No, not yet. 

5. “If you fix the Neon incompatibility, will it still be compatible with Luna/Mars”?. I honestly don’t know. 

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Hi Richard - thanks for the quick update.

Regarding #2 as mentioned in the issue thread I also tried a clean "install" of Eclipse Mars into which I installed the latest RISC-V plugin from the archive zip but it still had the Other flags bug.

Regarding #3 --specs=nsim.specs was in the previous (April) version of the plugin too.

I suspect that ideal defaults will be difficult to ascertain in the general case.

I know that my defaults (e.g. -m32, our own linker script etc.) will probably not suit others.

But otherwise the current defaults (other than the C++ linker Other flags = --specs=nsim.specs) seem OK to me.

Perhaps if some or all defaults could be overridden using a -platformCustomization file from eclipse.ini this would help but I'm not sure if that involves extra work in implementing the plugin and Eclipse/plugins seem very inconsistent in whether or not they allow defaults to be overridden in this way unfortunately.... 

[Richard Herveille]

Hi Tommy,

The archive was not rebuild (something related to make and timestamps …)

I forced a rebuild. Now the version should be updated, Bug #1 should be fixed now (due to the rebuild), C++ linker other flags should not have a default value anymore.

The code was/is updated, but the archive is the issue. Please check if that’s fixed now.

The Neon release issue is still open.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Hi Richard

The new version looks good - i.e. no more Other flags clashing and C++ Linker Other flags no longer --specs=nsim.specs.

Thanks a lot - much appreciated.

Will I log a separate ticket for the Neon incompatibility issue that Tim identified earlier?

Regards

Tommy

[Richard Herveille]

Yes please, file a new bug for Eclipse-Neon.

I will close #1

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Not sure what you mean.

Do you mean a VM with the RISC-V gcc/binutils/gdb etc. and Eclipse/CDT + RISC-V plugins preinstalled?

I don't think so but it would be simple to create one if you needed to do this.

[Tommy Murphy]

Hi Richard

Any ideas about/comments on this one:

https://github.com/riscv/riscv-gnu-toolchain/issues/188

Just to recap - when building the RISC-V tools I used configure --disable-float which seems to imply soft float support/libs only.

The plugins seem to insist on adding -mhard-float or -msoft-float depending on the Target Processor project property settings?

(Actually the hard float options always seem to be greyed out so I guess that -msoft-float is always used?).

But when the tools are built with only soft float support then gcc complains if it is passed -msoft-float.

Now I view this as a potential gcc bug since even if -msoft-float is redundant because that is the only mode supported, it doesn't seem wrong per se?

However for the moment at least I have to modify the plugin to stop it adding -msoft-float.

Do you see any other option here?

Do you consider it a bug that gcc complains about -msoft-float when soft float is supported?

[Tommy Murphy]

Correction - I see that in the plugin the single precision floating point option is available but the double and quad options are disabled.

I guess that if Single Precision Floating Point is checked then the plugin will use -mhard-float?

[Tommy Murphy]

Oh - if Single Precision FP is checked then the Double Precision FP and Quad Precision FP become enabled and available for use and if any of these is checked then -mhard-float is used.

[Richard Herveille]

Hi Tommy,

Yeah, that was the intended behaviour. If quad is supported, then double precision must be supported too. If double is supported, then single is supported too.

I would consider -msoft-float causing an error a GCC bug, because it’s listed as a supported option.

My reasoning:

1. define the hardware. This includes the FPU.

2. If there’s an FPU in the hardware, then use -mhard-float

3. If not, then use -msoft-float

That still makes sense to me. And I think GCC should support this. For the time being, what would you propose as a workaround?

You can always remove the -msoft-float from the command line (in the plugin), right?

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Richard Herveille]

I thought about this a bit.

As a workaround (or general option) I can add a ‘no -msoft-float’ switch. That would then disable enabling that option.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Richard Herveille]

I thought about this a bit.

As a workaround (or general option) I can add a ‘no -msoft-float’ switch. That would then disable enabling that option.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

On 01 Nov 2016, at 08:02, Richard Herveille <richard....@roalogic.com> wrote:

[Tommy Murphy]

Hi Richard - thanks for the quick reply.

I can remove -msoft-float for the moment alright.

But the issue seems more fundamental given what Andrew has posted here:

https://github.com/riscv/riscv-gnu-toolchain/issues/188

We changed the API. -msoft-float and -mhard-float are no longer options; we removed them to clearly delineate the calling convention from the ISA. The calling convention is selected by -mfloat-abi=soft, -mfloat-abi=single, or -mfloat-abi=double. Independently, the ISA is set with -march.

I guess this means that the options generated by the plugin may need to change?

Will I open an issue against the plugins to track this?

Regards

Tommy

[Tommy Murphy]

In case it helps here is more info about the provenance of the -mfloat-abi=x options.

https://github.com/riscv/riscv-gnu-toolchain/issues/187

[Tommy Murphy]

Hi Richard

Just looking at this again...

As far as I can see there are five options:

-mno-float

-mfloat-abi=soft

-mfloat-abi=single 

-mfloat-abi=double

-mfloat-abi=quad

At the moment the plugin provides:

Single Precision Floating Point (RVF)

Double Precision Floating Point (RVD)

Quad Precision Floating Point (RVQ)

which would logically correspond to the following respectively:

-float-abi=single

-float-abi=double

-float-abi=quad

none checked = -mfloat-abi=soft or -mno-float?

Perhaps the float options need to be extended to something like:

Enable Floating Point 

   Soft Floating Point = -mfloat-abi=soft

   Single Precision Floating Point (RVF) = -msoft-abi=single 

   Double Precision Floating Point (RVD)  = -msoft-abi=double

   Quad Precision Floating Point (RVQ)  = -msoft-abi=quad

If Enable Floating Point is unchecked then it implies -mno-float and the other options are disabled.

If Enable Floating Point is checked then the other options are enabled and Soft Floating Point is checked by default.

If more than one floating point option is checked then some validation needs to be done?

I presume that the dependency whereby double and quad are only enabled if single is checked remains?

I'm sure that I haven't covered all bases here but am just trying to tease the issue out.

Also I'm not sure if the naming of the options should be reviewed to align with the terminology used in the relevant specs/docs - e.g. Single Precision Floating Point ABI etc.?

Also I'm not sure if/how selection of the different options would impact the -march=RV... setting generated by the plugin?

Hope this helps.

Regards

Tommy

[Richard Herveille]

Hi Tommy,

You beat me to a reply :-)

The -march seems to specify what instructions may be issued to the CPU. For example requiring a floating point instruction when ‘F’ is missing causes GCC to error out.

That is still valid and works as intended.

However the -mfloat-abi option is confusing.

From Andrew:

<quote>

• -mfloat-abi controls which calling convention is used: "soft" means no args passed in registers; "single" means only single-precision values are passed in regisers; "double" means single- and double-precision values are passed in registers; and "quad" means single-, double-, and quad-precision values are passed in registers.
• Default float-abi for RVI and RVIF is "soft"; default for RVIFD is "double". "single" and "quad" are never used as default ABIs.

</quote>

To me this suggests that we don’t need to specify -mfloat-abi. By default it simply follows the hardware capabilities of the CPU.

Unless, for example, you want to force only single precision arguments to be passed by registers (and the rest via the stack?). In that case use -float-abi=soft

Based on this I guess the defaults are fine and there’s no need to specify -mfloat-abi, unless you want something different than the default.

However Andrew’s next comment:

<quote>

I'm fine with -msingle/double/quad-float (without InverseMask), which cause F, FD, and FDQ to be enabled. I think we'd still need -mno-float, which removes F.

</quote>

Seems to suggest we have an additional set of options?! Why are these necessary? Can’t we simply use -march??

And if we use -march, do we care about the ABI? I still think it would be a Compiler only option. Maybe place it under the “Optimisations” section?

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/70c7d721-6819-463b-990c-7bc21fd894ed%40groups.riscv.org.

[Tommy Murphy]

Hi Richard

Thanks again for the quick reply.

I agree that there is still some confusion about the applicable architectures, float ABI options etc.

And what level of configurability needs to be supported by the plugin configuration GUI, what options need to be presented, how/where they should be presented etc.

I've asked Andrew if he might be able to look at this discussion and post here in an attempt to clarify matters.

Hopefully he'll be able to do this soon.

I guess that the selected architecture (implied by some of the configuration options?) implies the best default handling of floats here.

But then it might be possible and in some cases desirable to choose a non default option. E.g. I presume that -msoft-abi=double would be valid with architecture RVQ?

On the other hand how likely would it be for users to "downgrade" float support with respect to the architecture? I don't know the answer to this.

Regards

Tommy

[Tommy Murphy]

Oh - yet another contribution that may be relevant here! :-)

https://groups.google.com/a/groups.riscv.org/d/msg/sw-dev/zPHwe8ih534/WbqcxR4zIgAJ

[Michael Clark]

Sorry for the terse question. Have the RVQ opcodes been defined?

I wasn't aware whether gcc and gas could emit the QP instructions and I didn't find them in riscv-opcodes last time I looked. The flags would seem to indicate that gcc has the encodings.

I'm also not sure if I had posted these "unofficial" notes on RV128, and if I had, they may have had some subsequent edits:

https://github.com/michaeljclark/riscv-meta/blob/master/doc/src/rv128.md

I have yet to hear anything definitive on the 128 bit encodings but I noticed there is a talk at the workshop on RV128 and I'm very curious to find out... interested to see the slides...

I'm not in a hurry. Just curious... (I'm supposed to be working on bin trans to x86 so RV128 is a bit of a distraction).

Regards,

Michael

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/70c7d721-6819-463b-990c-7bc21fd894ed%40groups.riscv.org.

[Andrew Waterman]

You can fully control everything using just -mfloat-abi and -march.

> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/C0D45307-9773-412B-A422-596422178696%40roalogic.com.

[Tommy Murphy]

Hi Richard

My understanding...

Obviously -march=xxx specifies the architecture of the target CPU.

-msoft-abi=yyy selects the required float ABI.

1. No F in xxx means no FPU so no hardware float support and no f registers etc.
   In this case only -mfloat-abi=soft makes sense - my understanding is that -mno-float means the same thing.
   
   
2. F in xxx means single precision FPU support.
   In this case -mfloat-abi=soft (-mno-float) or -mfloat-abi=single can be used.
   
   
3. D in xxx means double precision FPU support.
   In this case -mfloat-abi=soft (-mno-float), -mfloat-abi=single or -mfloat-abi=double can be used.
   
   
4. Q in xxx means quad precision FPU support.
   In this case -mfloat-abi=soft (-mno-float), -mfloat-abi=single, -mfloat-abi=double or -mfloat-abi=quad can be used.
   

Perhaps the default case could/should be to infer the applicable -mfloat-abi=yyy setting from the -march=xxx setting?

However perhaps there may be cases when a user wants to use a "downgraded" -mfloat-abi=yyy option where the architecture supports something "better" (e.g. -mfloat-abi=soft on an RV64IMQ CPU)?

So perhaps it might make sense to split the architecture configuration and the -mfloat-abi configuration in the plugin GUI?

Or at least make them separately configurable rather than inferring the architecture from the float configuration options (as it does right now I think?) or vice versa?

I'm not sure that this deals with all of the issues that you were questioning below.

Hope this helps.

Regards

Tommy

[bo ya]

Hi,

I am new to Eclipse. I successfully installed riscv-gnu-eclipse.

I want to run the example "Hello.c" but it showed this error.

How do I set the PATH?  

BTW,it may be a stupid question.Is it possible that eclipse can generate assembly code?

like riscv64-unknown-elf-objdump?

 

[Tommy Murphy]

You have to set the path to the tools outside of eclipse.

I use a small utility script to do this and then run eclipse rather than setting it globally in my system path.

#!/bin/sh
export PATH=$PATH:/path-to-my-riscv-gcc-tools/riscv-unknown-elf-gcc/bin
cd /path-to-my-eclipse/eclipse
./eclipse

Not really sure what you mean about eclipse generating assembly code?

Maybe you can clarify?

The RISC-V gcc tools can obviously deal with assembly code.

Hope this helps.

[Padmarao Begari]

To Set the PATH in eclispe

1. Select the project in the eclipse Project Explorer.
2. Right click on the project and select Properties from the context menu(Project > Properties)
3. Select C/C++ Build > Environment > Add

    then fill the fields

    Name: PATH

    Value: /path-to-riscv-gcc-tools/bin:$PATH

Regards

Padmarao

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/464a95b8-55d1-4b34-8e7b-b59fe9ccb5b2%40groups.riscv.org.

[Richard Herveille]

I am finally getting around to updating the Eclipse plug-in.

I wanted to implement what Tommy suggested in an earlier email, however the latest RSIC-V tools show the following floating point calling conventions:

-mabi=ipl32|ipl32d|ipl32f|lp64|lp64d|lp64f

What do these mean? Is what Tommy suggested still valid? Is there a list somewhere of what options GCC and binutils support and what each option means?

Thanks,

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/51b2abd4-44d8-4f3c-b44d-5fd54f92a06a%40groups.riscv.org.

[Tommy Murphy]

I think that things have changed a bit since I originally posted?

I thought that all that was necessary now was --march=rvXXYYY and the compiler should "do the right thing" - i.e. generate code appropriate for the specified supported extensions?

Where XX = 32 or 64 (and eventually 128?) and YYY = whatever options the CPU supports (e.g. I, M, A, F, D, Q, G = IMAFD, C, L, V, B, T etc.)?

Is it necessary to pass other options to control floating point usage?

I presume that if you have, say, an RV32IMAQ CPU but want to use soft float for some reason then you specify --march=rv32ima rather than --march=rv32imaq?

As such perhaps the plugin just needs to present checkboxes for the different extensions and allow the user to select which to use?

Perhaps with special handling for G = IMAFD?

[Tommy Murphy]

Should read 

> (e.g. i, m, a, f, d, q, g = imafd, c, l, v, b, t etc.)

since the --march= argument should be all lower case.

[Richard Herveille]

On 16 Mar 2017, at 13:28, Tommy Murphy <tommy_...@hotmail.com> wrote:

Should read 

> (e.g. i, m, a, f, d, q, g = imafd, c, l, v, b, t etc.)

since the --march= argument should be all lower case.

Really? The target dependent help from GCC shows all capitals.

“-march=      Generate code for given RISC-V ISA (e.g. RV64IM)”

Richard

On Thursday, 16 March 2017 12:25:44 UTC, Tommy Murphy wrote:

Where XX = 32 or 64 (and eventually 128?) and YYY = whatever options the CPU supports (e.g. I, M, A, F, D, Q, G = IMAFD, C, L, V, B, T etc.)?

[Richard Herveille]

Yes indeed … capitals error out. Maybe the example should then show (e.g. rv64im) ??

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Richard Herveille]

A few issue I run into:

1)

Compiling a testprogram with -march=rv32im yields the following errors:

“requested ABI requires -march to subsume the `D’ extension”

“ABI requires -march=rv64”

So it seems I need to specify an ABI and I assume the -mabi=xxx option is the one to use.

However that seems specify the floating point calling convention. There isn’t one, because no f,d,q in the -march option.

Setting -mabi=ilp32 (no idea what that does … 32bit integer, no floating point?) allows the compiler to complete.

2)

The assembler complains ‘-m32’ and ‘-m64’ are unrecognised options. But they are listed in the target-dependent-help.

3)

The assembler wants ‘-mabi=xxx’ as well, but this is not listed as a valid option in the target-dependent-help.

Also specifying -march=rv32im -mabi=ilp32 causes an error “ABI requires -march=rv32”.

Is it illegal to specify the extensions for the assembler?? (again the target-specific-help indicates extensions should be listed)

4)

Is there an explanation for the -mabi=xxx option?

Thanks,

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Sober Liu]

Ilp32 means int-long-pointer are all 32bits.

 

The error msg comes from https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/riscv.c, around line 3793.

I guess it means u are trying to compile program for platform without FPU, while the toolchain library had expected FPU available (because toolchain maybe build with rv64g).

 

From: Richard Herveille [mailto:richard....@roalogic.com]
Sent: Thursday, March 16, 2017 9:21 PM
To: Tommy Murphy; RISC-V SW Dev
Cc: Richard Herveille
Subject: Re: [sw-dev] Eclipse plugin available for download

 

* PGP - S/MIME Bad Signature, Signed by an unverified key

* <richard....@roalogic.com>
* Issuer: COMODO CA Limited - Unverified

 

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/27D89888-02F6-46CA-8120-31895FEA7700%40roalogic.com.

---

This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

---

[Richard Herveille]

That’s indeed what I’m doing, but that should be possible, right?

That’s why I specify -march=rv32im

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Sober Liu]

My understanding, maybe incorrect, that the toolchain itself have to define whether it will be used for hard-float or soft-float. E.g., its crt need this information and decide whether to init FPU and FPRs. And it’s library also depends on this information to generate FPU instructions or soft-float function calls.

 

When u trying to compiling a program, it’s too later to assign march=xxx. It acts only a double check to make sure you will not get unexpected result.

I think maybe you need to configure/make 2 toolchain for both hard/soft-float and select one of them under user requests.

> Old - S/MIME Bad Signature, Signed by an unverified key

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/1185D40C-1BA6-46BF-A641-21374EE8BD13%40roalogic.com.

[Richard Herveille]

I am trying to avoid building multiple toolchains.

I know the C-libraries might be an issue and may need recompilation.

But the toolchain itself should not have any restrictions.

The crt checks ‘misa’ to determine if it needs to initialise the FPU and FPRs.

The hard-float and soft-float seem to indicate what to use for floating-point storage; the integer or the floating-point register file. Does that mean I can implement a CPU that uses the integer register file to feed the FPU? In that case, the compiler definitely needs to be aware …

Finally it is the assembler (while compiling an assembler file) that is complaining. Compiling C works with the -march=rv32im switch.

Richard

On 16 Mar 2017, at 15:35, Sober Liu <sob...@nvidia.com> wrote:

My understanding, maybe incorrect, that the toolchain itself have to define whether it will be used for hard-float or soft-float. E.g., its crt need this information and decide whether to init FPU and FPRs. And it’s library also depends on this information to generate FPU instructions or soft-float function calls.

 

When u trying to compiling a program, it’s too later to assign march=xxx. It acts only a double check to make sure you will not get unexpected result.

I think maybe you need to configure/make 2 toolchain for both hard/soft-float and select one of them under user requests.

[Tommy Murphy]

I've always found this a bit confusing.
I assumed that building the toolchain with, say, --enable-multilib and --with-arch=rv32imaf would build libs with and without hard float support.
But it doesn't seem to and I'm not sure what the point of --enable-multilib is.
Also done of this stuff has been in a state of flux over recent months so I'm not sure what the current state of play is...

[Richard Herveille]

That is my understanding as well
Even if multi-lib is currently broken, I would still expect -march= to behave as I described.

Richard


Sent from my iPad

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/5c43f7f3-c98b-4f5a-ba39-4970e2177b45%40groups.riscv.org.

[Richard Herveille]

Can anyone from the GCC/Binutils development team shed some light on this please?

Thanks,

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Palmer Dabbelt]

I'm not quite sure what the issue is, but here's some things that might be
relevant:

* The only build-time differences between the various RISC-V toolchain
configure options are what the defaults are, all toolchains support all
targets. C libraries must be built to target each ISA and ABI variant
you're interested in, you can see an example of how we're doing that in
riscv-gnu-toolchain.

* -m32/-m64 are gone from RISC-V gcc/binutils, they're unnecessary because of
-march. Whatever documentation they're in is wrong, if you can give me a
pointer I'll fix it.

* -march=ISA controls the targeted ISA, using a lower case RISC-V ISA string
name (for example, "rv64ic"). This controls what instructions the compiler
generates and the assembler accepts. You're allowed to link together to
objects that were produced with different "-march" values.

* -mabi=ABI controls the targeted ABI, using an ABI string (for example
"ilp32d"). ABI strings look like the standard way to describe ABIs (ie
"ilp32" means Integer, Long, and Pointer are 32 bits; while "lp64" means
Long and Pointer are 64-bits) but with an addition letter describing the
largest supported floating-point mode (f, d, or q). ABI strings control how
C types exist in memory, and therefor it is illegal to link together two
objects of different ABIs.

* -mtune=UARCH controls performance-sensitive code generation for a target
microarchitecture, but doesn't have any correctness impact. Right now I
think we only support "generic", but there might still be a "rocket" tuning
in there as well.

At least some of the problems here are due to march/mabi mismatches -- it looks
like you're requested "-mabi=lp64d" code with "-march=rv32im". This is
impossible, as the "lp64d" ABI says that 64-bit integer/pointer types are
passed in X registers (which is impossible when xlen=32), and that
single+double are passed in F registers (which is impossible when flen=0).

The reason it's done this way is that "hard float" and "soft float" are a bit
ambiguous: does the "hard" refer to the ABI constraint or the instruction
constraint? There's actually four options for floating-point code generation:

* "-march=rv64id -mabi=lp64d": FP types are passed in F registers, and FP
operations are done using explicit floating-point instructions. This
coresponds to ARM's "-mfloat-abi=hard".

* "-march=rv64i -mabi=lp64d": FP types are passed in F registers, but FP
operations are done using a software floating-point implementation. This
doesn't make any sense, as on RISC-V you must implement the floating-point
instructions if you have F registers. Thus the toolchain explicitly
disallows this option -- though we could always allow it in the future, if
someone has a compelling reason to do so.

* "-march=rv64id -mabi=lp64": FP types are passed in X registers, but FP
operations are done using explicit floating-point instructions. This
cooresponds to ARM's "-mfloat-abi=softfp", a silly name.

* "-march=rv64i -mabi=lp64": FP types are passed in X registers, and FP
operations are done using a software floating-point implementation. This
cooresponds to ARM's "-mfloat-abi=soft".

You're more than welcome to implement whatever microarchitecture you want, if
it executes all the RISC-V instructions then it'll run code our toolchain
generates. Specifically as to your "CPU that use the integer register file to
feed the FPU" seems possible: if you're building a machine with register
renaming that shares the physical register file between X and F registers then
you could perform some renaming tricks to make fmv.x.d and friends just copy
physical register IDs instead of copying data. Optimizing a high-performance
machine for "-march=rv64i -mabi=lp64d" performance seems like a bad place to
spend your time, but in this case it might come for free from eliding all other
copy instructions so maybe it's worth it.

On Fri, 17 Mar 2017 05:54:49 PDT (-0700), richard....@roalogic.com wrote:
> Can anyone from the GCC/Binutils development team shed some light on this please?
>
> Thanks,
> Richard
>
>
> ROA LOGIC
> Design Services and Silicon Proven IP
>
> Richard Herveille
> Managing Director
> Phone +31 (45) 405 5681
> Cell +31 (6) 5207 2230

> richard....@roalogic.com <mailto:richard....@roalogic.com>

>
>
>
>
>> On 16 Mar 2017, at 15:46, Richard Herveille <richard....@roalogic.com> wrote:
>>
>> I am trying to avoid building multiple toolchains.
>> I know the C-libraries might be an issue and may need recompilation.
>> But the toolchain itself should not have any restrictions.
>> The crt checks ‘misa’ to determine if it needs to initialise the FPU and FPRs.
>>
>> The hard-float and soft-float seem to indicate what to use for floating-point storage; the integer or the floating-point register file. Does that mean I can implement a CPU that uses the integer register file to feed the FPU? In that case, the compiler definitely needs to be aware …
>>
>>
>> Finally it is the assembler (while compiling an assembler file) that is complaining. Compiling C works with the -march=rv32im switch.
>>
>> Richard
>>
>>
>>
>>
>>> On 16 Mar 2017, at 15:35, Sober Liu <sob...@nvidia.com <mailto:sob...@nvidia.com>> wrote:
>>>
>>> My understanding, maybe incorrect, that the toolchain itself have to define whether it will be used for hard-float or soft-float. E.g., its crt need this information and decide whether to init FPU and FPRs. And it’s library also depends on this information to generate FPU instructions or soft-float function calls.
>>>
>>> When u trying to compiling a program, it’s too later to assign march=xxx. It acts only a double check to make sure you will not get unexpected result.
>>> I think maybe you need to configure/make 2 toolchain for both hard/soft-float and select one of them under user requests.
>>
>>
>>
>> ROA LOGIC
>> Design Services and Silicon Proven IP
>>
>> Richard Herveille
>> Managing Director
>> Phone +31 (45) 405 5681
>> Cell +31 (6) 5207 2230

>> richard....@roalogic.com <mailto:richard....@roalogic.com>

>>
>>
>>
>>
>>
>>>
>>>
>>> From: Richard Herveille [mailto:richard....@roalogic.com <mailto:richard....@roalogic.com>]
>>> Sent: Thursday, March 16, 2017 10:23 PM
>>> To: Sober Liu; RISC-V SW Dev
>>> Cc: Richard Herveille; Tommy Murphy
>>> Subject: Re: [sw-dev] Eclipse plugin available for download
>>>
>>> * PGP - S/MIME Bad Signature, Signed by an unverified key
>>> That’s indeed what I’m doing, but that should be possible, right?
>>> That’s why I specify -march=rv32im
>>>
>>> Richard
>>>
>>>
>>> ROA LOGIC
>>> Design Services and Silicon Proven IP
>>>
>>> Richard Herveille
>>> Managing Director
>>> Phone +31 (45) 405 5681
>>> Cell +31 (6) 5207 2230

>>> richard....@roalogic.com <mailto:richard....@roalogic.com>

>>>
>>>
>>>
>>>
>>> On 16 Mar 2017, at 14:39, Sober Liu <sob...@nvidia.com <mailto:sob...@nvidia.com>> wrote:
>>>
>>> Ilp32 means int-long-pointer are all 32bits.
>>>

>>> The error msg comes from https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/riscv.c <https://github.com/riscv/riscv-gcc/blob/riscv-next/gcc/config/riscv/riscv.c>, around line 3793.

>>> richard....@roalogic.com <mailto:richard....@roalogic.com>

>>>
>>>
>>>
>>>
>>> On 16 Mar 2017, at 13:25, Tommy Murphy <tommy_...@hotmail.com <mailto:tommy_...@hotmail.com>> wrote:
>>>
>>> I think that things have changed a bit since I originally posted?
>>> I thought that all that was necessary now was --march=rvXXYYY and the compiler should "do the right thing" - i.e. generate code appropriate for the specified supported extensions?
>>> Where XX = 32 or 64 (and eventually 128?) and YYY = whatever options the CPU supports (e.g. I, M, A, F, D, Q, G = IMAFD, C, L, V, B, T etc.)?
>>> Is it necessary to pass other options to control floating point usage?
>>> I presume that if you have, say, an RV32IMAQ CPU but want to use soft float for some reason then you specify --march=rv32ima rather than --march=rv32imaq?
>>> As such perhaps the plugin just needs to present checkboxes for the different extensions and allow the user to select which to use?
>>> Perhaps with special handling for G = IMAFD?
>>>

>>> * <richard....@roalogic.com <mailto:richard....@roalogic.com>>

>>> * Issuer: COMODO CA Limited - Unverified
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org <mailto:sw-dev+un...@groups.riscv.org>.
>>> To post to this group, send email to sw-...@groups.riscv.org <mailto:sw-...@groups.riscv.org>.
>>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/ <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.
>>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/27D89888-02F6-46CA-8120-31895FEA7700%40roalogic.com <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/27D89888-02F6-46CA-8120-31895FEA7700%40roalogic.com?utm_medium=email&utm_source=footer>.

>>> This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
>>>

>>> * <richard....@roalogic.com <mailto:richard....@roalogic.com>>

>>> * Issuer: COMODO CA Limited - Unverified
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org <mailto:sw-dev+un...@groups.riscv.org>.
>>> To post to this group, send email to sw-...@groups.riscv.org <mailto:sw-...@groups.riscv.org>.
>>> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/ <https://groups.google.com/a/groups.riscv.org/group/sw-dev/>.
>>> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/1185D40C-1BA6-46BF-A641-21374EE8BD13%40roalogic.com <https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/1185D40C-1BA6-46BF-A641-21374EE8BD13%40roalogic.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/9DF2CAB6-D52C-40BD-B8F7-AE1C0EB5B8F4%40roalogic.com.

[Sober Liu]

Hi Palmer,
Thanks for the explanations in details. I have one question here:
For " C libraries must be built to target each ISA and ABI variant you're interested in, you can see an example of how we're doing that in riscv-gnu-toolchain.", what's the configure options if I hope to support both hard-float and soft-float?
And take printf lib "%f" for example, how the library know whether to take soft-float function call or FPU to handle floating type?

Do u mean for Linux build? I tried with newlib build and see following error with give -march=rv64im with tool configured with --with-arch=rv64g:
>error: requested ABI requires -march to subsume the `D' extension
>Target: riscv64-unknown-elf
>Configured with: ... --with-newlib ... --disable-multilib --with-abi=lp64d --with-arch=rv64g

Do u expect this build to match "-march=rv64i -mabi=lp64" from u list?

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/mhng-4bfc6d64-f66b-4ad6-bcbd-af8ec5af5cf8%40palmer-si-x1c4.

[Alex Bradbury]

On 17 March 2017 at 16:20, Palmer Dabbelt <pal...@dabbelt.com> wrote:
<snip>

> The reason it's done this way is that "hard float" and "soft float" are a bit
> ambiguous: does the "hard" refer to the ABI constraint or the instruction
> constraint? There's actually four options for floating-point code generation:
>
> * "-march=rv64id -mabi=lp64d": FP types are passed in F registers, and FP
> operations are done using explicit floating-point instructions. This
> coresponds to ARM's "-mfloat-abi=hard".
>
> * "-march=rv64i -mabi=lp64d": FP types are passed in F registers, but FP
> operations are done using a software floating-point implementation. This
> doesn't make any sense, as on RISC-V you must implement the floating-point
> instructions if you have F registers. Thus the toolchain explicitly
> disallows this option -- though we could always allow it in the future, if
> someone has a compelling reason to do so.
>
> * "-march=rv64id -mabi=lp64": FP types are passed in X registers, but FP
> operations are done using explicit floating-point instructions. This
> cooresponds to ARM's "-mfloat-abi=softfp", a silly name.
>
> * "-march=rv64i -mabi=lp64": FP types are passed in X registers, and FP
> operations are done using a software floating-point implementation. This
> cooresponds to ARM's "-mfloat-abi=soft".

Thanks for the documentation Palmer, I really like how this approach
avoids the -mfloat-abi mess.

For the E extension, is the same thing supported. e.g. I could specify
-mabi=lp32e with either -march=rv32i or -march=rv32e?

Is there an intention to support the rather verbose "version number"
ISA strings suggested in the spec?
(https://content.riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1.pdf
p68). They unfortunately require case sensitivity due to the the use
of 'p' for minor version number and (in the future) 'P' for packed
SIMD. e.g. RV64I2p0M2p0A2p0F2p0D2p0. These strings are verbose and
ugly, but I could see it becoming necessary for the C extension in
particular, or extensions like bit manipulation that are also liable
to grow over time.

I understand that Andrew is planning to submit proposals surrounding
M-mode at some point, introducing a new lowest common denominator for
compiler targets and code authors. e.g. an environment where
misaligned memory access is disallowed (as opposed to just potentially
slow), and where instructions such as rdcycle, rdinstret etc may be
illegal (the compiler won't be generating those, but there is the
opportunity to error on their use in the assembler). There's also the
possibility of trying to target rv32im but where only multiply is
implemented. Do you have any thoughts on how these M-mode only
requirements might be specified? Clang and LLVM have made good use of
-mattr for these kind of CPU specifics, but this doesn't seem to exist
currently in the GCC world. In the ARM world they've done things like
-mcpu=generic+feature or -mcpu=generic+nofeature

I'd really like to standardise these things across Clang and GCC.
Historically this has been painful due to backwards compatibility
(we're kind of stuck with -mfloat-abi in the ARM world) or lack of
communication between the communities, but we have the advantage of
starting fresh. As such, it would be good if future discussions about
these things could be made more visible. Please do CC me in relevant
PRs/issues. In general, I think decisions like this would be well
served by an RFC on the sw-dev list. The LLVM community has a simple
approach that is worth considering:
* RFCs are lightweight - just an email with 'RFC' in the title, and
the content in whatever form you want.
* If it's just a bugfix/performance enhancement, go straight to
standard patch review
* If you're proposing a change that may affect others (e.g. new
interface, break in compatibility), or be invasive, then go to the
mailing list with an RFC for feedback on design choices and the
general approach.

Best,

Alex

[Palmer Dabbelt]

Well, right now there's no support for E in any of the toolchain stuff.
Allowing this seems like a reasonable decision, but since I haven't done the
work yet I'm not sure if it'd be onerous.

We've been thinking E

>
> Is there an intention to support the rather verbose "version number"
> ISA strings suggested in the spec?
> (https://content.riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1.pdf
> p68). They unfortunately require case sensitivity due to the the use
> of 'p' for minor version number and (in the future) 'P' for packed
> SIMD. e.g. RV64I2p0M2p0A2p0F2p0D2p0. These strings are verbose and
> ugly, but I could see it becoming necessary for the C extension in
> particular, or extensions like bit manipulation that are also liable
> to grow over time.

The hope is not to support those, but to instead have the RISC-V foundation do
a good job designing ISAs such that we don't need to deal with versioning. The
version strings are lower-case-only now so they're extensible in an unambiguous
way to the full spec (ie RV64 instead of rv64).

> I understand that Andrew is planning to submit proposals surrounding
> M-mode at some point, introducing a new lowest common denominator for
> compiler targets and code authors. e.g. an environment where
> misaligned memory access is disallowed (as opposed to just potentially
> slow), and where instructions such as rdcycle, rdinstret etc may be
> illegal (the compiler won't be generating those, but there is the
> opportunity to error on their use in the assembler). There's also the
> possibility of trying to target rv32im but where only multiply is
> implemented. Do you have any thoughts on how these M-mode only
> requirements might be specified? Clang and LLVM have made good use of
> -mattr for these kind of CPU specifics, but this doesn't seem to exist
> currently in the GCC world. In the ARM world they've done things like
> -mcpu=generic+feature or -mcpu=generic+nofeature

There's a few in here:

* For M-mode stuff, if we need to support multiple machine mode ISAs that are
sufficiently different than user mode then we'll add some sort of
"-mmachine-mode=sifive-0.11". We're hoping to avoid that.

* Right now we have support for disabling individual instructions with some
flags like "-mno-div" and "-mno-fdiv". This could be extended to arbitrary
instructions easily.

* I wouldn't be opposed to some sort of "-mcpu" support, but I don't think the
"generic+feature" is a good idea -- that's what our other "-m" arguments are
for.

* The "-mattr" stuff looks a bit messy: if I understand it correctly it's for
passing arguments to various stages of the toolchain? We're trying to avoid
that by having all the toolchain programs understand all the same arguments
to the degree that's possible.

> I'd really like to standardise these things across Clang and GCC.
> Historically this has been painful due to backwards compatibility
> (we're kind of stuck with -mfloat-abi in the ARM world) or lack of
> communication between the communities, but we have the advantage of
> starting fresh. As such, it would be good if future discussions about
> these things could be made more visible. Please do CC me in relevant
> PRs/issues. In general, I think decisions like this would be well
> served by an RFC on the sw-dev list. The LLVM community has a simple
> approach that is worth considering:
> * RFCs are lightweight - just an email with 'RFC' in the title, and
> the content in whatever form you want.
> * If it's just a bugfix/performance enhancement, go straight to
> standard patch review
> * If you're proposing a change that may affect others (e.g. new
> interface, break in compatibility), or be invasive, then go to the
> mailing list with an RFC for feedback on design choices and the
> general approach.

That sounds good. Now that we're upstream things will be a lot more stable
(that's why there was a flurry of argument changes in the last 3 months, to get
everything sane and extensible). I'd also really like to have argument
compatibility across our backends.

[Alex Bradbury]

On 20 March 2017 at 16:23, Palmer Dabbelt <pal...@dabbelt.com> wrote:
> On Sat, 18 Mar 2017 01:44:34 PDT (-0700), a...@asbradbury.org wrote:
>
>>
>> Is there an intention to support the rather verbose "version number"
>> ISA strings suggested in the spec?
>> (https://content.riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1.pdf
>> p68). They unfortunately require case sensitivity due to the the use
>> of 'p' for minor version number and (in the future) 'P' for packed
>> SIMD. e.g. RV64I2p0M2p0A2p0F2p0D2p0. These strings are verbose and
>> ugly, but I could see it becoming necessary for the C extension in
>> particular, or extensions like bit manipulation that are also liable
>> to grow over time.
>
> The hope is not to support those, but to instead have the RISC-V foundation do
> a good job designing ISAs such that we don't need to deal with versioning. The
> version strings are lower-case-only now so they're extensible in an unambiguous
> way to the full spec (ie RV64 instead of rv64).

I think realistically versioning will be necessary - every previous
ISA has required versioning for at least some of its extensions!

>> I understand that Andrew is planning to submit proposals surrounding
>> M-mode at some point, introducing a new lowest common denominator for
>> compiler targets and code authors. e.g. an environment where
>> misaligned memory access is disallowed (as opposed to just potentially
>> slow), and where instructions such as rdcycle, rdinstret etc may be
>> illegal (the compiler won't be generating those, but there is the
>> opportunity to error on their use in the assembler). There's also the
>> possibility of trying to target rv32im but where only multiply is
>> implemented. Do you have any thoughts on how these M-mode only
>> requirements might be specified? Clang and LLVM have made good use of
>> -mattr for these kind of CPU specifics, but this doesn't seem to exist
>> currently in the GCC world. In the ARM world they've done things like
>> -mcpu=generic+feature or -mcpu=generic+nofeature
>
> There's a few in here:
>
> * For M-mode stuff, if we need to support multiple machine mode ISAs that are
> sufficiently different than user mode then we'll add some sort of
> "-mmachine-mode=sifive-0.11". We're hoping to avoid that.
>
> * Right now we have support for disabling individual instructions with some
> flags like "-mno-div" and "-mno-fdiv". This could be extended to arbitrary
> instructions easily.
>
> * I wouldn't be opposed to some sort of "-mcpu" support, but I don't think the
> "generic+feature" is a good idea -- that's what our other "-m" arguments are
> for.

At the same time, the +feature syntax was a very conscious decision
made by AArch64 to move away from -mfoo/-mnofoo for CPU features
<https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html>. We could
make different choices here, but it would be worth better
understanding the reasoning (and indeed - if this was something that
came from the ARM community or part of a wider effort to rationalise
things in GCC?). -march=rv64id+feature is probably better than
-mcpu=generic+feature. There is related discussion on this move in
LLVM here - not sure about the matching thread for GCC
<http://clang-developers.42468.n3.nabble.com/AArch64-Clang-CLI-interface-proposal-td4036950.html>

> * The "-mattr" stuff looks a bit messy: if I understand it correctly it's for
> passing arguments to various stages of the toolchain? We're trying to avoid
> that by having all the toolchain programs understand all the same arguments
> to the degree that's possible.

I misremembered, and thought -matr it had been exposed as a top-level
Clang argument, but that didn't happen. I agree it's probably
confusing enough have -march -mcpu -mtune and -mabi.

Best,

Alex

[Richard Herveille]

Hi Palmer,

Thanks for the detailed explanation.

* -m32/-m64 are gone from RISC-V gcc/binutils, they're unnecessary because of
  -march.  Whatever documentation they're in is wrong, if you can give me a
  pointer I'll fix it.

riscv-gcc-unknown-elf-gcc —target-help

shows -m32 and -m64 as valid options to pass to the assembler.

I managed to get the new toolchain in Eclipse working.

I still need to add the -mabi option.

Question, if I set -mabi or -march in GCC and use GCC to call the assembler/linker, are these options automatically fed into those as well? Currently I explicitly push the options into the assembler/linker using the -Wa, and -Wl options.

What exactly does -mabi specify? How parameters are passed when calling a procedure/function, but not where they’re stored (i.e. in RF/FPRF)?

Richard

[Palmer Dabbelt]

On Mon, 20 Mar 2017 12:47:01 PDT (-0700), richard....@roalogic.com wrote:
> Hi Palmer,
>
> Thanks for the detailed explanation.
>
>> * -m32/-m64 are gone from RISC-V gcc/binutils, they're unnecessary because of
>> -march. Whatever documentation they're in is wrong, if you can give me a
>> pointer I'll fix it.
>
> riscv-gcc-unknown-elf-gcc —target-help
> shows -m32 and -m64 as valid options to pass to the assembler.

Sorry about that, I missed the GAS help text. How does this look?

https://github.com/riscv/riscv-binutils-gdb/commit/4fcdfc2404194d57ec8f70f303d4adf297dd48ac

> I managed to get the new toolchain in Eclipse working.
> I still need to add the -mabi option.
>
> Question, if I set -mabi or -march in GCC and use GCC to call the assembler/linker, are these options automatically fed into those as well? Currently I explicitly push the options into the assembler/linker using the -Wa, and -Wl options.

On RISC-V, you should only be passing target-specific arguments to "gcc", which
will pass arguments to the various tools as necessary. One of the reasons we
chose this argument format is so every tool is on the same page.

> What exactly does -mabi specify? How parameters are passed when calling a procedure/function, but not where they’re stored (i.e. in RF/FPRF)?

The "-mabi" flag specifies the ABI for C/C++ code. This answers questions
like:

* Given a type (either "int" or "struct { int a; float b;}"), how is that
structure laid out in memory.

* Given a function prototype, where do callers put arguments (and by symmetry,
where does the callee get the arguments)? When arguments are in registers,
which registers are used? When arguments are in memory,

* Some less visible stuff, like caller/callee saved registers, debug info,
stack/register layout, the definition of relocations, TLS/GOT/PLT formats,
etc.

Specifically, the "-mabi" switch allows users to specify:

* "-mabi=ilp32*" vs "-mabi=lp64*": What are the sizes of "long", "int", and
pointers? "ilp32" means Integer, Long, and Pointer are 32 bits, while
"lp64" means Long and Pointer are 64 bits.

* "-mabi=*d" vs "-mabi=*f" vs "-mabi=*": Which floating point arguments can be
passed in F registers? "d" means double and float, "f" means float, and
no suffix means no floats are passed in registers.

There's an ABI document

https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md

That not only tells you what the ABI specifies, but exactly how it's specified.
This is a work in progress.

> richard....@roalogic.com <mailto:richard....@roalogic.com>

[Richard Herveille]

Hi,

I updated the Eclipse Plug-in to support the new toolchain and toolchain-options.

It’s available for download from https://github.com/RoaLogic/riscv_gnu_eclipse

[Tommy Murphy]

Cool - will have a look ASAP. Thanks. 

BTW - does it do anything to resolve the incompatibility with Eclipse Neon? 

I presume not or you would have said... :-)

https://github.com/RoaLogic/riscv_gnu_eclipse/issues/2

[Richard Herveille]

>
> BTW - does it do anything to resolve the incompatibility with Eclipse Neon?
> I presume not or you would have said... :-)

I am not sure. I removed a lot of unnecessary dependencies and am hoping that resolved that issue. But I have not particularly looked into it yet.

Richard



>
> https://github.com/RoaLogic/riscv_gnu_eclipse/issues/2

[Tommy Murphy]

Hi Richard

The plugin has support for -m32 and -m64 but is hardcoded in some of the Java code and in plugin.xml to use the riscv64-unknown-elf-* tools.

How is this expected to work?

This other post of mine may also be relevant here:

https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/fO_Xv_kFfRI

At the moment I'm using a RV32IM target and so have built riscv32-unknown-elf-* tools (i.e. configure --with-arch=rv32im) so to use these I had to modify the Java code and plugin.xml to change riscv64-unknown-elf to riscv32-unknown-elf everywhere.

Are you able to build riscv64-unknown-elf-* tools that support both 32 and 64 bit targets?

Thanks

Tommy

[Richard Herveille]

Hi Tommy,

The riscv64 toolchain supports both rv64 and rv32 targets. It's the -march option that defines this. I have both 32 and 64bit CPUs and use the same toolchain. 

The only issue is that multilib seems broken, so you need to build a newlib for each target, which is a real pain. 

Richard

Sent from my iPad

--

You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/ba1b55b0-cf35-48f4-b8a2-7c8c9b4a7c23%40groups.riscv.org.

[Tommy Murphy]

Hi Richard

Thanks for the quick reply.

How did you build a riscv64-unknown-elf-* toolchain that supports both 32 and 64?

Last time I tried using these instructions and configure --with-arch=rv32im and --with-arch=rv64im it built separate 32 and 64 bit tools.

https://github.com/riscv/riscv-gnu-toolchain

Are you using your own build scripts or something?

When you say "target" do you mean, say, rv32i, rv32im, rv32ima etc.?

Do you have to build newlib for all possible combinations of extensions (i, m, a, c, f, d, q etc.)?

How do you do this and how do you organize the libs in the deployed toolchain folder so that gcc/ld picks the right ones based on the flags passed at RISC-V program compile/link time?

Thanks a lot

Regards

Tommy

[Tommy Murphy]

If I download the zip from your github and try to install it in Eclipse (I tried Luna SR2 and Neon) something seems wrong:

Help > Install New Software

Add...

Archive...

Browse to the riscv_gnu_plugins_201703281534.zip that I previously downloaded from your github

OK

In the dialog I get "There are no categorized items" and cannot proceed.

Any ideas?

Thanks.

[Richard Herveille]

That should not have happened, I am checking what went wrong.

As a workaround, uncheck ‘Group Items by category”.

1. install new software

2. click ‘add’

3. click ‘archive’

4. select archive

5. ok

6. ok

7. uncheck ‘Group items by category”

8. select latest plugin

...

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/e2459af5-e02b-4b3a-9d77-78ba9d8aa0d3%40groups.riscv.org.

[Richard Herveille]

I fixed this. There’s a new archive (20170330) on GitHub

This was due to ‘version’ incompatibilities. Somehow there’s versions and version qualifiers all over the place and they all need to match.

I also started playing with the ‘update-site’ feature. Meaning Eclipse can check the github site and determine if there’s a new release. If anybody is willing to help me test/debug, then that would be appreciated.

Cheers,

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Thanks a lot Richard.

I'll try the new zip later.

What URL should I use for the update site?

I tried https://github.com/RoaLogic/riscv_gnu_eclipse and https://github.com/RoaLogic/riscv_gnu_eclipse/updatesite but in both cases Eclipse reported that there was no software to install.

[Tommy Murphy]

BTW - I tried an install of the new zip into Neon and I didn't get any errors so I presume that's good news?

I haven't actually tried it with a RISC-V toolchain yet though.

[Tommy Murphy]

Hi Richard

A few questions/comments:

1. One of the plugin build steps uses hex2verilog - where does this tool come from as I can't see that it's produced by a "regular" build of the RISC-V tools?
2. Do you know if there's any way to override plugin defaults through an external file (e.g. plugin_customization.ini referenced by eclipse.ini?)? For example, I would like -fdata-sections and -ffunction-sections enabled by default and to have the linker passed -Wl,-gc-sections but I can't seem to do this from an external file so have to modify the original plugin. I don't know if these can only be overridden in this way if certain APIs are used to retrieve settings or something like that?
3. I have added a "Print Size" build step that uses riscv64-unknown-elf-size to print size stats - this is modelled on (i.e. copied from :-) the GNU ARM Eclipse plugins. Would you be interested in/willing to integrate that into the plugin? If so I can send you the modified plugin.xml.
4. With the previous plugin I was able to specify -gc-sections in the linker Other flags but with the latest plugin I have to specify -Wl,-gc-sections. I can't see why but maybe this is something to do with the latest RISC-V tools versus the older ones that I was using before? Rather than a plugin issue per se (or at all)?
5. I haven't been able to test the update site installation mechanism for you because I still don't know what URL to specify. Maybe you can clarify?
6. When I get a chance I will try the plugin with Eclipse Neon - as I said above it installed OK but I haven't actually tried it.

Hope this helps.

Regards

Tommy

[Richard Herveille]

Hi Tommy,

1. One of the plugin build steps uses hex2verilog - where does this tool come from as I can't see that it's produced by a "regular" build of the RISC-V tools?

This is a remainder from my own toolchain.

It’s intended to generate a Verilog-hex file. But I’ve seen examples of objdump generating these kind of files. So I should add that instead.

2. Do you know if there's any way to override plugin defaults through an external file (e.g. plugin_customization.ini referenced by eclipse.ini?)? For example, I would like -fdata-sections and -ffunction-sections enabled by default and to have the linker passed -Wl,-gc-sections but I can't seem to do this from an external file so have to modify the original plugin. I don't know if these can only be overridden in this way if certain APIs are used to retrieve settings or something like that?

I honestly don’t know.

I will have to do some reading up to see how this would/should work.

3. I have added a "Print Size" build step that uses riscv64-unknown-elf-size to print size stats - this is modelled on (i.e. copied from :-) the GNU ARM Eclipse plugins. Would you be interested in/willing to integrate that into the plugin? If so I can send you the modified plugin.xml.

Yes please, whatever makes the plugin more useable.

4. With the previous plugin I was able to specify -gc-sections in the linker Other flags but with the latest plugin I have to specify -Wl,-gc-sections. I can't see why but maybe this is something to do with the latest RISC-V tools versus the older ones that I was using before? Rather than a plugin issue per se (or at all)?

This seems related to the new toolchain. The plugin always calls GCC, even if it’s just running the assembler or linker steps.

-Wa, and -Wl, are the correct ways to push the options into the assembler and linker. I ended up uprooting the entire command generation script to accommodate this.

5. I haven't been able to test the update site installation mechanism for you because I still don't know what URL to specify. Maybe you can clarify?

I need to check this myself first. Again, I need to read up on how this is supposed to work.

6. When I get a chance I will try the plugin with Eclipse Neon - as I said above it installed OK but I haven't actually tried it.

I removed quite a bit of unused dependencies. I hope that resolves the issue with Neon.

Cheers,

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

Hi Richard

Thanks for the reply.

The attached plugin.xml includes the "Print Size" build step modelled on the one in the GNU ARM Eclipse plugins.

It also contains some other small mods that I made to override/change some default settings, remove the hex2verilog build step which is irrelevant to me etc.

All mods are marked with "<!-- MICROSEMI: ... -->" comments.

There are no source changes to enable the "Print Size" build step - just changes to the plugin.xml.

To merge any of these changes you can just diff/merge between my plugin.xml and your original one.

Hope this helps.

If you have any issues or questions let me know.

Regards

Tommy

[Richard Herveille]

Hi Tommy,

Thanks, I’ll already incorporated this in my source code.

I am also rewriting hex2verilog to use riscv64-.-objcopy. It’s a useful step for us hardware engineers, therefore I’ll include it.

I also fixed a typo (risc64 versus riscv64) in one of the steps.

Expect a new git-push this week. Then we’ll tackle the ‘auto-update’ issue.

Cheers,

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

<plugin.xml>

[Tommy Murphy]

Thanks Richard.

Hadn't noticed the risc64-unknown-elf-g++ typo! :-)

What does hex2verilog do exactly just in case I can assist in replicating the same functionality with objcopy?

[Richard Herveille]

Hi Tommy,

hex2verilog generates a verilog file that can be read with $readmemh.

The new objcopy has a "-O verilog” output. So I am adding the functionality to the (existing) Create Flash option.

Hex2verilog will be completely removed.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Richard Herveille]

Ok, I seem to have this working … except for the --gap-fill <value> for objcopy.

Eclipse keeps insisting on removing the space between the command and the <value>.

Does anybody know how to preserve the space in an plugin.xml argument?

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

&nbsp; perhaps?

What are you using at the moment?

[Richard Herveille]

&nbsp; is not defined in XML.

I tried regular spaces, unicodes, … nothing works as I want it to work.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Richard Herveille]

I also noticed I am missing the -fpic option.

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

[Tommy Murphy]

What about &#160;

http://changelog.ca/log/2006/06/12/making_nbsp_work_with_xml_rss_and_atom

[Richard Herveille]

Neither … &# is unicode, which is illegal in the xml file.

Richard

ROA LOGIC

Design Services and Silicon Proven IP

Richard Herveille

Managing Director

Phone +31 (45) 405 5681

Cell +31 (6) 5207 2230

richard....@roalogic.com

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/a0009d46-47dc-44df-a067-9b3876ea7713%40groups.riscv.org.

[Tommy Murphy]

Can you post a snippet of the XML where you're trying to embed a space please?

Or better still a complete updated plugin.xml if it doesn't depend on any other (e.g. Java source) changes?