I just finished ‘Code: The Hidden Language of Computer Hardware and Software’ by Charles Petzold which was a really well-written (in my opinion) guided journey from flashing a light in morse code through to building a whole computer, and everything needed along the way.
The section on encoding instructions for the processor (built up from logic gates) - assembly instructions as a human readable version of the machine code - was particularly interesting to me, and as I was describing this to a colleague I remembered that it’s not the first time I’ve played with assembly…
Years and years ago (I don’t recall how it actually started) I spent some time trying to solve a puzzle. I don’t recall whether I saw the puzzle or a solution first, but I do remember wanting to be able to understand it properly, and ideally be able to use some software I wrote to reach the solution.
The puzzle was just a set of characters on a poster for the (then named) Australian Defence Signals Directorate (now the Australian Signals Directorate - one of our Secret Squirrel orgs) at ruxcon in 2011
ruxcon2011 DSD poster
Yes, that was a long time ago, but I never wrote up what I did, and now seems like a good enough time to get really distracted.
I would be surprised if I understood it well enough at the time, so I suspect I was aware of this blogpost which walks through the solution (spoilers). Nonetheless, I wanted to be able to do that myself, not just follow some instructions - I was confident that I could write enough code (of some sort) to go from this sequence of letters and symbols to the final solution.
My attempts at the time were mostly command-line attempts; the blog post linked above uses only web services, so that felt like I could make it ‘my own’. I first needed to get the characters into my computer - that’s just writing them out to a text file, say, a file called dsd
# dsd:
6AAAAABbi8uDwx4zwDPSigOK
ETLCiAM8AHQrg8EBg8MB6+wz
/7/z+TEct0SlpGf5dRyl53US
YQEE56Ri7Kdkj8IAABkcOsw=Knowing that this is base-64 encoded, I can decode it with hexdump
cat dsd | base64 -d | hexdump -C
00000000 e8 00 00 00 00 5b 8b cb 83 c3 1e 33 c0 33 d2 8a |.....[.....3.3..|
00000010 03 8a 11 32 c2 88 03 3c 00 74 2b 83 c1 01 83 c3 |...2...<.t+.....|
00000020 01 eb ec 33 ff bf f3 f9 31 1c b7 44 a5 a4 67 f9 |...3....1..D..g.|
00000030 75 1c a5 e7 75 12 61 01 04 e7 a4 62 ec a7 64 8f |u...u.a....b..d.|
00000040 c2 00 00 19 1c 3a cc |.....:.|
00000047To just get the bytecode, I used some different options and saved the file as dsd.hex
cat dsd | base64 -d | hexdump -v -e '/1 %02X ' > dsd.hex
# dsd.hex:
E8 00 00 00 00 5B 8B CB 83 C3 1E 33 C0 33 D2 8A 03 8A 11 32 C2 88 03 3C 00 74 2B 83 C1 01 83 C3 01 EB EC 33 FF BF F3 F9 31 1C B7 44 A5 A4 67 F9 75 1C A5 E7 75 12 61 01 04 E7 A4 62 EC A7 64 8F C2 00 00 19 1C 3A CC I did go a similar route to the linked blogpost and converted these bytes to shellcode, wrapped them in a C program and disassembled it with gdb, but much simpler was to use a better tool, in this case udis which I needed to install separately. This
gives the same result as the blogpost, which was nice
udcli -x dsd.hex > dsd.hex.asm
# dsd.hex.asm:
0000000000000000 e800000000 call 0x5
0000000000000005 5b pop ebx
0000000000000006 8bcb mov ecx, ebx
0000000000000008 83c31e add ebx, 0x1e
000000000000000b 33c0 xor eax, eax
000000000000000d 33d2 xor edx, edx
000000000000000f 8a03 mov al, [ebx]
0000000000000011 8a11 mov dl, [ecx]
0000000000000013 32c2 xor al, dl
0000000000000015 8803 mov [ebx], al
0000000000000017 3c00 cmp al, 0x0
0000000000000019 742b jz 0x46
000000000000001b 83c101 add ecx, 0x1
000000000000001e 83c301 add ebx, 0x1
0000000000000021 ebec jmp 0xf
0000000000000023 33ff xor edi, edi
0000000000000025 bff3f9311c mov edi, 0x1c31f9f3
000000000000002a b744 mov bh, 0x44
000000000000002c a5 movsd
000000000000002d a4 movsb
000000000000002e 67f9 a16 stc
0000000000000030 751c jnz 0x4e
0000000000000032 a5 movsd
0000000000000033 e775 out 0x75, eax
0000000000000035 126101 adc ah, [ecx+0x1]
0000000000000038 04e7 add al, 0xe7
000000000000003a a4 movsb
000000000000003b 62ec invalid
000000000000003d a7 cmpsd
000000000000003e 648fc2 pop edx
0000000000000041 0000 add [eax], al
0000000000000043 191c3a sbb [edx+edi], ebx
0000000000000046 cc int3 At this point, I got a bit lost (at the time) because I didn’t understand assembly well enough (or at all), so, continuing with the logic presented in the linked blogpost, I considered just working with the bytes directly.
All we really need to do it take the bytes starting at 0x5 and 0x23 and xor them. I figured I’ll need the decimal value of these addresses; 0x5 is just 5, but 0x23 = 16*2 + 3 = 35. We can of course get this via printf
printf "%d\n" 0x23 ## 35or less simply with the built-in calculator tool bc, going from (input) base 16 to (output) base 10
echo "obase=10;ibase=16; 23" | bc## 35I placed the bytes in sequence (removing spaces) with
str=$(cat dsd.hex | sed 's/ //g')
echo $str## E8000000005B8BCB83C31E33C033D28A038A1132C288033C00742B83C10183C301EBEC33FFBFF3F9311CB744A5A467F9751CA5E77512610104E7A462ECA7648FC20000191C3ACCSince I have 2 characters per hex, 0x5 starts at character 10, and 0x23 starts at character 70, so we define our strings as
astr=${str:70} # 0x23 to end
echo $astr## 33FFBFF3F9311CB744A5A467F9751CA5E77512610104E7A462ECA7648FC20000191C3ACCand
$ bstr=${str:10} # 0x5 to end
$ echo $bstr## 5B8BCB83C31E33C033D28A038A1132C288033C00742B83C10183C301EBEC33FFBFF3F9311CB744A5A467F9751CA5E77512610104E7A462ECA7648FC20000191C3ACCThere is overlap here, which we will have to deal with when we get to it. For now, we want to xor these. Let’s cut these down to 60 characters (where they start to overlap)
trimastr=${astr:0:60}
echo $trimastr## 33FFBFF3F9311CB744A5A467F9751CA5E77512610104E7A462ECA7648FC2trimbstr=${bstr:0:60}
echo $trimbstr## 5B8BCB83C31E33C033D28A038A1132C288033C00742B83C10183C301EBECThe command xor (^) chokes on this many digits (in fact, any more than about 8) so I’ve written a script to xor the characters one at a time:
for i in {0..59} ; do echo $(( 0x${astr:$i:1} ^ 0x${bstr:$i:1} )) | awk '{printf "%X",$0}' ; done > xor.dat
# xor.dat:
687474703A2F2F7777772E6473642E676F762E61752F6465636F6465642EWhat about that bit that overlapped? we only xored the first 60 characters, but the length of the string is
echo ${#astr}## 72so we need those first 12 (72-12) characters (6 hex) of overlap
olap1=${astr:60:12}
echo $olap1## 0000191C3ACCThe assembly code would have overwritten the overlapped part by the time it reached there, so we need to xor with the xor’d part, i.e. the first 12 characters of xor.dat
olap2=$(cat xor.dat | cut -c -12)
echo $olap2## 687474703A2FNow, finally, do the last xor (^)
for i in {0..11} ; do echo $(( 0x${olap1:$i:1} ^ 0x${olap2:$i:1} )) | awk '{printf "%X",$0}' ; done > xorolap.dat
# xorolap.dat:
68746D6C00E3so this needs to go at the end of our xor.dat
cat xor.dat xorolap.dat > xorfinal.dat
# xorfinal.dat:
687474703A2F2F7777772E6473642E676F762E61752F6465636F6465642E68746D6C00E3The final 00 and after is useless, so let’s drop it. Finally, we just need to convert this back to text using xxd -r
cat xorfinal.dat | sed 's/[0]\{2\}.*//' | xxd -r -p > dsd.solPhew. I’m not going to reveal the solution just yet, because this isn’t the end of the story (but I did get the right answer).
So, that’s a commandline solution to (at least this part) of the puzzle. But now I know R!
Learning more about assembly from the book ‘Code’, it occurred to me that the
operations - which could be implemented with something as simple as telegraph relays (or crabs) - were just operations on data. Given an input, produce an output (sort of). A MOV operation just moved some value stored at some address to another address (or to/from a register). This felt like it could be simple enough to encode in some R functions. Perhaps not some “pure” R functions, because I want the side-effect of altering a global memory bank, but surely I could do simple things like ADD.
I looked around to see if someone else had done this before. As is usually the case with odd requests, Mike (a.k.a. @coolbutuseless) has done something similar in the form of r64 which I didn’t appreciate was a sufficiently distinct flavour of assembly (I never had a Commodore64, we had an Amstrad CPC664 on which I really only played games). After a quick PR to bring that repo up to date with other changes by the author (a migration of one dependency) I realised this wasn’t what I needed, but did learn a lot from how it was structured.
Okay, on to building something myself. I knew I’d need some memory and some registers. The registers seemed easy - they wouldn’t hold a lot and I could address them by name, e.g. eax. An environment seemed natural, both because of the named list structure, and because I knew it would be mutable. That seemed like a benefit for this use-case - having a global set of registers I could move data in and out of without making copies of the thing or passing it around everywhere.
Next I’d need memory. I figured a vector of hex value made sense, but I wanted to be able to refer to the first one as 0x00. Now, the names of a vector need to be a character vector - you can’t use the actual hex values
memory <- c(0x00 = 0x19, 0x01 = 0x1a, 0x02 = 0x1b)## Error: <text>:1:18: unexpected '='
## 1: memory <- c(0x00 =
## ^so we need to use character strings
memory <- c("0x00" = 0x19, "0x01" = 0x1a, "0x02" = 0x1b)
memory## 0x00 0x01 0x02
## 25 26 27More importantly, we’ll need to ensure we only refer to these by the character
strings because [ first tries a coercion to integer, which, side-note, is why this works
(1:10)[2.3] # since as.integer(2.3) == 2## [1] 2(1:10)[4.7] # since as.integer(4.7) == 4## [1] 4The risk is that we use a hex value to extract an element, in which case we might accidentally try to get the first value with
memory[0x00]## named numeric(0)Instead, we want
memory["0x00"]## 0x00
## 25In order to make sure we always do this, we need a sanitize() function which
always returns the string.
We can convert a value to hexmode with as.hexmode, but that’s a lot of typing, so I added an alias as
hex <- as.hexmodeFor processing assembly instructions, we might see something like
mov eax, 0x5which should move the value 0x5 into the register eax… so we’ll need a way
to distinguish direct addresses from registers. Worse still, we might refer to the address stored in a register, as [eax]. A reg_or_val() function would identify anything which points to an address (containing a [), any of the named registers, or a value, and would return the address (or where that points).
With all of those pieces, the only thing left is to actually be able to run code.
Assembly runs sequentially through the instructions, unless we encounter some flow
control opcodes (e.g. JMP - jump to address - I’ll keep calling them opcodes but mnemonics is a more correct term). The basic process would then be to
read in the instruction, identify the opcode and the arguments, and execute, modifying the memory and registers in-place. Once that’s done, we move to the next instruction.
With flow control we might need to identify a different address to go to next, and that might depend on the status of the registers, for example JNZ 0x00 jumps to address 0x00 if the zero flag is not set. So, we can execute the current instruction but then apply any flag-based logic to see if we need to go to a new address, and go wherever we should go go next. This is implemented as runasm()
That takes care of running the code, but what are we running? Oh, operations. Right. Well, we need some of those. Going through the opcodes I need for the puzzle, I’ll need the following:
call
pop
mov
add
xor
cmp
jz
jmp
haltCALL just pushes a value onto the stack (register esp), POP retrieves it and
stores it at an address, MOV as we said moves a value from place to place, ADD
adds two values, XOR does what it suggests, and so on. These don’t seem tricky to implement, for example
mov <- function(x, y) {
# copy y into x
res <- hex(reg_or_val(y))
if (x %in% names(registers)) {
assign(x, res, envir = registers)
} else {
mem[sanitize(x)] <<- sanitize(res)
}
return(invisible(NULL))
}The wrinkle will be that particular instructions also update registers, for
example an ADD stores whether the result was 0x00 in the zero-flag register
function(x, y) {
# add y to x and save in x
res <- hex(reg_or_val(x)) + hex(reg_or_val(y))
if (x %in% names(registers)) {
assign(x, res, envir = registers)
} else {
mem[sanitize(x)] <<- sanitize(res)
}
assign("zf", hex(as.integer(res == 0x00)), envir = registers)
return(invisible(x))
}A JMP (or other jump) will check this register and jump (or not) accordingly.
With these pieces in place, an R package was a natural home for the code, so I can now present the {rx86} package: https://github.com/jonocarroll/rx86
Let’s use it to solve the puzzle!!!
Starting with the puzzle string
dsd <- "6AAAAABbi8uDwx4zwDPSigOK
ETLCiAM8AHQrg8EBg8MB6+wz
/7/z+TEct0SlpGf5dRyl53US
YQEE56Ri7Kdkj8IAABkcOsw="we decode it (this time in R)
(b64 <- base64enc::base64decode(dsd))## [1] e8 00 00 00 00 5b 8b cb 83 c3 1e 33 c0 33 d2 8a 03 8a 11 32 c2 88 03 3c 00
## [26] 74 2b 83 c1 01 83 c3 01 eb ec 33 ff bf f3 f9 31 1c b7 44 a5 a4 67 f9 75 1c
## [51] a5 e7 75 12 61 01 04 e7 a4 62 ec a7 64 8f c2 00 00 19 1c 3a ccThis will be the only non-R part: we still need to disassemble the bytecode into assembly, but we can do that from R with a system() call to udcli
(disas <- system("udcli -x", input = paste(b64, collapse = " "), intern = TRUE))## [1] "0000000000000000 e800000000 call 0x5 "
## [2] "0000000000000005 5b pop ebx "
## [3] "0000000000000006 8bcb mov ecx, ebx "
## [4] "0000000000000008 83c31e add ebx, 0x1e "
## [5] "000000000000000b 33c0 xor eax, eax "
## [6] "000000000000000d 33d2 xor edx, edx "
## [7] "000000000000000f 8a03 mov al, [ebx] "
## [8] "0000000000000011 8a11 mov dl, [ecx] "
## [9] "0000000000000013 32c2 xor al, dl "
## [10] "0000000000000015 8803 mov [ebx], al "
## [11] "0000000000000017 3c00 cmp al, 0x0 "
## [12] "0000000000000019 742b jz 0x46 "
## [13] "000000000000001b 83c101 add ecx, 0x1 "
## [14] "000000000000001e 83c301 add ebx, 0x1 "
## [15] "0000000000000021 ebec jmp 0xf "
## [16] "0000000000000023 33ff xor edi, edi "
## [17] "0000000000000025 bff3f9311c mov edi, 0x1c31f9f3 "
## [18] "000000000000002a b744 mov bh, 0x44 "
## [19] "000000000000002c a5 movsd "
## [20] "000000000000002d a4 movsb "
## [21] "000000000000002e 67f9 a16 stc "
## [22] "0000000000000030 751c jnz 0x4e "
## [23] "0000000000000032 a5 movsd "
## [24] "0000000000000033 e775 out 0x75, eax "
## [25] "0000000000000035 126101 adc ah, [ecx+0x1] "
## [26] "0000000000000038 04e7 add al, 0xe7 "
## [27] "000000000000003a a4 movsb "
## [28] "000000000000003b 62ec invalid "
## [29] "000000000000003d a7 cmpsd "
## [30] "000000000000003e 648fc2 pop edx "
## [31] "0000000000000041 0000 add [eax], al "
## [32] "0000000000000043 191c3a sbb [edx+edi], ebx "
## [33] "0000000000000046 cc int3 "We then read this back into R as a data.frame
asm <- suppressWarnings(
readr::read_fwf(paste(disas, collapse = "\n"),
col_types = "ccc",
col_positions = readr::fwf_widths(c(16, 16, 21)))
)
colnames(asm) <- c("addr", "bytecode", "instr")
# trim the leading 0s from addr since this is all we're using
asm$addr <- substr(asm$addr, nchar(asm$addr)-1, nchar(asm$addr))
asm## # A tibble: 33 x 3
## addr bytecode instr
## <chr> <chr> <chr>
## 1 00 e800000000 call 0x5
## 2 05 5b pop ebx
## 3 06 8bcb mov ecx, ebx
## 4 08 83c31e add ebx, 0x1e
## 5 0b 33c0 xor eax, eax
## 6 0d 33d2 xor edx, edx
## 7 0f 8a03 mov al, [ebx]
## 8 11 8a11 mov dl, [ecx]
## 9 13 32c2 xor al, dl
## 10 15 8803 mov [ebx], al
## # … with 23 more rowsThe last instruction, int3, is an interrupt, but let’s generalise it to a halt because we’ll be done
asm[33, "instr"] <- "halt"We can run this with {rx86}… we need a memory array and some registers
mem <- create_mem()
registers <- create_reg()Then we can run the code
runasm(asm)As we saw earlier, the ‘code’ part of the asm is stored in 0x00 to 0x21 with the remaining addresses being used for temporary storage, from 0x23. The operations encoded
perform an XOR between the values stored at 0x05 through to 0x21 with those starting at 0x23, storing the results starting at 0x23.
Extracting the memory from this offset onward (up to where it zeroes) results in
(mem_offset <- mem[which(names(mem) == "0x23"):length(mem)])## 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d
## "0x68" "0x74" "0x74" "0x70" "0x3a" "0x2f" "0x2f" "0x77" "0x77" "0x77" "0x2e"
## 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38
## "0x64" "0x73" "0x64" "0x2e" "0x67" "0x6f" "0x76" "0x2e" "0x61" "0x75" "0x2f"
## 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f 0x40 0x41 0x42 0x43
## "0x64" "0x65" "0x63" "0x6f" "0x64" "0x65" "0x64" "0x2e" "0x68" "0x74" "0x6d"
## 0x44 0x45 0x46 0x47 0x48 0x49 0x4a 0x4b 0x4c 0x4d 0x4e
## "0x6c" "0x00" "0xcc" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00"
## 0x4f 0x50 0x51 0x52 0x53 0x54 0x55 0x56 0x57 0x58 0x59
## "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00"
## 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x60 0x61 0x62 0x63 0x64
## "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00"
## 0x65 0x66 0x67 0x68 0x69 0x6a 0x6b 0x6c 0x6d 0x6e 0x6f
## "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00"
## 0x70 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7a
## "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00" "0x00"
## 0x7b 0x7c 0x7d 0x7e 0x7f
## "0x00" "0x00" "0x00" "0x00" "0x00"And then lastly, we need to convert this sequence of hex values into characters. I’ve added a helper which achieves this, dropping everything after the first null-terminating byte (0x00) then
hex2string(mem_offset)## [1] "http://www.dsd.gov.au/decoded.html"TADA!
This example is stored along with the package as a vignette, so
vignette("dsd_ruxcon_challenge", package = "rx86")The link in this solution just redirects to the ASD frontpage since the puzzle is now over 10 years old, but when it was active it led to a page with some binary
0100 0011 0100 1111 0100 1110 0100 0111 0101 0010 0100 0001 0101 0100 0101
0101 0100 1100 0100 0001 0101 0100 0100 1001 0100 1111 0100 1110 0101 0011Originally, I solved this part at the command line by storing this code in a file named decoded and running a similar bc conversion to before, but this time from binary (ibase=2) to hex (obase=16), storing the result in decoded.hex
for bin in $(cat decoded) ; do echo "obase=16;ibase=2; $bin" | bc >> decoded.hex ; doneFrom there, removing the line breaks and spaces, and passing through xxd in reverse (similar to hexdump but reverse works on my machine)
cat decoded.hex | tr '\n' ' ' | sed 's/ //g' | xxd -r -p Again, I’ll hold off showing the answer, but it was correct.
It would be satisfying to also do this in R, so I added another helper in {rx86} that does this conversion - it’s not terribly complex, but involves splitting a string into pairs of strings (split at some point) and a conversion
split_pairs <- function(x, split = "") {
sst <- strsplit(x, split)[[1]]
out <- paste0(sst[c(TRUE, FALSE)], sst[c(FALSE, TRUE)])
paste0(out, collapse = ",")
}
bin2ascii <- function(bin) {
nolb <- gsub("\n", " ", bin)
split <- strsplit(split_pairs(paste(nolb, collapse = " "), split = " "), ",")[[1]]
ints <- strtoi(split, base = 2)
intToUtf8(ints)
}It appears to do the job
binary <- "0100 0011 0100 1111 0100 1110 0100 0111 0101 0010 0100 0001 0101 0100 0101
0101 0100 1100 0100 0001 0101 0100 0100 1001 0100 1111 0100 1110 0101 0011"
bin2ascii(binary)## [1] "CONGRATULATIONS"There, an (almost) entirely R solution to the puzzle, and all it took was writing my own x86 assembly parser.
I did want to see if I’d made my parser too specific and it only worked with this one example around which I’d designed it, so I wanted to add another example. This
journey started with the book ‘Code’, so it felt fitting to use an example from there. In the book, an example of multiplying two 8-bit numbers is used, which
involved an ADC (add with carry) operation to handle overflow. This seemed like a good candidate, and I started coding it, but soon realised that the exact routine
relied on an add al, 0xff which has the effect of adding -1 in 8-bit, but on my machine
as.integer(0xff)## [1] 255and
as.hexmode(-1)## [1] "ffffffff"which isn’t compatible. I could instead code a SUB opcode and sub al, 0x01 (which I did) but at this point I decided to abandon the 8-bit idea and simplify down to just doing essential part of the program which multiplies 127 and 28 through repeated additions (via a loop). The asm for this is also stored in the package, and executing it is as simple as
mult_asm <- suppressWarnings(
readr::read_fwf(system.file("asm", "mult.asm", package = "rx86"),
col_types = "ccc",
col_positions = readr::fwf_widths(c(3, 6, 20)))
)
colnames(mult_asm) <- c("addr", "bytecode", "instr")
print(mult_asm)## # A tibble: 14 x 3
## addr bytecode instr
## <chr> <chr> <chr>
## 1 00 101005 mov al, [0x22]
## 2 03 201001 add al, [0x20]
## 3 06 111005 mov [0x22], al
## 4 09 101004 mov al, [0x21]
## 5 0c 221000 sub al, 0x01
## 6 0f 111004 mov 0x21, al
## 7 12 101003 jnz 0x00
## 8 15 20001e halt
## 9 18 111003 invalid
## 10 1b 330000 invalid
## 11 1e ff00 invalid
## 12 20 a7 data 167
## 13 21 1c data 28
## 14 22 00 resultAgain, we need a new memory array and some registers
mem <- create_mem(len = 64)
registers <- create_reg()Then run the code
runasm(mult_asm)The final result can be extracted but it is still a hex value
mem[sanitize(0x22)]## 0x22
## "0x1244"Converting it to an integer gives the expected result
as.integer(mem[sanitize(0x22)])## [1] 4676167*28## [1] 4676This, too, is stored as a vignette in the package, and can be found with
vignette("mult_code_petzold", package = "rx86")The package is far from perfect, and only supports what I needed it to, but I’ve learned a lot about assembly and got to build something I’ve always wanted to. Plus I’ve finally written up my process for this puzzle that has been sitting on a disused laptop for a decade.
That’s not quite the end, though - I really wanted to test out what I’ve learned so far, and what good is a new programming ability without a “Hello, world!” example?
Almost all of the examples I found floating around use ‘modern’ asm (without the bytecode) and allow such luxuries as “storing a string” and “system calls” - none of that here, thank you. Instead, I added a new opcode mnemonic int 0x80 which sort of does what it should - it writes to screen the value (converted to character) of whatever is in the register eax. That’s helpful, but I still need
the assembly that will use that. This is where I feel I’ve actually hand-programmed something myself. This is a piece of code that could literally have been punched into a card
.jpg)
Punch card
The whole thing works, of course
hello_asm <- suppressWarnings(
readr::read_fwf(system.file("asm", "helloworld.asm", package = "rx86"),
col_types = "ccc",
col_positions = readr::fwf_widths(c(3, 3, 20)))
)
colnames(hello_asm) <- c("addr", "bytecode", "instr")
print(hello_asm)## # A tibble: 23 x 3
## addr bytecode instr
## <chr> <chr> <chr>
## 1 00 10 mov ecx, 0x0e
## 2 01 10 mov al, 0x08
## 3 02 10 mov eax, [al]
## 4 03 cc int 0x80
## 5 04 28 sub ecx, 0x01
## 6 05 70 jz 0x17
## 7 06 05 add al, 0x01
## 8 07 e9 jmp 0x02
## 9 08 48 data
## 10 09 65 data
## # … with 13 more rowsmem <- create_mem()
registers <- create_reg()
runasm(hello_asm)## Hello, world!and I find that honestly, ridiculously pleasing.
This, too, is included in the package as
vignette("helloworld", package = "rx86")I’m satisfied that {rx86} works, at least in some sense.
I’ve learned a lot along the way, and who knows, maybe I’ll add some more opcodes to the package. If you have some suggestions, please let me know!
devtools::session_info()
## ─ Session info ───────────────────────────────────────────────────────────────
## setting value
## version R version 4.0.3 (2020-10-10)
## os Pop!_OS 20.10
## system x86_64, linux-gnu
## ui X11
## language en_AU:en
## collate en_AU.UTF-8
## ctype en_AU.UTF-8
## tz Australia/Adelaide
## date 2021-12-23
##
## ─ Packages ───────────────────────────────────────────────────────────────────
## package * version date lib source
## base64enc 0.1-3 2015-07-28 [1] CRAN (R 4.0.3)
## blogdown 1.7 2021-12-19 [1] CRAN (R 4.0.3)
## bookdown 0.24 2021-09-02 [1] CRAN (R 4.0.3)
## bslib 0.3.1 2021-10-06 [1] CRAN (R 4.0.3)
## callr 3.5.1 2020-10-13 [1] CRAN (R 4.0.3)
## cli 3.1.0 2021-10-27 [1] CRAN (R 4.0.3)
## crayon 1.3.4 2017-09-16 [1] CRAN (R 4.0.3)
## desc 1.4.0 2021-09-28 [1] CRAN (R 4.0.3)
## devtools 2.3.2 2020-09-18 [1] CRAN (R 4.0.3)
## digest 0.6.27 2020-10-24 [1] CRAN (R 4.0.3)
## dplyr 1.0.2 2020-08-18 [1] CRAN (R 4.0.3)
## ellipsis 0.3.1 2020-05-15 [1] CRAN (R 4.0.3)
## evaluate 0.14 2019-05-28 [1] CRAN (R 4.0.3)
## fansi 0.4.1 2020-01-08 [1] CRAN (R 4.0.3)
## fastmap 1.1.0 2021-01-25 [1] CRAN (R 4.0.3)
## fs 1.5.0 2020-07-31 [1] CRAN (R 4.0.3)
## generics 0.1.0 2020-10-31 [1] CRAN (R 4.0.3)
## glue 1.4.2 2020-08-27 [1] CRAN (R 4.0.3)
## hms 0.5.3 2020-01-08 [1] CRAN (R 4.0.3)
## htmltools 0.5.2 2021-08-25 [1] CRAN (R 4.0.3)
## jquerylib 0.1.4 2021-04-26 [1] CRAN (R 4.0.3)
## jsonlite 1.7.2 2020-12-09 [1] CRAN (R 4.0.3)
## knitr 1.37 2021-12-16 [1] CRAN (R 4.0.3)
## lifecycle 1.0.1 2021-09-24 [1] CRAN (R 4.0.3)
## magrittr 2.0.1 2020-11-17 [1] CRAN (R 4.0.3)
## memoise 1.1.0 2017-04-21 [1] CRAN (R 4.0.3)
## pillar 1.4.7 2020-11-20 [1] CRAN (R 4.0.3)
## pkgbuild 1.2.0 2020-12-15 [1] CRAN (R 4.0.3)
## pkgconfig 2.0.3 2019-09-22 [1] CRAN (R 4.0.3)
## pkgload 1.1.0 2020-05-29 [1] CRAN (R 4.0.3)
## prettyunits 1.1.1 2020-01-24 [1] CRAN (R 4.0.3)
## processx 3.4.5 2020-11-30 [1] CRAN (R 4.0.3)
## ps 1.5.0 2020-12-05 [1] CRAN (R 4.0.3)
## purrr 0.3.4 2020-04-17 [1] CRAN (R 4.0.3)
## R6 2.5.0 2020-10-28 [1] CRAN (R 4.0.3)
## readr 1.4.0 2020-10-05 [1] CRAN (R 4.0.3)
## remotes 2.2.0 2020-07-21 [1] CRAN (R 4.0.3)
## rlang 0.4.10 2020-12-30 [1] CRAN (R 4.0.3)
## rmarkdown 2.11 2021-09-14 [1] CRAN (R 4.0.3)
## rprojroot 2.0.2 2020-11-15 [1] CRAN (R 4.0.3)
## rstudioapi 0.13 2020-11-12 [1] CRAN (R 4.0.3)
## rx86 * 0.1.0 2021-12-22 [1] local
## sass 0.4.0 2021-05-12 [1] CRAN (R 4.0.3)
## sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 4.0.3)
## stringi 1.5.3 2020-09-09 [1] CRAN (R 4.0.3)
## stringr 1.4.0 2019-02-10 [1] CRAN (R 4.0.3)
## testthat 3.0.1 2020-12-17 [1] CRAN (R 4.0.3)
## tibble 3.0.4 2020-10-12 [1] CRAN (R 4.0.3)
## tidyr 1.1.2 2020-08-27 [1] CRAN (R 4.0.3)
## tidyselect 1.1.0 2020-05-11 [1] CRAN (R 4.0.3)
## usethis 2.1.5 2021-12-09 [1] CRAN (R 4.0.3)
## utf8 1.1.4 2018-05-24 [1] CRAN (R 4.0.3)
## vctrs 0.3.6 2020-12-17 [1] CRAN (R 4.0.3)
## withr 2.3.0 2020-09-22 [1] CRAN (R 4.0.3)
## xfun 0.29 2021-12-14 [1] CRAN (R 4.0.3)
## yaml 2.2.1 2020-02-01 [1] CRAN (R 4.0.3)
##
## [1] /home/jono/R/x86_64-pc-linux-gnu-library/4.0
## [2] /usr/local/lib/R/site-library
## [3] /usr/lib/R/site-library
## [4] /usr/lib/R/library