Actually I doubt that. I think p850ug1 (this machine) is the slowest linux box currently in use. Can anyone beat 1.15 bogomips? -tony

On 02/02/2012 20:11, allison wrote: Yes, I should have known better than to make that claim! -- Pete Peter Turnbull Network Manager University of York

I am not convinced it's slower tham mine... This machine has the original PC/AT motherboard with a 16MHz master clock. The CPU is a 486SLC-thing on a kludgeboard plugged into the 80286 socket. 7-and-a-bit Megabytes of RAM, everythign on the ISA bus. I am suprsied that it's that slow, given the higher master clock rate, and more RAM. Err, yes... I don't even try to run X on this machine... -tony

On 02/03/2012 03:51 PM, Cameron Kaiser wrote: Oh yeah, well, in my day, I ran Xenix on a Lisa at 5MHz, no windowing system there, on a pair of 5MB profile drives. :) And yes, you kids have it very nice these days, in my day, we used to hike uphill 5 miles in the snow, both ways, to/from school, and we had to watch out for sabre toothed cats. (Waiting for the guys that ran real UNIX on a PDP-8 to show up and say they rode T-Rex's to school.)

On Mon, 6 Feb 2012, Eric Smith wrote: So, does anyone have a record for oldest or weakest computer running Unix? The Z80 definitely did it. Maybe the 8080 could. I don't think the PDP-8 could. I've been trying to figure out if the PDP-8 could handle C, and the answers I get range from "I don't know" to "Definitely not". Something I'd really like to see is a Z-machine running on the PDP-8. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

I guess I'm a total anorak, but there was a TNIX.. [Tektronix Unix, running on a PDP11/23-based development sustem] -tony

I _may_ have the distribution kit for my machine I will see what I can find. -tony

On 6 Feb 2012 at 18:00, David Griffith wrote: "Running in native mode", I assume. Any Turing-complete processor with enough storage can emulate any other processor, however slowly. So I suppose it's possible to emulate, say, a 68000 on an 8008, given patience that would make Job despair. I think Al K. mentioned a port of of Unix to a Univac 1100 series machine, which probably qualifies both as a crufty and outre implementation (36 bit word, ones' complement). Moving a bit up, Cromemco could run Cromix on a System 3 with ZPU; I think Cromemco claimed that Cromix *was* Unix. A bit later, Onyx ran Unix/Xenix on Z8000. When the 68K came out, everyone was running Unix. --Chuck

Mouse wrote: The 8080? Not likely. If you're going to compare the 8080 to a PDP-11, it's a register-starved PDP-11 with no indexing. That means the code density is going to be *far* worse than PDP-11 code. A Z80 is much better in that regard.

On 6 Feb 2012 at 23:12, Eric Smith wrote: It depends largely on how things are implemented. I can well imagine an 8080 running a pcode sort of implmentation, a la Sweet16 (for the 6502). There may be a penalty in execution speed, but code density can be made to be comparable. --Chuck

On 7 Feb 2012 at 14:15, Eric Smith wrote: So, if SWEET16 is emulating something, what is it emulating? To me, it looks like a collection of (native code) subroutines, no matter how Woz pitched it. But on topic, I know that early Unix was not written in C, but has any version of Unix been rewritten in Pascal or Modula-2? --Chuck

On 7 Feb 2012 at 22:47, Eric Smith wrote: I suppose it depends upon how you look at it. There are plenty of machines out there with incomplete (i.e. not all instructions present in hardware), where execution of the unimplemented instruction causes a trap to a subroutine that performs the deisred operation. I would not, as a whole, call programs running on those machines, "emulated", even if they use some emulation facilities. Put on the appropriate fully-implemented hardware, nothing is emulated. Whle you could claim that 6502 SWEET16 is an emulator of sorts, really, the difference between a subroutine call with a variable number of arguments and SWEET16 code is vanishingly small. Both are activated by a JSR and control eventually returns to the calling program. So, back to the original premise, operations that take several bytes on an 8080 could be reduced considerably by resorting to a SWEET16 sort of implementation--i.e. an RST byte followed by an opcode byte, followe by operands, if any. So long as control returns to the calling code, that code, as a whole is not being emulated. Contrast this with P-code implementations, or CPU emulatons, where the program never gets control of the real P-counter--it's always being managed by the P-code interpreter or the emulation package. --Chuck

On 8 Feb 2012 at 16:02, Eric Smith wrote: Precisely my point. The P-code interpreter never relinquishes access of the *real* P-counter to the calling program. A native code subroutine (and Sweet16) does. You JSR to Sweet16 and it eventually returns. That's not the case with any interpreted code. SWEET16 is a set of routines with an unsual argument-passing convention. The calling program has control at the outset and receives control back when SWEET16 returns. That's not the case with Java, UCSD Pascal, etc. During execution of those the program is never aware of the underlying architecture. I can run P-code compiled programs on any platform that supports that variety of P-code. I cannot do the same with a 6502 program using SWEET16. Too much 6502 native code! --Chuck

On 8 Feb 2012 at 16:36, Eric Smith wrote: That's precisely the point--the program starts out in 6502 native mode. It calls (via JSR) a subroutine (SWEET16) that goes through the argument list (follows the JSR) until the end. If that's not native code, then neither is a printf(), which is invoked via a native-mode CALL instruction, which then interprets the string passed as an argument. I suppose you could argue that printf() is executing printf instructions and not native code, but that seems to be stretching the point. I can similarly run a sequence similar to the following (and I have): CALL DoSomething integer operation-one address operand-one address operand-two integer operation-two address operand-one address operand-two address operand-three 0 But let's get back to my original proposal. Suppose I want to implement an indirect fetch-and-postincrement operation corresponding to C *p++. I could write (in 8080 pseudocode): RST 5 db increment-and-fetch code dw address of pointer and write a servicer for RST 5 that would execute a short subroutine that would fetch the pointer, load and return the byte it points to and then increment and store the pointer. If fetch-and-increment- pointer is a common operation, I can potentially save a large amount of code. It's not emulation. That you need to use emulation to execute a 6502 program on a different platform should be the clue. --Chuck

I wrote: s/usual/unusual/

On 2/8/2012 8:47 PM, Sean Conner wrote: You, my good sir, are a witty blogger. I'm reading your "Protocol Stack..." entries now. Well worth a read by all, given the recent topics here. Jim -- Jim Brain brain at jbrain.com www.jbrain.com

It was thus said that the Great Chuck Guzis once stated: It's turtles all the way down though. There are other VMs that do this. Granted, they too, have unusual argument-passing conventions, but in C, I can call subroutines that run in the Lua VM [1] and receive control back. And said Lua VM can call back into my C code as well. I'm looking at some technical documentation I have on OS-9 (the non-Macinstosh operating system from Microware) and while I've never actually run OS-9, the documentation does state (about modules): BASIC09, for example, may run either I-code or 6809 machine language procedures arbitrarily by checking the langauge type code. To me, and the fact that the module type can be one of four different types of code [2], says to me that code *can* be written to load up a "module" and "call" it [3]. In fact, the documentation for OS-9 lists seven pre-defined module types, one of which is "program" and one of which is "subroutine", so the implication I see is that you can write "subroutines" in any language, and call them [4]. And yes, you can run a 6502 program using SWEET16---you just need to interpret 6502 code (although that's typically called an "emulator" [5]). -spc (SWEET16 is a simple 16-bit VM inside an Apple ][. I can run an Apple ][ emulator on an Amiga, which itself is emulated on a virtual PC running on a physical PC. At which point do the turtles stop?) [1] Lua code is compiled into an internal representation, and it's this "byte code" that Lua interprets directly. The actual byte code is an implementation detail, as LuaJIT uses a completely different form of bytecode prior to final conversion to native code [6]. [2] 6809 machine code BASIC09 I-code Pascal P-code COBOL I-code [3] Maybe by checking the type of code it is [2], and calling a code-specific argument passing method to invoke it. [4] In theory. Also in theory there is no difference between theory and practice. In practice however ... [5] Odd, isn't it? If the CPU can interpret the binary data directly, it's execution. If not, then it's interpretation, unless you are trying to interpret the machine code for another machine, then it's called emulation. [6] The LuaJIT is a drop-in replacement for the standard Lua intepreter. You can use either one interchangibly---even if you use Lua as a library. You can either link against lua or luajit. Also, the code LuaJIT produces is *fast* (although Lua itself is one of the fastest interpreters out there) and can rival C code in some cases.

On Feb 8, 2012, at 9:40 PM, Sean Conner wrote: I've not seen this "fastest" claim to be true. The plain old Lua interpreter certainly isn't bad as straight bytecode interpreters go (much faster than CPython, for example), and it's definitely one of the smallest in terms of memory footprint (even with the full standard libraries). It's not the speediest, though. I need to find the benchmarks I was looking at (it was from the point of view of implementing in games; Lua landed in the "great for scripting, maybe OK for AI but probably not ideal for physics" zone, but its memory consumption was probably the smallest out of everything (they only considered interpreted languages, so raw C/C++ aren't included). I haven't seen much of LuaJIT, but I know there was a project (IronLua?) to compile Lua to CLI bytecode to be run on Mono. Mono (which also JITs its bytecode) is pretty darn fast, and I'd give it a "nearly as fast as C with some important caveats" prize. It's a memory hog, though (probably because of its enormous .NET standard library). - Dave

A while back I asked about PDP-8 Unices. I don't remember any replies, though I seem to remember some existed. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Rational behavior is a choice, not a predestination. -- Kent Paul Dolan ----

On Tue, Feb 7, 2012 at 12:51 AM, Cameron Kaiser <spectre at floodgap.com> wrote: The oldest/weakest I've personally run UNIX on was an 11/24 w/dual RL02 (10MB each) and 2MB of RAM. It's far from a record. If I can find an affordable EAE for my PDP-11/20 and figure out how to sub the swap disk with something other than an unobtanium fixed-head disk, I'd run it there, but that's a long-term project. UNIX? Really? Or just something with a Bourne-like command line? I gotta say that I don't think so either. I am not aware of a C compiler for the PDP-8, but I think it would be exceedingly difficult to write one if were possible at all (I've done a lot of system and embedded code in C and debugged it in assembler, so I know a bit about the syntactical mapping that goes on with C abstractions to the instruction sets of MC68000s, VAXen, PDP-11s, etc). I would like that too. I've even thought a lot about it. IMHO, anyone who does it will be writing the Z-machine in PDP-8 assembler, just like what was done for the Z-80 and the 6502 for 1970s and 1980s micros. I _think_ the Mac Z-machine was the first written in C, but I could easily be mistaken on that. I know there were official Z-machines written in C for the Mac and the Amiga, and probably the later ones on the PC (not sure about the early v3 interpreters for DOS). I like Frotz. Frotz is huge compared to the 6K-8K early 8-bit interpreters. It gets more dicey trying to ask a 12-bit machine with 4K pages to emulate a 16-bit virtual machine. I would consider it a win if one could fit the Z-machine code in 2 fields with enough space left over for a 2-page system handler and a 1-page line printer (SCRIPT) handler, using any memory above 8K for object data and game file buffers. Three fields seems plausible. A few years back, I assisted with a modern from-scratch Z-machine effort for ElfOS on the 1802 (that I was showing off at an early VCFmw). On a 32K Spare Time Gizmos Elf2000, once the interpreter was loaded and the object tables were loaded, there was very little room to buffer the game - I think it was on the order of 1-3 512 byte disk blocks. You can fit a v3 game and interpreter in 32K, but to do it in less would probably require a read-write virtual memory scheme on the object data (fortunately, a full boat on a PDP-8 is 32K 12-bit words not 32K 8-bit bytes - that helps too). Strangely enough, I was just thinking about a 12-bit Z-machine this week. Anyone out there have 12-bit coding experience and have time to answer a few questions about OS/8 and file interchange from the 8-bit outer world? -ethan

On Tue, 7 Feb 2012, David Griffith wrote: There were numerous "Unix-like" OS's available. Xenix, even when sold by MICROS~1 (for 5160), seemed to actually BE Unix, less the trademark.

On Tue, 7 Feb 2012, allison wrote: While not exactly C, I've done a bit of fiddling with a byte code derived from the venerable Small-C compiler. The compiler figures things out in terms of a simple single-stack machine. There is one module in the compiler that takes the single-stack primitives and outputs assembly code for the target processor. It's possible to replace that module with one that outputs the primitives, then make an back end to turn them into code for something else. By that means, I made a variant of Small C that could compile for a variety processors ranging from from Z80 to VAX. I reworked them a bit to come up with something that could describe a simple FORTH. *That* I made go on stuff ranging from PDP-8 to VAX. Since the low-level words were written in the primitives derived from Small C, the same source could be compiled for any of the processors I ran it on. Essentially, a byte code. Of course, the PDP-8 version used 12-bit bytes. In the PDP-8 variant, each bytecode consisted of a JMS I Z instruction. Page zero was loaded up with JMP instructions that transferred to the routines that implement each primitive. For what it's worth (which is not much), it can be found here: http://anachronda.homeunix.com:8000/~rivie/third/ I've only put up the PDP-8 and Z80 versions, but I've also done a handful of other processors; enough to wring out byte-order and word-size dependencies. The PDP-8 version was done as a degenerate case involving one-byte cells. I used long symbol names in the PDP-8 source, so you'll need a variant of Doug Jone's PAL assembler that I've tweaked to take them. -- roger ivie rivie at ridgenet.net

On Sat, 18 Feb 2012, Toby Thain wrote: I made two changes: - Upped #define SYMLEN from 7 to 63 - Made certain that the object file is opened "wb" so it works under Windows. -- roger ivie rivie at ridgenet.net

On 20/02/12 2:22 PM, Ethan Dicks wrote: Thanks... Yes, I didn't realise it had a problem. I'm sure this version has built for me (but I don't use Ubuntu). I'll get back to you. --Toby

On 2/8/12 9:25 PM, "Dave McGuire" <mcguire at neurotica.com> wrote: Yup. IOT instructions *are* instructions, no greater or lesser than any other, and as you add IOT-based peripheral devices you are defining semantics for previously undefined instructions. Very cool.

On Tue, 7 Feb 2012, Roger Ivie wrote: On the P112 Sourceforge page you can download bootable images of UZI-180 for the P112. -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

I never really liked PNX. It's a personal thing, but for me the fun of the PERQ is the fact that you can modify the microcode. There is of course no hardware protection on the control store, and the mcirocode is not zwitched on a process switch under PNX (or I assume any other OS, there is no form of memory manager for the control store). There;s little problem modifyiung the microcode on a single-tasking OS like POS, but on a multi-staking one you've got to be darn cvareful differnet processes don;'to change the same thigns in differnt ways. In the end I decided I'd run unix on other machines and use the PERQ for that which only it can do. -tony

On 2/8/2012 6:06 PM, William Maddox wrote: Some of this has been archived on Bitsavers (http://bitsavers.org/bits/PERQ/floppy/accent/). Lisp M2 (which I believe is related to Spice Lisp) is there, but nothing for Accent UNIX. I haven't yet tried it on my real PERQ (I'm not sure if S5 supports the original Z80 subsystem or not, I should just write the floppies out and try it) and my emulator isn't yet to the point where it will run it either. I currently have S4 on my PERQ 1A but it's a very minimal install, no compiler and nothing much interesting other than the Sapphire window manager. - Josh

Ethan Dicks wrote: Wasn't there (at least at one time) a Minix port? Peace... Sridhar

Looking at http://cm.bell-labs.com/cm/cs/who/dmr/hist.html It appears that the pdp-8 was never part of real early real Unix, the started on the pdp-7 and then moved to the 11..