Understanding High Level Languages at a Fundamental Level

[crownedbishop]

I'm looking for resources that discuss how a high level language works from a fundamental level. I'm not looking for something that just says if you put this in your program, this is what will happen. I looked at your programming resources page, and that is all it gives lend to. I'm looking for a text or resource which starts and the particle level (i.e. the movement of electrons), and describes a high level language in terms of transistors and other components that are fundamentally explained in terms of physical phenomena. I couldn't find any text that goes over this. Anything I find has a black box approach on how the program actually works, and doesn't go into any physical phenomena. I would greatly appreciate if you know of any resources that go from physical phenomena and rigorously take that all the way up to some high level language.

 

[phinds]

I think what you seem to be looking for is way too broad to be well covered in a single resource. To really get the full picture, you'll want a course on solid state electronics, a course on computer architecture, a course on programming fundamentals and then a course on compilers.

Good luck.

 

[maajdl]

This could on point of view on your question:

http://rockingme.files.wordpress.com/2012/01/semiconductor-physics-and-devices-donald-neamen.pdf

Computers are made of nano-scale semiconductor devices.
Of course, this reference doesn't tell you anything about computers.
A computer is a system made by assembling huge numbers of semiconductor devices.
Therefore, when you want to analyse the functioning of a computer it is more the way it is designed (assembled) that matters than the detailed functioning of each gates.

 

[berkeman]

I think what you seem to be looking for is way too broad to be well covered in a single resource. To really get the full picture, you'll want a course on solid state electronics, a course on computer architecture, a course on programming fundamentals and then a course on compilers.

+1.0

 

[AlephZero]

The main point of any high level programming language is to isolate the program logic from the details of the hardware it runs on. Even when you have learned about all the links in the chain that phinds mentioned, you need to realize that an infinite number of different chains are possible.

 

[.Scott]

I'm looking for resources that discuss how a high level language works from a fundamental level. I'm not looking for something that just says if you put this in your program, this is what will happen. I looked at your programming resources page, and that is all it gives lend to. I'm looking for a text or resource which starts and the particle level (i.e. the movement of electrons), and describes a high level language in terms of transistors and other components that are fundamentally explained in terms of physical phenomena. I couldn't find any text that goes over this. Anything I find has a black box approach on how the program actually works, and doesn't go into any physical phenomena. I would greatly appreciate if you know of any resources that go from physical phenomena and rigorously take that all the way up to some high level language.

OK. There's actually a few technology paths from electron to "class". Here's a list of basics for one path:

Complimentary Metal Oxide Semiconductor (CMOS): This is one integrated circuit (IC) technology.

Field Effect Transistors (FETs): If you want to know what the electrons are doing, you need to study these things.

Basic Logic Gates: Using a high or low voltage level to encode "true" (or 1) and "false" (0) FET circuits can be designed for simple functions such as "NOT", "NOR", "NAND", "OR", "AND", and "XOR" (Exclusive Or).

Quartz Oscillator: Quartz is a piezoelectric material. A small carefully cut quartz crystal can be made to physically and electrically vibrate. The output can the be amplified and clipped to for a square wave of very consistent frequency. Of course, this can be used to establish a timebase (time of day) for the computer, but more basically, it can pace and synchronize logic. In essence, everything is done in "steps" as the signal from the quartz clocks some of the larger logic gates...

More logic gates: Those basic logic gates can be used to built larger gates such as set/reset
flip-flops (to store a single bit), toggle flip-flops (counting), binary adders (bit plus bit plus carry yields units and carry).

Major circuits: When the clock pulse is combined with these larger gates, major function blocks can be designed. Single bit gates are arrayed in sets of 16, 32, or more so that multibit word values can be handled throughout the circuit. For example, Arithmetic Logic Units (ALU) combine Add, Complement, Multiply, and sometime Divide circuits to allow words to be arithmetically combined based on other "command" bits. A more sophisticated circuit is a floating point processor that can operate on larger word values (32, 64, or more bits) that encode an exponent and mantissa.

More technology: Many of these words will be coming from or going to main memory, USB flash drives, etc. Each of these devices involves technologies that are subjects to themselves.

THE Central Processing Unit (CPU): Major circuits (ALUs, FPPs, Memory Caching, etc) are combined in the design of a complete CPU, the "thinking" part of the computer.

The instruction set, machine language: The CPU has several important registers. First among them is the "Program Counter". This is a word (array of bits, held in an array of flip flops) that can be used to address main memory to fetch an instruction. The instruction is one or more words that control the operation of the CPU. For example, CPU gates may respond to a particular bit code by using the next memory word (from the instruction pointer) as a memory address and cause the contents of that memory location to be copied to an accumulator (another CPU register) - a "Load" operation. Another might cause that accumulator content to be copied to the memory location - a "Store" operation. That instruction pointer is normally incremented after every use - so it's always pointing to the next memory location - the next instruction. But there will be other instruction codes for comparing, and either conditionally or unconditionally loading a new value into the instruction register - a "Jump" operation.

Memory mapped I/O: As I said earlier, there are many paths between the electron and the "class" syntax. And there are several ways of handling how the CPU will control external devices. A common way is with memory mapped I/O. Those Load and Store operations can act on any memory location - or even on locations that are beyond the range of the actual main memory. Other device controllers can be placed on the memory address and data bus a designed to respond to certain addresses as though they were memory locations. In this way, programs can pump data out to devices causing them to operate under the control if the CPU.

Macro Assembler: There was a time when computers were commonly programmed in binary machine language. But if your sitting at a key punch machine, isn't it easier to type "STORE" than to remember the binary code for a Store operation. If no one has ever written a macro assembler, what you do is write a macro assembler in machine language. So you code the instruction for reading a punch card into an array of memory locations, check a particular column for a recognized opcode (STORE, LOAD, JMP, CMP, JNE (Jump is not equal), ADD, etc), build up machine instructions to another location in memory, check other columns on the card for other symbols, build up tables of symbols in another memory area, etc, etc, and then loop back to the top to read another card. And the first program you will write in your new macro assembler is the macro assembler. That way you can improve it without having to deal with those obscure instruction codes. But if someone already wrote a macroassembler - but not for you CPU, then you can code the macro assembler for your computer using their computer. That will keep you away from machine language all together.

Link editor: The next program you might want to write is a link editor. To do this you create a more sophisticated version of the macroassembler that creates linkable modules - machine code that can be relocated to any location in memory - with symbolic references to other linkable modules. The link editor then takes these linkable modules and combines them to form a since executable machine language file.

Libraries: Once you have your macro assembler, your next step will be to create software libraries. For example, the instructions for reading from that card reader may be fairly involved. So write that program once in the form of a subroutine and it will be available everytime you need it within your macroassembler or any other program. You can create whole libraries of IO routines, math routines, character string manipulation routines, etc. Keep these in libraries and the change your link editor so that it recognizes libraries and only copies the modules it needs into the final executable.

Operating System: Some of those libraries are awfully handy. In fact, as disk drives increase in capacity, you might decide that you should keep all your executables and other data files on disk. So those library routine that access the disk and deal with the disk directory structure should really be in memory all of the time. Also, you decide to enhance your CPU by having it support "interrupts", signals from external devices that indicate that it's time to "service" that device. In this case "service" simply means to operate it with addition Load and Store operations. Those interrupt routines also need to be in main memory all the time. And your operating system is born.

Compiler: Once again, we will assume that you don't already have a compiler on another type of CPU available to you. So you will need to use your macro assembler to write your compiler. The only conceptual differences between the compiler and the macroassembler are: 1) each command may code to several machine language instructions, and 2) the commands are generic to any CPU. But the effect is the same. The compiler reads in lines and generated relocatable object modules that can be linked with your link editor.

 

[D H]

I'm looking for resources that discuss how a high level language works from a fundamental level. I'm not looking for something that just says if you put this in your program, this is what will happen. I looked at your programming resources page, and that is all it gives lend to. I'm looking for a text or resource which starts and the particle level (i.e. the movement of electrons), and describes a high level language in terms of transistors and other components that are fundamentally explained in terms of physical phenomena.

What you are looking for goes very much against the grain of a high level language. The very purpose of a high order language is to abstract away those low level machine constructs. Most high order languages have a concept of an abstract machine on which the language runs, abstractly. It shouldn't matter one bit if the bits are falling dominos or electronic switches. More importantly, learning about those low level constructs gets in the way of learning those high level constructs, at least at first.

That said, "all non-trivial abstractions, to some degree, are leaky" (Joel Spolsky). Eventually a good programmer does need to learn about those lower level concepts. An efficient matrix multiplication function needs to be structured just right to take advantage of how cache memory works. That memory is paged and cached in modern computers is a leaky abstraction that strongly impacts the behavior of high order languages. That's but one of many examples of abstractions leaking up from the machine level to much higher levels of abstraction.

 

[crownedbishop]

Thank you guys.
@DH Wouldn't you need to understand all these low level machine constructs if you were to make a high level language. It just seems that abstracting away for lower level concepts will cause your computer to not run as efficiently as if you ran everything on lower level concepts.
@AlephZero If there is an infinite amount of different chains possible to go from fundamental phenomena to some high level language, then wouldn't this be all the more reason to understand everything that happens. Wouldn't it be wise to look at other possible chains and compare each efficiency.
@.Scott Thanks a bunch for the path. I think that answered my question.

 

[FactChecker]

Thank you guys.
@DH Wouldn't you need to understand all these low level machine constructs if you were to make a high level language.

High level languages run on many computers with different hardware architectures. The place to worry about efficiency is at lower levels (assembly language) where the language is hardware specific.

It just seems that abstracting away for lower level concepts will cause your computer to not run as efficiently as if you ran everything on lower level concepts.

The higher level languages concentrate on efficiency of programming. The current challenge is to allow error-free programs to be written. Testing, debugging, and security is the bottleneck.

 

[Nick O]

High level languages run on many computers with different hardware architectures. The place to worry about efficiency is at lower levels (assembly language) where the language is hardware specific.

This. The physics of computation isn't important to a language designer. Architecture is important to compiler writers, but compilers will be different for every system. Even then, there is a lower level (microarchitecture) that varies within the confines of a well-defined architecture. This is only a concern for highly specialized applications, I would think.

 

[D H]

Thank you guys.
@DH Wouldn't you need to understand all these low level machine constructs if you were to make a high level language. It just seems that abstracting away for lower level concepts will cause your computer to not run as efficiently as if you ran everything on lower level concepts.

So?

It's not at all uncommon for a scientific program to spend almost all of the CPU time in 0.1% of the code. That tiny 0.1% of the code, yes, you *might* want to pay special attention to it. The remaining 99.9% of the code? You just don't care. That the code is *right* is much, much more important than efficiency. Getting things right and keeping costs down are paramount. Squeezing every last bit of performance? 99.9% of the time, it's not important at all. It wasn't important back in the 1970s when Donald Knuth wrote

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.​

That was 40 years ago. Worrying about efficiency is even more counterproductive nowadays than it was then. It's time to worry about efficiency when profiling identifies your bottlenecks. Until then, worrying about performance is a waste of programmer time and risks that the program isn't correct.

 

[nsaspook]

Anything I find has a black box approach on how the program actually works, and doesn't go into any physical phenomena. I would greatly appreciate if you know of any resources that go from physical phenomena and rigorously take that all the way up to some high level language.

Most of what you want is in the embedded programming area that usually involves direct hardware/real-time programming. It's targeted at programmers that use machines at a lower level than most applications coders but even there the use of higher level languages like C is common and usually requires a hardware background in circuit/logic design with software expertise to handle data structures efficiently. The design and use of efficient and easily understandable data structures is where high level languages shine.
http://www.embedded.com/

 

[Nick O]

If you don't mind taking very broad steps, I think I can break it into five bite-size (relatively speaking) units. If you want more rigor, you're asking for a computer engineering curriculum.

1. Basic chemistry, college freshman level

2. Semiconductor physics

3. Digital Logic

4. Computer architecture

5. Compilers

I think learning those five units will allow you to connect the dots and get a rough understanding of how a high level language works. But, it should be noted that each of these can be the subject of several university courses.

 

[neomahakala108]

High Level Programming Langauge wording makes one think about Programming Languages that require Abstract Thinking, on High Level of Abstraction.

Not in terms of Assembler Instructions or Electronic Circuits, but with more or less High-Level Syntax.

Of course what is High & what is Low is relative.