[tommyboy123x]

I have always had a dream... as far-fetched as it may seem... to create my own programming language. I've searched on google for some info on them and i feel like i have a grasp on how it works and whatnot, but i was wondering if its just an impossible dream, or if hours and hours of work could give me my own language..? Personally, i know c++, python, (html of course), php, pretty well and am learning perl.

any comments are welcome!

[office politics]

i've seen articals on creating compilers before. never read them tho. prolly a good place to start.

[tommyboy123x]

i have seen articles, but they explain HOW they work, not how to make them. if you have any links that'd be sweet

[office politics]

http://www.daniweb.com/techtalkforums/thread31222.html

this thread is a good read. there's a BNF tutorial in the last post that also seems like a good read.

[tommyboy123x]

i was brainstorming the other day of ways to make my language fast, and i came to think, what if i could eliminate the compiler, and simply have it programmed in binary/machine language..?

Is there anyway to do this?

also, thanks a ton for the link csamuels!!

[TheHeadFL]

Then you would just be writing assembly.

Which isn't neccesarily faster, if you don't know how to do all the optimizations that a good compiler can do.

[tommyboy123x]

well how exactly does the compiler send the data to the cpu? or how did they make the first language?

[TheHeadFL]

A compiler takes a high level language like C or C++ or whatever and breaks it down into assembly language instructions.

For instance

x = 2;
x++;
if (x < 5)
{
   x+=2;
}
else
{
   x-=2;
}
x = x * 2;

Would generate this assembly (approximately, MIPS assembly)

  ADDIU A0, R0, 2
  ADDIU A0, A0, 1  
  ADDIU A1, A0, 0
  SUBIU A1, A1, 5
  BGEZ A1, label1
  ADDIU A0, A0, 2
  J label2
label1:
  SUBIU A0, A0, 2
label2:
  MULIU A0, A0, 2
  SB A0, x

For reference, SB = Store Byte, ADDIU = Add Immediate Unsigned, BGEZ = Branch on Greater Than or Equal to Zero, J = Jump. Register R0 always contains zero.

Values are assigned to registers by way of adding the contents of R0 and that value, and storing the contents in the destination register.

Anyway, those instructions all contain a binary representation...

ADDIU might specify a 6-binary bit code, maybe 000100.

Lets say we have the instruction ADDIU A0, R0, 2

We build the machine code:

ADDIU = 000100
A0 = 00010
R0 = 00000
"2" = 0000000000000010

On a 32 bit machine, this instruction is represented as (actually its in reverse, but for illustration we won't reverse it):

00010000010000000000000000000010
ADDIU   A0   R0     Immediate

In hex:
10400002

This is the code that is sent to the CPU to be executed.

[tommyboy123x]

ok, i think i understand that... but i always thought binary numbers were 8 bits long

"2" = 0000000000000010

so how does the actual code reach the processor... is that the OS's job? if so how does it do it?

also, you mentioned 32 bit system... how would you change the program to run as 64. i've actually been wanting to try and switch a program i made from 32 to 64. i know its just the amount of bits sent to the processor at a time, but how do you control that (and number of threads, etc). As you can tell, im only a moderate programmer

sorry if i am overwhelming you or something... im just very curious .

i cannot even begin to express how greatful i am that you have been answering my questions in this thread and the os one... thank you!

[TheHeadFL]

Binary numbers can be any number of digits long.

And a 64 bit processor just has 64 bit long instructions. You would just use a compiler that generates the longer instruction formats to convert a program to 64 bit. (Unless you're using assembly code, which is 32/64 bit specific sometimes)

Generally this is broken down like:

6 bit instruction
8 bit register addresses (x 3)
34 bit immediate data

Or something similar to this.

Some instructions do not make use of all the bits and therefore those instructions are zero-filled in the ranges that specify certain options.

For instance, part of the 'opcode' (the 6 bit instruction) is telling the CPU what type of instruction it is. These are flag bits.

(I'm just making up the specifics here, but it would be similar to this)

For instance, bit 6 might specify 2 address, 1 immediate (off) or 3 address, register to register (on).

Or lets say bit 7 specifies direct addressing (on) or indirect addressing (off).

On some instructions, the format is

OPCODE Register, Register, Register

or

OPCODE Register, Register, Immediate

or

OPCODE Register, Address

or

OPCODE Address

etc.

Once the compiler generates this code, it is fed to the CPU by any number of ways.

The most basic way (which is what I think you're probably interested in) is the way that is going on below the level of the operating system, which happens when the computer first posts.

So how does this get to the CPU? Well, every processor is hard coded with the logic for a reset signal. When you first power on the computer, the RESET signal (line) is HIGH, which just means active, on, whatever. After some period of time (a few clock ticks later) it goes LO. During the time the RESET signal was high, the CPU instruction counter was reset to some default. (Lets say memory address 0x00000000 for simplicity sake... in reality on an x86 processor its like 0x7777FFFF or something, but the actual location is irrelevant)

The instruction cycle in a simple pipelined CPU is going to be something like:
FETCH --> DECODE --> EXECUTE --> MEMORY --> WRITEBACK

So, as soon as reset goes to low, and the pipe is empty, the CPU begins the FETCH cycle. It looks in the internal register, the "PC" or Program Counter register. This will contain that initial value. This tells the processor where the first instruction to execute will always reside. (Usually in the BIOS, actually)

For the purposes of simplicity, we will ignore caching and assume that all memory access happens in one clock tick. The reality of the situation is more complex, but doesn't change what I am about to explain.

The CPU requests that memory be read at the PC location. The instruction is read from memory and the CPU accepts it in on one of its buses. The instruction is then stored in a temporary register.

Next, the CPU shuffles the instruction (just a string of bits) to the DECODE unit. The decode unit breaks down the instruction and sets the appropriate internal flags for the CPU. Is the instruction a register register instruction, does it contain immediate data, is the addressing direct or indirect, and is the instruction a branch or not? Then the addresses of the registers, memory locations, or immediate data are extracted from the instruction. These addresses (or data) are then put onto the respective buses inside the CPU. Also, the CPU determines the actual opcode of the instruction and sets a bus that tells the CPU what operation it will be performing.

All this data is then passed to the EXECUTE unit. Any arithmetic operations (math) is performed here and the results stored in internal pipeline registers. The results of branch comparisons are evaluated (>, <, ==, etc) and those results stored. Memory addresses are computed (adding, subtracting offsets).

The results of this stage are then passed along to the MEMORY stage, where the CPU reads or writes any neccesary values from the data portion of memory. (Not instruction portion, which is usually stored separately)

The MEMORY stage results are passed to the WRITEBACK stage, where the results of the EXECUTE unit and the MEMORY unit are stored in the actual (L1 cache) general purpose registers of the CPU.

At this point, the program counter is incremented by 1 instruction. (4 bytes for a 32 bit, 8 for a 64 bit) If the instruction was a branch, the branch offset is also added (i.e. skip X instructions if something is true).

The process then repeats.

In this way the CPU takes that binary I just showed you and makes use of it.