https://devblogs.microsoft.com/oldnewthing/20220419-00/?p=106496 Skip to main content [RE1Mu3b] Microsoft The Old New Thing The Old New Thing The Old New Thing * Home * DevBlogs * Developer + Visual Studio + Visual Studio Code + Visual Studio for Mac + DevOps + Developer support + CSE Developer + Engineering@Microsoft + Azure SDK + IoT + Command Line + Perf and Diagnostics + Dr. International + Notification Hubs + Math in Office * Technology + DirectX + PIX + SurfaceDuo + Startups + Sustainable Engineering + Windows AI Platform * Languages + C++ + C# + F# + Visual Basic + TypeScript + PowerShell Community + PowerShell Team + Python + Q# + JavaScript + Java + Java Blog in Chinese * .NET + .NET + .NET MAUI + Blazor + ASP.NET + NuGet + Xamarin * Platform Development + #ifdef Windows + Apps for Windows + Azure Depth Platform + Azure Government + Bing Dev Center + Microsoft Edge Dev + Microsoft Azure + Microsoft 365 Developer + Old New Thing + Windows MIDI and Music dev + Windows Search Platform * Data Development + Azure Cosmos DB + Azure Data Studio + Azure SQL Database + OData + Revolutions R + SQL Server Data Tools * More [ ] Search Search Cancel The Applesoft Compiler (TASC): We have the source code, in a sense [png] Raymond C April 19th, 2022 Back in the early 1980's, the Apple ][ computer was taking the personal computing world by storm, and Microsoft released a compiler for Applesoft BASIC. That compiler went by the name TASC: The Apples oft Compiler. TASC was written by one person in his dorm room while studying at MIT. Microsoft licensed the product and hired the author, who spent the summer at the Northup building1 polishing the code. As noted on page 61 of the manual: TASC is a "two-pass" compiler, since it compiles in two major steps. PASS0 simply picks up user inputs and sets up compilation parameters, so it is not really part of the actual compilation process. The Applesoft program TASC runs PASS0. PASS0 and PASS1 chain to PASS1 and PASS2, respectively. All three passes were written largely in Applesoft, and TASC was used to compile itself. Chaining refers to a program instructing the system to replace the current program in memory with another program, but preserve the values of some or all variables. Chaining was a common technique when your program got too large to fit into memory all at once, so you broke it into multiple programs that each handed off control to each other. Even if you hadn't made it that deep into the manual, you could have figured out that TASC was used to compile itself because TASC used its own runtime library. Chaining was not a feature native to Applesoft BASIC. It was one of a handful of language extension provided by TASC itself, through the use of magic comments that begin with an exclamation point. This meant that once TASC development reached the point that it required chaining, it could be run only in its compiled form. There was no way to bootstrap it from the interpreter. As the author added features, he kept hitting the Apple ]['s 48KB RAM limit and was forced to delete all the comments from the code, and when that wasn't enough, he resorted to shortening all the important variable names to one character. Such is the desperation of developing on a system with very tight memory constraints. Everything was working smoothly, until the author returned to school for a semester. Upon returning to Microsoft, he found that he no longer understood the code. He had a sprawling compiler, with no comments, and unhelpful variable names.2 Yet somehow, he finished TASC, and it shipped. If you dig through the TASC manual, you can find all sorts of wonderful implementation details. All of the real work happened in pass 1. This performed code generation and left placeholders for references to other locations like branch targets or variables. Pass 2 consisted of resolving these references and patching up the code. Even though Pass 1 had all the smarts and Pass 2 was just doing clerical work, it was Pass 2 that took the most time because it was I/O-bound, and floppy disks are not speed demons when it comes to random access. Pass 2 was I/O-bound not only because of the need to patch the object code, but also because the table of line numbers was itself written to disk, there not being enough RAM to keep it in memory. Pass 2 made a pass through the object code once for each variable, since the references to a variable were threaded through the object code as a linked list, similar to how 16-bit Windows threaded external references through the code instead of keeping a separate fixup table. Your program has 100 variables? Then that's 100 passes through the object code to update references to 100 variables. When the code generator needed to access a variable, it didn't do so directly. The 6502 was an 8-bit processor, so none of the variables fit into a register. You needed to call a function to transfer the variable's value to or from a common staging area.3 Your traditional code generation went something like this: ; BASIC code: X = A + B ; traditional code generation lda #address_of_a_lo ldy #address_of_a_hi call load_variable_to_accumulator lda #address_of_b_lo ldy #address_of_b_hi call load_variable_to_arg call add_arg_to_accumulator lda #address_of_x_lo ldy #address_of_x_hi call store_accumulator_to_variable To save four bytes at each call site, the address-loading is factored out, and each variable gets a dedicated entry point: ; revised code generation call load_variable_a_to_accumulator call load_variable_b_to_arg call add_arg_to_accumulator call store_accumulator_to_variable_x ... ; block of variable access functions load_variable_a_to_accumulator: lda #address_of_a_lo ldy #address_of_a_hi jmp load_variable_to_accumulator load_variable_b_to_arg: lda #address_of_b_lo ldy #address_of_b_hi jmp load_variable_to_arg store_accumulator_to_variable_x: lda #address_of_x_lo ldy #address_of_x_hi jmp store_accumulator_to_variable This is a net win if each variable is accessed several times, which is a pretty fair assumption. To save code size further, the access function was itself parameterized on the type of access. store_arg_to_variable_x: ldx #4 .byte 0x2c ; swallow next two bytes load_variable_x_to_arg: ldx #3 .byte 0x2c ; swallow next two bytes store_accumulator_to_variable_x: ldx #2 .byte 0x2c ; swallow next two bytes load_variable_x_to_accumulator: ldx #1 lda #address_of_x_lo ldy #address_of_x_hi jmp do_something_with_variable ; uses value in X to decide what to do We are using the trick of jumping into the middle of an instruction to provide multiple entry points to a common block of code. The author of TASC was very proud of this optimization. Related reading: Excuse me, has anybody seen the FOCAL interpreter? 1 This is the same building that was next door to the restaurant that inspired an important variable name in the 16-bit Windows kernel. 2 Also, Applesoft BASIC didn't have local variables. All variables were global. That certainly didn't help with understanding the code. 3 It has been said that when you write code for the 6502, you're not so much writing code as you are writing microcode. The CPU itself has only three 8-bit registers (A, X, and Y), and only A can do arithmetic. Anything of more than ephemeral value must be stored in memory. The real working space was the zero page. For example, you might decide that one region of the zero page was the logical "accumulator", and most of your time was spent transferring values into or out of that accumulator, interspersed with occasionally performing arithmetic on or testing the value in that accumulator. Perhaps the most famous example of treating the 6502 as microcode is the SWEET16 interpreter, written by Steve Wozniak, which emulated a 16-register 16-bit virtual processor in roughly 300 bytes of memory. [png] Raymond Chen Follow Tagged History Read next Why are there separate Program Files and Program Files (x86) directories? Why can't we just combine them? [png]Raymond C March 29, 2022 37 comments The cats sitting on a fence in early builds of Windows 8 Something to look at when all is lost. [png]Raymond C February 8, 2022 3 comments 10 comments Leave a commentCancel reply Log in to join the discussion. * [png] Henry Skoglund April 19, 2022 7:50 am collapse this comment The constraints of the 6502 also affected the designs of games, for example did you know why the Apple ][ version of Space Invaders, the Apple Invader game has a "decoration pane" to the right, i.e. why the playing field does not occupy the full width of the screen? Because the screen width is 280 pixels but handling more than 256 pixels was too much of a stretch for the 6502 (it would have been too slow). Log in to Reply + [png] Vincent Weaver April 20, 2022 11:30 am collapse this comment as someone who has done a lot of Apple II hi-res programming recently, while it is a minor pain drawing past 256 pixels, in general it's one of the least weird issues with that graphics mode. Since the framebuffer is grouped in chunks of 7 pixels (or 3.5 depending on how you look at it) it's often easier to keep co-ordinates in a divided by 7 framework since any standard putpixel routine would have to do a divide by 7 anyway (not particularly easy to do in a fast or compact way on 6502). in the end though if Microsoft was that concerned about address space on the Apple II they wouldn't have wasted a number of bytes in the ROM for the backwards/EOR encrypted "MICROSOFT!" string they hid just after the sine tables Log in to Reply o [png] Paradice . April 20, 2022 10:36 pm collapse this comment "Wasted"? They were probably the most valuable 10 bytes in the code from MS' perspective. Log in to Reply * [png] Paul Topping April 19, 2022 9:57 am collapse this comment I worked for a GUI Computer Aided Design software company in the late 70's. It was my first job out of college. The system we worked on, like TASC, had a lot more code than would fit into memory on the minicomputers we were using, Data General Eclipse and the like. Until now, I never heard the term "chaining" applied to the technique of swapping in code from disk into a running program. We used the term "core load" to refer to each chunk. (Core as in core memory, of course.) We linked each one (there were hundreds) as if it was a single executable. They all had the same code and data below a certain address and an entry point at that address, or a constant distance above it. The lower, common code chunk obviously contained the code to read the desired core load from disk and jump to the entry point. Interesting times! Log in to Reply + [png] Paul Topping April 19, 2022 10:12 am collapse this comment I see from Wikipedia that they call the technique I mention, "overlays". Chaining is reserved for the practice of replacing the whole program. From the distance of time, it all amounts to the same thing. Log in to Reply + [png] Antonio Rodriguez April 19, 2022 10:45 am collapse this comment In the Apple II, chaining was common for large programs, but it only worked in Wozniak's Integer Basic. IIRC, that was because Integer Basic stored the variables in the lower end of memory and the program in the higher end, so it was trivial to load a new program without destroying the variables. When Applesoft arrived, it swapped things around, and placed the program at the lower end, followed by the variables. The location of the variables varied with the length of the program, so you had to move all the variables and fix the internal pointers (array and string variables were just descriptors which pointed to the actual data - in fact, Applesoft implementation of strings was very similar to COM's BSTR [guess where the "B" comes from?], but I'm getting off-track). It wasn't until the introduction of ProDOS in 1983 that Applesoft gained a CHAIN command. By the time ProDOS became common, most newer Apple II models were being sold with 128 KB of RAM, which allowed you to store program segments in the /RAM/ disk, and also use it for storing and recalling entire variable sets. That allowed you to switch from one program to another seamlessly, in a few seconds and without touching disk. Magic! Log in to Reply * [png] Georg Rottensteiner April 19, 2022 9:21 pm collapse this comment Small memory leads to really fun stuff. For a C64 game (also on the 6510, quite similar to 6502) I had common routines in lower memory, and for the loaded stages (from disk, taking half a minute or more to load in) a "reserved" block of memory. Albeit the zero page was mostly used for a few shared variables, since they can be accessed a bit faster (and with smaller opcodes) Thanks to todays cross assembling tools I could share symbols with a little rebuild and was able to directly call the common routines. I have the utmost respect for the people that did it back then with all the restraints, waiting for half an hour per compile, etc. Log in to Reply + [png] Antonio Rodriguez April 20, 2022 1:10 pm collapse this comment You worked with tight memory and CPU time constraints, but development used to be way more interactive (and rewarding) than today. Most programs were written in machine code or in Basic, and both were interactive: you could just type (or edit) a sentence or instruction, and run it immediately, or inspect or modify memory and variables and continue execution. And in the case of assembler, you could patch the program after hitting a breakpoint and resume execution after it. You could even do the patching by typing assembly code which got translated immediately to opcodes, thanks to the MiniAssembler built into the firmware. Basic compilers, lite the TASC, gave you the best of both worlds: quick development in the interactive environment of Basic, and, when the program was polished, great performance in the binary. Compiling was quite slow, but you only had to compile once for each release! Log in to Reply * [png] Dave Gzorple April 19, 2022 10:38 pm collapse this comment Was it TASC or the Apple Pascal compiler that was nondeterministic, you got a different output every time you ran it? What you had to do was keep re-running the compile until you got a compiled program that didn't crash when run. It's been way too long, but from memory it was TASC because I remember having to wait ages for it to run repeatedly. Log in to Reply * [png] Al Grant April 22, 2022 2:50 pm collapse this comment We used TASC to compile a program that optimized the component placement sequence for surface mount robots. This was mission critical for a large factory, and so large that all the comments were kept in a separate file (one benefit of BASIC having numbers on every line!). Somehow TASC fit in alongside it. TASC took half an hour to compile the program, but it was rock solid. Good points about compiled code making much use of calls to helper primitives (3 bytes per primitive). It was not unlike a stack machine. FORTH cut out the JMPs and stored just the addresses of the primitives (2 bytes). Performance was about even with compiled BASIC since all the heavy lifting was done in the primitives. I guess the main performance benefit that came from TASC was eliminating syntax analysis, symbol lookup and line number lookup - with effectively no registers, there would have been little benefit from the mid-end and back-end optimizations we spend so much time on these days. Log in to Reply Archive April 2022 March 2022 February 2022 January 2022 December 2021 November 2021 October 2021 September 2021 August 2021 July 2021 June 2021 May 2021 April 2021 March 2021 February 2021 January 2021 December 2020 November 2020 October 2020 September 2020 August 2020 July 2020 June 2020 May 2020 April 2020 March 2020 February 2020 January 2020 December 2019 November 2019 October 2019 September 2019 August 2019 July 2019 June 2019 May 2019 April 2019 March 2019 February 2019 January 2019 December 2018 November 2018 October 2018 September 2018 August 2018 July 2018 June 2018 May 2018 April 2018 March 2018 February 2018 January 2018 December 2017 November 2017 October 2017 September 2017 August 2017 July 2017 June 2017 May 2017 April 2017 March 2017 February 2017 January 2017 December 2016 November 2016 October 2016 September 2016 August 2016 July 2016 June 2016 May 2016 April 2016 March 2016 February 2016 January 2016 December 2015 November 2015 October 2015 September 2015 August 2015 July 2015 June 2015 May 2015 April 2015 March 2015 February 2015 January 2015 December 2014 November 2014 October 2014 September 2014 August 2014 July 2014 June 2014 May 2014 April 2014 March 2014 February 2014 January 2014 December 2013 November 2013 October 2013 September 2013 August 2013 July 2013 June 2013 May 2013 April 2013 March 2013 February 2013 January 2013 December 2012 November 2012 October 2012 September 2012 August 2012 July 2012 June 2012 May 2012 April 2012 March 2012 February 2012 January 2012 December 2011 November 2011 October 2011 September 2011 August 2011 July 2011 June 2011 May 2011 April 2011 March 2011 February 2011 January 2011 December 2010 November 2010 October 2010 September 2010 August 2010 July 2010 June 2010 May 2010 April 2010 March 2010 February 2010 January 2010 December 2009 November 2009 October 2009 September 2009 August 2009 July 2009 June 2009 May 2009 April 2009 March 2009 February 2009 January 2009 December 2008 November 2008 October 2008 September 2008 August 2008 July 2008 June 2008 May 2008 April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 May 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 Relevant Links I wrote a book Ground rules Disclaimers and such My necktie's Twitter Categories Code History Tips/Support Other Non-Computer Stay informed Login Insert/edit link Close Enter the destination URL URL [ ] Link Text [ ] [ ] Open link in a new tab Or link to existing content Search [ ] No search term specified. Showing recent items. Search or use up and down arrow keys to select an item. Cancel [Add Link] Code Block x Paste your code snippet [ ] Cancel Ok What's new * Surface Pro 8 * Surface Laptop Studio * Surface Pro X * Surface Go 3 * Surface Duo 2 * Surface Pro 7+ * Windows 11 apps * HoloLens 2 Microsoft Store * Account profile * Download Center * Microsoft Store support * Returns * Order tracking * Virtual workshops and training * Microsoft Store Promise * Flexible Payments Education * Microsoft in education * Devices for education * Microsoft Teams for Education * Microsoft 365 Education * Education consultation appointment * Educator training and development * Deals for students and parents * Azure for students Business * Microsoft Cloud * Microsoft Security * Azure * Dynamics 365 * Microsoft 365 * Microsoft Advertising * Microsoft Industry * Microsoft Teams Developer & IT * Developer Center * Documentation * Microsoft Learn * Microsoft Tech Community * Azure Marketplace * AppSource * Microsoft Power Platform * Visual Studio Company * Careers * About Microsoft * Company news * Privacy at Microsoft * Investors * Diversity and inclusion * Accessibility * Security English (United States) * Sitemap * Contact Microsoft * Privacy * Manage cookies * Terms of use * Trademarks * Safety & eco * About our ads * (c) Microsoft 2022