3 ms·

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, Appl

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

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.