ARM compiler recommendation - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: ARM compiler recommendation

Quoted text here. Click to load it

As a matter of fact, it's not.  Looks like you never bothered to look
at other ports of GCC besides Cygwin32.  MinGW32, e.g., or DJGPP,
which are ports to native Win32 API (no cygwin DLL), and to 32-bit
DOS, respectively.

Even Cygwin's GCC can be used quite nicely without using their port of
Bash as the shell.  The real reason that they decided not to deliver
it that way is that Cygwin assumes a Unix-ish *environment*, rather
than the mere superficial usage of a Unix-ish shell.  That's how they
got around the ton of problems caused by issues like backslashes
instead of slashes used as directory separators, and drive letters.

But this means that most non-Cygwin tools wouldn't interact very well
with the Cygwin port of GCC.  E.g., command-line completion with the
<Tab> key works on Win2K and XP, but the command lines you get from
that would be quite incompatible with the format expected by Cygwin
GCC.  

One important aspect of this is building GCC itself.  For that, you
ultimately need a complete Unix-ish toolchain like Cygwin, unless
you're prepared to only ever cross-compile GCC from, say, Linux to
Cygwin, instead of being able to build it natively.

Quoted text here. Click to load it

But it has to *find* those files first.  And that's already where the
trouble starts.  E.g. DOS/Windows style PATH or INCLUDE path settings
would be utterly unusable to a Unix-born program like GCC without
rather massive internal changes.

It's a bad idea to look at the Cygwin port of GCC as just an isolated
effort: Cygwin is really a complete simulation of the Unix environment
on Unix, including the GCC compiler as one among many building blocks.
If a simulated Unix is not what you want, Cygwin may not be the right
choice for you.

Quoted text here. Click to load it

Because "they" do --- though for a different meaning of "they" than
the one you currently seem to be presuming.

Quoted text here. Click to load it

Not even the Cygwin ports are actually "stuck" to the Unix shell in
that way.

--
Hans-Bernhard Broeker ( snipped-for-privacy@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Re: ARM compiler recommendation

Quoted text here. Click to load it

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



Re: ARM compiler recommendation

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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 www.python.org and you will get an idea of the range of uses of
python.  I have used it to provide gui interfaces to embedded systems, for
some server programs, and for a number of small programs generating data for
other programs (such as for generating crc tables to be included in embedded
systems).

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it
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.

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Quoted text here. Click to load it
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

Quoted text here. Click to load it



Re: ARM compiler recommendation
Quoted text here. Click to load it

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.



Re: ARM compiler recommendation
Quoted text here. Click to load it
pet

I think so too - our main difference seemed to be a misunderstanding.

Quoted text here. Click to load it
a
bit
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.

Quoted text here. Click to load it
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?

Quoted text here. Click to load it

Be careful - if it is too successful, Mr. Gates will just buy you up :-)





Re: ARM compiler recommendation
On Mon, 11 Aug 2003 11:42:58 +0200, "David Brown"

Quoted text here. Click to load it

For details of our ARM Forth compiler see:
  www.mpeltd.demon.co.uk
Good code, and when combined with our PowerNet TCP/IP stack,
produces one of the smallest general purpose web servers I've
come across.

Stephen
--
Stephen Pelc, snipped-for-privacy@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: ARM compiler recommendation

Quoted text here. Click to load it

I really don't follow your problem - are you saying that it would be fine if
gcc were a windows console program rather than a unix-style CLI program?  If
so, then what exactly is the issue?  Do you think that gcc needs to be run
from, say, a cygwin bash shell rather than a NT command prompt?  This is, of
course, completly wrong (*building* a gcc compiler is far easier when you
have the full cygwin tools installed rather than a more "native" mingw
toolkit, but that has nothing to do with *running* it).  I run gcc (for many
targets) either directly from an NT/W2K command prompt (normally via make),
or via my editor (mostly jedit, but sometimes others).  A command prompt is
faster for doing less-common builds, while running via the editor gives me
automatic highlighting of source code errors and the like.


Quoted text here. Click to load it

For most popular targets, you can download ready-to-run gcc binaries for
windows.  Some even come packaged with nice installers, and other tools such
as a debugger bundled together.  It is also perfectly possible to download
the source (gcc source, plus patches if needed), and build native windows
versions of the compiler yourself.  This is definitely easier using cygwin,
since it gives you a *nix like environment under windows, and you can follow
the same build instructions as under *nix.  But the resulting binaries can
run happily without any cygwin "polution" other than the odd dll.  You can
even build gcc with mingw - this is a bit more awkward (since it is less
*nix-like).

Quoted text here. Click to load it



Re: ARM compiler recommendation

Quoted text here. Click to load it

Go ahead and fix it.

Quoted text here. Click to load 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!!
We've slightly trimmed the long signature. Click to see the full one.
Re: ARM compiler recommendation
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Third-person plural pronoun; in this case refering to the
geeks/freaks/acedemics/hackers that perpetuate the use of ancient, archiac
operating systems :-O

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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



Re: ARM compiler recommendation

Quoted text here. Click to load it
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?





Re: ARM compiler recommendation

Quoted text here. Click to load it
[Stuff snipped]

If you want a windows binary of gcc-arm with a IDE try:
http://sourceforge.net/projects/gnude/
It does not need cygwin or any other unix shell simulations.

Regards
   Anton Erasmus



Re: ARM compiler recommendation

Quoted text here. Click to load it
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).


Quoted text here. Click to load it



Re: ARM compiler recommendation

Quoted text here. Click to load it

I'm regularly running GDB on embedded AT91's with a self-made stub at the
target. It does work, even with the DDD graphic front-end. I'm sure that the
TCL/TK modified GDB (Insight by Red Hat) will work as well - even with
MS-Windows graphics.

Tauno Voipio
tauno voipio @ iki fi



Re: ARM compiler recommendation
Quoted text here. Click to load it

There-in lies the problem! I've seen some posts about problems with these
tools being related to particular versions of the TCL-TK libraries (another
massive and complex project in its own right). To me it simlpy looks like to
much effort to build, fix and maintain the tools. The build tree for all of
the components required to build the compiler was huge and incomprehensible
last time I looked. I don't know about you, but I just don't have the time
to get to know this seemingly archaic mass of trees, sources and scripts to
have the confidence to switch to it.

It was the Insight GDB (Windows GUI) that I played with on a couple of
occasions; I got nowhere and didn't have the time to persue the problem.

Regards


Tim



Re: ARM compiler recommendation

Quoted text here. Click to load it
(another
Quoted text here. Click to load it
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.




Site Timeline