Welcome to novaBBS (click a section below)
|mail  files  register  nodelist  faq  login|
Herbert Kleebauer wrote:
On 12.11.2020 12:58, Bernhard Schornak wrote:Quite and simple because there are twice as much registers plus
-> RCX byte to convert (only the lowest byte is converted!)
I never understood the purpose of 64 bit assembly programming. 16 bit assembly
was fun. A .com file with nothing but CPU instructions (and maybe some BIOS calls).
But AMD (no V86 mode) and 64 bit Windows stole the fun.
32 bit code runs in 32 and 64 bit Windows, 64 bit code only in 64 bit Windows.
So, what is the advantage of 64 bit assembly code. Smaller? Faster? Or just
because 64 sounds better than 32?
an address room of 18,446,744,073,709,551,616 byte.
Definitely not. The new registers and the expansion of the old ones~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
B2hex byte => hexadecimal string
Why not a little bit more complex problem? The last assembly program I wrote
years ago was an AES encryption program as a replacement for a no longer usable
16 bit program. Not as small as the 16 bit code, but still not too big. Can
you get it much smaller with 64 bit code?
add prefix bytes, so even if you use exactly the same code, it will
grow in size when it is compiled as 64 bit program.
Size no longer matters for more than a decade now, because even low
class PCs have more than 4 GiBiByte. 8 GiBiByte is beginners level,
16 GiBiByte is standard, 32/64 GiBiByte are workstations, more than
that are 'gaming' (the synonym for "stupid people buying *anything*
their gurus tell 'em they must have").
What really matters is speed - gained by making use of the hardware
architecture as much as possible. This is the most important issue,
while size is something nobody really cares since Windows XP, Warty
Warthog 4.10, Mac OS X Snow Leopard 10.6, et cetera...
This batch will create the exe:Which is the crux - my code is optimised to feed all four execution
certutil -f -decode %~f0 aes32.exe>nul
aes32.exe : de-/encrypt stdin to stdout using AES algorithm
usage: aes32 password <infile >outfile
The password size is 256 bit (32 byte) and the password has to be
provided base64 encoded. This means you have to use 44 base64
characters (A-Z,a-z,0-9,+,/). If less than 44 characters are given,
the characters are repeated until 44 characters are reached. Any
non base64 character is ignored.
aes32 This_is_my_password <infile >outfile
is the same as:
aes32 This is my password <infile >outfile
aes32 Thisismypassword <infile >outfile
If a "-" character is used in the command line, encryption instead
of decryption is done.
If a "*" character is used in the command line, Electronic Codebook
mode (ECB) is used instead of Cipher Block Chaning (CBC).
You should not use ECB mode in normal usage but only to verify
the encryption using the example provided in the AES specification:
Plaintext (hex): 00112233445566778899aabbccddeeff
Key (hex): 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
Key (base64): AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=
Create an infile containing the above 16 byte input.
aes32 -*AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8= <infile >outfile
should give an outfile with:
8E A2 B7 CA 51 67 45 BF EA FC 49 90 4B 49 60 89
Note: the program is size and not speed optimized, so it is not very fast.
pipes of a Ryzen processor, so in the best case 4 instructions will
be executed simultaneously per clock cycle. This is the reason, why
the posted code executes in *much less* cycles than the instruction
count might suggest.
It is just a change in paradigms - at the beginning, size mattered,
because storage prices were the determining factor. Meanwhile, mass
media are in the Terabyte range and RAM is much cheaper than a CPU.
Up-to-date processors have at least 8 cores with two register sets,
allowing 'hyper threading'. Each core has multiple execution pipes,
allowing simultaneous execution of instructions.
Today, the challenge is to feed all pipes continuously, not to save
precious bytes to crunch the code down to fit into limited RAM - we
all had to write a lot of assembler code to fill up the 32 GiBiByte
installed in my current machine... ;)
On the other hand, there are few programmers who care about how the
code they write is executed, because modern "programming" languages
are separated from the hardware, and work on all machines where the
appropriate interpreter exists. That's the reason, why old compiled
programs run much faster than their new, Gigabyte filling brethren.
If our 'vertically moving dustbin' emits some more doctrines of his
"US Americans can't count"-religion, I consider to publish some en-
and decryption code used in my programming system. It does not emit
predictable output: Each encryption throws unique output, depending
on the input, only. (My point: I don't use AES, because I prefer my
own code. It surely isn't bullet proof, but it is too hard to break
it to sacrifice time for trying, even if that code was published 16
years ago and the algorithm itself is a very simple one...)
| Re: The best way to stay ON TOPIC|
By: Bernhard Schornak on Thu, 12 Nov 2020