0 Replies Latest reply on May 19, 2008 11:11 AM by elgersmad

    I have an idea for a new Compiler

    elgersmad
      It uses Logical Gates and a Graphic Programming Interface.

      Hello All,

      I'm fairly new to this forum. But, back in college I took Electronics, not computer science. I did study Digital Electronics, and Machine Language Programming. Back in 1998 when I first started thinking about this, I started reading into it. Then I looked at the Processors, they were not fully capable of it in the fastest possible execution style. But, then I did figure out and the AMD 64 bit series of processors are fully capable of a Reduced Instruction Set Compiler and a Graphic Progamming Language over a primarily written programming language.

      Right now, I'm aware of several commands that make it possible to represent logic gates. Yea, I do mean AND, OR, XOR, NOT, NAND, and NOR. A 1 or a 0 always comes from a Decoder Block. A Decoder block in Machine Language is the output of the ALU on a => or < Function. It allows you to read a list of conditions for a list of variables, and then send them to the ALU and preform the logical function of a gate for large groups of gates or large groups of inputs up to 64 from looking at registers in fewer steps than a list of Feed Through or Nested IF Statements based upon the machine equivalent. Each Type of Gate based upon the number Inputs or the number outputs it's shared with, or how ever many can be checked in a quick list are put together based upon 2 situations. Which gates are First, and how First is defined. From the top of a menu from File to Help would check all states on list to load a bitwise array of 1s and 0s based upon the result of the ALU ANDing. This is just example situation.

      The pointer has to be within the range of the Height and Width of the Button, that would represent one set of conditions for the File Button.

      Mouse X,Y
      Button Top Left X,Y
      Button Bottom Right X,Y
      LeftButtonClicked??

      MX > Btl_X

      Then ALU will put out a 1 if it's MX or the Mouse Pointer is Greater than the Top Left Corner of the Button. The next line looks like this.

      MY > Btl_Y

      Don't assume anything would be written this way. On the sceen you see a bar menu graphic with the buttons on the top row, and you've connected a black line to the top right corner of the Button. The Black line connected to an AND gate's input has produced these to variables because, you connected another input to a graphic of a mouse. This works more like a schematic capture for a electronics simulator and in place of part functions and values, you have a Digital Simulator look and feel to the IDE.

      The Next wire is connected to the Bottom Right Corner and produces,

      MX < Btr_X

      MY < Btr_Y

      and the last logical wire to the AND Gate produces this

      LeftButtonClicked

      Right there you have a 5 input AND Gate. Reading through the List Since, 1+1+1+1+1 = 5 when you read through the list, 5 = 1. Alternately, you can use a Bit mask of 11111, and when it's ANDed by the ALU via a bitwise operation, the result is 11111.

      Here's what happens, you can check up to 64 conditions if you stack them up using the ALU by ANDing them against a Bitmask of All 1s. Then it's only a matter of where I read the output of the ALU.

      If you have Focus and 5 menu buttons, you can check all of the Buttons at once because it only requires 25 bits. In the code once a 1 has made it through the mask initiates a jump instruction to another jump instruction, could be short could be long, or it could be a C convention variable/string Handle, Command Line, Dll handle doesn't matter.

      If you have 64 2 input you can check up to 128 inputs.

      The whole key to this operating properly is defining a loop based upon jump instructions. Automatically choosing the shortest code. All of the buttons you see on the menu when there is focus are checked at the same time.

      The software should evaluate the macros to define which method works faster.

      Example 2

      N = user input Bin
      N>0 Bitwise operation = 10
      N=5 Bitwise operation = 01

      result in register A = 11

      N=N*2

      N>5 Bitwise operation = 10
      N=10 Bitwise operation = 01

      result in register B = 11

      Result from A and B being ANDed by the ALU = 11

      N>0 AND N>5 produce 1s that are placed into a register bitwise first gate first input, second gate second input. Most high density checking would most likely be used in authoring games. But, the speed of execution is very important. If you can shoot through the if statements having them strictly between the ALU and the compiler keeping track of where short jumps take place in the cach between pieces of code during compile, and Gate Location and outputs are linked to Jump instructions short or long pending on the data they are linked to everything should work fine.

      The real advantage is in being able to use DeMorgan's Theroems to reduce the instructions of any program that works to it's absolute minimum and by simply counting bytes check for the shortest code and quickest executing. I don't see any practical way to bunch so many if statements together based upon any form of list of equations. Most are feedthrough, and where they should be selected based upon variables of type and or string if that or pointer.

      After you have all of your logical gates the only real concern is math and the ability of the processor to produce proper results. If and the IF is not usually a part of the order of operations nor does it deal with using the processor in the same manner as a typical program. The ability to attach gates to arrays is critical to game design.

      There a few other things about compiler design that I've thought of. If you can decompile any program, you can recognize which compiler it came from. I can't think of way to figure out what program is doing unless you use boolean algebra and gates. But, you could detect any virus because, they often include crossing and combining code. The list of macros used by a given program language is often much shorter than the list of viruses out there. This would speed up the scanning process only if the software could figure out what a virus is. Not only that, you can store your program as a boolean equation as a means of making checking for viruses easier by maintain a different file format. Like that equation at the end, or in the comment fields. Programs require plenty of user input. Nothing on the screen for keylogger, and spyware reports to a server somewhere without a functioning application. So, you could trace events like digital signals to find this junk.