Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Mar 1996 22:17:06 +1030 (CST)
From:      Michael Smith <msmith@atrad.adelaide.edu.au>
To:        kuku@gilberto.physik.rwth-aachen.de
Cc:        msmith@atrad.adelaide.edu.au, terry@lambert.org, jdp@polstra.com, nate@sneezy.sri.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: GAS question
Message-ID:  <199603171147.WAA19417@genesis.atrad.adelaide.edu.au>
In-Reply-To: <199603171115.MAA09356@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Mar 17, 96 12:14:59 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Christoph P. Kukulies stands accused of saying:
> > 
> > VC++ is targeted to _one_ processor.  GCC supports several dozen.
> 
> This ain't quite true. VC++ is also targeted to Alpha axp and - I don't
> have my VC++ 4.0 CD handy right now - I believe to other platforms as
> well. 

OK, I'll rephrase it then; VC++'s code generator was designed with a single
target in mind, GCC was designed from the ground up to be target independant.

As Bruce has observed, the GCC 'constraint' mechanism lets you tell the 
compiler in explicit terms what effect your code, or a call to an 
external routine, has on the state of the processor, in a general and
portable fashion. 

In, say, an embedded environment, this saves you from having to wrap all
your firmware calls in register save/restores.  I'm sure it wins big 
elsewhere, that's just my personal experience with it 8)

> --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de

Speaking of personal experience, there's been a lot of bitching about
Unix development tools going on.  It's been my experience that many 
Unix-environment programmers are basically Luddites.  There _are_
tools that fit at _least_ half of the wishlist items I've seen bandied
about here, it's just that _nobody_uses_them_!

For crying out loud, wasn't it you, Terry, that was complaining about 
not having an environment where you could click on a compiler error
and jump to the offending line of source?  Emacs has been doing that
for as long as it's known what a mouse _is_.

You want a debugger that will show you the source as you trace, will 
let you recompile, reload, breakpoint from where you were and start
again?  GDB swallowed in an emacs will do that too.  ddd and ups are both
wonderful tools.  gdb-remote is so f*cking fantastic that Cisco appear
to use it; cygnus certainly aren't going broke just yet, and gcc & co.
are basically their bread and butter AFAIK.

For all the spewage about Motif, the X4u stuff, particularly their
DTP package, looks _gorgeous_.  WordPerfect works, and doesn't suck 
too badly either.

Excess use of 'application frameworks' leads to 'framework applications'.
Yetch.  Who needs 'case statements'?  That's what event bindings under 
any decent X-using toolkit are for.  Kuku can complain that Tk may not
ring his bell - if all he's talking about is its visuals, then I suggest
that looking uder the hood at the work it takes off your program would
be a good start.

No, the tools aren't perfect.  Yes, 'good enough' tools _do_ exist.

I don't swallow the inverse-NIH, sorry.

(Rant off.  I just saw "Judge Dredd", and I didn't like it either. 8)

-- 
]] Mike Smith, Software Engineer        msmith@atrad.adelaide.edu.au    [[
]] Genesis Software                     genesis@atrad.adelaide.edu.au   [[
]] High-speed data acquisition and      (GSM mobile) 0411-222-496       [[
]] realtime instrument control          (ph/fax)  +61-8-267-3039        [[
]] Collector of old Unix hardware.      "Where are your PEZ?" The Tick  [[



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603171147.WAA19417>