A student writes, and I reluctantly respond to all of you.  Reluctantly,
because I know you have a problem set due and a possible PA1 re-grade to
work on, and this is outside the scope of EE 306.  However, since I also
know that many of you are curious about some of this, I will respond.

Please put this email message in perspective.  Only to be looked at AFTER
you have completed all your responsibilities. 

        Dear Dr. Patt,

        I was sitting in class today thinking about the inner workings 
        of computer microarchitecture, (I mean, what else could someone 
        be doing?!) 


        and I came up with a few questions. I tend to come up with 
        random questions, and for that I am sorry. So anyways on a 
        more serious note...

        1.) I was looking at the LC-3 microarchitecture in Appendix C, and
        remembered you talking about in class that there was, in the LC-3, 
        a 4 to 16 decoder used in the decode phase to decode the 16 opcodes 
        that are possible. In my laptop, is there situated somewhere an n 
        to 2^n decoder used to decode all the opcodes of the x86? Is it 
        really that "simple"? Or am I missing something?

Like most of microarchitecture implementations, the answer is: yes and no.
Some ISAs are more complicated than others.  For the simple ones, the simple
decoder can be enough.  For more complicated ones (the one in your PC that
runs Windows, for example), sometimes the Decode phase takes multiple
clock cycles, wherein the simple decoder is the first step in the process, and
is used to partition the instructions into subsets, so that individual
differences between instructions in the same subset and other subtleties 
are handled in subsequent clock cycles.  If this sort of thing captures 
your interest so much that you can not pay attention in class, I have some 
good news for you: EE 360N, and when you become a graduate student, EE 382N. 

        2.) I know that we write in assembler language for the LC-3. And 
        its ISA defines the opcodes that the assembler translates to 
        binary. Does the x86 work the same way? 


        Does it serve as the assembler after an already 
        compiled high level language? 

Yes, although in the old days, high level languages were usually translated
directly to the 0s and 1s without first going through the assembly language
form.  Many high level languages today do in fact compile to an assembly
language which is then further translated by an assembler, much like what
we did in class last week.

        So, does 
        a java compiler compile my program to the x86 assembly language, 
        which then assembles it to the corresponding binary code? 

That is certainly one of the ways we get Java programs to run on x86
processors.  There is also another way, using what we call an intermediate 
form (the Java Byte Codes).  That is, we can also compile Java programs into
Java Byte Codes.  If one goes that route, one must either now translate from 
Java Byte Codes to x86 code, or build a microarchitecture that implements the 
Java Byte Codes as its ISA.

        If this 
        is true, could I write a java compiler (with limitations due to 
        only 16 LC-3 opcodes) that compiles my java file to the
        LC-3 assembly language, which I could then assemble and load into the
        LC-3? (I once again am forced to worry about a run-on.)

You ask, "Could I?"  If you know how to write compilers, sure.  If the
question is whether it is possible for someone to write a java compiler
that compiles Java to LC-3, the answer is: Absolutely!

        Muchas Gracias por su tiempo!
        <<name withheld to protect the student who is not paying attention 
        in somebody's class>>

Mon plaisir.
Yale Patt