5 ms·

The OP says that 8-bit CPUs couldn't handle Pascal well, and that Action! (release in 1983) was the first IDE for 8-bit machines. But Apple Pascal was released

The OP says that 8-bit CPUs couldn't handle Pascal well, and that Action! (release in 1983) was the first IDE for 8-bit machines. But Apple Pascal was released for the Apple II in 1979. Based on UCSD Pascal, the Apple Pascal system was basically an OS that simply was an IDE; and it worked perfectly well on 8-bit hardware. I had quite a lot of fun with it back in the day.

forinti 1y ago
I learnt Pascal on a Beeb. It had a compiler, an editor, and a runtime in two 16KB ROMS.
cmrdporcupine 1y ago
If I'm not mistaken Apple Pascal ran a virtual machine which executed "p-Code" and the compiler emitted that. Because, yeah, the 6502 is a difficult target for high level languages.
ajross 1y ago
Apple Pascal was a UCSD Pascal descendant, which means it was a P-Code interpreter. The article is broadly correct. The 6502 had what amounts to a mixed-performance address space. All indirect addressing had to be done via pairs of registers in the zero page at addresses 0-255. Essentially all the "pointers" in your application wanted naturally to live as one of these 128 "pointer registers". But that's not the way natural code generation wants to work, where the pointers get stored in the data memory along with everything else. So compiled languages need to have some kind of trampoline for every pointer to copy it into the memory where it needed to live, which was a really tall order for the optimizers of 1983. Or they could just cheat and compile to a virtualized instruction set and feed that to an interpreter. Apple chose this, twice: once with Woz's sweet16 in which Integer BASIC was written, and again with the port of the P-Code interpreter for Pascal.
sema4hacker 1y ago
Around 1979 or 1980 I was working for an 8080-based CRT terminal manufacturer and ported UCSD Pascal to our 8080 system, which worked flawlessly. I don't remember the details, but I believe all I had to do was implement a few BIOS-style routines. I got hung up for a few days because I had inited the heap pointer to a byte boundary instead of a word boundary, but after that everything booted and ran as advertised.
kjs3 1y ago
The OP says that 8-bit CPUs couldn't handle Pascal well The 6502 might not have been able to handle Pascal well, but Borland Turbo Pascal for CP/M (z80, 8080, etc) worked very, very well. It was also released in 1983 or so, but dunno whether it or Factor was 'first'.
- guenthert 1y ago
  Yes, Turbo Pascal was awesome and quite possibly the best programming environment for the Z80. The register-starved 6502 however relies on zero-page addressing for efficient code, that's difficult to exploit in compilers for high level languages (and hence why you don't see that in general purpose CPUs anymore). One way around that is to compile to a byte code which is then interpreted (e.g. BCPL, UCSD Pascal).
  - wduquette 1y ago
    And in fact I eventually went from Apple Pascal to Turbo Pascal on a Kaypro 4 running CP/M-80. It was like coming home.
brucehoult 1y ago
As others have pointed out, Apple Pascal was a bytecode interpreter, not compiled to native 6502 code. Even worse, the bytecode was standard UCSD Pascal, designed for mainframes, and not really how you'd design bytecode if you knew you were going to implement it on a 6502. We can actually compile Pascal / C style languages to the 6502 pretty well these days. The way to do it is treat it the same as a RISC machine with a lot of registers (let's say 32 2-byte pairs in zero page, leaving 75% of ZP for globals and a handful of important runtime functions that benefit from self-modifying code). Split the 32 pseudo-registers up into A, S, T registers the same as you do for any RISC (or x86_64 for that matter). It's problem to handle recursion. Just the same as any function call, put anything you still want after the function call into S registers, and in the called function if it needs to use S registers then it needs to save them on a stack (NOT the 256 byte hardware stack) first and restore them after. For more than one or two saved registers it's better to use a runtime function for this -- 12 cycles overhead, but lots of bytes of code saved. RISC-V's -msave-restore provides a good model for this. You can make a nice set of 2-address arithmetic routines between 16 or 32 bit Zero-Page registers by using the X and Y registers to pass which locations to work on. add16: clc lda 0,x adc 0,y sta 0,x lda 1,x adc 1,y sta 1,x ret ... ldx #dst ldy #src jsr add16 This reduces the call site from 13 bytes to 7 bytes (and you can often reuse an X or Y), while increasing the execution time for an inline add from 20 cycles to 42 (1 cycle extra per instruction for the indexed addressing = 6, 4 cycles for loading X and Y, 12 cycles for the jsr/ret) For 32 bit arithmetic the time overhead is much reduced. For floating point it would be negligable! There is no convenient way to make 3-address routines, but `mov16` is only 5 instructions and 28 cycles. Or just 4 instructions (8 bytes) and 12 cycles if inlined, which might be a better tradeoff i.e. lda src1 sta dst lda src1+1 sta dst+1 ldx #dst ldx #src2 jsr add16 vs ldx #dst ldy #src1 jsr mov16 ldy #src2 jsr add16 Stack-based 6502 code is both bigger and slower than (pseudo) register-based code -- a zero-argument `jsr add16` itself is smaller, but it's significantly slower, and loading and storing values between stack and somewhere else will be much more code and much slower. Stack-based bytecode has a whole lot more overhead again to fetch the next instruction and dispatch to the correct code for it. Register-based bytecode would be a much better idea, as it uses several times fewer bytecode instructions, and is more compact to boot (see Dalvik vs JVM ... sad that webasm didn't pay attention).
eschneider 1y ago
I remember Kyan Pascal on the Atari. It worked, but I'm not sure it worked _well_. Better than BASIC, but still quite a bit slower than ASM. Action! was much nicer if you were looking to deliver software on the Atari.

forinti 1y ago

I learnt Pascal on a Beeb. It had a compiler, an editor, and a runtime in two 16KB ROMS.

cmrdporcupine 1y ago

If I'm not mistaken Apple Pascal ran a virtual machine which executed "p-Code" and the compiler emitted that. Because, yeah, the 6502 is a difficult target for high level languages.

ajross 1y ago

Apple Pascal was a UCSD Pascal descendant, which means it was a P-Code interpreter. The article is broadly correct. The 6502 had what amounts to a mixed-performance address space. All indirect addressing had to be done via pairs of registers in the zero page at addresses 0-255. Essentially all the "pointers" in your application wanted naturally to live as one of these 128 "pointer registers". But that's not the way natural code generation wants to work, where the pointers get stored in the data memory along with everything else. So compiled languages need to have some kind of trampoline for every pointer to copy it into the memory where it needed to live, which was a really tall order for the optimizers of 1983. Or they could just cheat and compile to a virtualized instruction set and feed that to an interpreter. Apple chose this, twice: once with Woz's sweet16 in which Integer BASIC was written, and again with the port of the P-Code interpreter for Pascal.

sema4hacker 1y ago

Around 1979 or 1980 I was working for an 8080-based CRT terminal manufacturer and ported UCSD Pascal to our 8080 system, which worked flawlessly. I don't remember the details, but I believe all I had to do was implement a few BIOS-style routines. I got hung up for a few days because I had inited the heap pointer to a byte boundary instead of a word boundary, but after that everything booted and ran as advertised.

kjs3 1y ago

The OP says that 8-bit CPUs couldn't handle Pascal well The 6502 might not have been able to handle Pascal well, but Borland Turbo Pascal for CP/M (z80, 8080, etc) worked very, very well. It was also released in 1983 or so, but dunno whether it or Factor was 'first'.

guenthert 1y ago
Yes, Turbo Pascal was awesome and quite possibly the best programming environment for the Z80. The register-starved 6502 however relies on zero-page addressing for efficient code, that's difficult to exploit in compilers for high level languages (and hence why you don't see that in general purpose CPUs anymore). One way around that is to compile to a byte code which is then interpreted (e.g. BCPL, UCSD Pascal).
- wduquette 1y ago
  And in fact I eventually went from Apple Pascal to Turbo Pascal on a Kaypro 4 running CP/M-80. It was like coming home.

brucehoult 1y ago

As others have pointed out, Apple Pascal was a bytecode interpreter, not compiled to native 6502 code. Even worse, the bytecode was standard UCSD Pascal, designed for mainframes, and not really how you'd design bytecode if you knew you were going to implement it on a 6502. We can actually compile Pascal / C style languages to the 6502 pretty well these days. The way to do it is treat it the same as a RISC machine with a lot of registers (let's say 32 2-byte pairs in zero page, leaving 75% of ZP for globals and a handful of important runtime functions that benefit from self-modifying code). Split the 32 pseudo-registers up into A, S, T registers the same as you do for any RISC (or x86_64 for that matter). It's problem to handle recursion. Just the same as any function call, put anything you still want after the function call into S registers, and in the called function if it needs to use S registers then it needs to save them on a stack (NOT the 256 byte hardware stack) first and restore them after. For more than one or two saved registers it's better to use a runtime function for this -- 12 cycles overhead, but lots of bytes of code saved. RISC-V's -msave-restore provides a good model for this. You can make a nice set of 2-address arithmetic routines between 16 or 32 bit Zero-Page registers by using the X and Y registers to pass which locations to work on. add16: clc lda 0,x adc 0,y sta 0,x lda 1,x adc 1,y sta 1,x ret ... ldx #dst ldy #src jsr add16 This reduces the call site from 13 bytes to 7 bytes (and you can often reuse an X or Y), while increasing the execution time for an inline add from 20 cycles to 42 (1 cycle extra per instruction for the indexed addressing = 6, 4 cycles for loading X and Y, 12 cycles for the jsr/ret) For 32 bit arithmetic the time overhead is much reduced. For floating point it would be negligable! There is no convenient way to make 3-address routines, but `mov16` is only 5 instructions and 28 cycles. Or just 4 instructions (8 bytes) and 12 cycles if inlined, which might be a better tradeoff i.e. lda src1 sta dst lda src1+1 sta dst+1 ldx #dst ldx #src2 jsr add16 vs ldx #dst ldy #src1 jsr mov16 ldy #src2 jsr add16 Stack-based 6502 code is both bigger and slower than (pseudo) register-based code -- a zero-argument `jsr add16` itself is smaller, but it's significantly slower, and loading and storing values between stack and somewhere else will be much more code and much slower. Stack-based bytecode has a whole lot more overhead again to fetch the next instruction and dispatch to the correct code for it. Register-based bytecode would be a much better idea, as it uses several times fewer bytecode instructions, and is more compact to boot (see Dalvik vs JVM ... sad that webasm didn't pay attention).

eschneider 1y ago

I remember Kyan Pascal on the Atari. It worked, but I'm not sure it worked _well_. Better than BASIC, but still quite a bit slower than ASM. Action! was much nicer if you were looking to deliver software on the Atari.