Why K-map has states in sequence of 00,01,11,10 instead of 00,01,10,11?
It's because in the first sequence, each entry differs in only one bit whereas in the second sequence the transition from 01 to 10 changes two bits which produces a race condition. In asynchronous logic, nothing ever happens at the same time, so 01 to 10 is either 01 00 10 or 01 11 10 and that causes problems.
In the process of simplification, when 2 minterms, with one bit differing,r ORed, one variable gets eliminated as 1 + 0 = 1
This is because if we write 00 01 11 10 then in between two there is a difference of two bits and as smparkes told that asynchronous cannot take two values a time so that is the only way left now. As we take gray code in a similar way gray code of 00 is 00, of 01 is 01, of 11 is 10 and of 10 is 11. In this way k map is numbered.
Related
a super stupid question:
I have an integer in my code, which occupies 4 bytes ( of course ), this information in memory is represented as a pack of four hexadecimal of two digits, for example
int x = 1000
in memory is represented as
e8 03 00 00
where the first hex represents the "lower" byte and the last is the "highest".
How is this representation called? Are there other representations? I just need the name. I'm struggling to find online this information :(
Thanks
The word you are looking for is Endianness.
I am trying to create a copybook structure for my data file.
Part of the data looks like this
C 0000.00
Since it has 0000.00 , in my copybook, we declared it as a PIC 9(04)v9(02).
but when i map it using fileaid, i get this error
15 EF-PURCH-FEE-AMT 6/AN 0000.0
15 EF-FILLER4 975/AN 0
The decimal point is considered as another byte and the last zero is spilling into the subsequent field
I have tried to define the picture clause as zoned decimal by giving value as PIC ZZZ9V99 as well. But its still spilling into next field.
Expected result. :
15 EF-PURCH-FEE-AMT 6/AN 0000.00
15 EF-FILLER4 975/AN 0
Actual result:
15 EF-PURCH-FEE-AMT 6/AN 0000.0
15 EF-FILLER4 975/AN 0
PIC definition as of now:
15 EF-PURCH-FEE-AMT PIC ZZZ9V99.
15 EF-FILLER4 PIC X(975).
Please refer to the documentation for the PICTURE clause of a data definition. There you will find that the V is a presumed or virtual decimal point, not a physical one. You may be able to attain your desired result with...
15 EF-PURCH-FEE-AMT PIC 9999.99.
So my book says i can define a table of words like so:
table: dw "13,37,99,99"
and that i can snatch values from the table by incrementing the index into the address of the table like so:
mov ax, [table+2] ; should give me 37
but instead it places 0x2c33 in ax rather than 0x3337
is this because of a difference in system architecture? maybe because the book is for 386 and i'm running 686?
0x2C is a comma , and 0x33 is the character 3, and they appear at positions 2 and 3 in your string, as expected. (I'm a little confused as to what you were expecting, since you first say "should give me 37" and later say "rather than 0x3337".)
You have defined a string constant when I suspect that you didn't mean to. The following:
dw "13,37,99,99"
Will produce the following output:
Offset 00 01 02 03 04 05 06 07 08 09 0A 0B
31 33 2C 33 37 2C 39 39 2C 39 39 00
Why? Because:
31 is the ASCII code for '1'
33 is the ASCII code for '3'
2C is the ASCII code for ','
...
39 is the ASCII code for '9'
NASM also null-terminates your string by putting 0 byte at the end (If you don't want your strings to be null-terminated use single quotes instead, '13,37,99,99')
Take into account that ax holds two bytes and it should be fairly clear why ax contains 0x2C33.
I suspect what you wanted was more along the lines of this (no quotes and we use db to indicate we are declaring byte-sized data instead of dw that declares word-sized data):
db 13,37,99,99
This would still give you 0x6363 (ax holds two bytes / conversion of 99, 99 to hex). Not sure where you got 0x3337 from.
I recommend that you install yourself a hex editor and have an experiment inspecting the output from NASM.
I know 0D 0A means new line,What's 09 09 09 09 09 09 09 3F ?
It's from UTF-8.
According to this ascii table that is 7 tabs followed by a question mark.
09 is TAB
3F is ?
So you have 2 newlines, 7 tabs, a question mark and another newline.
Assuming its ASCII.
0x09 = 'Horizontal Tab'
0x3F = '?'
From here.
an Operating system can use three different kind of numeric bases in order to encode characters. Binary, decimal or hexadecimal encoding. Most of the times the encoding is done using an iso table code ASCII table which for every computer usable characters, defines a binary, decimal and hexadecimal value who would represent it as a number.
You should take a look to man ascii then ;)
I am using DeDe to create an API (Interface) I can compile to. (Strictly legit: while we wait for the vendor to deliver a D2010 version in two months, we can at least get our app compiling...)
We'll stub out all methods.
Dede emits constant declarations like these:
LTIMGLISTCLASS =
00: ÿÿÿÿ....LEADIMGL|FF FF FF FF 0D 00 00 00 4C 45 41 44 49 4D 47 4C|
10: IST32. |49 53 54 33 32 00|;
DS_PREFIX =
0: ÿÿÿÿ....DICM.|FF FF FF FF 04 00 00 00 44 49 43 4D 00|;
How would I convert these into a compilable statement?
In theory, I don't care about the actual values, since I doubt they're use anywhere, but I'd like to get their size correct. Are these integers, LongInts or ???
Any other hints on using DeDe would be welcome.
Those are strings. The first four bytes are the reference count, which for string literals is always -1 ($ffffffff). The next four bytes are the character count. Then comes the characters an a null terminator.
const
LTIMGLISTCLASS = 'LEADIMGLIST32'; // 13 = $0D characters
DS_PREFIX = 'DICM'; // 4 = $04 characters
You don't have to "doubt" whether those constants are used anywhere. You can confirm it empirically. Compile your project without those constants. If it compiles, then they're not used.
If your project doesn't compile, then those constants must be used somewhere in your code. Based on the context, you can provide your own declarations. If the constant is used like a string, then declare a string; if it's used like an integer, then declare an integer.
Another option is to load your project in a version of Delphi that's compatible with the DCUs you have. Use code completion to make the IDE display the constant and its type.