== 11/14/07, Grant Edwards == (and 11/14/07, Peter Jansen later)
On 2007-11-14, Oleg Verych <[email protected]> wrote:
For the Nth time, I'm once again stuck because mspgcc and/or
binutils doesn't know about the device type I'm using (this
time it happens to be the MSP430F2330).
Why does the compiler have to be aware of the exact part I'm
using?
Maybe this is because of the ``usual'' application for IA-32
or AMD64 types of *CPUs*.
No, it isn't. There are ports of mspgcc to other architectures
(e.g. H8, SH, 6812, 68K, ARM etc), that all have scores and
scores of different models, and none of them have the problems
with CPU model support like mspgcc does.
Let's say features, not problems.
However, most of those ports don't include header files for the
peripherals at all like the MSP430 does. That requires you to
know enough about embedded systems development to be able to
choose and modify an include file or a linker script. mspgcc
tries to hide everything beneath the covers. The problem with
that is that it limits the usage to the cases that have been
previously set up.
But, it's easier and faster to spend 30 seconds modifying a
linker script and include file than it is patching and
rebuilding an entire toolchain.
So, not that bad, isn't it? Only to make this system more flexible
requires some work.
[]
But C compiler is just part of whole c-libc-asm-linker chain,
of course.
True, but I don't see your point.
I meant, that there's room to place flexibility to. First two (c-libc)
are just text processing. Very poor text processing, limited to just
make-it-build on all UNIX clones and Win32 (autoconf/automake) and to CPP
(C preprocessor: #include, #ifdef/#endif) is a problem.
Designing powerful configuration system, that is capable of point-tuning
source on many levels, like
* per-coded-feature (CPU, peripheral: to build/to do not, tune parameters),
* per-function,
* per-code-line
is a very big problem. And i saw such problems in the (modern hype) Linux
development.
There are very old problems, like in GNU tools -- a bunch whores that
require to be available on every possible OS today. Or hardware whore
Linux, that have quite opposite config/build requirements, but still is a
software project. They developed their ways, usually very old on the
base.
Nothing new scalable and flexible is available (in open source, i mean).
But i still think, that ideas of 70s, not CPP, but mainly stream editor
and regular expressions (all in one is `sed`), with some additional
specialized (for speed) tools, glued with quality shell scripting, can
bring portable, flexible, scalable and maintainable solution.
Sadly in 1990s/2000s with all that perl, web, python stuff, many just
don't or even can't realize this now.
There should be an example. This is one of the highest entries in my slow
TODO list. There's so much crap to get rid of, that i just stuck, like
bulldozer.
It's time to make new design decisions and to invest time to
flexible infrastructure, once
I think it would reduce support headaches if the toolchain
didn't know about every individual CPU model number. Just
provide code generation options (HW mult or not, 20-bit
addressing or not). Providing include files for the different
peripherals is great, but that doesn't need to be hooked into
the toolchain.
GCC ports for other processor families (e.g. Hitachi H8) don't
have this problem: you tell it which of the three or four
instruction sets to generate code for, and you're on your way.
The H8 port doesn't have to know about the 50-100 different
processor model numbers, since they all have common
instruction sets. Hitachi can introduce new parts until
they're blue in the face, and you don't have to upgrade gcc
since the new parts all use one of the already-supported
instruction sets.
MSP430 itself and mspgcc are going to go up in numbers.
Which is why the close coupling between the MSP430 model
numbers and the toolchain is going to become more and more of a
problem in the future.
Especially for those, who have almost no time or courage to develop open
source, only to use (which is good after all) mostly. Only Linux-hype is
one. But still it's just hundreds of people easily pushing crap further.
Did you see same in glibc (~two main developers), GCC (collection) (~10
or so)?
== 11/14/07, Peter Jansen ==
[]
Is there some way to de-couple the cpu type from the toolchain
a little? Maybe by provide a "generic" CPU type and a linker
script and msp430xXXXX.h template file?
I did a patch for this quite some time ago (2007-01-27), asking for
comment and quite some water has gone under the bridge for work on the
compiler since then.
Its quite possiable to use the MSP-A and MSP-B (and now MSP-C for the X)
CPU definitions. This makes the compiler devoiced from the CPU type
number and then binutils to select a 'generic' linker script and then
just change your linker script for the application. Sould I re-work the
patches and put them in now?
I know... quit whining and do it...
A few hints above, whining might prompt someone to do something about it :-)
I see another development problem here.
There must be a distributed development, not personal patch/personal
commit.
The main issue is making new versions to be built and available for
testers. Testers, who in this case, are not interested in whole
to patch/to build/to report toolchain problems.
I don't know what SoureForge provides, but now it's quite obvious, that
there's one main platform: linux-2.6/glibc-2. A software package built
against this two is in 90% cases should work on any distro (static build
sould work on 99.9%). It's almost like WinAVR. And yes it's possible in
open source now. All distro zoo is just noise with fancy
security/virtualization KDE-vs-Gnome stuff.
So, making a build server somewhere, managed with e-mail + automatic
commit checks, that will produce daily build archives, that can be easily
`tar -jxf` unpacked/installed into /usr/local, will bring more dynamic.
No stupid CVS-vs-SVN-vs-all or python-vs-ruby flame wars. Just plain
linux-glibc, shell, MTA (mail transfer agent, like exim) and some tools.
Debian has one, but it is the distribution, just building available
soft, not interested in development, only in bugs and politics and
religion.
Easy, distributed development structure is the thing, that can help.
But if you saw my prev. trolling about sucking software, i should say,
that there's much more crap to cleanup before anything can be done
*easily*.
--
-o--=O`C
#oo'L O
<___=E M
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
