> From: Peter Restall > The problem boiled down to the Microchip guys patching the GNU/Linux toolchain > in a way that assumed a 32-bit host architecture, meaning sign extension and > other bugs frequented the 64-bit builds. Not casting aspersions here, as these > things tend to happen when budgets/deadlines are involved (especially with a > relatively niche processor/environment and limited target audience); but I'd > have personally expected better integration. I feel the same. 64-bit machines have been widely available for a couple of years at this point. Pretty soon you won't be able to buy a 32-bit desktop. And given that these tools came from unix, the lack of 64-bit unix support is getting more glaring and unprofessional all the time. > I basically managed to use my patched toolchain for a while even though they > were nothing more than surface hacks; I had to put up with the occasional > annoying 'hang' when compiling with optimisations on certain files (easily > fixed by re-compiling without optimisations for those offending files), but > all-in-all it was OK. However, I hit a terminal problem when I started adding > assembly files to my project; missing this and that, unresolved symbols, etc. Ah. Great. So I'm doomed. > At the point I could no longer link with assembler modules I gave up (I've no > desire and real time to learn the binutils internals) and just started using > MPLAB on my 32-bit XP partition. I don't actually like the MPLAB product > (annoying bugs and it looks old / half-baked compared to what I'm used to). Yup. As someone who's used VB, Delphi, Visual Studio, Netbeans/Eclipse, etc for nearly two decades, MPLAB is rather clunky. Does one or two things really well, but I think the only thing that saves it is the small size of most PIC projects. > I prefer my GNU/Linux toolchains, but credit to Microchip as they've released > most of it for free. With any luck the future releases will continue with > the GNU tools, but they will be better tested on a range of architectures. Well, not not that much credit, given they HAVE to release it under GPL. I've found it a little contradictory that they take advantage of such a robust open-source project (saving them years of work) yet basically release it in a broken state and insist that the PIC headers and library files necessary to make it function can't be redistributed. Especially since the level of "intellectual property" in those files is essentially nil, comprising mostly of a long list of register names and addresses that anyone could obtain from reading their public datasheets. As for switching off optimizations in the GNU compiler? Don't get me started. Their licencing effectively kills any interest in improving their tools or creating easy-to-install packages, because we can't legally redistribute them. So they stay bad, confined to 32-bit windows, and off the computers of millions of people who can't dedicate three days to patching source. As someone else said recently, Microchip needs to figure out if they're in the business of making silicon or selling compilers. I would hope the former, since their chips are fantastic, but their development tools are sub-standard. This leads to new generations of hardware hobbyists and university courses using Atmel instead, because their tools are available, and easier to install. Yes, windows might be the most popular consumer OS in the world, but the target audience is PROGRAMMERS. Let's not even get into the issues with trying to build multi-target projects on windows, without a decent makefile. Compile farms? Version control? Unit and regression testing with .bat files? Don't make me laugh. And even if you manage it, your environment will be so non-standard as to make it nearly impossible to share your work. > From: Xiaofan Chen > > That being said, probably Microchip will fix the issues now that > they are developing a new IDE for Linux and Mac OS X. As > per previous post by Alan Pearce the new IDE will be based > on NetBean. So the associated toolchains will also be ported. > I hope they will then support 64bit Linux. Well, there's at least hope for the future. Perhaps they could accelerate their program by releasing the compiler toolchains sooner. Then we can hammer on them and fix the core bugs while they're still fiddling with the syntax highlighting. Seriously, if they could get their act together on the compiler, I suspect most of the rest of the work would be done for them. > From: "William \"Chops\" Westfield" > > Don't 64bit OSes continue to run 32bit applications? Why do a 64bit > build of gcc/etc at all? Three reasons: 1. Speed 2. Reliability 3. Speed I know that's technically only two reasons, but it's such an important one I though I'd mention it twice. But yes, I see your point. I'm considering it strongly. GCC itself is perfectly happy on 64-bit. I just hope their "configure" copes with targeting ia32 on a 64 bit machine. > From: "M. Adam Davis" >> Well, they are re-doing the MPLAB toolkit in Java. > > Say it ain't so! Not the whole toolchain, I assume, as that would be stupid. Just the IDE. > I don't have anything against Java itself, but the tools that are > produced often leave a *lot* to be desired. Eclipse is ok sometimes, > for instance (bloated and slow, but 'ok' for some values of ok) but, > for example, the AVR32 environment that was built on top of it is an > absolute dog in terms of performance and usability - worse than normal > eclipse, and don't get me started on the programming process. Eclipse is going through a tricky adolescence at the moment, growing into a generic IDE platform rather than the slick Java-only environment it used to be. But for all it's faults and modern bloat, I still use it because it's moving in a good direction and can do things other IDE's just can't. (Even if Mylyn seems a bit silly.) > I hope they have some wicked smart Java engineers doing the work, but > I fear the result will be a step backwards. Agreed. Some of the extended language toolkits are just awful. > From: "Alan B Pearce" > I was told by a sales guy that "it is being rewritten in Netbeans" ... How long ago? It hasn't been called that for a while now. :-) > Realistically Java is probably the best way to get easy multi-platform > tools. Yes. One thing I do love about Eclipse is I have it installed on Windows, Linux, and Mac, in multiple locations and it's exactly the same everywhere. My choice of IDE is totally decoupled from my choice of OS. I have PHP projects where I can sit down at any computer and ten minutes later be hacking my code in the cloud with ease. Which is the general concept I'm trying to bring to PIC development. Program anywhere, anywhen, from any browser. Code wants to be free, but programmers want it more. -- Jeremy Lee BCompSci (Hons) The Unorthodox Engineers www.unorthodox.com.au -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist