mike@cimcor.mn.org (Michael Grenier) (02/15/89)
I'm currently considering supporting the UNIX 386 market with a
pascal compiler I have running under Microport V/AT. It will
generate assembly language output from the compiler which will
call up the assembler to generate the binary much in the same
way as pcc does. Now a question.
I have no fear in supporting Microport, Bell Tech, AT&T, Interactive,
ENIX and so forth as rumor has it they support the standard UNIX V.3
assembler for the 386. I have no fear that in fact the pascal compiler
will run under SCO UNIX V/386. I have a BIG fear that the rumored
MASM like assembler SCO uses will not handle the UNIX assembler's
opcodes and directives and will therefore not assemble the output
of the pascal compiler.
Is it true that SCO will not support the standard UNIX V.3 assembler?
It would be disappointing to have SCO doing something different again.
-Mike Grenier
mike@cimcor.mn.org
uunet!rosevax!cimcor!mike
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (02/17/89)
In article <647@cimcor.mn.org> mike@cimcor.mn.org (Michael Grenier) writes: | .............................. I have a BIG fear that the rumored | MASM like assembler SCO uses will not handle the UNIX assembler's | opcodes and directives and will therefore not assemble the output | of the pascal compiler. I'm not sure what you mean by "rumored." It's been shipping for over a year. It is not the standard UNIX assembler. | | Is it true that SCO will not support the standard UNIX V.3 assembler? | It would be disappointing to have SCO doing something different again. Define "support." SCO supports the UNIX assembler in the same way that MS-DOS supports 1-2-3. You're welcome to run it if you wish. Programs using COFF format seem to run just fine under the recent versions of Xenix. SCO doesn't *sell* that assembler, just as IBM doesn't supply 1-2-3. Let's take a hypothetical case (to avoid violating our license). If we had Xenix/386 v2.3.1 and Microport v/386, and pulled the executables off the Microport and put them on the Xenix system, with a little hypothetical diddling the assembler would work just fine. It's not clear to me that SCO will ever offer the V.3 C compiler and assembler, which is too bad because they could do so easily and bundle it with the development set. The only reason I can see to use it is compatibility at the assembler source level. Any reasonable C program will run fine on either compiler, but faster after compilation on the Xenix compiler in most cases. It's not really a lot of work to generate source for one or the other, and would probably be worth doing from a standpoint of potential customers. You could bundle your compiler with the assembler if you wanted, since the user has to buy it from someone it might as well be you. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
dyer@spdcc.COM (Steve Dyer) (02/17/89)
In article <13163@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > Define "support." SCO supports the UNIX assembler in the same way that >MS-DOS supports 1-2-3. You're welcome to run it if you wish. Programs >using COFF format seem to run just fine under the recent versions of >Xenix. SCO doesn't *sell* that assembler, just as IBM doesn't supply >1-2-3. The absence of UNIX V/386 "as" hasn't been too heavy a burden to bear, although it prevents me from running programs compiled (into assembly language) with GCC. Still, I find Bill's analogy rather forced. SCO, insofaras it licenses UNIX V/386 from AT&T (which contains "as"), has the prerogative to ship UNIX "as" but it (at least right now) elects not to do so. This is not quite the same as IBM electing not to supply 1-2-3. I don't know what the big deal would be to ship both the SCO "as" and "ld" along with the AT&T "masm" and "ld". It's really only important for compiler writers, who quite naturally want a uniform environment across all 386 UNIX boxes. I've never complained to SCO about this, so they haven't had the courtesy of responding. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu
debra@alice.UUCP (Paul De Bra) (02/17/89)
In article <647@cimcor.mn.org> mike@cimcor.mn.org (Michael Grenier) writes: >... >Is it true that SCO will not support the standard UNIX V.3 assembler? The "merged" product from SCO should RUN the standard UNIX V.3 assembler, but that doesn't mean it will USE it. So although you will be able to generate binaries that run on SCO using the standard UNIX V.3 assembler (and loader maybe), there will be a licensing problem to supply this assembler for Xenix. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
mike@cimcor.mn.org (Michael Grenier) (02/18/89)
From article <13163@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr): > In article <647@cimcor.mn.org> mike@cimcor.mn.org (Michael Grenier) writes: > | .............................. I have a BIG fear that the rumored > | MASM like assembler SCO uses will not handle the UNIX assembler's > | opcodes and directives and will therefore not assemble the output > | of the pascal compiler. > > > Let's take a hypothetical case (to avoid violating our license). If we > had Xenix/386 v2.3.1 and Microport v/386, and pulled the executables off > the Microport and put them on the Xenix system, with a little > hypothetical diddling the assembler would work just fine. > I can see that taking the Microport (or other UNIX ) as(1) command over to SCO UNIX V/386 will allow me to run the COFF assembler. But how about the next step - Does the SCO UNIX come with the COFF libraries, linker, etc. to handle building the final executable. Moreover, even if they are supplied, do they conform (.i.e do the libraries have the same entry points) as standard UNIX on the 80386? Since the pascal compiler uses the C library for all the built in functions (like using malloc when the program calls NEW(ptr)) the calls must be compatible. How well does SCO's sdb work on COFF binaries. A recent review in UNIX World mentioned problems with it if the binary didn't have the full symbolic information in it (not that this is a big issue). I can't really bundle the UNIX assembler with the Pascal compiler without paying AT&T some big bucks. I could generate the COFF binaries directly especially with the help of a wonderful book by Nutshell Associates but seeing the assembly output would be nice. Thanks for the information though. -Mike Grenier mike@cimcor.mn.org uunet!rosevax!cimcor!mike
rosso@sco.COM (Ross Oliver) (02/23/89)
Regarding the recent discussion of SCO's support of AT&T's 386 assembler, the SCO XENIX 3.2 Development System will contain almost literally EVERYTHING that is in XENIX 2.3 and AT&T UNIX. In this context it will contain: Microsoft 8086/286 C compiler generating OMF. Microsoft 386 C compiler generating either OMF or COFF Microsoft MASM generating 8086/80286 OMF and 386 OMF or COFF AT&T 386 assembler generating 386 COFF Microsoft linkers for generating 8086/286/386 x.out, also DOS and OS/2 executable formats AT&T linker generating 386 COFF. The net result is that the 3.2 Development System will let you generate 8086 / 286 code for XENIX, DOS and OS/2 and 386 code for XENIX and UNIX. The current Develpment System, release 2.3 (confusing, eh?), does not include the AT&T assembler, and cannot generate COFF object modules. However, the linker will accept COFF libraries and object modules, and will generate XENIX x.out binaries from them. Ross Oliver Technical Support The Santa Cruz Operation, Inc.
tim@ora.UUCP (Tim O'Reilly) (02/23/89)
In article <648@cimcor.mn.org>, mike@cimcor.mn.org (Michael Grenier) writes: > I can't really bundle the UNIX assembler with the Pascal compiler without > paying AT&T some big bucks. I could generate the COFF binaries > directly especially with the help of a wonderful book by > Nutshell Associates but seeing the assembly output would be nice. Correction: That's O'Reilly & Associates, publishers of Nutshell Handbooks, not Nutshell Associates. The book in question is called Understanding and Using COFF, by Rich Gircys, and is available by calling the number given below. -- Tim O'Reilly (617) 527-4210 or (800) 338-NUTS O'Reilly & Associates, Inc., Publishers of Nutshell Handbooks 981 Chestnut Street, Newton, MA 02164 UUCP: uunet!ora!tim ARPA: tim@ora.uu.net
ked@garnet.berkeley.edu (Earl H. Kinmonth) (02/24/89)
>The current Develpment System, release 2.3 (confusing, eh?), does
While most of 2.3 appears to be specific to the 386, will the non-specific
portions be made available in 286 versions? For example a fixed setvbuf()
and function prototypes for #include files are not inherently 386 specific.