programing environment : vxworks +powerpc
branch instruction:
b targetaddress
NIA = CIA+ EXTS（LI||0b00)
<br>while NIA-CIA= 0x82fb7b4 = 1000 0010 1111 1011 0111 1011 0100</br>
<br>EXTS(LI) = 1000 0010 1111 1011 0111 1011 01 </br>
I followed the powerpc white paper book.
LI take only 24Bits . but i calculated 26 bits and i don't know how to trim it.
from https://www.ibm.com/docs/en/aix/7.2?topic=set-b-branch-instruction
The b instruction branches to an instruction specified by the branch target address. The branch target address is computed one of two ways.
Consider the following when using the b instruction:
If the Absolute Address bit (AA) is 0, the branch target address is computed by concatenating the 24-bit LI field. This field is calculated by subtracting the address of the instruction from the target address and dividing the result by 4 and b'00'. The result is then sign-extended to 32 bits and added to the address of this branch instruction.
If the AA bit is 1, then the branch target address is the LI field concatenated with b'00' sign-extended to 32 bits. The LI field is the low-order 26 bits of the target address divided by four.
The b instruction has four syntax forms. Each syntax form has a different effect on the Link bit and Link Register.
Related
The following regex within DB2 SQL works pretty well to get extra elements out of an address (i.e. not the street name or number). Limiting myself to two cases (UNIT or GATE) to keep my example simple, where HAD1 is the field containing the first line of a street address:
select HAD1,
regexp_substr(HAD1,'(UNITS?|GATES?)\s[0-9A-Z]{1,}')
from ECH
where regexp_like(HAD1,'(UNIT|GATE)')
and length(trim(HAD1)) > 12
I get this:
Ship To REGEXP_SUBSTR
Address
Line 1
UNIT 4, 117 MONTGOMORIE RD UNIT 4
END OF WAINUI RD, HIGHGATE -
UNIT 3, 37 TE ROTO DRIVE UNIT 3
GATE 6 52 MAHIA ROAD GATE 6
UNIT B 11 LANGSTONE LANE UNIT B
ASHBURTON FITTINGS GATE 2 GATE 2
GOODS: PLACEMAKERS - WESTGATE -
UNIT 3, 37 TE ROTO DRIVE UNIT 3
ASHBURTON FITTINGS GATE 2 GATE 2
SH 8A TARRAS-LUGGATE HIGHWAY GATE HIGHWAY
Which is very encouraging. It correctly didn't pick up HIGHGATE or WESTGATE because they weren't followed by a space then something else.
But it did pick up LUGGATE (last line), which I don't want. So, I'd like to be able to include that my text strings are not preceded by any character.
As you may guess I'm an absolute beginner with regex, so thank you for your patience.
Edit
Now I have my most excellent regex like so:
\b(GATE|LEVEL|DOOR|UNITS?)\s[\dA-Z]{1,}
Using it over a larger data set I notice the occasional unwanted match where, for instance, GATE is followed by an ordinary English word:
THE THIRD GATE ON THE LEFT = GATE ON
The gates, levels, doors and units that I'm looking for will always be followed by one of the following: (a) A number of up to 6 digits (b) One letter (c) A number and one letter, possibly with a dash
Examples:
UNIT 7A
GATE 6
GATE 31113
UNIT B
LEVEL B2
LEVEL 2B
UNIT D06
So, my follow up question is, can I limit the number of letters in second part of the expression to 0 or 1, but allow up to six digits.
I've played around with the numbers in curly brackets but they seem to affect only how many characters are returned rather than how many characters must be present.
I'm working on a language L = { every pair of zeros is separated by 1's that's of length 4i, i>=0 }
e.g. 110011110 should be accepted because the first two zeros are separated by nothing. Then the next pair is separated by 4 ones.
Here's my attempt for the NFA, anything missing?
We can use Myhill-Nerode directly to derive a minimal DFA for this language. The reasoning is straightforward.
e, the empty string, can be followed by any string in L to get to a string in L.
0 can be followed by 1* or by (1^4i)L to get to a string in L.
1 can be followed by L to get to a string in L. This means it is indistinguishable from the empty string. That also means we don't need to worry about longer strings that start with 1, since they will be covered by shorter strings that don't start with 1.
00 can be followed by the same stuff as 0 can, so it is indistinguishable. This also means we don't need to worry about longer strings that start with 00, since they are handled by shorter strings that don't.
01 can be followed by 1* or 111(1^4i)L to get to a string in L.
10, 11 can be ignored as they start with 1 (see 3)
000, 001 can be ignored as they start with 00 (see 4)
010 cannot be followed by anything to get a string in L. We can also ignore anything that starts with this since it can't lead to a string in L.
011 can be followed by 1* or 11(1^4i)L to get a string in L.
100, 101, 110, 111 can be ignored as they start with 1 (see 3)
0000, 0001, 0010, 0011 can be ignored as they start with 00 (see 4)
0100, 0101 can be ignored since they start with 010 (see 8)
0110 cannot be followed by anything to get to a string in L so is indistinguishable from 010.
0111 can be followed by 1* or 1(1^4i)L to get a string in L.
1000, 1001, 1010, 1011, 1100, 1101, 1110, 1111 can all be ignored since they start with 1 (see 3)
The only string of length four distinguishable from shorter strings was 0111; 01110 is indistinguishable from 010 in that nothing leads it to a string in L, and 01111 is indistinguishable from 0 in that it can be followed by 1* or (1^4i)L to get to something in L.
This may seem like a lot of work, but it was a pretty simple exercise. We can go back through and list our complete set of shortest-length distinguishable strings:
e, from point 1 above
0, from point 2 above
01, from line 5 above
010, from point 8 above
011, from point 9 above
0111, from point 14 above
To write down a DFA, we need one state for each of these shortest-length distinguishable strings. The transitions from the state corresponding to string x will lead to states corresponding to strings formed by concatenating input symbols to x. So:
___________________________
| ^
0 V 1 1 1 | 1
--->(e)--->(0)--->(01)--->(011)--->(0111)
\_/ \_/ | 0 | 0 | 0
1 0 | V V
|<-----------------
V
(010)
\___/
0,1
e is the initial state.
the state for e loops to itself on 1 since e.1 = 1 and 1 is indistinguishable from e. Indistinguishable strings lead to the same state in a minimal DFA.
the state for e goes to the state for 0 on 0 since e.0 = 0 and 0 is distinguishable from all strings of the same or shorter length.
state 0 leads to state 01 leads to state 011 leads to state 0111 on 1s, since 0111 = 011.1 = 01.1.1 = 0.1.1.1 and these are all distinguishable from strings of the same or shorter length.
0111 leads to 0 on 1 since 0111.1 = 01111 which is indistinguishable from 0.
states 0, 01, 011 and 0111 lead to state 010 on 0 since 0.0 = 00, 01.0 = 010, 011.0 = 0110 and 0111.0 = 01110 are indistinguishable from 010.
010 leads to itself on all inputs since nothing can be added to it to get a string in L, so the same is true for any concatenation with this at the front.
Now that we have the structure, we simply have to look at each state and say whether its canonical string is in L. If so, the state is accepting; otherwise, it is not.
e is in L, so (e) is accepting.
0 is in L, so (0) is accepting.
01 is in L, so (01) is accepting.
010 is in L, so (010) is not accepting.
011 is in L, so (011) is accepting.
0111 is in L, so (0111) is accepting.
This completes the derivation of the minimal DFA for L.
I'm trying to assemble proper track data given a CVC3 and a bunch of positional parameters. But the EMV C-2 Kernel book is about as obtuse as you could imagine (would it kill somebody to include an example!?!). Can anyone help work this example:
9f62 - pcvc3(t1) - Position of CVC3 in track1: 0x38 (4-6?)
9f63 - punatc(t1) - Unpredictable Number Track1 Pos: 0x3C6 (2-3 7-10?)
9f64 - natc(t1) - Digits in track1 ATC: 4
9f65 - pcvc3(t2) - Position of CVC3 in track2: 0x38 (4-6)
9f66 - punatc(t2) - Unpredictable Number Track2 Pos: 0x3C6 (2-3 7-10?)
9f67 - Digits in track2 ATC: 4
After successful checksum generation:
9f61 - track2 CVC3 - 2EF4
9f60 - track1 CVC3 - 609B
9f36 - ATC - 1E47
assuming the discretionary data field starts out as all 0s, how does it end up? The spec says this:
Convert the binary encoded CVC3 (Track2) to the BCD encoding of the
corresponding number expressed in base 10. Copy the q least significant digits of the
BCD encoded CVC3 (Track2) in the eligible positions of the 'Discretionary Data' in
Track 2 Data. The eligible positions are indicated by the q non-zero bits in
PCVC3(Track2).
I read that as:
CVC3 = 0x609B = 24731 (so copy 731? What does BCD have to do with this? Or are they just saying "copy the 731 as bcd encoded to the byte array"?)
yes you are correct it is rather obtuse. you are correct that you would convert your p values (pCVC3, and PUNATC) to binary. (0011 1000, 0011 1100 0110 for your track1 p values) you then right align the proper values with the discretionary data. example
Bxxxxxxxxxxxxxxxx^ /^14111014010000000000
....000000000000000000CCC000
....00000000000000AAAA000UU0
so you say that you CVC3 for track 1 is 609B which is 24,731, since you PCVC3 is asking for only 3 characters youd set 731 in. your ATC is 1E47 which is 7,751. your PUNATC is asking for 4 digits so you'd use 7751. FYI... if the ATC is lower than the requested characters you'd pad with 0's. Your unpredictable number is even more tricky... so you make a 4 byte random number. convert it to a uint (base 10) and then mark the 8 most significant bytes as 0. example. lets say your random 4 bytes is 29A6 06AE. in base 10 that is 698,746,542. mark out the first 8 characters with 0. and you are left with 000,000,002. you'd place 02 in for you unpredictable number placment.. so.. all that said your track would look like this
Bxxxxxxxxxxxxxxxx^ /^14111014017751731020
the last character is equal to the length of the unpredicatable number (numeric) digits. which was 02.. so the last digit is 2 making your final track data
%Bxxxxxxxxxxxxxxxx^ /^1411014017751731022;
track2 is very similar. good luck with it. I understand your frustrations with this. :)
For Objective-C:
Hi everyone, I'm trying to convert a hex input into binary. For example, someone enters in :
A55
I want that to convert to
101001010101
I've tried looking through past posts and none seem to be working for me. Any help would be greatly appreciated.
Use a lookup table: there are only 16 possible characters in a HEX representation, each corresponding to a four-character binary code group. Go through the HEX character-by-character, obtain a lookup, and put it in the resultant NSString.
Here is a copy of the lookup table for you.
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
A 1010
B 1011
C 1100
D 1101
E 1110
F 1111
There are multiple options as to how to do lookups. The simplest way would be making a 128-element array, and placing NSStrings at the elements corresponding to codes of the characters (i.e. at positions '0', '1', ..., 'E', 'F', with single quotes; these are very important).
I believe there is a built-in function for this. If not, you should at least be able to go hex->dec then dec->bin
You can write the conversion from scratch if you know the number of characters, bin to hex is common enough algorithmically.
A mathematical look at the algorithms
SO Answers in C/C++ Another
Base 10 to base n in Objective C
C Hex->Bin
Build a lookup table (an array where you can supply a value between 0 and 15 to get the binary for that hex digit):
char *hex_to_bin[] = {
"0000", "0001", "0010", "0011",
/* ... */
"1100", "1101", "1110", "1111"
};
There should be 16 elements in that table. The conversion process for multiple digits is to handle one digit at a time, appending the results onto the end of your result storage.
Use getchar() to read a char:
int c = getchar();
if (c < 0) { puts("Error: Invalid input or premature closure."); }
Use strchr() to determine which array index to retrieve:
char *digits = "00112233445566778899AaBbCcDdEeFf";
size_t digit = (strchr(digits, c) - digits) / 2;
Look up the corresponding binary values for digit:
printf("%s", hex_to_bin[digit]); // You'll want to use strcat here.
Very basic question here.
I have to write out a data glossary for a COBOL program. This data glossary includes the following details about every variable:
Name
Data type
Range of values (if applicable)
Line numbers
Fuller name
I have several variables that include level 88 switches. My question is this: Are these level 88 switches counted as variables, and should I include them in the data glossary? Or, judging by the data glossary structure I have to work with, should they be ignored in this context?
And while I'm here, another simple question. Should fillers be included in data glossaries? This program in particular contains a LOT of filler variables, most being simple "PIC X" variables.
Assuming I understand the question being asked.
It would help if you could give an example with a COBOL layout and data glossary entry one with and one without an 88 entry. However, I'll do my best to try to answer the question.
No, 88 level entries are not variables and they do not increase or decrease the length of the record. They simply allow you to create a conditional statement.
With that being said should your data glossary only include variables that contribute to the length of the record?
If yes then there shouldn't be a separate data glossary entry per 88 item. However, it might help to explain a given variable's value[s] (3 and maybe 5 or even an extra line for expected values).
01 record-store.
02 location pic 9(4).
88 dist-center value 100, 101, 102.
02 value pic 9(6).
02 paid pic X(1).
88 yes value 'Y', 'y'.
88 no value 'N', 'n'.
Your data glossary would/could be:
location
Name: location
Data Types: integer
Range of Value: 0-9999
Line Numbers: 20
Fuller name: location of the data
Expected Values:
100, 101, 102 for distribution centers
1-99 for customers
103-9999 invalid
Now knowing your expected values you might go back and change your 88 values?
...
02 location pic 9(4).
88 dist-center value 100, 101, 102.
88 customers value 1 thru 99.
88 invalid value 0, 103 thru 9999.
...
If no then:
You could have a separate data glossary entry pre 88 level entry.
Your data glossary would/could be:
location
Name: location
Data Types: integer
Range of Value: 0000-9999
Line Numbers: 20
Fuller Name: The location of the data
dist-center
Name: dist-center
Data Types: boolean
Range of Value: 100, 101, 102
Line Numbers: 5
Fuller Name: Is location is a distribution center
customer
Name: customer
Data Types: boolean
Range of Value: 1-99
Line Numbers: 5
Fuller Name: Is location a customer
invalid
Name: invalid
Data Types: boolean
Range of Value: 0001, 0010, 0100
Line Numbers: 5
Fuller Name: Is location an invalid value
As usual, it depends. :-)
The level 88 values seem to belong under part 3 "Range of values", especially if they document the only values allowed for some variable.
The FILLER fields are of course important if the documentation is used to reconstruct the records. If you just want to document the usage of the other fields, they are not very interesting.
The 'PIC X' FILLER variables are probably flags in working storage with 88 levels, and therefore quite important.
For instance, we use this type of construct a lot:
01 FILLER PIC X.
88 OPTION-IS-ON VALUE 'Y', FALSE 'N'.
88 OPTION-IS-OFF VALUE 'N'.
This defines a flag which we only reference using it's conditions. For example we might use it like this:
SET OPTION-IS-ON TO TRUE. | This puts a 'Y' in the PIC X
.
.
.
IF OPTION-IS-ON
do something
END-IF
In this case we never need to refer to the actual flag value itself, and hence you do not need to give it a name.
The 'FALSE' in the 88 level just allows you to specify what is stored when you use the statement:
SET OPTION-IS-ON TO FALSE | This puts an 'N' in the PIC X
which of course is the same as saying:
SET OPTION-IS-OFF TO TRUE | This also puts an 'N' in the PIC X
It all depends what is more readable at the time.