I want to ask why ImageBase offset in one PE header is equal to 32h and other 35h
IMAGE:calc.exe offset 32h
IMAGE:ser2.exe offset 35h
I think it's because these were made by different toolchain. The first one is extremely likely cl.exe+link.exe and the other one may have been made by gcc+ld.
Related
I am just starting studying Assembly (x86, NASM) in university and I am really confused about how it works. Out of the many questions I have about it, this keeps bugging me.
When do I need to speficify the size of the operand? Is there a rule? For example:
segment data use32 class=data
a db 10
b dw 40
segment code use32 class=code
start:
mov AX, [b]
div BYTE [a]
Here we specified the size of the operand in the div opcode as BYTE. If I delete that BYTE part, I get an error, so we need to specify it.
segment data use32 class=data
a db 10
b dw 40
segment code use32 class=code
start:
mov AH, 2
mul AH
Here, we didn't need to specify the size of the operand 2. It just works.
So when do I have to specify the size? Is it as simple as: when I have a variable declared in memory, specify its size? Considering the examples given above, I am inclined to think so, but through my short experience with Assembly I found that it tends to defy my logic as to how things should work.
Also, after illuminating me about when we need to specify the size, can you please also tell me WHY we need to do this? When we need to do it, why do we need to do it? I mean, we already declared the variable, so the type of the variable should be visible to the program, shouldn't it? Why do we need to specify the size, else we get an error?
You don't need to specify an operand size if it can be inferred from something else you did specify. For example, mov only works on two operands of the same size, and AX is a word-sized register, so in mov AX, [b], it can infer that [b] must be word-sized. But you only specify one operand to div, so you have to tell it what size [a] is since it doesn't have any information to infer it from.
Let's say we have two fixed sized binary numbers (8-bit), e.g.
00000101 (5) and 00100000 (32)
The task is to add them in offset binary (excess of 128). Are there any specific rules concerning how to go about this?
Would I for instance first convert both the numbers into offset binary notation, then add them and afterwards subtract the offset (because I added it twice)? But if so, what about overflow, given that the imaginary registers are only 8 bit wide?
Or would I first subtract the excess and then add the second number? Are there any conventional rules when it comes to offset binary arithmetic?
I'm preparing for an exam in computer architecture and computer data arithmetic. This has been a task on an exercise sheet in a previous term. I'v already searched the net extensively for answers but can't seem to find a solid one.
I do not know what the "conventional rules" are for this operation, but I can tell you how I did this operation back when I did machine code.
This method works well when the offset is half the first number that overflows the register. That is the case for you, since the offset is 128 and the 8-bit register overflows on 256. This works especially well when the two numbers you want to add are already in the offset format.
The method is: add the two offset numbers, as unsigned addition and ignoring any overflow, then flip the most significant bit.
In your case, you are adding 10000101 (5 in offset) and 10100000 (32 in offset). Adding those results in 00100101, since there is overflow out of the most significant bit. Flipping the most-significant bit results in 10100101, which is indeed 37 in offset format.
This method may result in overflow, but only when the result is too positive or too negative to fit into the offset format anyway. And in most CPUs the two operations (unsigned addition and flipping the MSB) are practically trivial.
could anyone tell me that
is it right way if i calculate the crc by the method given below:
i did this because dataword length is large.
is it right?
The bottom set of divisions are what you want for a CRC, and arrive at the correct remainders. Your quotients each need one more bit, but they are not used anyway.
The top division was not completed, but it is not relevant, since you need to append the four zeros first as you did in the bottom left, or the four-bit CRC as you did in the bottom right.
Ultimately, You are doing the same thing what a division does. Refer https://www.wikihow.com/Divide-Binary-Numbers binary division for more. However, the data word to be sent to the receiver should not be altered.
I recently was working on a checkout system based in flex 3 and had an order total that didn't make sense to me. I was adding a subtotal, shipping cost, and tax. All 3 of those values were rounded to 2 decimal places but my answer didn't appear to be rounded at all.
After looking into what was happening I discovered any time you add .95 and .15 instead of getting 1.1 you get 1.09999999 repeating. Starting with variations of that doesn't make a difference, in my original case it was (17.95 + 5 + 1.15). Flex gave me 24.09999.
Is there a reason for this? I can just round the final number again and get the correct result but it seems odd that such basic arithmetic would be wrong. Thanks.
Because of the way computers handle floating point numbers, they often times will be very close to, but not exactly the same value you input. The number has to fit in a fixed number of bits, so some resolution is lost for the trade off of space. This is a limitation of computers, not flex.
A fairly simple explanationhttp://joshblog.net/2007/01/30/flash-floating-point-number-errors/
A much more in depth explanation
https://en.wikipedia.org/wiki/Floating_point
Okay, so I am trying to drive a 7 segment based display in order to display temperature in degrees celcius. So, I have two displays, plus one extra LED to indicate positive and negative numbers.
My problem lies in the software. I have to find some way of driving these displays, which means converting a given integer into the relevant voltages on the pins, which means that for each of the two displays I need to know the number of tens and number of 1s in the integer.
So far, what I have come up with will not be very nice for an arduino as it relies on division.
tens = numberToDisplay / 10;
ones = numberToDisplay % 10;
I have admittedly not tested this yet, but I think I can assume that for a microcontroller with limited division capabilities this is not an optimal solution.
I have wracked my brain and looked around for a solution using addition/subtraction/bitwise but I cannot think of one at all. This division is the only one I can see.
For this application it's fine. You don't need to get bothered with performance in a simple thermometer.
If however you do need something quicker than division and modulo, then bitwise operations come to help. Basically you would use bitwise & operator, to compare your value to display with patterns describing digits to be displayed on the display.
See the project here for example: http://fritzing.org/projects/2-digit-7-segment-0-99-counting-with-arduino/
You might also try using a 7-seg display driver chip to simplify your output and save pins. The MC14511BCP (a "4511") is a good one. It'll translate binary coded decimal (BCD) to the appropriate 7-seg configuration. Spec sheets are available here and they can be commonly found at electronics parts stores online.