Z80 register pairs - cpu-registers

I am fairly new to the Z80 and machine code, so please don't assume I know anything.
Basically, what I want to know is this: If you load register H with a value (I'll call it y), will HL then be 0xy0? e.g. if H was loaded with 0xAF would HL be 0xAF00?
And would the same be true for loading L with y?
Thanks in advance.

The H and L 8-bit registers can be treated independently. Loading a value in H, will not affect the value in L, and vice versa. The two registers H and L can also be treated as a 16-bit register pair. The following source FIRST STEPS IN MACHINE CODE describes this.
two single register transfers, e.g.
LD H, B
LD L, C
to copy BC into
HL.
and
You can, if you wish, load a register pair directly with a single
instruction, rather than use two instructions. From last time, you
will recall that the H and L, B and C, and D and E registers can be
paired such that they effectively can hold any number between 0 and
65535 (00 to FFFF hex). C, E, and L form the low byte of the pair,
while B, D, and H are the high bytes.

Related

Go Pointers pointing to different memory locations but updating same variable [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
Summary: a is pointing to a memory address of 0x40e020 which is assigned to b. c, is then assigned to b's memory location (or so I thought). When I print out the address of c &c it points to a different spot in memory 0x40c138.
package main
import (
"fmt"
)
func main() {
var a int = 42
b := &a
c := b
*c = 4
fmt.Println(a, b, &c) // output --> 4 0x40e020 0x40c138
}
Question: How is the pointer c updating a's value? I would expect a to print out 42, but the compiler spits out 4.
A picture might help. Here is (some of) the memory in your computer, around 0x40c138 through 0x40e020 or so:
+---------+ +---------+
????????: | * | (variable "b") 0x40c138: | * | (variable "c")
+----|----+ +----|----+
v ________________________________/
+---------+'
0x40e020: | 4 | (variable "a")
+---------+
Variables b and c both point to variable a. You print the value of variable b, which is 0x40e020, which is how we know where a itself lives in memory. You print the address of variable c, which is how we know where c itself lives in memory. You do not print the address of variable b so we are not sure where it lives, but we do know that b and c both point to a, so we can draw the arrow coming out of each one.
Since the arrow coming out of c points to a, writing through *c writes to a.
Let's break down exactly what's happening here:
var a int = 42
b := &a
c := b
You now have three variables, each with its own location in memory. a is an integer with the value 42. b and c each have the same value, which is the memory address of a.
*c = 4
This dereferences the pointer c and writes the value 4 to the memory location it points to, which is the memory location of a. This is why when printing a you see the value 4 - this line overwrites the value in a's memory location. That's the primary purpose of pointers - to allow multiple references to the same value in memory.
fmt.Println(a, b, &c) // output --> 4 0x40e020 0x40c138
This prints the value of a, the value of b (which is the address of a), and the address of c.
c prints the memory address of a. b is a variable that holds a's memory address and c is b (these variables hold the same value).
When you print &c, you print the memory address of the variable c which holds a's memory address.
The reason you can update a's value with c is because the * operator lets you access or follow the memory address c holds and update the value it is holding.

RSA decryption using only n e and c

I need to decrypt c and I was given only n, e and c and computing p and q or phi(n) would be close to impossible so what other alternatives do I have? I tried calculating p and q but I made very little progress with the search in the last 24 hours of continuous running the program.
These are the values I was given:
n: 58900433780152059829684181006276669633073820320761216330291745734792546625247
e: 65537
c: 56191946659070299323432594589209132754159316947267240359739328886944131258862
Also, in another challenge only c and n were given and the values were a lot bigger. Do you have any suggestions for that too?
Well, it seems that this question is CTF related, because the patterns of n, e, and c are weak numbers.
You can solve it with RsaCtfTool:
python RsaCtfTool -n 58900433780152059829684181006276669633073820320761216330291745734792546625247 -e 65537 --uncipher 56191946659070299323432594589209132754159316947267240359739328886944131258862
timctf{CENSORED}
https://www.dcode.fr/rsa-cipher
Try this one but it need p and q. So I use the hand calculator to find p and q.
Using Fact(n), ex: Fact(91)= 7x13, so p=7, q=13

CRC: false positive under some circumstances

Consider two computers A and B. A has uses G and B uses G' where G' != G and of different degrees. Computer A wants to send a data D and it uses CRC for that cause.
The claim says that there couldn't be a scenario where A sends a CRC-message corresponding to data D and computer B will accept it as a valid message. Why is that?
We know that computer A sends D*2^r XOR R (r is the degree of G) and computer B divides by G'. So in other words, why can't G', accidentally, divide D*2^r XOR R?
Obviously it has something to do with the fact that deg(G) != deg(G') but I didn't figure it out.
Thanks!

Julia : BLAS.gemm!() parameters

I want to use the BLAS package. To do so, the meaning of the two first parameters of the gemm() function is not evident for me.
What do the parameters 'N' and 'T' represent?
BLAS.gemm!('N', 'T', lr, alpha, A, B, beta, C)
What is the difference between BLAS.gemm and BLAS.gemm! ?
According to the documentation
gemm!(tA, tB, alpha, A, B, beta, C)
Update C as alpha * A * B + beta*C or the other three variants according to tA (transpose A) and tB. Returns the updated C.
Note: here, alpha and beta must be float type scalars. A, B and C are all matrices. It's up to you to make sure the matrix dimensions match.
Thus, the tA and tB parameters refer to whether you want to apply the transpose operation to A or to B before multiplying. Note that this will cost you some computation time and allocations - the transpose isn't free. (thus, if you were going to apply the multiplication many times, each time with the same transpose specification, you'd be better off storing your matrix as the transposed version from the beginning). Select N for no transpose, T for transpose. You must select one or the other.
The difference between gemm!() and gemv!() is that for gemm!() you already need to have allocated the matrix C. The ! is a "modify in place" signal. Consider the following illustration of their different uses:
A = rand(5,5)
B = rand(5,5)
C = Array(Float64, 5, 5)
BLAS.gemm!('N', 'T', 1.0, A, B, 0.0, C)
D = BLAS.gemm('N', 'T', 1.0, A, B)
julia> C == D
true
Each of these, in essence, perform the calculation C = A * B'. (Technically, gemm!() performs C = (0.0)*C + (1.0)*A * B'.)
Thus, the syntax for the modify in place gemm!() is a bit unusual in some respects (unless you've already worked with a language like C in which case it seems very intuitive). You don't have the explicit = sign like you frequently do when calling functions in assigning values in a high level object oriented language like Julia.
As the illustration above shows, the outcome of gemm!() and gemm() in this case is identical, even though the syntax and procedure to achieve that outcome is a bit different. Practically speaking, however, performance differences between the two can be significant, depending on your use case. In particular, if you are going to be performing that multiplication operation many times, replacing/updating the value of C each time, then gemm!() can be a decent bit quicker because you don't need to keep re-allocating new memory each time, which does have time costs, both in the initial memory allocation and then in the garbage collection later on.

Recursion in Towers of hanoi

I have read the Towers of Hanoi problem statement and the solution as well. The solution states that when you have to move a set of N disks from A to B, use C as temp and transfer N-1 disks from A to C. Then transfer Nth disk from A to B and then transfer the N-1 disks from C to B. I know that the problem has reduced in size and therefore a contender for implementation recursively. However, we cannot transfer more than 1 disk at a time. How can we transfer N-1 disks in the first place.
By using the recursion. See also Tower of Hanoi: Recursive Algorithm and the wikipedia page
The recursion is as follow: You know how to move 1 disc, suppose you know how to move n-1 discs, how do you move n discs?
The "suppose" part is your recursion: You move 10 discs by moving 9, then 1 then 9.
To move the 9 discs, you move 8, then 1, then 8.
To move the 8 discs...
...
To move the 2 discs, you move 1, then 1, then 1.
That's the recursive step. Transfer N-1 disks from A to C using the same algorithm that transfers N disks from A to B. If N is one, then simply move the single disk. (Or, equivalnently, if N is zero, do nothing).
In pseudocode:
move(N, A, B):
if (N > 0)
move(N-1, A, C)
move_single_disk(A, B)
move(N-1, C, B)

Resources