NI Labs
Feedback on NI Labs
Yes, I am familar with memory, caches, data flow etc. I am attempting to replace the if statement with a different, better and faster implimentation of logic. These symbols would be added to the graphic language.
Now, this binary adder would represent a single section of code inside of a loop, in the program language any highlighted box filled with gates is a loop. Connect the output of that given loop to any other loop or output.
Carry in, A and B can be sent through the ALU for NOT at the same time. Checking the conditions would consist of moving information through memory based upon where it stored. Some part of that data could come from a USB port, or somewhere in the Data Cach on the CPU. So, first you have a list of commands that provide you with the data you need for 1s and 0s on those inputs. Then, the next thing that would happen since the values are set, the ALU has a logical AND Function, I can check AND gates 0 through 3 by providing the ALU with two sets of 1s and 0s, and AND all four gates to find the condition or logical state on all four gates. The reason why is ANDing via the ALU is a bitwise operation. That means that in the DATA cach is two binary Dwords for a 64 bit system and a single Dword for a 32. The next row of AND gates down could all then be checked at the same time as well. Eliminate nested if statements, and the result is that you can do this. As far as writing applications is concerned it's a better way of handling graphics. But, an image isn't handled as an image, but a set that is represented by a state of 1 or 0. The more times I can utilize the ALU over routing information around and around through the CPU all flowing at 32 or 64 bits wide, the bitwise operation would take place in one of the registers. When I am checking four gates at one time I use two registers to produce bitwise operations and run through a list of checks to find states of Carry in, A and B. Where it speeds up is where the list is just 1s and 0s and the state is placed into the Register. The final move is to send both to the ALU and find the combined result. No real application is going to use a binary adder. It's just that the logic of gates can be applied to machine language in a way that the if statement doesn't operate like an 8 foot pipe and just a water line to a faucet when all you need a faucet not a fire hydrant. It makes room to do more at once than the flow of information in a language like C or Visual Basic would really allow. They are function modules. It also helps to eliminate long names in variables, strings, and the only time anything like that would be used in a program would be for chaining a program, or a DLL, or some other program that was designed to grant another program access like a driver. The long names make it easy for programmers to access and control the program from the outside. Inputs are basically locations in memory and if there were nothing on all three inputs, the result is 0, faster excution would be to jump all of the other instructions or just continue to check the inputs in the first loop. When there is something on the input side, then it will work to the output. Although, you would have highlighted all of those gates. The binary adder is a bad example except for program flow because, you could just send two numbers to the ALU and get it done in one clock cycle. But, the inputs and outputs could be from any set it is connected like a button/set of pixels, greater than or less than function reading a port. Equal to, Less than and Greater than are all decoders and there is no reason to use this kind of logic in programming to design that kind of decoder. But, if a number has to be greater than and less than two numbers for x on the screen, greater than and less than two numbers for y on the screen, you have four potential 1s that all need to be present and true before the mouse button is clicked which would be the fifth condition.
In a series of if statements the program flow is much different, and a program can be written to where the CPU has to read through everything without an escape or reason. So, that binary adder really represents nested if statements.
So your source code can then be reduced once you've managed to get what you want to happen to happen, software can reduce the number of instructions to the minimum number of instructions.
http://en.wikipedia.org/wiki/Circuit_minimization
It is just that the ALU does not support all of the basic logic gate functions, XOR, NOT, AND, but there is a total of 7 that would need to be implimented. It's only because the ALU only requires one clock cycle to preform the task up to 32 or 64 bits. Then there is the proposition of how many inputs/registers are available to 1 clock pulse for the ALU. The ability to ADD 10 seperate numbers at one time from ten seperate registers. That may not be possible or simple enough fit, but the gate logic sure is for two inputs. All it would do is speed up the process. I am certain that it will take several macros/machine language instruction sets to impliment this in how much differently because, you would always look at eliminating the maximum number of clock pulses required for a function written. So, for awhile you would be comparing to C to establish where the turning point is and the instructions really run faster. In any case, when you write the program, the graphic style wouldn't change because, you can apply those rules of reduction.
Ton
LabVIEW user groep 
Message Edited by Ravens Fan on 06-29-2008 10:41 PM
).
