Spock levels of fascinating from me. I want to learn how to compile a pdp11 emulator on my mac.
Compiling an emulator is quite easy: have a look at simh. It's very portable and should just work out of the box.
Once you've got that working, try installing a 2.11BSD distribution. It's well-documented and came after a lot of the churn in early Unix. After that, I've had great fun playing with RT-11, to the point that I've actually written some small apps on it.
> After that, I've had great fun playing with RT-11 [...]
If you want to play around with RT-11 again, I made a small PDP-11/03 emulator + VT240 terminal emulator running in the browser. It's still incomplete, but you can play around with it here: https://lsi-11.unknown-tech.eu/ (source code: https://github.com/unknown-technologies/weblsi-11)
The PDP-11/03 emulator itself is good enough that it can run the RT-11 installer to create the disk image you see in the browser version. The VT240 emulator is good enough that the standalone Linux version can be used as terminal emulator for daily work. Once I have time, I plan to make a proper blog post describing how it all works / what the challenges were and post it as Show HN eventually.
The daves garage youtube has an episode where he documents the pitfalls of compiling 2bsd for a PDP-11/83. https://www.youtube.com/watch?v=IBFeM-sa2YY basically it is an art on a memory constrained system.
What I found entertaining was when he was explaining how to compile the kernel, I went Oh! that's where openbsd gets it from. it is still a very similar process.
What’s the process look like?
On openbsd it's
cd /sys/arch/$(machine)/conf
cp GENERIC CUSTOM
vi CUSTOM # make your changes
config CUSTOM
cd ../compile/CUSTOM
make
I have never done it for 2bsd but according to http://www.vaxman.de/publications/bsd211_inst.pdf
cd /usr/src/sys/conf
cp GENERIC CUSTOM
vi CUSTOM
./config CUSTOM
cd /sys/CUSTOM
makeFrom the link:
> It's somewhat picky about the environment. So far, aap's PDP-11/20 emulator (https://github.com/aap/pdp11) is the only one capable of booting the kernel. SIMH and Ersatz-11 both hang before reaching the login prompt. This makes installation from the s1/s2 tapes difficult, as aap's emulator does not support the TC11. The intended installation process involves booting from s1 and restoring files from s2.
Apparently Yufeng got SIMH to run it: https://www.tuhs.org/pipermail/tuhs/2025-February/031427.htm...
good luck though. my emulator is not particularly user friendly, as in, it has no user interface. i recommend simh (although perhaps not for this thing in particular).
So what mechanism do you have set up to reply 4 minutes after being mentioned? :)
I've been messing around with RSX-11M myself! I find these early OSes quite fascinating. So far I've set up DECNet with another emulator running VMS, installed a TCP stack, and a bunch of compilers.
Works great on Apple Silicon
What’s the difference between an emulator and a simulator in this context?
There is LOADS of gray area, overlap, and room for one's own philosophical interpretation... But typically simulators attempt to reproduce the details of how a particular machine worked for academic or engineering purposes, while emulators are concerned mainly with only getting the desired output. (Everything else being an implementation detail.)
E.g. since the MAME project considers itself living documentation of arcade hardware, it would be more properly classified as a simulator. While the goal of most other video game emulators is just to play the games.
I don't want to offend you , but this has made me even wonder more what the difference is.
It just feels that one is emulator if its philosophy is "it just works" and simulator if "well sit down kids I am going to give you proper documentation and how it was built back in my days"
but I wonder what that means for programs themselves...
I wonder if simulator==emulator is more truer than what javascript true conditions allow.
Not the case at all. Tons of emulators are near 100% accurate.
Irrelevant to the concept being expressed, and does not invalidate.
The goals merely overlap, which is obvious. Equally obviously, if two goals are similar, then the implimentations of some way to attain those goals may equally have some overlap, maybe even a lot of overlap. And yet the goals are different, and it is useful to have words that express aspects of things that aren't apparent from merely the final object.
A decorative brick and a structural brick may both be the same physical brick, yet if the goals are different then any similarity in the implimentation is just a coincidense. It would not be true to say that the definition of a decorative brick includes the materials and manufacturing steps and final physical properties of a structural brick. The definition of a decorative brick is to create a certain appearance, by any means you want, and it just so happens that maybe the simplest way to make a wall that looks like a brick wall, is to build an actual brick wall.
If only they had tried to make it clear that there is overlap and the definitions are grey and fuzzy and open to personal philosophic interpretation and the one thing can often look and smell and taste almost the same as the other thing, if only they had said anything at all about that, it might have headed off such a pointless confusion...
Huh? I didn't mention anything about accuracy. And "accuracy" (an overloaded and ill-defined term on its own) doesn't have anything to do with the differences between simulators and emulators.
exactly. makes you wonder , is it all just philosophical.
Calling the same thing a different name.
In theory, an emulator is oriented around producing a result (this may mean making acceptable compromises), whereas a simulator is oriented around inspection of state (this usually means being exact).
In practice the terms are often conflated.
The difference is about as crystal clear as compiler/interpreter.
compiler creates a binary in elf format or other format which can be run given a shared object exists.
Intepreter either writes it in bytecode and then executes the bytecode line by line ?
Atleast that is what I believe the difference is , care to elaborate , is there some hidden joke of compiler vs intepreter that I don't know about ?
I assume GP meant that a lot of compilers also interpret and interpreters also compile.
For compilers, constant folding is a pretty obvious optimization. Instead of compiling constant expressions, like 1+2, to code that evaluates those expressions, the compiler can already evaluate it itself and just produce the final result, in this case 3.
Then, some language features require compilers to perform some interpretation, either explicitly like C++'s constexpr, or implicitly, like type checking.
Likewise, interpreters can do some compilation. You already mentioned bytecode. Producing the bytecode is a form of compilation. Incidentally, you can skip the bytecode and interpret a program by, for example, walking its abstract syntax tree.
Also, compilers don't necessarily create binaries that are immediately runnable. Java's compiler, for example, produces JVM bytecode, which requires a JVM to be run. And TypeScript's compiler outputs JavaScript.
Then what is the difference, I always thought of Java as closer to python in the sense that it's running the byte code. And python also has bytecode.
I don't know what the difference is , I know there can be intepreters of compilers but generally speaking it's hard to find compilers of intepreters
Eg C++ has compilers , intepreters both (cpi) , gcc
Js doesn't have compilers IIRC , it can have transpilers Js2c is good one but i am not sure if they are failsafe (70% ready) ,
I also have to thank you , this is a great comment
Programming languages mostly occupy a 4-dimensional space at runtime. These axes are actually a bit more complicated than just a line:
* The first axis is static vs dynamic types. Java is mostly statically-typed (though casting remains common and generics have some awkward spots); Python is entirely dynamically-typed at runtime (external static type-checkers do not affect this).
* The second axis is AOT vs JIT. Java has two phases - a trivial AOT bytecode compilation, then an incredibly advanced non-cached runtime native JIT (as opposed to the shitty tracing JIT that dynamically-typed languages have to settle for); Python traditionally has an automatically-cached barely-AOT bytecode compiler but nothing else (it has been making steps toward runtime JIT stuff, but poor decisions elsewhere limit the effectiveness).
* The third axis is indirect vs inlined objects. Java and Python both force all objects to be indirect, though they differ in terms of primitives. Java has been trying to add support for value types for decades, but the implementation is badly designed; this is one place where C# is a clear winner. Java can sometimes inline stack-local objects though.
* The fourth axis is deterministic memory management vs garbage collection. Java and Python both have GC, though in practice Python is semi-deterministic, and the language has a somewhat easier way to make it more deterministic (`with`, though it is subject to unfixable race conditions)
I have collected a bunch more information about language implementation theory: https://gist.github.com/o11c/6b08643335388bbab0228db763f9921...
The easy definition is that an interpreter takes somethings and runs/executes it.
A compiler takes the same thing, but produces an intermediate form (byte code, machine code, another languages sometimes called "transpilar"). That you can then pass through an interpreter of sorts.
There is no difference between Java and JVM, and Python and the Python Virtual Machine, or even a C compiler targeting x86 and a x86 CPU. One might call some byte code, and the other machine code .. they do the same thing.
While an interpreter can do optimizations, they do not produce "byte code" -- by that time they are compilers!
As for the comparison with the JVM .. compare to a compiler that produces x86 code, it cannot be run without an x86 machine. You need a machine to run something, be it virtual or not.
I would generalize it to a compiler produces some sort of artifact that is intended to later be used directly, while for an interpreter the whole mechanism(source to execution) is intended to be used directly.
The same tool can often be used to do both. trival example: a web browser. save your web page as a pdf? compiler. otherwise interpreter. but what if the code it is executing is not artisanal handcrafted js but the result of a typescript compiler?
An interpreter runs the code as it is being read in.
A compiler processes the code and provides an intermediate result which is then "interpreted" by the machine.
So to take the "writes it in byte code" -- that is a compiler. "executes the byte code" -- is the interpreter.
If byte code is "machine code" or not, is really secondary.
Adding some anecdata, I feel like emulator is mainly used in the context of gaming, in which case they actually care a great deal about accurate reproduction (see: assembly bugs in N64 emulators that had to be reproduced in order to build TAS). I haven't seen it used much for old architectures; instead I'd call those virtual machines.
definitely agree on simulator though!
I think it is more about design, emulation mimics what something does. A simulator replicates what something does.
It is a tiny distinction, but generally I'd say that a simulator tries to accurately replicate what happens on an electrical level as good one can do.
While an emulator just does things as a black box ... input produces the expected output using whatever.
You could compare it to that an accurate simulator of a 74181 tries to do it by using AND/OR/NOT/... logic, but an emulator does it using "normal code".
In HDL you have a similar situation between structural, behavioral design ... structural is generally based on much more lower level logic (eg., AND/NOR/.. gates ...), and behavioral on higher logic (addition, subtraction ...).
"100%" accuracy can be achieved with both methods.
Too easy! Going to build one with NAND gates.
Have fun with that
https://hackaday.com/2017/01/03/make-logic-gates-out-of-almo...