In article <8uui3a$lpp$1@inn.qnx.com>, Brown, Richard <brownr@aecl.ca> wrote:
Just to add my 0.02$ cdn.
Watcom is in the process of becoming OpenWatcom (free - see the newsgroups
hosted on news.scitechsoft.com) and the maintainers seem to be an eager
bunch. One mentioned that they would like to see a version 11 for QNX4 (but
they can’t do it alone they need QSSL support). I bet they would also be
willing to produce a x86 NTO compiler with some QSSL support.
This keeps being raised, but I doubt if anyone has considered the complexity
of such an undertaking, and whether there are the resources available for
it or a substantial demand for it.
First and foremost, the Watcom compiler itself is unable to generate
ELF objects, while the linker is only capable of producing ELF executables
and can’t deal with ELF libraries, or ELF AR archives, to the best of
my knowledge.
Couple this with the difficulty of dealing with shared objects. Now,
the linker would have to know about dealing with UNIX ELF shared objects
and relocations. In addition, the code generator must be capable of
generating position independent code, including an alteration in the
register allocations available and the calling conventions assumed.
This is a lot of work, and I would be less pessimistic if I believed a
serious undertaking to port to Linux were underway.
Given the above, one has to wonder what driving reason there would be
for doing so, given that C9X is on the way, which would have a major
impact on the demands for the C compiler, the C++ compiler is way
out of date, and floating point, for example, while IEEE754 compliant
isn’t compliant with newer specifications or with the arithmetic
aspects of C9X.
To give you a hint, there are a number of compiler issues that would
negatively impact open source ports to the Watcom compiler. An alarming
amount of code of UNIX origin assumes one or more of the following nasties:
- Stack parameter passing is always used, and it’s safe to
call a fixed argument function with variable numbers of arguments
- void returns from non-void functions are okay
- Variable argument lists use the pointer model (as opposed to arrays),
AND
It’s okay to do an assignment to or from a va_list
- Floating point unordered results always return false for any
binary arithmetic operation
- This is really nasty to find, giving unpredictable incorrect results
I’ve hit all of these and more too many times to count.
“Bill at Sierra Design” <> BC@SierraDesign.com> > wrote in message
news:8uudh8$hac$> 1@inn.qnx.com> …
Dan <> none@no.spam> > wrote in message news:8usiv0$l28$> 1@inn.qnx.com> …
I’d like to, but we do not have QNX4. We started working QNX products
(Neutrino) in February this year. We took a certain amount of risk by
plunging straight into a new OS, but we never looked back. It’s perfect
for
our application.
There will aways be issues to sort out, new drivers to port etc, but
full
credit to people at QNX, they’ve started with a great kernel and built
it
into a very good platform for real-time apps.
Of course some of us have known this for many years.
I think it’s a little unfair to compare gcc with MS VisualC++ because
gcc
is
much more generic compiler. MS target only one class of processors and
can
afford using wider range of instructions including the specialised
instructions found in MMX etc.
{
/*
Unfair? Maybe.
But if I am developing for platform X I want to use whatever
runs best on platform X.
*/
platform X = Intel( QNX );
}
\
–
Steve Furr email: furr@qnx.com
QNX Software Systems, Ltd.
