peteh@indep1.UUCP (Peter Harmon) (11/27/88)
Are there any languages available that run under Microport system V/AT other than the ones which are distributed with it? I'm not looking for anything in particular. Nor am I concerned with whether the languages are commercial, shareware, or public domain. Also, how many of you USENETters would like another language or two for their '286 Microport system, and which language(s) would you want? Post if you wish, or email responses to me. I'll summarize in a month or so (or whenever the volume of responses diminishes enough to suggest approaching their end). Peter Harmon <pete@indep1.UUCP>
mdm@cocktrice.UUCP (Mike Mitchell) (12/01/88)
In article <308@indep1.UUCP> peteh@indep1.UUCP (Peter Harmon) writes: >Are there any languages available that run under Microport system V/AT other >than the ones which are distributed with it? > I have ported the Basic interptetor from the archives. It works as expected.. -- Mike Mitchell BELL: (505) 471-7639 2020 Calle Lorca #43 ARPA: mdm@cocktrice.UUCP Santa Fe, NM 87505 UUCP: ...!uunet!dmk3b1!cocktrice!mdm
wtr@moss.ATT.COM (12/03/88)
In article <308@indep1.UUCP> peteh@indep1.UUCP (Peter Harmon) writes: >Are there any languages available that run under Microport system V/AT other >than the ones which are distributed with it? try checking out some of the comp.unix.sources archive sites, as well as the microport bbs. there are some pretty good PD packages out there. (an xlisp interpreter, and a pascal-to-c translater for pascal work come to mind) has anyone out there posted these programs over to V/AT? ===================================================================== Bill Rankin Bell Labs, Whippany NJ (201) 386-4154 (cornet 232) email address: ...!att!moss!wtr
plocher@uport.UUCP (John Plocher) (12/04/88)
>>Are there any languages available that run under Microport system V/AT > >try checking out some of the comp.unix.sources archive sites, ... Per Bergstrom's Pascal to C translator ported without much hastle (easier than Bnews 2.11vxx did!) The logo interpreter also was simple to port. The Basic-in-Bourne-Shell was amusing :-) but the real basic works better. Happy hunting, -John Plocher
moran@tron.UUCP (Harvey R Moran) (12/06/88)
In article <268@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: >>>Are there any languages available that run under Microport system V/AT >> >>try checking out some of the comp.unix.sources archive sites, ... > >Per Bergstrom's Pascal to C translator ported without much hastle (easier than I could use a clue. How did you get around the problem that it all seems to compile fine, but the assemble symbol table overflows? The program is (deliberately) designed to form one *giant* source module. Until seing John's posting, I assumed that those of us with a '286 and no HUGE memory model need not apply. Harvey Moran moran%tron.UUCP@umbc3.UMD.EDU ...!{wb3ffv,netsys}!hrmhpc!harvey
mike@cimcor.mn.org (Michael Grenier) (12/07/88)
From article <395@tron.UUCP>, by moran@tron.UUCP (Harvey R Moran): >> John Plocher wrote : >>Per Bergstrom's Pascal to C translator ported without much hastle (easier than > > I could use a clue. How did you get around the problem that it > all seems to compile fine, but the assemble symbol table overflows? Microport has a beta version of the as command which does not have the symbol/hash table overflow problem. However, that will not help you with the big Pascal to C converter posted awhile back (I don't know if this is the one John Plocher was talking about porting). Even with a working /bin/as command, the linker will die because the resulting code segment is larger than 64K (I tried it). The UNIX 286 compiler/assembler will not generate multiple segments in large model for a given source file. The linker only deals in these resulting segments and wouldn't know how to break them up. The fix would be to have the assembler generate multiple segments but that solution is not trivial to implement since it requires look ahead to see if the next function would push the segment over the ledge (64K limit) which requires resolving the addresses of the next function up front to get the resulting length. Another solution would be to put each function in its seperate segment but this creates one heck of alot segments for the linker possibly slowing things down considerably. If anyone has some good ideas..let me know. -Mike Grenier mike@cimcor.mn.org uunet!rosevax!cimcor!mike {anybody who is anybody}!bungia!cimcor!mike
plocher@uport.UUCP (John Plocher) (12/07/88)
In article <395@tron.UUCP> moran@tron.UMD.EDU (Harvey R Moran) writes: >In article <268@uport.UUCP> plocher@uport.UUCP (John Plocher) writes: >>Per Bergstrom's Pascal to C translator ported without much hastle (easier than > > I could use a clue. How did you get around the problem that it >all seems to compile fine, but the assemble symbol table overflows? >The program is (deliberately) designed to form one *giant* source module. >Until seing John's posting, I assumed that those of us with a '286 >and no HUGE memory model need not apply. Oops, "much" == running it thru a simple program to make each procedure its own source file. If there is much demand, I can make it avaliable from Microport Support - it fits on a single disk, src and all. -John Plocher