--- Quote Start ---
Jeff, any word on getting these patches integrated? And what is the best way to report things like this?
--- Quote End ---
The truth is I'm the only Altera Nios2 GNU toolchain guy (which is one more than we had for half a decade...) and to date I've been pretty much continuously in crisis mode putting out fires. (For some reason Altera prefers that I favor corporate customers with large contracts over forums users...) So these patches have been molding in my wishfile, alas.
I believe the Official Procedure for getting attention paid to a patch or such is to submit it as an issue via an Altera FAE. Since I only see the arriving-in-my-mailbox end of that procedure, I'm not sure what the external interface looks like. I found a big backlog of those sitting in the bugbase when I hired on. :-)
In other news:
ACDS 14.1 has transparent support for >256MB of code, no special options like -Wl,--relax-all needed. A Major Customer requested (well, demanded) this, so it was custom-developed via a Mentor contract. It works via a linker tweak which redirects jmp/call instructions to destinations outside the 26-bit immediate field range of the jmp/call instructions to little trampoline code sequences which use jmpr/callr for full 32-bit address range capability. Took awhile to make this happen, but I think the result is pretty nice, as GNU toolchain things go. (Nothing in gcc makes one gasp at the sheer elegance, exactly...)
The Linux version of the toolchain (available only directly from Mentor, since Altera does not yet have full direct support for Nios2 Linux, although we seem to be headed that direction -- e.g. we're now the mainstream maintainer of Nios2 Linux kernel stuff, if I understand correctly) supports 64KB (up from 32KB) GOT tables for position-independent code, by biasing the base pointer to point into the middle of the GOT rather than the start, thus allowing the full -32K -> 32K immediate field range to be used. (We've been hearing from customers who use C++ OpenGL libraries and such that they've been hitting the 32KB GOT wall on Nios2 Linux. C++ seems to generate a lot of globals in at least some situations; I haven't dug into that to figure out what is really going on, since officially I'm just supporting Nios2 on bare metal.)
Additionally, the Linux Nios2 toolchain now supports the conventional -fpic vs -fPIC distinction, generating "big-GOT" code when -fPIC is specified, allowing basically unlimited GOT size (at the cost of multi-instruction sequences to access the GOT).
Internally, engineering has been asking us for better code density; we were chatting with Mentor about this and they reported that from poking around a bit examining the code, it appeared that the Nios2-platform gcc/binutils code has never been seriously tuned. (That conclusion probably won't surprise you. :-) We haven't committed to funding a project to do such tuning, but it seems to be in the air at the moment.
There's more Nios2/toolchain stuff in the tubes, but I think nothing I can post about yet. Suffice to say that we're by no stretch of the imagination abandoning Nios2 in favor of ARM (say), even though we're shipping ARM-based SOPCs. (I mention that because at least one major customer seemed to be concerned about it and to need conference-call reassurance.) ARM and Nios2 are both cool, but they address very different markets, both of which are of major interest to Altera. (Personally, I'd like to put a Nios2 in a hobby UAV, using the FPGA side for low-level computer vision processing and servo control and the Linux side for high-level flight planning etc. That sounds like balls of fun and super cost-effective, but somehow the unfun projects always seem to need to be done first. Maybe this year. Just took delivery of a 3drobotics drone with a hexcopter supposedly in the mail -- they look like good platforms to hack up for this sort of stuff.)
Oh, also worth mentioning: There's a major Altera push to upstream all of our Nios2-support stuff for the GNU toolchain. Legal has signed off on it, all the relevant code has had copyright formally signed over to FSF, rms has signed off on it, and all the major parts have been reviewed and accepted at this point; expect to see gcc 4.9 and similar-generation releases of the binutils etc with Nios2 support out of the box. (One major exception is "smallc" support in newlib: That's a huge patch which I think the newlib team is unlikely to ever accept, so I'll probably be stuck hand-merging it into mainstream newlib releases for the foreseeable future. Thpt.)
So things are trundling along pretty nicely, albeit at major-corporation release-cycle speeds rather than open source overnight-delivery speeds.
-Jeff
Honored Contributor
