On 2018-12-04, David Brown <david.brown@hesbynett.no> wrote:> I also find startup code and libraries can be terrible - they are often > written in assembly simply because they have /always/ been written in > assembly, and often bear the scars of having been translated from the > original 6805 assembly code (or whatever) through 68k, PPC, ARM, etc., > probably by students on summer jobs.I definitely second the "students on summer jobs" opinion. Over the years I've seen a lot of sample/library code from silicon vendors and most of it was truly awful. It was often clearly written by somebody who didn't have a working knowledge of either the hardware or the language they were using. Sometimes it just plain didn't work, but since the authors obviously didn't understand what the hardware was actually supposed to do, they had no way of knowing that. In my experience, trying to use anything from silicon vendors beyond the header files with register addresses/structures has always been a complete waste of time. -- Grant Edwards grant.b.edwards Yow! at BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI- gmail.com
Makefile or not?
Started by ●December 3, 2018
Reply by ●December 4, 20182018-12-04
Reply by ●December 4, 20182018-12-04
Grant Edwards <invalid@invalid.invalid> wrote:> I definitely second the "students on summer jobs" opinion. Over the > years I've seen a lot of sample/library code from silicon vendors and > most of it was truly awful. It was often clearly written by somebody > who didn't have a working knowledge of either the hardware or the > language they were using. Sometimes it just plain didn't work, but > since the authors obviously didn't understand what the hardware was > actually supposed to do, they had no way of knowing that.That's been our experience too. We reported a bug (with included fix) in a particular vendor's module, and their response was not to fix the bug but to delete the module from their portfolio. Then a few years later the module reappeared - with the bug still present. Theo
Reply by ●December 4, 20182018-12-04
On 12/3/18 4:05 PM, Jacob Sparre Andersen wrote:> Phil Hobbs wrote: > >> We use cmake for that--it allows unit testing on a PC, as you say, and >> also automates the process of finding libraries, e.g. for emulating >> peripherals. > > How does it automate finding emulation libraries? That sounds like a > cool feature. > > We use GNU Makefiles, but we handle the matching up of emulation > libraries with the real thing by hand. We then typically use different > source directories for emulation libraries and actual drivers. > > Greetings, > > Jacob >I'll ask my colleague who's doing most of the work on that. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●December 4, 20182018-12-04
On 12/3/18 2:36 PM, Grant Edwards wrote:> On 2018-12-03, DJ Delorie <dj@delorie.com> wrote: >> Grant Edwards <invalid@invalid.invalid> writes: >>> I use Emacs, makefiles, and meld. >> >> +1 on those. My memory isn't good enough any more to remember all >> the byzantine steps through an IDE to re-complete all the tasks my >> projects require. >> >> Especially since each MCU seems to have a *different* IDE with >> *different* procedures to forget... >> >> And that's assuming they run on Linux in the first place ;-) > > The most important rule to remember is: > > Never, ever, use any software written or provided by the silicon > vendor. Everytime I've failed to obey that rule, I've regretted it. > > I've heard rumors that Intel at one time wrote a pretty good C > compiler for x86.I've used it, circa 2006-7, and for my application (highly multithreaded 3D electromagnetic simulation on a SMP) it was amazing--it blew the doors off both Visual C++ and gcc under cygwin. (For sufficiently permissive values of 'amazing', that is, i.e. 1.5-1.8x on the same hardware.) ;)> > However, having used other development software from Intel, I find > that impossible to believe. [Acually, Intel MDS-800 "blue boxes" > weren't bad as long as you ran CP/M on them insteaod of, ISIS.] > > And don't get me started on compilers and tools from TI, Motorola, or > various others either... > > Some of them have put some effort into getting good Gnu GCC and > binutils support for their processors, and that seems to produce good > results. If only they had realized that's all they really needed to > do in the _first_ place...In defence of Eclipse, it does do a much better job of humanizing gdb than the other things I've used, such as ddd. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●December 4, 20182018-12-04
On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:> In defence of Eclipse, it does do a much better job of humanizing gdb > than the other things I've used, such as ddd.Ah, I remember ddd from decades back. It always seemed about 70% finished. Is it still a thing? ... there appears to be a Gentoo ebuild: # emerge --search ddd [ Results for search key : ddd ] Searching... * dev-util/ddd Latest version available: 3.3.12-r4 Latest version installed: [ Not Installed ] Size of files: 5,554 KiB Homepage: https://www.gnu.org/software/ddd Description: Graphical front-end for command-line debuggers License: GPL-3 LGPL-3 FDL-1.1 [ Applications found : 1 ] However, it looks like 3.3.12 was released 10 almost years ago. The TCL/Tk based GUI that sort of "came with" gdb for a while about 10-15 years ago wasn't too bad (can't remember it's name). But, for the most part I prefer the gdb command line -- though I sometimes use gdb-mode in emacs. Most of the embedded stuff I work on isn't amenable to interactive breakpoint/step/examine/resume type debugging anyway. Milliseconds after you hit a breakpoint, all sorts of hardware and protocols will start to timeout, overflow, underflow, and generaly get upset. Once you stop, you can't expect to step/resume and get useful behavior. Non-embedded stuff I do in Python, and don't need a debugger. ;) -- Grant
Reply by ●December 5, 20182018-12-05
On 05/12/18 03:25, Phil Hobbs wrote:> On 12/3/18 2:36 PM, Grant Edwards wrote: >> On 2018-12-03, DJ Delorie <dj@delorie.com> wrote: >>> Grant Edwards <invalid@invalid.invalid> writes: >>>> I use Emacs, makefiles, and meld. >>> >>> +1 on those. My memory isn't good enough any more to remember all >>> the byzantine steps through an IDE to re-complete all the tasks my >>> projects require. >>> >>> Especially since each MCU seems to have a *different* IDE with >>> *different* procedures to forget... >>> >>> And that's assuming they run on Linux in the first place ;-) >> >> The most important rule to remember is: >> >> Never, ever, use any software written or provided by the silicon >> vendor. Everytime I've failed to obey that rule, I've regretted it. >> >> I've heard rumors that Intel at one time wrote a pretty good C >> compiler for x86. > > I've used it, circa 2006-7, and for my application (highly multithreaded > 3D electromagnetic simulation on a SMP) it was amazing--it blew the > doors off both Visual C++ and gcc under cygwin. (For sufficiently > permissive values of 'amazing', that is, i.e. 1.5-1.8x on the same > hardware.) ;)Intel's C (and C++) compiler is still very much a major choice for the x86 platform, with good support for the latest standards and a fair degree of gcc compatibility (inline assembly format, attributes, etc.). It is generally considered to be the best choice for automatic vector SIMD code generation, and has support for parallelising code using multiple threads. But it is also well known for making code that is particularly poor on non-Intel x86 processors.> >> >> However, having used other development software from Intel, I find >> that impossible to believe. [Acually, Intel MDS-800 "blue boxes" >> weren't bad as long as you ran CP/M on them insteaod of, ISIS.] >> >> And don't get me started on compilers and tools from TI, Motorola, or >> various others either... >> >> Some of them have put some effort into getting good Gnu GCC and >> binutils support for their processors, and that seems to produce good >> results. If only they had realized that's all they really needed to >> do in the _first_ place... > > In defence of Eclipse, it does do a much better job of humanizing gdb > than the other things I've used, such as ddd. >Agreed - Eclipse + gdb is a perfectly solid debugger. It is not always perfect, but no debugger I have ever used is always reliable or works as you expect. Certainly it is fine for most debugging purposes. In the past, I have used both ddd and gvd (which later became part of gps, the GNAT Programming Studio) as front ends. There are plenty of other gdb front-ends available - those with a strong sense of irony might like to try using MS Visual Studio.
Reply by ●December 5, 20182018-12-05
On Mon, 3 Dec 2018 19:36:50 +0000 (UTC), Grant Edwards <invalid@invalid.invalid> wrote:>I've heard rumors that Intel at one time wrote a pretty good C >compiler for x86. > >However, having used other development software from Intel, I find >that impossible to believe. [Acually, Intel MDS-800 "blue boxes" >weren't bad as long as you ran CP/M on them insteaod of, ISIS.]Actually it was an excellent compiler: it was the absolute best for highly optimized code through the 80's and 90's. It was, however, persnickety and infamous for its barely decipherable errors and warnings. I think the word "difficult" sums it up. Intel's compiler STILL is the best on x86 for floating point and for auto vectorizing to use SIMD. In recent years GCC has taken the lead for integer code. For a long time Microsoft acknowledged that Intel's compiler was superior: it is an open secret that Windows itself through NT was built using Intel's tool chain, and that the OS kernel continued to be built using Intel up through XP. Vista was the first Windows built entirely on Microsoft's own tool chain. Through several major versions, Visual Studio included a configuration switch that directed it to use Intel's tools rather than Microsoft's. This always was possible anyway using foreign tool settings, but for a long time Intel's tools were supported directly. George
Reply by ●December 5, 20182018-12-05
On 12/3/18 2:36 PM, Grant Edwards wrote:> On 2018-12-03, DJ Delorie <dj@delorie.com> wrote: >> Grant Edwards <invalid@invalid.invalid> writes: >>> I use Emacs, makefiles, and meld. >> >> +1 on those. My memory isn't good enough any more to remember all >> the byzantine steps through an IDE to re-complete all the tasks my >> projects require. >> >> Especially since each MCU seems to have a *different* IDE with >> *different* procedures to forget... >> >> And that's assuming they run on Linux in the first place ;-) > > The most important rule to remember is: > > Never, ever, use any software written or provided by the silicon > vendor. Everytime I've failed to obey that rule, I've regretted it.How about for FPGAs? ;) Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●December 5, 20182018-12-05
On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote:> >> Never, ever, use any software written or provided by the silicon >> vendor. Everytime I've failed to obey that rule, I've regretted it. > > How about for FPGAs? ;)I spent some time working with a NIOS2 core on an Altera Cyclone-something-or-other. In the beginning, somebody got conned into using the Altera tools for doing software development. As expected, they were horrendous. It was Eclipse with a bunch of plugins. IIRC, there were Eclipse plugins that called scripts written in bash that called Perl scripts that called Java apps that generated TCL that got fed to other scripts that generated header files... and on and on and on. The tools required more RAM that most of our development machines had. And it appeared to re-generate everything from scratch everytime you wanted to build anything. After fighting what that for a few months we threw it all out and started from scratch with the gnu toolchain, makefiles, and our own header files we wrote with info gleaned from the above mess. There was also some sort of gdb-server executable that we extracted from deep within the bowels of of the Altera IDE. We had to write some sort of wrapper for that to get it to run stand-alone and talk to the USB byte-blaster thingy. Once we ditched the massive pile of Altera's garbage IDE, things went much smoother. [Until, as the project neared completion, it became obvious that the performance of the NIOS2 was nowhere near what was promised, and the whole thing was abandoned.] The hardware guys were, of course, chained to the Altera VHDL IDE software for the duration -- presumably for heinous sins committed in a previous life. -- Grant Edwards grant.b.edwards Yow! Kids, don't gross me at off ... "Adventures with gmail.com MENTAL HYGIENE" can be carried too FAR!
Reply by ●December 5, 20182018-12-05
On 12/5/18 2:34 PM, Grant Edwards wrote:> On 2018-12-05, Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> wrote: >> >>> Never, ever, use any software written or provided by the silicon >>> vendor. Everytime I've failed to obey that rule, I've regretted it. >> >> How about for FPGAs? ;) > > I spent some time working with a NIOS2 core on an Altera > Cyclone-something-or-other. In the beginning, somebody got conned > into using the Altera tools for doing software development. As > expected, they were horrendous. It was Eclipse with a bunch of > plugins. > > IIRC, there were Eclipse plugins that called scripts written in bash > that called Perl scripts that called Java apps that generated TCL that > got fed to other scripts that generated header files... and on and on > and on. The tools required more RAM that most of our development > machines had. And it appeared to re-generate everything from scratch > everytime you wanted to build anything. > > After fighting what that for a few months we threw it all out and > started from scratch with the gnu toolchain, makefiles, and our own > header files we wrote with info gleaned from the above mess. > > There was also some sort of gdb-server executable that we extracted > from deep within the bowels of of the Altera IDE. We had to write > some sort of wrapper for that to get it to run stand-alone and talk to > the USB byte-blaster thingy. > > Once we ditched the massive pile of Altera's garbage IDE, things went > much smoother. [Until, as the project neared completion, it became > obvious that the performance of the NIOS2 was nowhere near what was > promised, and the whole thing was abandoned.] > > The hardware guys were, of course, chained to the Altera VHDL IDE > software for the duration -- presumably for heinous sins committed in > a previous life. >Nah, you can get out of the IDE there too. You wind up having to write Makefiles that write and call Tcl scripts that communicate with a jtag-server executable that you extract from deep within the bowels of the IDE. It's deeply unpleasant, and still preferable for production code to using the IDE. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
