I've been working on yasm assembly language and I generated a listing file that contains the following. I need help understanding how the memory displacement is computed in the first column. Thanks in advance.
1 %line 1+1 memory.asm
2 [section .data]
3 00000000 04000000 a dd 4
4 00000004 CDCC8C40 b dd 4.4
5 00000008 00000000<rept> c times 10 dd 0
6 00000030 01000200 d dw 1, 2
7 00000034 FB e db 0xfb
8 00000035 68656C6C6F20776F72- f db "hello world", 0
9 00000035 6C6400
Assembler is producing bytes (machine code), starting at some start address (here 0) and laying them next to each other. So first a dd 4 produces 4 bytes of data 04 00 00 00, thus memory at addresses 0, 1, 2 and 3 are filled up. Next free slot is at address 4. There goes b dd 4.4, again 4 bytes long. c times 10 dd 0 is 40 bytes long, so 8+40 = 48 (0x30) => next free slot.
Related
i dont understand completely but to me it seems like there cant be a problematic/hazardous path.
So its about hazards that can occur in a half-adder circuit with Inverters XORs and Ands. Cant get to create the structural term and diagram.
Would really appreciate help
To my unterstanding there cant be a data hazard but a structural hazard can obviously occur due to different gatters used. but cant get an Structural KV-Diagram out of it because theres only 2 variables x and y.
All 16 cases with the POS hazards explained are shown below:
\a 0 1
b\
0
1
0
00
00
0
1
10
00
not a . not b
2
01
00
a . not b
3
11
00
not b
4
00
10
not a . b
5
10
10
not a
6
01
10
a . not b + not a . b [(a, b)]: (1, 0) = 1 ==> (0, 1) = 1, but (0, 0) = 0 or (1, 1) = 0 could be hit during transition; SOP resolves this: not (a.b)
7
11
10
not b + not a [(a, b)]: (1, 0) = 1 ==> (0, 1) = 1, but (1, 1) = 0 could be hit during transition; SOP resolves this: not (a.b)
8
00
01
9
10
01
similar to 6 above
10
01
01
11
11
01
similar to 7 aove
12
00
11
13
10
11
similar to 7 aove
14
01
11
similar to 7 aove
15
11
11
So I am new to supervised machine learning, but I've been reading books and articles about it and I'm stuck on a problem. (Not stuck, but I don't understand the logic behind classification algorithms). I am trying to classify records as being wrong or not based on historical data.
So this is the original data (training data):
Name Office Age isWrong
F1 1 32 0
F2 2 61 1
F3 1 35 0
F4 0 25 0
F5 1 36 0
F6 2 52 0
F7 2 48 0
F8 1 17 1
F9 2 51 0
F10 0 24 0
F11 4 34 1
F12 0 21 0
F13 2 51 0
F14 0 27 0
F15 3 37 1
(only showing top 15 results of 200 results)
A wrong record is any record which reports an age LOWER than 18 or HIGHER than 60, or an office location that is NOT {0, 1, 2}. I have more records that display a 1 when any of the mentioned conditions are met. I trained my model with this dataset and I created a test dataset to test the results. However, I end up getting 0 on the prediction column of every record. I used a Naïve Bayes approach because this approach assumes independence between the features variables which is my case (no relationship between the office number and age). I know there are other methods like Logistic Regression and SVC(SVM), but I assume that they require a degree of relationship between the features variables. Despite that, I still tried those two approaches and got the same results. Am I doing something wrong? Do I need to specify something before training my model?
Here is what I did (very simple):
NaiveBayes nb = new NaiveBayes().setLabelCol("isWrong");
NaiveBayesModel nbm = nb.fit(dataset);
nbm.transform(dataset2).show();
Here is dataset2 (top 15):
Name Office Age
F1 9 36 //wrong, office is 9
F2 2 20
F3 1 17
F4 2 43
F5 2 90 // wrong, age is >60
F6 1 36
F7 1 40
F8 2 52
F9 2 49
F10 1 38
F11 0 28
F12 0 18
F13 1 40
F14 1 31
F15 2 45
But like I said, the prediction column displays 0 every time. Any idea why?
I don't know why you are opting for transform(). It just tries to cast the result dtype to the same one as the original column has
To get the probability you should be using the function:
predict_proba(X): Return probability estimates for the test vector X.
The following code should work perfectly in your scenario
NaiveBayes nb = new NaiveBayes().setLabelCol("isWrong");
nb.fit(dataset)
nb.predict_proba(dataset2)
I am trying to print to a ESC/POS compatible printer and am struggling to get my head around GS v 0. I have just connected from a Mac and sending commands is hex via CoolTerm.
The docs say ...
GS v 0 m xL xH yL yH d1....dk
-----------------------------------------------------
[Name] Print raster bit image
[Format] ASCII GS v 0 m xL xH yL yH d1....dk
Hex 1D 76 30 m xL xH yL yH d1....dk
Decimal 29 118 48 m xL xH yL yH d1....dk
[Range] 0≤xL≤48, xH=0; 0≤yL≤255, yH=0; 0≤d≤255
k=(xL+xH×256)×(yL+yH×256)(k≠0)
[Description] Selects Raster bit-image mode. The value of m selects the mode, as follows:
+------+------------+----------------------------+---------------------------+
| m | MODE | Vertical Dot Density | Horizontal Dot density |
+------+------------+----------------------------+---------------------------+
|0, 48 | Normal | 200 DPI | 200 DPI |
+------+------------+----------------------------+---------------------------+
|1, 49 |Double-width| 200 DPI | 100 DPI |
+------+-------------+---------------------------+---------------------------+
|2, 50 |Double-height| 100 DPI | 200 DPI |
+------+-------------+---------------------------+---------------------------+
|3, 51 | Quadruple | 100 DPI | 100 DPI |
+------+-------------+---------------------------+---------------------------+
• xL, xH, select the number of data bits ( xL+ xH × 256) in the horizontal direction for the bit image.
• yL, yH, select the number of data bits ( yL+ yH × 256) in the vertical direction for the bit image.
• This command has no effect in all print modes (character size, emphasized, double-strike, upside-down, underline, white/black reverse printing, etc.) for raster bit image.
• The part of bit image that exceeds the printable area will not be printed.
• d indicates the bit-image data. Set time a bit to 1 prints a dot and setting it to 0 does not print a dot.
So from this I deduce I need to send the following in HEX
1D 76 30 30 20 00 00 01
Does the image data now follow this, and do I have to send a message saying the image has ended?
I remember there is <ESC>K (not GS) command to print 8 lines of pixels. See ESC commands for details. After K must be sent 2 bytes - number of data bytes and the real data. But it is not guaranteed whether every printer will support this. What is the brand and model of your?
The docs say:
Hex 1D 76 30 m xL xH yL yH d1....dk
with m being 0x48..0x51, so you can't send
1D 76 30 30 20 00 00 01
but rather, for instance
1D 76 30 48 20 00 00 01
I don't think it makes much sense that xH and yL are 0.
I have an alarm system that I have configured to send SMS messages to my phone as well as over Ethernet.
Here a few of the SMSes I receive:
5522 18 1137 00 003 1C76
5522 18 3137 00 003 3278
5522 18 1130 00 002 E36E
5522 18 1401 00 001 ED6E
5522 18 1302 00 003 ED70
5522 18 1302 00 004 EE71
5522 18 1302 00 009 F376
5522 18 3147 00 009 417F
5522 18 1137 00 004 1D77
5522 18 3137 00 009 3379
5522 18 1602 00 000 0870
The first 4 bytes are the account number, the next 2 are always 18, the next 4 are event codes, 2 group bytes and 3 zone numbers. At the end there are 4 bytes which I suspect is some kind of checksum.
This is some kind of Ademco Contact ID format. However, I do not recognize the checksum.
It's not a time stamp as the last message (0870) is sent periodically and is always the same.
When sending via DTMF 0 should have value 10, but I do not know if that is the case with SMSes. Most likely not.
The checksum formula in Ademco's Contact ID is calculated using the formula:
S= HEX Checksum which is one digit.
(Sum of all message digits + S) MOD 15 = 0
and if the value is equal to 10 the checksum digit is 0.
The official Contact ID specification is here:http://li0r.files.wordpress.com/2012/07/sia-dc-05-1999-09_contact_id.pdf
So, using 5522 18 1602 00 000 0870 as an example:
LET C = checksum
5+5+2+2+1+8+1+6+2=32
(32+S) modulo 15 is congruent to 0
We then need the closest multiple of 15 going higher than 32 which would be 45.
45-32=13
Lets test that.
45 modulo 15 is congruent to 0
It is correct however, as Contact ID is 16 digits and you have 19 I would suspect that your panel is using a different proprietary implementation of Contact ID. If you post the make/model of the panel that this came from I may be able to explain things further.
I hope this answers your question!
-Alex
P.S.: To calculate mod use a percent sign in Google
P.P.S: The document that describes Contact ID is actually: DC-05-1999.09 the document you referenced is actually the computer interface communication protocol specifications.
I just want to correct AdemcoGuy's calculation as it seems to be incorrect:
So, the example was 5522 18 1602 00 000 0870
We need to replace each 0 by 10.
So:
5+5+2+2+1+8+1+6+10+2+10+10+10+10+10 = 92
than 100-92 = 8
So the cheksum is 8
Anyway in the question the checksum seems missing and what is the last 4 digit only knows who manufactured the panel which has been send it :)
#ACCT MT QXYZ GG CCC where:
ACCT: 4 Digit Account number (0-9, B-F)
MT: Message Type - Always 18
Q: Event qualifier, which gives specific event information:
1: New Event or Opening
3: New Restore or Closing
6: Previously reported condition still present (Status report)
XYZ: Event code (3 Hex digits 0-9,B-F)
GG: Group or Partition number (2 Hex digits 0-9, B-F). Use 00 to indicate that no specific group or partition information applies.
CCC: Zone number (Event reports) or User (Open / Close reports) (3 Hexdigits 0-9,B-F ). Use 000 to indicate that no specific zone or user information applies.
To look up event codes see this document (pdf).
I came across this post while trying to figure out the checksums of my own alarm system (Woonveilig/Egardia) that seems to be using the same format. I found a forum post on the german alarm forum that contains a snippet of C code to calculate CRCs for the LUPUS alarm system. This CRC calculation method seems to match both my own and Lasse's SMS based system. Here's the C code converted to a simple calculation tool:
#include <stdio.h>
#include <string.h>
// Code from: https://www.alarmforum.de/showthread.php?tid=12037&pid=75893
/**
* Fletcher Checksum.(LUPUS version, 16-bit)
*/
static unsigned int fletcher_sum(char* data, int len) {
unsigned int sum1 = 0x0, sum2 = 0x0;
while (len) {
unsigned int tlen = (len > 256) ? 256 : len;
len -= tlen;
do {
sum1 += *data++;
sum1 = (sum1 & 0xff);
sum2 += sum1;
sum2 = (sum2 & 0xff);
} while (--tlen);
}
return sum2 << 8 | sum1;
}
int main() {
char input[50];
int sum;
printf("Enter input: ");
fgets(input, sizeof(input), stdin);
sum = fletcher_sum(input, strlen(input)-1);
printf("%x\n", sum);
return 0;
}
Example (first SMS from the question post):
# cc checksum.c
# ./a.out
Enter input: 5522 18 1137 00 003
1c76
I am confused as to how memory is stored when declaring variables in assembly language. I have this block of sample code:
val1 db 1,2
val2 dw 1,2
val3 db '12'
From my study guide, it says that the total number of bytes required in memory to store the data declared by these three data definitions is 8 bytes (in decimal). How do I go about calculating this?
It also says that the offset into the data segment of val3 is 6 bytes and the hex byte at offset 5 is 00. I'm lost as to how to calculate these bytes and offsets.
Also, reading val1 into memory will produce 0102 but reading val3 into memory produces 3132. Are apostrophes represented by the 3 or where does it come from? How would val2 be read into memory?
You have two bytes, 0x01 and 0x02. That's two bytes so far.
Then you have two words, 0x0001 and 0x0002. That's another four bytes, making six to date.
The you have two more bytes making up the characters of the string '12', which are 0x31 and 0x32 in ASCII (a). That's another two bytes bringing the grand total to eight.
In little-endian format (which is what you're looking at here based on the memory values your question states), they're stored as:
offset value
------ -----
0 0x01
1 0x02
2 0x01
3 0x00
4 0x02
5 0x00
6 0x31
7 0x32
(a) The character set you're using in this case is the ASCII one (you can follow that link for a table describing all the characters in that set).
The byte values 0x30 thru 0x39 are the digits 0 thru 9, just as the bytes 0x41 thru 0x5A represent the upper-case alpha characters. The pseudo-op:
db '12'
is saying to insert the bytes for the characters '1' and '2'.
Similarly:
db 'Pax is a really cool guy',0
would give you the hex-dump representation:
addr +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F +0123456789ABCDEF
0000 50 61 78 20 69 73 20 61 20 72 65 61 6C 6C 79 20 Pax is a really
0010 63 6F 6F 6C 20 67 75 79 00 cool guy.
val1 is two consecutive bytes, 1 and 2. db means "direct byte". val2 is two consecutive words, i.e. 4 bytes, again 1 and 2. in memory they will be 1, 0, 2, 0, assuming you're on a big endian machine. val3 is a two bytes string. 31 and 32 in are 49 and 50 in hexadecimal notation, they are ASCII codes for the characters "1" and "2".