(another
to
of
incomprehensible
to
You might be better off just buying pre-build windows binaries, with telephone support. It is always important to balance the time taken to get tools working as desired with their costs.
And as for a gdb front-end, try "gvd" - it comes as a ready-to-run windows program and can attach to any gdb back-end.
Yes.
Yes. I've even read that you can use MS Visual Studio to drive gcc.
OK.
--
Grant Edwards grante Yow! ... Um...Um...
at
visi.com
I thought that the executables need cygwin.dll to run, but they don't need the shell (which I thought was what he was asking).
--
Grant Edwards grante Yow! I feel real
at SOPHISTICATED being in
visi.com FRANCE!
Hey calm down now ;-) I'll tell you what kind of programmer I am... BUSY! Yes I'm extremely interested in many new ideas, provided they're of benefit. I understand enough about python to know I don't want to know any more about it; it's yet another language for scripting, spawned from acedemia. Similarly with 'tcl' a mammoth project for assitsting with compiling tools... very niche, very huge and not relevent to my daily work.
Your presumptions are incorrect Mr Brown; I just happen to be interested in technologies that have practical benefit and have a future. In particlar I've spent a lot of personal time investigating xUML, template metaprogramming, asynchronous computing, low energy computing, reactive systems, convergence of hardware and software and numerous languages, OO design patterns and the list goes on.
As a devoloper with nearly a quarter of a century of experience I don't actually beleive batch development (edit, compile, link, download, debug) has a futeure in any case; experence has shown me that far too much time is wasted with faulty silicon, compilation tools, poor quality commercial RTOSs and device drivers. Forth would be of more practical use to me than python... and that's nearly as old as me.
I'm most interested why you would think that becoming 'python' and 'tcl' savvy would be time well spent for embedded development in any case. What sort of programmer are you? Have you ever written a compiler or an interpreter or an RTOS. How can microprocessor and software architecture be impoved for lower power, smaller packaging, greater reliablity and faster development... or do you just spend your time writing scripts to build tools?
Tim
Go ahead and fix it.
"They?"
"They" probably could, but "they" don't particularly want to, since "they" seem to be happy running it on Unix. Even if it didn't require Cygwin, that's the only way I'd ever use it on Win32.
"You" are the one who want's something else. It's free, open source: you want it to complier/run under native Win32 w/o Cygwin, then you do it or hire somebody else to.
--
Grant Edwards grante Yow! FUN is never having
at to say you're SUSHI!!
visi.com
I might just do that... If I were a student, didn't have a life, didn't have any deadlines and couldn't think of more interesting projects to spend time on. The cost in time and money to a business for 'fixing' tools just to be able to build a compiler exceeds the cost of a good quality commercial compiler by orders of magnitudes... or are you suggesting 'fixing' other peoples tools just for fun? I don't know about you, but I certainly don't have the time in my job and I have far more interesting projects of my own for personal time... and then there's the wife and daughter.
Third-person plural pronoun; in this case refering to the geeks/freaks/acedemics/hackers that perpetuate the use of ancient, archiac operating systems :-O
So? All you're saying is you and the GCC creators prefer Unix to Windows; personally I think they both stink to high heaven. By quirk of fate, I happen to have a working lifetime's experience using and developing for Mr Gate's dismal efforts; most of my clients also use Windows workstations for software development. I have neither the time, nor the inclination to become competent in Unix just for the sake of being able to build a compiler, that's for sure. I'm quite happy with ARM's ADS compiler and very excited by their RealView compilation tools... for Windows I hasten to add. Ironically, ARM seem to manage to be able to produce all of their tools for both platforms quite competently.
Au contraire Mr Edwards; I use ADS v1.2 and RVCT 2.01. They ain't perfect, but they work out of the box ... mostly (although curses to FlexLM and all who develop/lash it together). If you go back to my original reply to the gentleman, I listed three different compilers for ARM that I have had experience with and a short satement of my opinion of them... which is what was asked for.
I'm not pooh-poohing the open source movement; far from it. I've got some interesting stuff from GNU and others (XASM, Forths and other interpreters, embeddable GUIs); haven't really used anything practucally though. The Boost template libraries are extremely impressive; top-notch quality. I hope to be contributing something rather neat myself soon too.
Tim Clacy
-Wall
/RogerL
-- Roger Larsson Skellefteå Sweden
[Stuff snipped]
If you want a windows binary of gcc-arm with a IDE try:
Regards Anton Erasmus
Sorry about that - I get a bit stressed myself sometimes. But it bugs me when people dismiss tools out of hand, just because the one thing they know about them is not interesting. I know that everyone, including myself, does it - but you managed to misjudge a fair number of great tools and languages in just a few short sentences.
benefit.
about
That is true - for python of seven years ago. While python has an accademic background (the language's "benevolent dictator for life" is a mathematician), and is popular in accademic and scientific circles, it is widely used in all sorts of programming on desktops and servers, commercial and open source, big and small, for quick prototypes and for full systems, with almost all programs being cross-platform between windows and *nix (and often mac) systems. Spend two minutes looking at the range of library modules at
Similarly with tcl/tk - it is a big system, with a wide range of uses, of which "assisting with compiling tools" is just one. It is fair enough that you don't want to learn about these sorts of tools - I have never had the inclination to learn tcl/tk either. But you wrote that you shied away from programs written by others that used these tools - and that is going too far.
in
Personally I think it is the most efficient method for many types of programming (although it's worth noting that I use python for PC programming - and that means there is no compiling or linking, and I can easily change and modify programs while they are running), especially for embedded programming. Although the compile and link steps are a relic of older, less powerful computers - for embedded development, they should be fused to give more optomisation possibilities.
Unfortunately, we don't get to change the world, and you are stuck with batch development for most embedded development. I would like to avoid C - I think it is a rotten language for small embedded systems - but in many cases, it is the most practical choice.
is
RTOSs
This is certainly the case - but trying to integrate tools into large monolithic lumps will only make it worse. Let the compiler experts write compilers, and the editor experts write editors - I am not interested in an IDE with a great compiler and a buggy editor, or vice versa.
Forth has many advantages (many disadvantages too). The idea of debugging, testing and changing the program while running the system has a lot of uses. It is also more cross-platform than many other languages. Kind of like python, really.
Actually, I didn't suggest that becoming an expert in python and tcl/tk is going to be time well spent for you (although if you do much pc programming, then python could be worth it). My complaint was that you seemed averse to using any software that relied on tcl or python. To quote, "If I'm going to run into Unix (or folders with 'trampoline', 'etc', 'tcl', 'python' in the names), please tell me now and save me the bother." You sounded like you were scared of anything new outside your cosy little windows world - the kind of programmer who would be overjoyed if MS brought out Visual Basic for the 8051. Obviously, that does not apply to you. For my incorrect assumption, I appologise - but I think you can understand why I read your post in that way.
be
I've been an embedded systems developer for about ten years, on a variety of systems, and I also do pc programming, server programming, some electronic design, and a whole lot of other stuff (it's a small company, and I'm addicted to reading manuals, so I get a lot of odd jobs). I write programs and scripts (how do you define "script" ? Is that a program for an interpreted language?) for pcs when they are useful - I could not do my job properly without them. But, as I said, I am not suggesting every embedded developer learns pc programming, or to use command-line programs (I use "windiff" rather than "diff" because the gui is normally more useful).
David
message
Can you name a modern computing platform that has a screen, keyboard and mouse, and is not a dedicated system (such as a games console or dedicated email system), that is not sufficiently unix-like? Some platforms, such as windows and macs, need a few downloads, but that's nothing that can't be easily remedied (given the disk space and internet bandwidth).
have
time
It's fair enough feeling you don't have the time to work on open-source software yourself, but you are going a bit far with your insults - the smiley doesn't help. Just remember that without these geeks/freeks/acedemics/hackers, computing as you know it would not exist. Or are you so naïve as to believe that MS wrote all the software in windows, ARM wrote all their developement tools from scratch, and Al Gore invented the internet?
David Brown wrote:
David. OK, I think we're mostly on the same planet :-) Incidentally, my pet project of some two years is an interpreter for either embedded or desktop development. I loath the edit, compile, link, download, debug cycle; it's a stiffling way of working; too many things have to work before anything works. An interpreter just needs to be able to read and write a byte or bit steam; new hardware can be up and under development very quickly. As regards your concern about performance, here is where I have a rather interetesing idea (as far as I know, unprecidented)... The interpreter is merely the core mechanism for constructing event-driven state-machines from definitions. The language, therefore is an extremely simple language NOT for running programs but for defining optimally efficient machines that interract through events (soft signals). It simply can't be beaten; the best optimizing compiler in the world can only optimize short sequences of code, not multiple loosely coupled threads. Best yet, for 'light-weight' signals (those that have no context), the only CPU context that needs saving and restoring for switching execution between different machines is the program counter; this is intertia-less threading. Thread-switching between C/C++ compiled code always requires a full CPU context save and restore (plus cache flush + TLB flush on some OSs - process switching). Of course, once the core interpreter is up and running, you can construct more sophisticated interpreters, themselves event-driven state-machines. For instance, you could build an interpreter that accepts xUML models (executable UML models). Heck, you could also build a Java VM live on the platform!
One really suprising thing about this is that the base VM needs only four intructions and one working register; that means that you could implement this in hardware in a few dozen gates... and get rid of the CPU all together! Another revalation is that it scales beautifully; two VMs is 2 x the power, 100 VMs is 100s x the power. There's actually enough chip area on a typical embedded CPU for 10s of thousands of these. Oh... and the icing on the cake; because the base VM is so simple, it could spin at THz... and its' totally adiabatic; you could implement it in energy recovering logic; then, thousands of these things running concurrently would use only a fraction of the power traditional CPUs. I'm going to put it on GNU shortly (for ARM architecture); of course, the only platform dependent bit is the four instructions... so it's pretty darned easy to port :-)
Tim
P.S. An OS (kernel, drivers, services) can be implemented entirely as event-driven state-machines; this could actually put Mr Gates out of business.
pet
I think so too - our main difference seemed to be a misunderstanding.
abit
regards
core
The
programs
events
I'm not sure that you'll make an interpreter that can't be beaten for efficiency (run-time efficiency, that is - you can easily beat compiled code for code compactness). But certainly C and other procedural (or OO) languages are never going to be able to get the most optimal code - they insist on doing things in the order that is written, even if that is not the best order.
switching
TLB
interpreter
on
on
its'
then,
of
This is going to be very interesting to look at once you're ready - I take it you'll post a link to your website once its ready for others to try?
Be careful - if it is too successful, Mr. Gates will just buy you up :-)
For details of our ARM Forth compiler see:
Stephen
-- Stephen Pelc, snipped-for-privacy@mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web:
Actually even compared to -Wall ADS produces more warnings. We use the following for gcc:
-Wall -Wstrict-prototypes -Wshadow -Wpointer-arith -Wwrite-strings
-Winline
-- 42Bastian Do not email to bastian42@yahoo.com, it's a spam-only account :-) Use @epost.de instead !
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.