jkenton@pinocchio.encore.com (Jeff Kenton) (07/25/90)
From article <1990Jul24.234511.10564@esegue.segue.boston.ma.us>, by msnyder@cis.ohio-state.edu (Michael V Snyder): > > Ah yes. The TI 99/4 was slow only in BASIC, and that was because its > basic interpreter was written not in assembler, not in some high level > compiled language, but in ANOTHER INTERPRETED LANGUAGE! There was, Part of the software problem with that TI chip was that the guy that designed the chip did such a nice job that they rewarded him by putting him in charge of the software group. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com --- always at (617) 894-4508 --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
jac@paul.rutgers.edu (Jonathan A. Chandross) (07/26/90)
esmith@apple.com (Eric Smith) > The amazing slowness (could they have made it slower if they tried?) was > due to BASIC storing the user's program and variables in the memory > attached to the TMS9918 VDP (video data processor). Every time the > interpreter needed to access a byte of the BASIC program or variable, it > had to write the address to the VDP then read the data. True. But on top of that they made the mistake of getting a Basic from Microsoft. All of Microsoft's Basics are written (or at least used to be) in a virtual machine language. All you have to port the Basic is to write a simulator for that virtual machine. Of course, this adds an additional layer of indirection and thus seriously slows down your interpreter. The Apple ][+ used a Microsoft version Basic sold as "Applesoft". We used to call it "Applesloth". The difference between it and the Integer Basic on the Apple ][ (written by Woz) was just simply amazing. Jonathan A. Chandross Internet: jac@paul.rutgers.edu UUCP: rutgers!paul.rutgers.edu!jac
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (07/29/90)
In article <Jul.25.22.06.38.1990.22690@paul.rutgers.edu>, jac@paul.rutgers.edu (Jonathan A. Chandross) writes: > > True. But on top of that they made the mistake of getting a Basic from > Microsoft. All of Microsoft's Basics are written (or at least used to > be) in a virtual machine language. All you have to port the Basic is > to write a simulator for that virtual machine. Of course, this adds an > additional layer of indirection and thus seriously slows down your > interpreter. >... > > Jonathan A. Chandross > Internet: jac@paul.rutgers.edu > UUCP: rutgers!paul.rutgers.edu!jac I once worked for a small startup (long dead) that purchased BASIC from Microsoft for an 8086 based system. It was written in 8085 assembly language, with some 8086 assembly language in the math*.asm files. (It used a DEC-10 808* cross assembler built out of the DEC assembler, not INTEL's ASM85 or ASM86.) It was a nice little interpretor, supporting many features of the defunct ANSI Extended BASIC standard. During the time I spent in Seattle talking to Allen, Gates, &co. about how to port it to our operating system (minor details like virtual memory, multi-tasking, and multi-processors conflicted with the original design of the interpretor), I had the distinct impression that it was their original and still at that time primary BASIC. Comments in the code implied that it was written by Gates, Allen, and Monty (?) in the summer of 1973. I think they were working on or had a "compiled" BASIC around 1980 when I dealt with them. Perhaps the compiler used a "virtual machine." Vernon Schryver vjs@sgi.com
colin@array.UUCP (Colin Plumb) (07/31/90)
In article <Jul.25.22.06.38.1990.22690@paul.rutgers.edu>, jac@paul.rutgers.edu (Jonathan A. Chandross) writes: > > True. But on top of that they made the mistake of getting a Basic from > Microsoft. All of Microsoft's Basics are written (or at least used to > be) in a virtual machine language. All you have to port the Basic is > to write a simulator for that virtual machine. Of course, this adds an > additional layer of indirection and thus seriously slows down your > interpreter. I think you are confusing Microsoft's Basic (assembler) with its applications, which have large parts compiled to a virtual machine p-code optimised for code density. The idea is to pack as many features as possible into 640K and accept the speed penalty as inconsequential in user-interface code. Important internal routines are, of course, compiled to native code. Of course, the fact that most of Microsoft's applications aren't written using normal C compilers means that Microsoft's programmers can't use any of the spiffy commercially-available development tools. This is a non-trivial cost. -- -Colin
brett@smosjc.UUCP (Brett Coon) (08/01/90)
In article <2929@awdprime.UUCP>, tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: > In article <Jul.25.22.06.38.1990.22690@paul.rutgers.edu> jac@paul.rutgers.edu (Jonathan A. Chandross) writes: > >All of Microsoft's Basics are written (or at least used to > >be) in a virtual machine language. > > Can anyone confirm this? TRS-80 Model I (I think the first major MS BASIC) TI99/4 BASIC was written in a language called GPL, which I believe stood for Graphics Programming Language. GPL could only run from special ROMs called GROMS, which contained their own auto-incrementing address counters. To access a given GROM location, you had to write the two byte address to a special memory location (two writes and two NOPs for delay) and then read the data from another memory location. Subsequent sequential GROM accesses didn't require you to write a new address, due to the counters. TI used this convoluted scheme to allow large amounts of software to be mapped into a small section of the TI's 64K address space - the stock TI only had 256 BYTES of directly accessible RAM. I'm not sure what originally started this discussion, but I think it's worth noting that the TMS9090 CPU (used in the TI99/4), with its memory-to-memory architecture, had the easiest to program assembly language I've ever used, even more straight-forward than the 680x0 series. 16 general purpose registers and almost instant context switches. -brett -- |Brett Coon | uunet!smosjc!brett | |S-MOS Systems, Inc. | "You like 'em, anchovies?" | |San Jose, CA | -Runaway Train |
rmk@frog.UUCP (Rick Kelly) (08/01/90)
In article <9408@goofy.Apple.COM> esmith@apple.com (Eric Smith) writes: >From article <1990Jul24.234511.10564@esegue.segue.boston.ma.us>, by >msnyder@cis.ohio-state.edu (Michael V Snyder): >> Ah yes. The TI 99/4 was slow only in BASIC, and that was because its >> basic interpreter was written not in assembler, not in some high level >> compiled language, but in ANOTHER INTERPRETED LANGUAGE! There was, >I don't know what language was used to implement TI 99/4 BASIC, although >I would bet that it was in assembler. >The amazing slowness (could they have made it slower if they tried?) was >due to BASIC storing the user's program and variables in the memory >attached to the TMS9918 VDP (video data processor). Every time the >interpreter needed to access a byte of the BASIC program or variable, it >had to write the address to the VDP then read the data. The TI 99/4 BASIC interpreter was written in GPL (Graphics Programming Language), which was in turn interpreted by a GPL interpreter in the TI roms. Every BASIC instruction was interpreted twice! The actual speed of BASIC programs was remarkable considering this handicap. I spent many hours with this machine trying to write tighter, faster code. Construction of loops and the placement of "gosub" routines had to be done with care. The Extended BASIC cartridge seemed to have some routines written in native code, and there was a noticeable peerformance difference. Rick Kelly Charles River Data Systems 508-626-1011 rmk@frog.UUCP