4 ms·

Microsoft's use of pcode in BASIC predates even Visual Basic. I believe the first use of it was in QuickBASIC 4.0 (~87-88), which had an adversing campaign buil

Microsoft's use of pcode in BASIC predates even Visual Basic. I believe the first use of it was in QuickBASIC 4.0 (~87-88), which had an adversing campaign built around the fact it could compile at some ridiculously high rate. What was happening, however, was that part of the compilation process was built into the editor and run incrementally. When you typed in and completed a line of code, it would be shipped off to the compiler, analyzed for errors, and then represented in the editor. This was easiest to see in the fact that the editor would automatically capitalize keywords, but also visible in the fact it would immediately report certain kinds of errors and make other minor code corrections. Heady stuff in 1988 when running at 4.77MHz. (The same was true for the interactive debugging tools built into the IDE.) In any event, this was the precursor for similar functionality in later products, ranging from MS BASIC 7.0 to the Visual BASIC series. BASIC 7.0 was also interesting in that it was at the tail end of Microsoft's BASCOM product line for DOS. For years, they'd offered a BASIC compiler product in parallel with the interpreted products that got most of the press ant attention. The compiler product was what you used if your interpreted BASIC program needed more execution speed or better packaging. It was BASIC 7 where the QuickBASIC IDE officially converged with the full machine code compiler. BASIC 7 included the IDE, a full compiler that could also target OS/2, and an ISAM database library. It was really a precursor to all the uses of VB to build line of business apps, etc. > I was told that many office applications (on windows 3.1) were 90% pcode and 10% assembly. The C compiler (at least) had options for compiling C into pCode that would be interpreted at runtime. I've forgotten most of the details other than that it was mainly sold as a code compression scheme of sorts. This was on the observation that pCode was more compact, but slower. (The pCode and the interpreter itself were all bundled into an x86-specific binary file, so there was no pretense of any of the cross-platform aspirations commonly associated with pCode.)

scarface74 8y ago
Microsoft was writing BASIC interpreters for early 8 but computers. The original AppleSoft Basic built into Apple II’s in the early 80s was written by MS.
- mschaef 8y ago
  Yup. They were founded on a BASIC for the Altair 8800. pCode as an architectural element of their BASICS, however, was ten or more years after that. (IIRC, Applesoft BASIC's execution model was a doubly linked list of statement structures. My guess is tokenized, but not in the same sense as QB4 compiled to pcode.)
  - scarface74 8y ago
    I don’t remember them being a double link list. IIRC, the first two bytes of a tokenized line was the address of the next statement and each command was tokenized. For speed, if you had a “subroutine” (gosub/return) that was called frequently, it was better to place it at the beginning of the program because it was an O(n) operation to travel the linked list. It makes me sad thinking about how much more I knew about the underpinnings of my computer architecture and chosen language in the 8th grade than I know now as a working professional. I can still write 65C02 assembly language using an Apple // emulator but I wouldn’t know where to start with x86.
    - mschaef 8y ago
      > I don’t remember them being a double link list. IIRC, the first two bytes of a tokenized line was the address of the next statement and each command was tokenized. You may well be right... it's been a longer time than I care to admit. > I can still write 65C02 assembly language using an Apple // emulator but I wouldn’t know where to start with x86. My job out of school was at least partially to write software for an embedded 4MHz 80188... not too different from an original PC. Even in such a limited environment, virtually everything was written in C. This includes things like interrupt handlers directly invoked by the CPU and task switching code in our primitive RTOS. I think the only assembler was a bit of startup code. > It makes me sad thinking about how much more I knew about the underpinnings of my computer architecture... I see your point, but my view is that the goal of many of the abstractions we have is to make it possible to shift our focus to higher level and presumably more important concerns. It doesn't always work out that way, of course - sometimes the abstractions get in the way - but I do miss the power of today's languages when I go back to lower level tooling. One side note to this is that the embedded project above started out running in real mode X86, but by the time I'd left, we had ports for 32-bit protected mode, MC68K, and a version hosted Win32. There were sound technical and commercial reasons for all of this, but it all would have been a lot more costly to achieve in time and money if we'd been coding in assembler. In other words, we arguably gained by not knowing more about the underpinnings of our computer.

scarface74 8y ago

Microsoft was writing BASIC interpreters for early 8 but computers. The original AppleSoft Basic built into Apple II’s in the early 80s was written by MS.

mschaef 8y ago
Yup. They were founded on a BASIC for the Altair 8800. pCode as an architectural element of their BASICS, however, was ten or more years after that. (IIRC, Applesoft BASIC's execution model was a doubly linked list of statement structures. My guess is tokenized, but not in the same sense as QB4 compiled to pcode.)
- scarface74 8y ago
  I don’t remember them being a double link list. IIRC, the first two bytes of a tokenized line was the address of the next statement and each command was tokenized. For speed, if you had a “subroutine” (gosub/return) that was called frequently, it was better to place it at the beginning of the program because it was an O(n) operation to travel the linked list. It makes me sad thinking about how much more I knew about the underpinnings of my computer architecture and chosen language in the 8th grade than I know now as a working professional. I can still write 65C02 assembly language using an Apple // emulator but I wouldn’t know where to start with x86.
  - mschaef 8y ago
    > I don’t remember them being a double link list. IIRC, the first two bytes of a tokenized line was the address of the next statement and each command was tokenized. You may well be right... it's been a longer time than I care to admit. > I can still write 65C02 assembly language using an Apple // emulator but I wouldn’t know where to start with x86. My job out of school was at least partially to write software for an embedded 4MHz 80188... not too different from an original PC. Even in such a limited environment, virtually everything was written in C. This includes things like interrupt handlers directly invoked by the CPU and task switching code in our primitive RTOS. I think the only assembler was a bit of startup code. > It makes me sad thinking about how much more I knew about the underpinnings of my computer architecture... I see your point, but my view is that the goal of many of the abstractions we have is to make it possible to shift our focus to higher level and presumably more important concerns. It doesn't always work out that way, of course - sometimes the abstractions get in the way - but I do miss the power of today's languages when I go back to lower level tooling. One side note to this is that the embedded project above started out running in real mode X86, but by the time I'd left, we had ports for 32-bit protected mode, MC68K, and a version hosted Win32. There were sound technical and commercial reasons for all of this, but it all would have been a lot more costly to achieve in time and money if we'd been coding in assembler. In other words, we arguably gained by not knowing more about the underpinnings of our computer.