the last few days I was interested in how a computer works and I want to understand what the PC with CPU, RAM, GPU etc. does (on a low-level) with 0 and 1.
So 8 Bits equals 1 Byte, (e.g. 10100110). My question is: Can a computer "skip" Bits, meaning, jump to the next Byte, based on the first (signed) Bit? I mean, usually a PC processes all Bits of a Byte. If a PC could skip a Byte based on its signed Bit, it would not have to read and process the next seven Bits, and would be in theory faster than if it would process every Bit, expecially with enormous data amounts. I hope you can understand my thought.
For example, if the first Bit is a 0, then process this Byte, if it is a 1, skip this Byte. Or a more useful example, when I have a table with two columns, I could mark the left column with 0s and the right with 1s, and if the left column is not equal to what I search, I skip the remaining 0s, the following 1s and read the next 0s then (the next row of my table).
Is this somehow possible, with a normal PC or a custom self-build? Would that make my processes faster?
Related
I am bit confused how start and stop bit are differentiated from the actual data bits. For example say "data" whose binary is 01100100 01100001 01110100 01100001 is being set from System A to System B as a single packet (because it's less than 64 Kibibytes) bit by bit. Please let me know how start bit and stop bits are added to these data bits. There were two related thread on Stacloverflow with only one answer this was not accepted but is very confusing. Can someone explain it in simple terms please. Thank you
When you want to send data over serial line, you need to synchronize transmitter and receiver. The start bit simply marks the beginning of the data chunk (typically one byte with or without parity bit), and the stop bit marks the end of data chunk.
In the beginning, there’s no data being transmitted - let´s say there is ‘0’ on the line for some time. The receiver is waiting for the start bit (both start and stop bits are always ‘1’). When the start bit arrives, it starts an internal timer and on every tick it reads the value from the line, until all data and parity bits are read. Then it waits for the stop bit and then it begins to start waiting for a new start bit.
Without the start bit, the receiver would not now when to start reading data bits. Imagine sending zero byte without parity: The line would just stay in 0 state all the time.
The stop bit is not necessary, it’s there just for enhancing the reliability (both receiver and transmitter must use the same frequency).
So, the start and stop bits don’t need to be distinguished from data bits. Quite the oposite: They allow the receiver to properly identify data bits.
When sending your data, you would take them byte by byte and for each of them you would send the start bit (‘1’) first, then individual bits, then maybe parity bit and then a ‘1’ - the stop bit, everything at a given frequency. Then you would wait at least for one timer tick.
Usually you don’t need to do all of this, because there are specialized chips for this on the board. You just provide your data using a buffer and wait until they’re sent, or you wait for data being received.
I'm not even sure if this is possible but I think it's worth asking anyway.
Say we have 100 devices in a network. Each device has a unique ID.
I want to tell a group of these devices to do something by broadcasting only one packet (A packet that all the devices receive).
For example, if I wanted to tell devices 2,5,75,116 and 530 to do something, I have to broadcast this : 2-5-75-116-530
But this packet can get pretty long if I wanted (for example) 95 of the devices to do something!!!
So I need a method to reduce the length of this packet.
After thinking for a while, I came up with an idea:
what if I used only prime numbers as device IDs? Then I could send the product of device IDs of the group I need, as the packet and every device will check if the remainder of the received number and its device ID is 0.
For example if I wanted devices 2,3,5 and 7 to do something, I would broadcast 2*3*5*7 = 210 and then each device will calculate "210 mod self ID" and only devices with IDs 2,3,5 and 7 will get 0 so they know that they should do something.
But this method is not efficient because the 100th prime numbers is 541 and the broadcasted number may get really big and the "mod" calculation may get really hard.(the devices have 8bit processors).
So I just need a method for the devices to determine if they should do something or ignore the received packet. And I need the packet to be as short as possible.
I tried my best to explain the question, If its still vague, please tell me to explain more.
You can just use a bit string in which every bit represents a device. Then, you just need a bitwise AND to tell if a given machine should react.
You'd need one bit per device, which would be, for example, 32 bytes for 256 devices. Admittedly, that's a little wasteful if you only need one machine to react, but it's pretty compact if you need, say, 95 devices to respond.
You mentioned that you need the device id to be <= 4 bytes, but that's no problem: 4 bytes = 32 bits = enough space to store 2^32 device ids. For example, the device id for the 101st machine (if you start at 0) could just be 100 (0b01100100) = 1 byte. You would just need to use that to figure out which byte of the packet to use (ceil(100 / 8) = the 13th) and bitwise AND that byte against 100 % 8 = 4 = 0b00000100.
As cobarzan said, you also can use a hybrid scheme allowing for individual addressing. In that scenario, you could use the first bit as a signal to indicate multiple- or single-machine addressing. As cobarzan said, that requires more processing, and it means the first byte can only store 7 machine signals, rather than 8.
Like Ed Cottrell suggested, a bit string would do the job. If the machines are labeled {1,..,n}, there are 2n-1 possible subsets (assuming you do not send requests with no intended target). So you need a data structure able to hold every possible signature of such a subset, whatever you decide the signature to be. And n bits (one for each machine) is the best one can do regarding the size of such a data structure. The evaluation performed on the machines takes constant time (on machine with label l just look at the lth bit).
But one could go for some hybrid scheme. Say you have a task for one device only, then it would be a pity to send n bits (all 0s, except one). So you can take one additional bit T which indicates the type of packet. The value of T is set to 0 if you are sending a bit string of length n as described above or set to 1 if you are using a more appropriate scheme (i.e. less bits). In the case of just one machine that needs to perform the task, you could send directly the label of the machine (which is O(log n) bits long). This approach reduces the size of the packet if you have less than O(n/log n) machines you need to perform the task. Evaluation on the machines is more expensive though.
I learned that a register field to specify one out of 64 registers takes 6 bits.
since 64 = 26
but don't we have to consider the right most bit ?, which is 20, in which case we require 7 bits to specify one out of 64 registers..
If there is only one possible value, you need no bits at all. If you have one bit, it has two possible values.
So if there was only one register, no bits would be needed at all to select it. If there were two registers, you'd need one bit -- a zero in that bit could select one register, a one the other.
Continuing, if you have two bits, they have four possible values. If you have three bits, they have eight possible values. Going up, six bits has sixty-four possible values, so that's sufficient to chose one of sixty-four registers.
I'm confused when it comes to encoding the address for a J-format instruction.
From Class Notes:
Assume L1 is at the address 4194340 in decimal, which is 400024 in hexadecimal. We fill the target field as an address in instructions (0x100009) rather than bytes (0x400024).
Can someone please explain to me why this is?
The j instruction jumps to the passed target.
However, because the instruction set is limited to 32 bits, and 6 are used for the op-code, only 26 may be used for the jump target.
This means that the distance a j instruction can travel is limited as it works by appending its target to some number of the most significant bits of the current IPC.
The MIPS instruction set could have been defined by saying that when a j instruction is encountered you add the first 6 bits of the IPC to the 26 bit target of the j instruction, but instead it was noted that instructions that a program can jump are always "word-aligned". This means that these address are always a multiple of 4 and therefore the last 2 bits of the address are always 0.
This allows us to not encode the last 2 bits in our jump target and instead encode bits 3-28. This means that to get the target of a j instruction you take the first 4 bits of the PC, add the jump target, and then add two zeros.
Hopefully with that explanation out of the way it makes sense why the target 0x400024 is encoded in the j instruction by the bits 0x100009 i.e. 0x400024 >> 2. Because the last two bits are not needed.
To specify exactly what I mean with a constant space generator for the digits of pi, consider the following process:
I hook up a microprocessor with n bytes of RAM (for some constant n) and a printer. I start the process. From now on every x cycles one digit in base b of pi will be sent to the printer, until the end of time.
Does such an algorithm exist?
The answer is no.
Without infinite space, any program must eventually either terminate or start cycling through the same states. Think of "state" as the value of all the memory bytes - including the instruction pointer and everything else - written as a single huge number). A computer is basically a big DFA. If you have 256 bits of state, your program can perform at most 2^256 steps before it starts cycling.
If you are cycling, you are not calculating PI, because it is transcendental.