3 ms·
> no C yet, just B, but evidently the B compiler was already generating native code instead of stack bytecode No, B always generated interpreted/threaded code
by aap_ 4y ago
> no C yet, just B, but evidently the B compiler was already generating native code instead of stack bytecode
No, B always generated interpreted/threaded code on UNIX, certainly on the PDP-7. We have the runtime and B library from that time.
- kragen 4y agothe manual seems to claim otherwise when speaking about the -11, in that it says the B compiler produced a.out and n.out files just like the assembler (presumably by invoking it) you could do this just by aggregating the interpreter (which is never mentioned) with the bytecode in a single file, but that would imply making 10 copies of the interpreter if you had 10 programs compiled with B, on a 512-kibibyte disk; a highly suboptimal tradeoff under the circumstances but even in such a case what symbols would you put in n.out
- aap_ 4y agoThe interpreter is part of the binary yes. I have reversed what was available here: http://squoze.net/B/ http://squoze.net/B/ and written my own B compiler that generates the same threaded code as well: https://github.com/aap/b https://github.com/aap/b
- kragen 4y agothank you very much for the extremely awesome correction what do you suppose the b command put in n.out
- aap_ 4y agoI actually didn't know about n.out before. It wasn't mentioned in the v1 manual so they must have gotten rid of it by then. However it seems that it is just a symbol table that's generated by the assembler. B code is eventually also passed to the assembler so it would just contain whatever symbols were in the assembly i suppose.