On Fri, 17 Jul 2009 09:58:29 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:
>Hans-Bernhard Br�ker wrote:
>> David Brown wrote:
>>
>>> While I agree that it's bad that project files and files on the disk
>>> are forcibly tied, I believe that if a file is not part of a projects
>>> source code, it should not be in the source code directory! If a file
>>> is not part of your current program, don't keep it mixed up with the
>>> rest of the program. For my development work, I always compile using
>>> a makefile that compiles all .c files in the directory. For me,
>>> "project management" is simply file management.
>>
>> Well, that's cutting it a little to simple. Projects exist where not
>> all source files are needed in every target being made.
>>
>> Projects exist where it would be a complete nightmare if there were to
>> be such a thing as "the" source directory instead of a strictly
>> maintained tree of source directories. There's directory-based access
>> control sometimes, or auto-generated source that has no business sitting
>> in the same directory as the manually maintained one.
>
>That's all true enough - and methods that suit one type of project and
>one type of developer might not suit everyone. Let me just say that I
>think the ideal situation is a one-to-one correspondence between files
>in your source code directory/directories and the files that are
>compiled and linked into the project. But if your project structure
>does not make this practical, you will need to do something else.
IOW; it works, unless it doesn't work. If there is to be any reuse,
you're going to have files that aren't used in a particular build or
version. You certainly don't want source files spread out all over
the place or worse, multiple copies of the same file.
Reply by David Brown●July 17, 20092009-07-17
Hans-Bernhard Br�ker wrote:
> David Brown wrote:
>
>> While I agree that it's bad that project files and files on the disk
>> are forcibly tied, I believe that if a file is not part of a projects
>> source code, it should not be in the source code directory! If a file
>> is not part of your current program, don't keep it mixed up with the
>> rest of the program. For my development work, I always compile using
>> a makefile that compiles all .c files in the directory. For me,
>> "project management" is simply file management.
>
> Well, that's cutting it a little to simple. Projects exist where not
> all source files are needed in every target being made.
>
> Projects exist where it would be a complete nightmare if there were to
> be such a thing as "the" source directory instead of a strictly
> maintained tree of source directories. There's directory-based access
> control sometimes, or auto-generated source that has no business sitting
> in the same directory as the manually maintained one.
That's all true enough - and methods that suit one type of project and
one type of developer might not suit everyone. Let me just say that I
think the ideal situation is a one-to-one correspondence between files
in your source code directory/directories and the files that are
compiled and linked into the project. But if your project structure
does not make this practical, you will need to do something else.
Reply by vinnie●July 16, 20092009-07-16
>Op Mon, 06 Jul 2009 11:05:39 +0200 schreef <nobody@nowhere.com>:
>> Does anybody know what has happened to their old compilers e.g. H8/300
>> or Z180?
>>
>> Is somebody buying the rights to these products?
>
>Very small market I guess. IAR has EOLed H8/300 two years ago, and even
>then they never released a GUI version for it.
>
>
>--
>Gemaakt met Opera's revolutionaire e-mailprogramma:
>http://www.opera.com/mail/
It is funny that this question turned into a rant about IDEs, Eclipse, and
how difficult it is to change from one chip vendor to another.
Shameless Plug: everyone reading this thread should get a Renesas SPB:
http://america.renesas.com/spb
Digikey and other distributors stock them.
IDEs don't need to be expensive, limited or slow. This kit shows off the
Renesas HEW IDE and explains how you can do development on 8/16/32 MCUs
with one IDE. It has Makefile export, project management features and
integrated debugging. Plus there's DLL extensions that let you control the
whole works from VB and other tools. Renesas ompilers are essentially free
for <64k of code. And if you like GCC, you can plug it into the HEW IDE
too!
Reply by ●July 16, 20092009-07-16
David Brown wrote:
> While I agree that it's bad that project files and files on the disk are
> forcibly tied, I believe that if a file is not part of a projects source
> code, it should not be in the source code directory! If a file is not
> part of your current program, don't keep it mixed up with the rest of
> the program. For my development work, I always compile using a makefile
> that compiles all .c files in the directory. For me, "project
> management" is simply file management.
Well, that's cutting it a little to simple. Projects exist where not
all source files are needed in every target being made.
Projects exist where it would be a complete nightmare if there were to
be such a thing as "the" source directory instead of a strictly
maintained tree of source directories. There's directory-based access
control sometimes, or auto-generated source that has no business sitting
in the same directory as the manually maintained one.
>> Quite a while back I installed Hi-Tide which was the HiTech
>> implementation of Eclipse.
>>
>> During the first day I decided to delete a project and found that the
>> source files were automatically deleted as well. I complained to
>> HiTech and got the response yeah it does that. I haven't tried it
>> since.
>
> That is Eclipse for ya.
>
> Eclipse is the basis for the Xilinx EDK's SDK. I like the debug
> features but the whole thing is hateful for version control (a million
> little XML files with no apparent rhyme or reason). And yes, when you
> remove a file from the project, it deletes it from the file system.
>
> Also, consider that you have a directory called src where you keep
> your sources. Eclipse always assumes that if a file is in that
> directory, then it's part of the project. Why does this suck? Well,
> all sources are compiled. Since the MicroBlaze linker is too stupid to
> check to see if a function is actually called (no smart linking),
> everything compiled ends up in your executable. So if your sources are
> of the "one file one function" sort, a workaround is to simply not add
> the unused sources in the project. Which you can't do in Eclipse. And
> if you delete the source from the project, it's deleted from the file
> system and it messes up the version control.
>
> Maybe this was improved in 11.2. Dunno.
>
While I agree that it's bad that project files and files on the disk are
forcibly tied, I believe that if a file is not part of a projects source
code, it should not be in the source code directory! If a file is not
part of your current program, don't keep it mixed up with the rest of
the program. For my development work, I always compile using a makefile
that compiles all .c files in the directory. For me, "project
management" is simply file management.
When you take about a directory of files with one function per file, it
sounds to me like a library. If that's the case, then just build it as
a library - when you link to that library, only required functions will
be included in the executable.
Finally, although I have never used the MicroBlaze, I believe the
compiler is gcc. Depending on the version of gcc (and matching
binutils), you might have the "-ffunction-sections" switch which puts
each function in its own code section, and the -Wl,--gc-sections which
tells the linker to drop unneeded sections. Alternatively (again,
depending on the version of gcc) you might have the "--combine
-fwhole-program" switches which compiles everything at once, and treats
all functions as effectively "static". Unused static functions will
then be dropped. In other words, you *do* have smart linking - if the
MicroBlaze gcc is a new enough version.
Reply by Andy Peters●July 15, 20092009-07-15
On Jul 11, 2:10=A0pm, Raveninghorde <raveninghorde@invalid> wrote:
> On Sat, 11 Jul 2009 20:20:54 GMT, n...@puntnl.niks (Nico Coesel)
> wrote:
>
>
>
> >Jon Kirwan <j...@infinitefactors.org> wrote:
>
> >>On Sat, 11 Jul 2009 22:39:55 +1000, The Real Andy
> >><thereala...@nospam.com> wrote:
>
> >>><snip>
> >>>Well they way I see it is you can do it the hard way or the easy way.
> >>>I like the easy way. Means I can get something to market quickly, and
> >>>more time for me or more time to develop new stuff for my customer.
> >>>Yup, I can do the command line stuff, but if they take care of it for
> >>>me its one less thing i need to do and the happier I am. Bring it on I
> >>>say.
> >>><snip>
>
> >>I consider the command line way to be the easy way. =A0I have a LOT mor=
e
> >>control and I completely avoid dealing with IDE 'issues' when they
> >>happen.
>
> >>It is the difference between using a Rube-Goldberg contraption or a
> >>simple tool. =A0Compilers are very simple to use. =A0So are linkers. =
=A0They
> >>don't need all the foo-foo -- colored fonts, sizable fonts, dockable
> >>toolbars, print previews, and a bevy of things none of which have one
> >>iota to do with anything about compiling and linking. =A0When you add
> >>all those extras, no matter what, there is a whole bag of software in
> >>there which can work poorly, incorrectly, well, or anything in
> >>between. =A0And one can get caught up in trying to adjust this or that
> >>to "make it right," but it is all a waste.
>
> >>By the way, if you ask any of the developers of these tools (and I
> >>have), you will get admissions from them that they spend something on
> >>the order of 80-90% of their VERY VALUABLE compiler knowledge time on
> >>all this dross. =A0Which means it is time that does NOT go into the
> >>compiler or linker, where I'd MUCH RATHER it be spent.
>
> >I doubt that. Judging from the IDEs from Keil and IAR they spend too
> >little time on their IDEs. Its a pile of crap. There is a good reason
> >everybody seems to move to Eclipse. I'm not saying Eclipse is perfect
> >(it is a Java application after all) but it does a lot of wonderful
> >things that make it easy to deal with sourcecode and it helps to
> >organize different builds as well. I have projects that produce over
> >10 different pieces of (related) firmware.
>
> Quite a while back I installed Hi-Tide which was the HiTech
> implementation of Eclipse.
>
> During the first day I decided to delete a project and found that the
> source files were automatically deleted as well. I complained to
> HiTech and got the response yeah it does that. I haven't tried it
> since.
That is Eclipse for ya.
Eclipse is the basis for the Xilinx EDK's SDK. I like the debug
features but the whole thing is hateful for version control (a million
little XML files with no apparent rhyme or reason). And yes, when you
remove a file from the project, it deletes it from the file system.
Also, consider that you have a directory called src where you keep
your sources. Eclipse always assumes that if a file is in that
directory, then it's part of the project. Why does this suck? Well,
all sources are compiled. Since the MicroBlaze linker is too stupid to
check to see if a function is actually called (no smart linking),
everything compiled ends up in your executable. So if your sources are
of the "one file one function" sort, a workaround is to simply not add
the unused sources in the project. Which you can't do in Eclipse. And
if you delete the source from the project, it's deleted from the file
system and it messes up the version control.
Maybe this was improved in 11.2. Dunno.
-a
Reply by ●July 13, 20092009-07-13
On Jul 13, 12:13=A0am, Walter Banks <wal...@bytecraft.com> wrote:
> > Really? =A0I've yet to work at any company that standardized on a parti=
cular
> > IDE -- they are just too many bits and pieces that don't typically inte=
rface
> > "nicely" to a generic IDE.
>
> About half of our customers have company standard IDE's. that integrate
> their tools. They use tools sets that support error reporting standards a=
nd
> tool execution standards. Source level debugging is done using one of abo=
ut
> 3 or 4 standard formats.
>
> They do well at mixing compilers, processor simulators, system simulators
> jtag and other background mode emulators with a common IDE.
So many of these things become possible when you are willing to put
that critical hacking session to make them work. For example, gcc can
be launched out of Visual Studio just fine... if you write a script to
reformat the error messages to what VS expects. Abandoned that long
ago, but it was a useful capability for a while, building embedded
code from the same environment used to debug a desktop build of the
algorithms.
Reply by Walter Banks●July 13, 20092009-07-13
rebel wrote:
> On Sun, 12 Jul 2009 23:00:56 -0500, Walter Banks <walter@bytecraft.com> wrote:
>
> >
> >
> >MC wrote:
> >
> >> Having optimizations turned off is pretty bad -- the code frequently
> >> bank-switches to the memory bank it is already in, for instance. So the
> >> un-optimized compiler is good for learning C and testing algorithms, but
> >> its output is rather bloated.
> >>
> >> I seem to recall they want over $1000 for the optimizing version of the
> >> compiler. I wish they would get it down to much less, or even give it
> >> away free as they do their other tools.
> >
> >Turning off optimizations never helps promote a compiler. It is counter
> >productive for the compiler company. A couple numbers that are worth
> >mentioning about compiler development is a good compiler for a new
> >processor typically costs about 10% of the silicon development cost and
> >currently generates about 1% of the total revenue.
>
> So raising the selling price of the silicon to get an extra 1% into the till
> (i.e. negligible) would offset the loss of revenue from giving away the tool,
> even if you ignore the increase in small volume sales that such a move would
> generate.
Partly correct. The business perspective in much more complicated. It
would mean contracting out compiler development and funding that at
the same non revenue time that the silicon was being non revenue putting
more financial pressure on the silicon company when they can least afford it.
You are correct in the long term.
The tools needed to support small volume sales effectively are different
than the tools that are needed for large volume sales. The initial question
is, "Why should that be?" Most of the differences are around source
management, application metrics, code maintenance, debugging, validation
and regression testing.
Small volume stresses fast time to market, solid reference designs
low debugging costs and testing.
The needs of the two markets are quite different.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com
Reply by rebel●July 13, 20092009-07-13
On Sun, 12 Jul 2009 23:00:56 -0500, Walter Banks <walter@bytecraft.com> wrote:
>
>
>MC wrote:
>
>> Having optimizations turned off is pretty bad -- the code frequently
>> bank-switches to the memory bank it is already in, for instance. So the
>> un-optimized compiler is good for learning C and testing algorithms, but
>> its output is rather bloated.
>>
>> I seem to recall they want over $1000 for the optimizing version of the
>> compiler. I wish they would get it down to much less, or even give it
>> away free as they do their other tools.
>
>Turning off optimizations never helps promote a compiler. It is counter
>productive for the compiler company. A couple numbers that are worth
>mentioning about compiler development is a good compiler for a new
>processor typically costs about 10% of the silicon development cost and
>currently generates about 1% of the total revenue.
So raising the selling price of the silicon to get an extra 1% into the till
(i.e. negligible) would offset the loss of revenue from giving away the tool,
even if you ignore the increase in small volume sales that such a move would
generate.
Reply by Walter Banks●July 13, 20092009-07-13
Joel Koltner wrote:
> "Walter Banks" <walter@bytecraft.com> wrote in message
> news:4A574681.1A6D66@bytecraft.com...
> > We encourage and support our customers to use the IDE they are familiar
> > with (most have company standards on IDE's).
>
> Really? I've yet to work at any company that standardized on a particular
> IDE -- they are just too many bits and pieces that don't typically interface
> "nicely" to a generic IDE.
About half of our customers have company standard IDE's. that integrate
their tools. They use tools sets that support error reporting standards and
tool execution standards. Source level debugging is done using one of about
3 or 4 standard formats.
They do well at mixing compilers, processor simulators, system simulators
jtag and other background mode emulators with a common IDE.
Regards,
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com