41–50 of 61 posts
Earlier quoted context omitted.
To be pedantic, V0 actually refers to the PDP-7 UNIX released in 1969. 1971 saw the port to the PDP-11/20, which was released as UNIX-11 and soon after, V1 UNIX.
The edition numbers refer to the manual pages more than the software, which in the early days was under continual development running on approximately one machine. It wasn’t released in 1971.
Earlier quoted context omitted.
> 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.
the 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 h…
Newly discovered earliest draft of a Unix manual (1971) - https://news.ycombinator.com/item?id=10794189 - Dec 2015 (40 comments)
The Unix Time-Sharing System, unpublished draft (1971) [pdf] - https://news.ycombinator.com/item?id=10660727 - Dec 2015 (1 comment)
this is great. i realized that manuals and documentation might have used a lot of paper back then. the new PDF that was typeset using troff is half the length of the original!
Earlier quoted context omitted.
yeah, i think some of that was cp/m compatibility crap; too bad about 8.3 the other thing is that the pdp-11 had working segmentation, the 8086 didn't, so trapping faults in user processes so they couldn't break the kernel would have required some kind of interpretation or something did you know microsoft was shipping xenix in 01981 (the same year they started shipping qdos/ms-dos/pc-dos) and shipping xenix for the 8…
According to some sources, which I sadly cannot point out to, just vague memories from somewhere, so take it with a grain of salt. Early MS-DOS development used to be done from those Xenix environments, they would cross-compile to PCs, until later on, did they migrate to MS-DOS directly. Most likely around MS-DOS 5, given the MS-DOS 3.3 resources and how MS-DOS 4 development went. On the other hand, there is the what…
Earlier quoted context omitted.
Oddly enough, it looks both more and less featured than MS-DOS, and the PDP-11 it ran on was somewhat close to the first IBM PC in memory and CPU speed. Some comparison points with MS-DOS 1.0: - 8.3 filenames - no subdirectories - single user - 32-bit file sizes and offsets (64k file size limit was definitely not enough by then) - FCB-based API (not file handles), FAT12 filesystem with 32MB limit - Hardcoded device n…
yeah, i think some of that was cp/m compatibility crap; too bad about 8.3 the other thing is that the pdp-11 had working segmentation, the 8086 didn't, so trapping faults in user processes so they couldn't break the kernel would have required some kind of interpretation or something did you know microsoft was shipping xenix in 01981 (the same year they started shipping qdos/ms-dos/pc-dos) and shipping xenix for the 8…
The earliest models didn't. See: https://gunkies.org/wiki/PDP-11/20
Earlier quoted context omitted.
According to some sources, which I sadly cannot point out to, just vague memories from somewhere, so take it with a grain of salt. Early MS-DOS development used to be done from those Xenix environments, they would cross-compile to PCs, until later on, did they migrate to MS-DOS directly. Most likely around MS-DOS 5, given the MS-DOS 3.3 resources and how MS-DOS 4 development went. On the other hand, there is the what…
Hmm. Wasn't it done on a dec-10?
Earlier quoted context omitted.
the 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 h…
The interpreter is part of the binary yes. I have reversed what was available here: http://squoze.net/B/ and written my own B compiler that generates the same threaded code as well: https://github.com/aap/b
what do you suppose the b command put in n.out
Earlier quoted context omitted.
yeah, i think some of that was cp/m compatibility crap; too bad about 8.3 the other thing is that the pdp-11 had working segmentation, the 8086 didn't, so trapping faults in user processes so they couldn't break the kernel would have required some kind of interpretation or something did you know microsoft was shipping xenix in 01981 (the same year they started shipping qdos/ms-dos/pc-dos) and shipping xenix for the 8…
> pdp-11 had working segmentation The earliest models didn't. See: https://gunkies.org/wiki/PDP-11/20
this also explains a remark in the manual that puzzled me about the break() system call (p. 43, §A1.17):
> To save time, UNIX does not swap all of the 4K user core area when exchanging core images. The locations swapped are those from the beginning of the core image to the initial program break, and from the top of user core down to the stack pointer. The initial program break is determined by the size of the file containing the program. The system’s idea of how much to swap may be altered by using this call:
sys break
newbreak
in later versions of unix, of course, attempting to access memory after the break would result in a segmentation fault, but evidently in this version whatever you wrote there would just sometimes be lost when 'exchanging core images' — and presumably it wasn't just the segment limit that was missing on the -11/20, but also implicit indexing off the segment base pointer, which would imply that a mere context switch would require swapping the user program out in this way, just as on the pdp-7
i don't suppose anyone else here has knowledge if this inference is correct?
in any case, thank you very much for this correction!
Earlier quoted context omitted.
The interpreter is part of the binary yes. I have reversed what was available here: http://squoze.net/B/ and written my own B compiler that generates the same threaded code as well: https://github.com/aap/b
thank you very much for the extremely awesome correction what do you suppose the b command put in n.out