phenofire

Hello. I'm having a hard time understanding the interaction between code, programming language, and the actual computer.
I've seen tutorials on the net about how to write your own programming language, for example. To do that, aren't they using a programming language? That totally doesn't make sense to me.
Then there's the matter of how the code actually interacts with the computer. Can someone out there take me step by step through how code works its way down to the actual hardware and then back onto the screen? And wouldn't this entire process have to go through the windows operating system? It's hard for me to explain what I'm asking, I just don't understand how code works at its most basic level.
And how come I never see a command like "draw" in most programming languages? If games are written with these languages how do they get all the flashy stuff onto the screen?
As you can see, I'm in a doozy. Any help appreciated.

Dizzutch

This is not really something easily explained in one post, I've taken about 3 classes on this subject.
basically this happens
your code is translated into a different code, called assembly language, in assembly language each line is one change little change in memory or disk. ex
in assembly would look something like so
this is then translated into binary code, (1's and 0') which is then read by the processor, and performs the operation requested.

what graphics is concerned, when the code is executed, the code is sent video card which handles the operation and draws to the screen.
This is a tiny little explaination of the process, but as I said, it's not simple, and just knowing how to check your email on windows, is not going to give you the tools to completely understand the process. There are a whole bunch of books on Computer Design out there that explain this in detail, they are usually about 1000 pages. I've read 3 of those as well and still don't know everything about it.

__________________
naked pictures of you | PFO F@H stats

coldDeath

I think i understand what you mean by the first question: If a programming language is written in another programming language, how was the first one made?
I don't know

But for the second question: Most languages don't have graphics built in, you need an extra module/header/package (or whatever).
Say you wanted to make a game in C++, you would use OpenGL or DirectX as graphics libraries.
And in a scripting language it is the same, Python uses PyGame.

__________________

Polyphemus_

@Dizzutch: what kind of assembly language is that?

Dizzutch

some very loose MIPS, it might run in SPIM, i havn't used assembly in 2 years, it's not really my thing..

__________________
naked pictures of you | PFO F@H stats

Arevos

You have to understand that programming languages are abstractions. They are tools to make it easier for us to tell computers what to do. Without programming languages, computers only understand machine code, which is long sequence of binary data that tells the computer how it should manipulate other long sequences of binary data.

This is rather difficult for humans to follow, and hence the need for programming languages. These go from very low level languages like assembly (which just directly maps machine code commands to easy-to-remember tokens) right up to high level languages like Lisp, Python, or Ruby. Generally speaking, the higher level the language is, the faster it is to design a program in, and the slower the program runs.


That's not a trivial task by any stretch of the imagination, and it's not really necessary to know. Do you need to be able to design a modern car engine to be able to drive a car?

Programming languages tend to be pretty bare in terms of functionality. They reserve all the flashy stuff for libraries. Libraries are collections of functions that are usually designed to do a specific job. For example, you might have a graphics library with a "drawLine" function. To use this function, you'd need to import the library first.

This ensures programming environments don't get bloated with unneeded functionality. For instance, If you wanted to create an email client, you wouldn't want all the overhead of a 3D engine, would you?

Arevos

It was hard-wired into the CPU.

phenofire

OK, I understand about graphics and programming languages now. Thanks everyone! But I still don't get how code interacts with hardware.
For instance, if you use a graphics library in a program, wouldn't the instructions contained in that library have to exist in some form on the hardware somewhere - how else could the computer interpret the code? Would a video card be able to interpret more instructions than integrated graphics, and if so wouldn't that mean some machine code wouldn't work on computers without one? And, how could all these video (or other) card companies maintain compatability?
Also, how does the computer know what sequence of 1s and 0s to turn into what output?

Polyphemus_

about the video cards... i'll tell you first how text mode works, because that's the only thing i know exactly atm When you boot the operating system and switch to protected mode, the video memory will be at 0xB8000. Every character on the screen will be 2 bytes. The first byte the actual character, the second byte the color. An example (dunno this is correct, but it is something like this):
For graphic stuff you can either use VESA, a standard or the special video software, which includes 2D and/or 3D accelaration. When you use VESA, you have a piece of memory where you can write your pixel data. That piece of memory contains only 1/5 of your screen (or something like that). Such a piece is called a bank. You can switch between the banks using the asm out instruction, IIRC.

about how the cpu executes the 1s and 0s? I have no idea

Arevos

Basically, the CPU sees a video card's input as a piece of memory. By placing bytes onto this area of 'memory', the CPU communicates with the video card.

Generally speaking, the operating system handles communication with the graphics card, and uses drivers to bridge the compatability gap. In Windows, the manufacturers of the graphics card usually supply the drivers that enable the operating system to talk to the graphics card.

There are standards and compatability layers (like drivers) that ensure all the parts of your computer can talk to one another. Although it's not a simple business; I'm sure most of us have had times in the past when our computers have failed to talk to a particular piece of hardware.