phil@eecs.nwu.edu (William LeFebvre) (02/15/91)
I have ouestions regarding Encore Mach 1.0 In article <14033@encore.Encore.COM>, boykin@encore.com (Joseph Boykin) writes: |> Encore Mach version 1.0 is now shipping from Encore. All existing |> customers with support will automatically receive an update tape |> in the near future.... Support??? What type of support? Do you mean Mach software support? |> Mach version 1.0 is based on the version 2.5 Mach kernel from |> CMU and the 4.3BSD-tahoe utilities.... Which format does it use for object files and executables? I'm not familiar enough with Mach and Tahoe to answer that on my own. I hope the answer is not "COFF". We currently are running UMAX 4.0 (the BSD look-alike) on our Multimax. I am thinking that it might be worthwile to switch to Mach. Anyone have any thoughts on that idea? Does anyone have an idea how much it would cost to switch? (Maybe I should ask my salesman). Any other thoughts on this would be appreciated. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
boykin@encore.com (Joseph Boykin) (02/18/91)
In article <3507@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: |> I have ouestions regarding Encore Mach 1.0 |> |> |> Encore Mach version 1.0 is now shipping from Encore. All existing |> |> customers with support will automatically receive an update tape |> |> in the near future.... |> |> Support??? What type of support? Do you mean Mach software support? Yes. |> |> Mach version 1.0 is based on the version 2.5 Mach kernel from |> |> CMU and the 4.3BSD-tahoe utilities.... |> |> Which format does it use for object files and executables? I'm not |> familiar enough with Mach and Tahoe to answer that on my own. I hope |> the answer is not "COFF". The answer is definately COFF since that is what all of Encore's compilers and linkers for the Multimax use. |> We currently are running UMAX 4.0 (the BSD look-alike) on our Multimax. |> I am thinking that it might be worthwile to switch to Mach. Anyone |> have any thoughts on that idea? Yes, but my opinion is probably biased! |> Does anyone have an idea how much it would cost to switch? $1,000 for Mach. $4,000 for NFS. ---- Joseph Boykin Manager, Mach OS Development Encore Computer Corp Treasurer, IEEE Computer Society Internet: boykin@encore.com Phone: 508-460-0500 x2720
phil@eecs.nwu.edu (William LeFebvre) (02/19/91)
In article <14083@encore.Encore.COM>, boykin@encore.com (Joseph Boykin) writes: |> In article <3507@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: |> |> Which format does it use for object files and executables? I'm not |> |> familiar enough with Mach and Tahoe to answer that on my own. I hope |> |> the answer is not "COFF". |> |> The answer is definately COFF since that is what all of Encore's compilers |> and linkers for the Multimax use. Hmpph! |> |> Does anyone have an idea how much it would cost to switch? |> |> $1,000 for Mach. |> $4,000 for NFS. I find that pricing structure quite odd. We already have the "NFS option" for Umax 4.0. Would we still have to pay this additional $4000 for NFS under Mach? William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
boykin@encore.com (Joseph Boykin) (02/19/91)
In article <3649@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: |> In article <14083@encore.Encore.COM>, boykin@encore.com (Joseph Boykin) writes: |> |> In article <3507@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: I sent a reply to the author last week, but meant to do a followup so the rest of the group could see it. |> |> The answer is definately COFF since that is what all of Encore's compilers |> |> and linkers for the Multimax use. |> |> Hmpph! Why would you care what object file format we use? Unless you have another machine with the same instruction set (unlikely on an NS32K based system!) with a different object file format, what's the difference? |> |> |> Does anyone have an idea how much it would cost to switch? |> |> |> |> $1,000 for Mach. |> |> $4,000 for NFS. |> |> I find that pricing structure quite odd. Why? |> We already have the "NFS option" for Umax 4.0. Would we still have to |> pay this additional $4000 for NFS under Mach? Most of the reason for this has to do with SUN, not Encore. SUN is requiring us to pay royalties for NFS under Mach. That royalty can be measured in thousands of dollars given a bunch of different factors. Regardless, this is a different product, just because someone buys NFS for Umax there doesn't seem to be alot of reasoning behind giving NFS for Mach for free. It cost us to develop it, it costs us to maintain it and it costs (big time) for royalties. If we didn't have to pay another royalty to SUN, than the price should be less for those with NFS for Umax, but that isn't the case. ---- Joseph Boykin Manager, Mach OS Development Encore Computer Corp Treasurer, IEEE Computer Society Internet: boykin@encore.com Phone: 508-460-0500 x2720
phil@eecs.nwu.edu (William LeFebvre) (02/20/91)
To help sort this out: |> is boykin |> |> is me In article <14091@encore.Encore.COM>, boykin@encore.com (Joseph Boykin) writes: |> Why would you care what object file format we use? Unless you have |> another machine with the same instruction set (unlikely on an NS32K based |> system!) with a different object file format, what's the difference? Kyoto Common Lisp cares. gcc cares. gdb cares. And there are other commonly used items of free software that like to have the Berkeley(?) a.out format. These may eventually be modified to cope with COFF (some already have), but in the meantime my job is harder. I wouldn't care quite so much, except that I have yet to find a decent debugger for UMAX. We have cdb and I don't see it as "decent". There is no dbx equivalent, and even if we had the source to dbx we couldn't use it because, well, because it doesn't understand COFF. |> phil@eecs.nwu.edu (William LeFebvre) writes: |> |> boykin@encore.com (Joseph Boykin) writes: |> |> |> $1,000 for Mach. |> |> |> $4,000 for NFS. |> |> |> |> I find that pricing structure quite odd. |> |> Why? |> ... |> Most of the reason for this has to do with SUN, not Encore. |> SUN is requiring us to pay royalties for NFS under Mach. That royalty |> can be measured in thousands of dollars given a bunch of different factors. A HA! That explains it. I had forgotten about the royalties. I found it odd that a package could cost 4 times as much as something that is substantially larger (and must be much more complicated) than itself. |> Regardless, this is a different product, just because someone buys NFS |> for Umax there doesn't seem to be alot of reasoning behind giving NFS |> for Mach for free. I didn't say there was. I was just asking. |> If we didn't have to pay |> another royalty to SUN, than the price should be less for those with |> NFS for Umax, but that isn't the case. And that is, likely, the crux of the matter. William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
randy@uokmax.ecn.uoknor.edu (Longshot) (02/20/91)
boykin@encore.com (Joseph Boykin) writes: >In article <3649@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: >|> In article <14083@encore.Encore.COM>, boykin@encore.com (Joseph Boykin) writes: >|> |> The answer is definately COFF since that is what all of Encore's compilers >|> |> and linkers for the Multimax use. >|> >|> Hmpph! >Why would you care what object file format we use? Unless you have >another machine with the same instruction set (unlikely on an NS32K based >system!) with a different object file format, what's the difference? Well, there is some development software, particularly GNU tools, that does not work well with COFF (some not at all). Since, to my knowledge, you (Encore) do not have an ANSI-compliant C compiler or any C++ compiler at all, we on the user-end must use these third-party tools. The g++ program cannot handle COFF at all; you must use an additional utilitie that makes source-level debugging nearly impossible by munging many of the symbols in the table. But all this aside, the problem is not so much that COFF is used, but that the COFF used on Encore systems does not gel with the COFF patches given to adapt g++. The patches work with other COFF systems, but not Encore. -- Randy J. Ray University of Oklahoma, Norman Campus (405)/325-5370 !chinet!uokmax!randy randy@uokmax.uucp randy@uokmax.ecn.uoknor.edu Nancy Reagan meets Ms. Manners: "Just say 'No, thank you.'" \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\///////////////////////////////////////
boykin@encore.com (Joseph Boykin) (02/21/91)
In article <3713@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: |> |> Why would you care what object file format we use? Unless you have |> |> another machine with the same instruction set (unlikely on an NS32K based |> |> system!) with a different object file format, what's the difference? |> |> Kyoto Common Lisp cares. gcc cares. gdb cares. Several people pointed out via both email and news about public domain tools. The reason I didn't comment about them was because several people have ported those tools to Mach in the past. Some releases are harder to port than others (the guy here who tried to port the latest g++ never finished it), but the release before that was a relatively small effort. Gdb has been ported to Mach by several groups, including CMU (I think CMU will provide you with a multi-threaded version of GDB). I acknowledge that this may be a problem, but so far, there haven't been too many problems porting things to Mach. Note that we don't do very much different with COFF than e.g. Umax4, so I'm not sure why there is a problem there either. In either case, news isn't the forum for discussing the problem. |> $1,000 for Mach. |> $4,000 for NFS. |> |> |> I find that pricing structure quite odd. |> |> ... |> Most of the reason for this has to do with SUN, not Encore. |> SUN is requiring us to pay royalties for NFS under Mach. That royalty |> can be measured in thousands of dollars given a bunch of different factors. |> |> |> A HA! That explains it. I had forgotten about the royalties. Sorry if I sounded "testy" about this one, but you're right, paying that much for royalties doesn't make me happy either. So much for "open systems" from SUN! ---- Joseph Boykin Manager, Mach OS Development Encore Computer Corp Treasurer, IEEE Computer Society Internet: boykin@encore.com Phone: 508-460-0500 x2720
phil@eecs.nwu.edu (William LeFebvre) (02/21/91)
In article <14103@encore.Encore.COM>, boykin@encore.com (Joseph Boykin) writes: |> So much for "open systems" from SUN! You know the old saying: "Open systems for open wallets!" William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>
meissner@osf.org (Michael Meissner) (02/21/91)
In article <14103@encore.Encore.COM> boykin@encore.com (Joseph Boykin) writes: | In article <3713@casbah.acns.nwu.edu>, phil@eecs.nwu.edu (William LeFebvre) writes: | |> |> Why would you care what object file format we use? Unless you have | |> |> another machine with the same instruction set (unlikely on an NS32K based | |> |> system!) with a different object file format, what's the difference? | |> | |> Kyoto Common Lisp cares. gcc cares. gdb cares. | | Several people pointed out via both email and news about public domain | tools. The reason I didn't comment about them was because several | people have ported those tools to Mach in the past. Some releases | are harder to port than others (the guy here who tried to port the | latest g++ never finished it), but the release before that was | a relatively small effort. Gdb has been ported to Mach by several | groups, including CMU (I think CMU will provide you with a multi-threaded | version of GDB). GCC itself has no problems with COFF. | I acknowledge that this may be a problem, but so far, there haven't | been too many problems porting things to Mach. Note that we don't | do very much different with COFF than e.g. Umax4, so I'm not sure | why there is a problem there either. In either case, news isn't | the forum for discussing the problem. The main problem with COFF is in the debugging support. Off of the top of my head, the problems are: 1) You cannot have code in include files (each object module can only have one .file directive) -- parser generators in particular get bitten by this, since they use #line directives to switch between the parser skeleton file, and the .y file containing the user's actions; 2) You cannot debug inline functions, even if they come from the same source file, since line numbers must be >= to the first line number inside of a function; 3) Standard COFF has no means of handling void, void *, const, volatile, or long double types; 4) Forward references to structure tags cause some problems, and references to completely unknown tags cause even more problems; 5) No support for more than 6 levels of *, (), or [] for a given declaration; 6) No support for nested functions, ala PASCAL. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?