HP3000-L Archives

February 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jim Wowchuk <[log in to unmask]>
Reply To:
Jim Wowchuk <[log in to unmask]>
Date:
Wed, 22 Feb 1995 10:28:56 +1100
Content-Type:
text/plain
Parts/Attachments:
text/plain (65 lines)
At 11:40 AM 21/2/95 -0800, Bruce Toback laments:
>The problem is not one of "how difficult" but "how many would be sold."
 
HP *should* have some idea based on how many C vs C++ compilers are sold on
the 9000, then scale back those number for the 3000.  My impression is that
while C on the 3000 is available, it very much a minority language compared
to Cobol, Pascal and probably even Fortran! If the market isn't there then I
guess it becomes a pretty low-priority task  :(
 
>First, the ported compiler has to have the "look and feel" of any
>other HP3000 compiler. That means its defaults may need to be different
[snip...about look & feel, pragmas, iostreams and xdb]
 
Should the task be that difficult?  After all, the C++ compiler on the 9000
already produces object files compatible with the 3000.  So the compiler
probably already is compatible.  Given that the C manual is now the same for
both 9000 and 3000, I wouldn't expect the C++ manual to be any different.
The #pragma issues, calling conventions are already handled in C so that
should be a no-brainer.  Mangled names...?  Well, they are just names, so
provided they can be treated as external "C" calls, the intrinsics should
fall in line.  The 3000 linker handles case and special characters now.
IOstream...? Again, the current C library is already able to mask files as
byte streams even in MPE/iX 4.0.  So I don't see a great difficulty there.
I think in most cases the routines resolve down to the same basic
input/output mechanisms used in C.  xdb?...Again, as the object files are
compatible between 9000 and 3000, I don't think xdb would be a difficulty to
port.
 
I see the biggest hurdle is some sort of management of the libraries.
Anyone writing C++ is going to want to create libraries, and almost
certainly they will want dynamic libraries.  The C++ model is so different
than that for dynamic libraries on the 3000, I can't see how they would
reconcile it.  Using the current XLs, I can't see how they can be
re-designed to support class structures with polymorphism and inheritence.
On the 9000 I suspect it was easier...dynamic libaries were something new
only coming in on 9.0 (or was it 8?).  With no history behind (and no legacy
of apps) I'm sure the design could be adapted as needed.  So what is the
point of rejigging all the 3000 XL structures and utilities if only a few
sites are going to use it?  :(
 
Maybe the situation will change when OO-COBOL is on the scene!  :o
 
>A "quick-and-dirty" port, not including any of these items, would probably
>be easy. It would also be difficult to sell and nearly impossible to
>support. Given the engineering effort necessary to do the job right,
>it's unlikely to happen.
 
I think the key phrase is "difficult to sell".  If someone wants to do C++
programming, then they are probably committed to Unix anyway.  So continue
pointing to the 9000, where there are also X and SoftBench tools to assist.
The rest of us are left trying to make a "sow's ear out of a silk purse". :)
 
Speaking of things OO - has anyone ever used the Eiffel language and had it
compiler generate C output which was then loaded on the 3000?
 
----
Jim Wowchuk                    Internet:    [log in to unmask]
Vanguard Computer Services     Compu$erve:  100036,106
 _--_|\                        Post:        PO Box 18, North Ryde, NSW 2113
/      \                       Phone:       +61 (2) 888-9688
\.--.__/ <---Sydney NSW        Fax:         +61 (2) 888-3056
      v      Australia
"Life is short...but my god, sometimes Thursday afternoons are so slow!",
                                                              B.Whitely

ATOM RSS1 RSS2