joachim@jrix.radig.de (Joachim Riedel) (10/06/90)
We now use the INTEL-Package: ASM86, LOC86, LIB86, OH86, CREF86 and LINK86 as a develop-system for 8086/80186 programs on IBM/PC (MS-DOS,PC-DOS). Our target system is a stand-alone numeric control (ANC39 (NCE510)). We now work with a 386 and SCO-UNIX and we need VPIX to assemble and link our software. Is the Intel or a similar package also available for UNIX SysV 386 without using VPIX ? Thanks for your help Joachim Companies: Please send information and/or prices to the following ---------- address ATAS Gmbh Liebigstrasse 16 6453 Seligenstadt am Main Tel. +49 6182 80646 FAX: +49 6182 80627 ---------------------------------------------------------------------
tneff@bfmny0.BFM.COM (Tom Neff) (10/07/90)
In article <1990Oct5.183147.341@jrix.radig.de> joachim@jrix.radig.de (Joachim Riedel) writes: >ASM86, LOC86, LIB86, OH86, CREF86 and LINK86 > >Is the Intel or a similar package also available for UNIX SysV 386 >without using VPIX ? Yes, you need the Intel UNIX/386 hosting package for the language products. It contains a front end called UNXUDI which is actually also a V86 task manager like VP/ix only much simpler -- it doesn't try to be a full fledged PC, just to provide the utilities with a meg of memory in real mode and UDI support. Contact your Intel salesman. -- "Take off your engineering hat = "The filter has | Tom Neff and put on your management hat." = discreting sources." | tneff@bfmny0.BFM.COM
peter@ficc.ferranti.com (Peter da Silva) (10/08/90)
In article <15917@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: > In article <1990Oct5.183147.341@jrix.radig.de> joachim@jrix.radig.de (Joachim Riedel) writes: > >ASM86, LOC86, LIB86, OH86, CREF86 and LINK86 > >Is the Intel or a similar package also available for UNIX SysV 386 > >without using VPIX ? > Yes, you need the Intel UNIX/386 hosting package for the language > products. Better would be to get the Xenix/286 products. UNXUDI is by definition limited to 1 Meg. We do binds here that require up to 3 Meg MEMPOOL. 286 emulation instead of 386 emulation, and it'll run on any System V/386. > a full fledged PC, just to provide the utilities with a meg of memory in > real mode Virtual 8086 mode. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
tneff@bfmny0.BFM.COM (Tom Neff) (10/08/90)
In article <:C96DR1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <15917@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >> In article <1990Oct5.183147.341@jrix.radig.de> joachim@jrix.radig.de (Joachim Riedel) writes: >> >ASM86, LOC86, LIB86, OH86, CREF86 and LINK86 >> >Is the Intel or a similar package also available for UNIX SysV 386 >> >without using VPIX ? > >> Yes, you need the Intel UNIX/386 hosting package for the language >> products. > >Better would be to get the Xenix/286 products. UNXUDI is by definition >limited to 1 Meg. We do binds here that require up to 3 Meg MEMPOOL. 286 >emulation instead of 386 emulation, and it'll run on any System V/386. Wait a minute -- it is not my impression that, regardless of the hosting platform, the 86 language tools would ever use more than a meg of memory. Inside, all hosted versions are really the same 8086 OMF files containing the same code. All that differs is the wrapper or special loader used. Are you saying that under Xenix, you can get PLM86, for instance, to report more than 1024K free in the DICTIONARY SUMMARY section of the listing file? I am skeptical. -- For the curious: +---+ Tom Neff Here's what RS-232 pins do! ==|:::|== tneff@bfmny0.BFM.COM -- Inmac +---+ uunet!bfmny0!tneff
cs00aas@unccvax.uncc.edu (ali seif) (10/09/90)
Hi, I am new on the net. Does any one have information regarding Cache memory and Virtual address? Please reply to me at (cs00aas@unccvax) and please send some info about them or where I can find some articles about them. thank you in advance, please reply very soon if possible. Eli.
peter@ficc.ferranti.com (Peter da Silva) (10/09/90)
In article <15919@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: > Wait a minute -- it is not my impression that, regardless of the > hosting platform, the 86 language tools would ever use more than a meg > of memory. Inside, all hosted versions are really the same 8086 OMF > files containing the same code. All that differs is the wrapper or > special loader used. Sorry, the Xenix 286 products we're using are indeed written in iAPX286 native mode. These run under Xenix System III, Xenix System V, and UNIX System V. From a recent BND286 run: SUMMARY OF MEMORY USAGE 1686KB MEMORY USED FOR SYMBOLS 16KB DISK SPACE USED FOR SYMBOLS. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
tneff@bfmny0.BFM.COM (Tom Neff) (10/09/90)
In article <+3A6RL4@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <15919@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >> Wait a minute -- it is not my impression that, regardless of the >> hosting platform, the 86 language tools would ever use more than a meg ^^ ^^ >> of memory. Inside, all hosted versions are really the same 8086 OMF >> files containing the same code. All that differs is the wrapper or >> special loader used. > >Sorry, the Xenix 286 products we're using are indeed written in iAPX286 ^^^ ^^^ >native mode. These run under Xenix System III, Xenix System V, and UNIX >System V. > >From a recent BND286 run: ^^^ ^^^ > >SUMMARY OF MEMORY USAGE > 1686KB MEMORY USED FOR SYMBOLS > 16KB DISK SPACE USED FOR SYMBOLS. We are zeroing in on something other than the original question. Who has seen how PLM86, for instance, behaves on the 286 platform? I still bet they don't use more than a meg. -- The genius of you Americans is that you never make ** Tom Neff any clear-cut stupid moves, only complicated stupid ** tneff@bfmny0.BFM.COM moves that leave us scratching our heads wondering if we might possibly have missed something. -- Gamel Abdel Nasser
tneff@bfmny0.BFM.COM (Tom Neff) (10/10/90)
In article <_:A6TTA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <15925@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >> We are zeroing in on something other than the original question. > >No, we're not. The problem at hand is doing x86 development on System V. ^^^ >It is not clear to me that the "modern" intel 86 tools (including the >current 80286 and 80386 tool sets) are the best way. The request was NOT this generic. Our European friend has an 8086-based numeric control target processor for which he *NEEDS* to generate OMF86 code. Specifically. I know this type of setup; I have one myself. It's not a question of which kind of "x86" development setup is theoretically nicer. Intel's OMF86 based language tools exist in their own universe. > In fact, if I may >be allowed a mild flame, the UNXUDI method is totally barmy, and we >REALLY need native 80386 tools to get decent performance and functionality. Oh, maybe. As long as it works reliably! I would like bigger symtabs. >> Who >> has seen how PLM86, for instance, behaves on the 286 platform? I still >> bet they don't use more than a meg. > >I'm sure they don't... but our copy of PLM86 from the good old days does. If any version of PLM86 (not PLM286 or BND286, etc) uses more than a meg, then I'd like to see a section of the listing file where it reports more than 1024K available. Quote it here? -- Nobody wants justice. /\ \/ Tom Neff -- Alan Dershowitz /\ \/ tneff@bfmny0.BFM.COM
peter@ficc.ferranti.com (Peter da Silva) (10/10/90)
In article <15925@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: > We are zeroing in on something other than the original question. No, we're not. The problem at hand is doing x86 development on System V. It is not clear to me that the "modern" intel 86 tools (including the current 80286 and 80386 tool sets) are the best way. In fact, if I may be allowed a mild flame, the UNXUDI method is totally barmy, and we REALLY need native 80386 tools to get decent performance and functionality. But given that Intel has decided that DOS is the premier development platform and decided to load all their development tools down with 64K segments and 1M total address space... don't throw away those old intel 80286 tools, yet. > Who > has seen how PLM86, for instance, behaves on the 286 platform? I still > bet they don't use more than a meg. I'm sure they don't... but our copy of PLM86 from the good old days does. I'm saying that if you want to do x86 development on an 80[34]86 running UNIX, doing it in a DOS emulation mode is crazy and the older intel tools are far better suited to the task. They're still not perfect: they use up huge amounts of VM because of the limits of x286emul. But they're better than nothing. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
joachim@orfeo.radig.de (Joachim Riedel) (10/11/90)
In <_:A6TTA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I'm saying that if you want to do x86 development on an 80[34]86 running >UNIX, doing it in a DOS emulation mode is crazy and the older intel tools >are far better suited to the task. Maybe you are right, but remember one thing: We still edit our source code with UNIX-Editors (EMACS and EDT (EDT is the VAX-VMS-Editor our boss is used to since ....)) We have a batch job that temporarily switches to VPIX, compiles or links and then goes back to UNIX. Our Intel-Hexfiles are only about 400kb, so we only need 2 Minutes to link (Intel 33Mhz-Board) and therefore I think it is not crazy to use DOS-Emulan. One year ago an our VAX we need 30 Minutes to link, for us UNIX is terrible, no time to enjoy a coffee. But I agree that a 8086-Assembler for UNIX386 in realtime is the better solution but it seems it is not available. (I got a mail that one company may have it, we'll try). Tks for your help and excuse my bad english grammar. It is good to know that there are still assembler programmers out there, and a interesting discussion although I missed one article. Joachim ------------------------------------------------------------------- Joachim Riedel Geschwister-Scholl-Str. 48 6050 Offenbach am Main Germany Phone: +49 69 85 62 25 joachim\@jrix.radig.de -------------------------------------------------------------------
tneff@bfmny0.BFM.COM (Tom Neff) (10/11/90)
In article <1990Oct11.084750.1183@orfeo.radig.de> joachim@orfeo.radig.de (Joachim Riedel) writes: >We still edit our source code with UNIX-Editors (EMACS and EDT (EDT is >the VAX-VMS-Editor our boss is used to since ....)) We have a batch job >that temporarily switches to VPIX, compiles or links and then goes back >to UNIX. Unfortunately I find that VP/ix can be a bit flakey when invoked from a shell script. Also it messes with the screen, other devices etc. and can be slow to load. In comparison, the UNXUDI loader is very fast and clean. It still creates a V86 task but is much less ambitious about trying to create an elaborate PC simulation within the box. All it sets up is what a well behaved UDI application needs to run. -- Shut up he explained. ++ Tom Neff -- Ring Lardner ++ tneff@bfmny0.BFM.COM or uunet!bfmny0!tneff
vjs@calcite.UUCP (Vernon Schryver) (10/13/90)
Maybe PLM*86 would run faster as a native UNIX program. Who cares? It would generate the same code. PLM86 was mind boggling bad even at peep-hole optimizing in MDS-311 days. (MDS-311 was the ISIS 8085 cross development package you could get for your very own low speed 8086 in 1978.) The "code" generated by PLM386 is not significantly different, at least in the versions I've used. PLM386 still wastes registers and cycles with abandon--as if the *86 had any to spare. It still cannot strength reduce multiplies of constant powers of two. It usually ignores and so recomputes condition codes generated by preceding statements. And so on and on. Besides, the beasts that are the slowest are ASM386 and BLD386, at least under VP/ix and DOSMerge. It takes longer to link the stuff I do than it does to compile or assemble it, despite having stripped symbols in preceding BND386 passes. The assembler seems slower, in lines/hour, than the compiler. Anyone with freedom of choice (i.e. no dusty albatrosses) would choose almost any C compiler. Vernon Schryver, vjs@calcite.uucp
joachim@orfeo.radig.de (Joachim Riedel) (10/13/90)
In <15941@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: >Unfortunately I find that VP/ix can be a bit flakey when invoked from a >shell script. Also it messes with the screen, other devices etc. and >can be slow to load. In comparison, the UNXUDI loader is very fast and >clean. It still creates a V86 task but is much less ambitious about >trying to create an elaborate PC simulation within the box. All it sets >up is what a well behaved UDI application needs to run. You're still right. Once we started on a VAX using a Cross-Compiler, we bought the INTEL-Dos-Package for our field technicians to use on a LAPTOP. The INTEL-package was much faster on the laptop than the one on our vax. So we decided to switch to a faster multi-user-system and bought SCO-UNIX (I use Interactive, ever installed NEWS on SCO-UNIX ??). INTEL, Munich, told us that a package for 8086 assembler is not available for UNIX, only one for the 386. So my boss decided not to buy this package, instead we now use VP/IX. We didn't invoke VPIX from a UNIX-Shell-Script, we use a DOS-Batch-Job. VPIX is automatically invoked when a DOS-Command is to be executed in the command line (try: dir). We load the INTEL-Hex-File with a parallel interface ( cp anc39.abs /dev/lp0) directly in our CNC and then we use our hardware debuggers. The only problem we had with VPIX is when we try to copy a large Hex-File with DOS-Command copy to a disk. The file is sometimes corrupted (50:50) so we use doscp. Regards Joachim
tneff@bfmny0.BFM.COM (Tom Neff) (10/14/90)
In article <96@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: > >Maybe PLM*86 would run faster as a native UNIX program. Who cares? It >would generate the same code. This is quite true, and in fact a virtue, the rest of Vern's message notwithstanding. >PLM86 was mind boggling bad even at peep-hole optimizing in MDS-311 days. >(MDS-311 was the ISIS 8085 cross development package you could get for your >very own low speed 8086 in 1978.) Ah, and what a system it was. We still have one of the old Tower of Power mds's sitting around somewhere. It would make... an attractive planter. This, of course, dates from the long-forgotten days when micros were required to do useful WORK to earn their supper; unlike our modern all-electric era when they're expected to spew waste-cycles doing pointless X Windows crap like all the other CPUs. > The "code" generated by PLM386 is not >significantly different, at least in the versions I've used. PLM386 still >wastes registers and cycles with abandon--as if the *86 had any to spare. There was one major revision of the PL/M code generator, about 1987. Other than that it is largely still the same old cranky beast that existed in 1981. It doesn't do quite so many wild ass optimizations as whatever precious academic effort has everyone's heart a-flutter this week. But it is very *predictable* and that is extraordinarily comforting in a number of unglamorous, rent-paying types of situations. >It still cannot strength reduce multiplies of constant powers of two. It >usually ignores and so recomputes condition codes generated by preceding >statements. And so on and on. Yes, and so on... every PL/M programmer has at least one thing he HATES about the compiler. That's how I know it's a good one. It spreads the hate around rather evenly. >Anyone with freedom of choice (i.e. no dusty albatrosses) would choose >almost any C compiler. Oh yeah? I suggest looking at the original Mark Williams C compiler, which was OEM'd as "Intel C" up through 3.0. You want to talk about BAAAAAAD code! I'm amazed they offered an assembler listing option at all: simple modesty ought to have intervened. :-) Nowadays Intel C has been totally rewritten with an ANSI parser -- and the PL/M code generator!!! So there's no way out. If you want to generate OMF, that is. If you don't want OMF, you've invented some other job for yourself, and you might as well add a Cray to the wishlist while you're at it. -- Technology is a way of organizing ' ' Tom Neff the universe so that man doesn't have ' ' tneff@bfmny0.BFM.COM to experience it. -- Max Frisch ' ' uunet!bfmny0!tneff
vjs@calcite.UUCP (Vernon Schryver) (10/15/90)
In article <15947@bfmny0.BFM.COM>, tneff@bfmny0.BFM.COM (Tom Neff) writes: > This, of course, dates from the long-forgotten days when micros were > required to do useful WORK to earn their supper; unlike our modern > all-electric era when they're expected to spew waste-cycles doing > pointless X Windows crap like all the other CPUs. In my view, the morbid obesity of modern systems is in the tradition of the half hearted effort put into the PLM86 compiler in 1979. PLM86 was a crock in 1978, perhaps justified by pressures to beat the Z8000 and 68K to market. > It [PLM386] doesn't do quite so many wild ass optimizations as > whatever precious academic effort has everyone's heart a-flutter this > week. But it is very *predictable* and that is extraordinarily > comforting in a number of unglamorous, rent-paying types of situations. That's good only if your rent-paying situations permit 3x the RAM, 1/3 the performance, and 3x the time-to-completion because the tools are so primitive. I found the tools primitive compared to previous experience when first introduced to them in 1978, and see no sign in recent glossy INTEL releases, cataloges and brochures that much has changed. Do you really consider the C from GNU, MIPS, SGI, DEC, and Sun "academic"? > >Anyone with freedom of choice (i.e. no dusty albatrosses) would choose > >almost any C compiler. > > Oh yeah? I suggest looking at the original Mark Williams C compiler, > which was OEM'd as "Intel C" up through 3.0. ... I wrote "<almost> any C compiler" on purpose. How do GNU gcc and Greenhills gcc compare to PLM/386? The little Greenhills *86 code I've read was a breath of fresh air. How is the AT&T C compiler? > ... If you want to generate OMF ... What's the attraction of OMF, either the old "open" version or the new proprietary one? What's wrong with a.out, coff, or even elf? If you must have OMF, you probably need it for some PLM that will not die. It would have been trivial to convert coff et al to the old OMF with a little hacking (I did a little of that in about 1979); I bet it would be easy to reverse engineer a coff-to-new-secret-OMF today. What's hard about writing your own a.out or coff downloader? Or just blowing PROM's from a.out directly? (A.out is very simple on purpose, so the UNIX kernel can handle it.) Imagine using ancient UNIX tools such as make, grep, find, awk/sed, sh/csh/perl, sort, dbx/sdb/adb, vi/ed/ex/emacs, lex/yacc directly when developing for *86's, instead of standing on your head to work around the wonders of UDI/DOS/VPix. Of course, if technical considerations were paramount, you would choose any of the CPUs designed in the last 10 years with benefit of the *86 experience, such as MIPS, 88K, 29K, or SPARC. I've recently found the 29K great for embedded control, altho the C compiler is dreadfully similar to the INTEL notion of "good enough." Vernon Schryver, vjs@calcite.uucp
peter@ficc.ferranti.com (Peter da Silva) (10/15/90)
In article <96@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: > Maybe PLM*86 would run faster as a native UNIX program. Who cares? It > would generate the same code. But as you mention the rest of the tools are slow, too. And if the job gets big enough you can't bind it under UNIX, because it's too big for UNXUDI, and the Xenix version uses up too much VM because of a problem in x286emul. > Anyone with freedom of choice (i.e. no dusty albatrosses) would choose > almost any C compiler. But intel *does* claim to support the thing. To not provide support for the best development systemm they offer is lunacy. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
peter@ficc.ferranti.com (Peter da Silva) (10/22/90)
I don't care about the optimisation. I'm still trying to figure why the diagnostic for a corrupted library is that the binder core dumps. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com