Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

As of next Thursday, UNIX will be flushed in favor of TOPS-10. Please update your programs.


programming / alt.lang.asm / Re: The best way to stay ON TOPIC

Subject: Re: The best way to stay ON TOPIC
From: skybuck2000
Newsgroups: alt.lang.asm
Date: Sat, 14 Nov 2020 13:58 UTC
References: 1 2 3 4
X-Received: by 2002:a37:8c05:: with SMTP id o5mr6751422qkd.396.1605362309330;
Sat, 14 Nov 2020 05:58:29 -0800 (PST)
X-Received: by 2002:a05:6830:1af7:: with SMTP id c23mr4714316otd.358.1605362308723;
Sat, 14 Nov 2020 05:58:28 -0800 (PST)
Path: i2pn2.org!i2pn.org!aioe.org!peer01.ams4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Sat, 14 Nov 2020 05:58:28 -0800 (PST)
In-Reply-To: <rolvdf$p09$2@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=84.25.43.167; posting-account=np6u_wkAAADxbE7UBGUIOm-csir6aX02
NNTP-Posting-Host: 84.25.43.167
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me> <rok9c0$20j$1@gioia.aioe.org> <rolvdf$p09$2@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com>
Subject: Re: The best way to stay ON TOPIC
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Sat, 14 Nov 2020 13:58:29 +0000
Content-Type: text/plain; charset="UTF-8"
X-Received-Bytes: 11489
X-Received-Body-CRC: 3476559869
View all headers
On Friday, November 13, 2020 at 1:49:53 PM UTC+1, Bernhard Schornak wrote:
Herbert Kleebauer wrote:


On 12.11.2020 12:58, Bernhard Schornak wrote:

-> 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?
Quite and simple because there are twice as much registers plus
an address room of 18,446,744,073,709,551,616 byte.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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?
Definitely not. The new registers and the expansion of the old ones
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.

But:

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:

@echo off
certutil -f -decode %~f0 aes32.exe>nul
goto :eof

-----BEGIN CERTIFICATE-----
TVpgAQEAAAAEAAAA//8AAGABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAoAAAAA4fug4AtAnNIbgBTM0hTmljZSB0byBtZWV0IHNvbWVi
b2R5IHdobyBpcyBzdGlsbCB1c2luZyBET1MsDQpidXQgaGlzIHByb2dyYW0gcmVx
dWlyZXMgV2luMzIuDQokAFBFAABMAQEAUHmlNgAAAAAAAAAA4AAPAQsBBQwACAAA
AAAAAAAAAACuEAAAABAAAAAgAAAAAEAAABAAAAACAAAEAAAAAAAAAAQAAAAAAAAA
ACAAAAACAAAAAAAAAwAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAAAAAAAAAAAAAA
GBAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAYAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALnRleHQAAACUCwAAABAAAAAIAAAAAgAA
AAAAAAAAAAAAAAAAIAAA4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABmEAAAeBAAAIYQAACWEAAA
ohAAAAAAAABOEAAAAAAAAAAAAABAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
S0VSTkVMMzIuZGxsAABmEAAAeBAAAIYQAACWEAAAohAAAAAAAAAAAEdldENvbW1h
bmRMaW5lQQAAAEV4aXRQcm9jZXNzAAAAR2V0U3RkSGFuZGxlAAAAAFJlYWRGaWxl
AAAAAFdyaXRlRmlsZQD/FQAQQACJxjHSv5QWQACsCMB0ZDwidQL30gnSdfE8IHXt
McmB/8AWQABza6wIwHRHPC11BYPJAevqPCp1BYPJAuvhPCt1BLA+6yo8L3UEsD/r
Ijwwcs08OXcELPzrFjxBcsE8WncELEHrCjxhcrU8enexLEeq66yJDXAWQAC+lBZA
ADn3dQXptAIAAIH/wBZAAHMDpOv1vpQWQACJ97kLAAAArcDkAmbBwALByAjA5ALA
6ARmwcAEwcgICODBwBCJB4PHA+LcugAAAAC5/wAAAInTic0xwNHtcwIx2HQE0ePr
9LuAjQAAPf8AAAB2DonFMdg56HICiejR6+vrPAF0AuLOux8AAAC4YwAAANHpcwYx
2NDD6/Z1+oiQhBhAAIiChBdAAP7CdaO+lBZAALoBAAAAvyAAAAC7hBdAAItEN/z3
xx8AAAB1HMHICLkEAAAA18HICOL698cfAAAAdQ4x0NHi6wj3xw8AAAB03zNEN+CJ
BDeDxwSB/+wAAAB2vrkAAQAAuwAAAAC4AQAAAOsPjRQAMdD2xP90BTUbAQAAiIOE
GUAAiJiEGkAAQ+LixgWFGkAAAKFwFkAASA+I3wAAAEgPiH4AAABIeCjofwEAAIM9
aBZAAAB0aOgBAgAA6KsBAACDPWgWQAAQdN/opQEAAOtO6FcBAACDPWgWQAAQdUDo
OQIAAOg8AQAAgz1oFkAAAHQogz1oFkAAEHUY6GwBAAC+hBZAAL90FkAAuQQAAADz
pevM6FwBAADrBehNAQAA6foAAAAPMaN0FkAAiRV4FkAA6IcBAADoMQEAAOjlAAAA
gz1oFkAAAHTWvoQWQAC/dBZAALkEAAAArTEHg8cE4vjoWAEAAOgCAQAAgz1oFkAA
EA+ExP///+j4AAAA66HoogAAAIM9aBZAABB1k+icAAAA/zV0FkAA/zV4FkAA/zV8
FkAA/zWAFkAA6G8BAAC+hBZAAL90FkAAuQQAAACtMQeDxwTi+OhbAAAAgz1oFkAA
AHRDgz1oFkAAEHUw6IsAAAC+hBZAAL90FkAAuQQAAADzpY8FkBZAAI8FjBZAAI8F
iBZAAI8FhBZAAOuFg8QQ6GAAAADrCIPEEOhOAAAAUP8VBBBAAGC9hBZAAOsGYL10
FkAAMcADBWAWQAB1DWr2/xUIEEAAo2AWQABqAGhoFkAAahBVUP8VDBBAAAnAdQrH
BWgWQAAAAAAAYZDDYL0QAAAA6wdgiy1oFkAAMcADBWQWQAB1DWr1/xUIEEAAo2QW
QABqAGhsFkAAVWh0FkAAUP8VEBBAAAnAdQhqAP8VBBBAADktbBZAAHXwYZDDxwWM
G0AAvRVAAMcFiBtAABQWQADHBZAbQACEF0AAxwWEG0AAAAAAAOiTAAAA/wWEG0AA
6KoAAADoxwAAAIE9hBtAAA4AAAB0BegCAQAA6G0AAACBPYQbQAAOAAAAcs7DxwWM
G0AAzRVAAMcFiBtAACQWQADHBZAbQACEGEAAxwWEG0AADgAAAOgzAAAA/w2EG0AA
6GwAAADoRQAAAOgeAAAAgT2EG0AAAAAAAHQR6J0AAACBPYQbQAAAAAAAdc7DizWE
G0AAweYEjbaUFkAAv3QWQAC5BAAAAK0xB4PHBOL4w4sdkBtAAL90FkAAvQQAAACL
B7kEAAAA18HACOL6q01178O7dBZAAIs1jBtAAL0EAAAAuQQAAADBwAis1+L5UE11
8LkEAAAAid9Yq+L8wwsGAQwHAg0IAw4JBA8KBQADBgkMDwIFCAsOAQQHCg0Av3QW
QAC5BAAAAFGLNYgbQAC5BAAAAMHjCL0DAAAArIoUL+gwAAAAMMNNefLi6Ikfg8cE
WeLUwwIBAQMDAgEBAQMCAQEBAwIOCQ0LCw4JDQ0LDgkJDQsOJf8AAAB0HoHi/wAA
AHQWioCEGkAAAoKEGkAAg9AAioCEGUAAwzHAwwAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAA==
-----END CERTIFICATE-----


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.

This means;

aes32 This_is_my_password <infile >outfile

is the same as:

aes32 This is my password <infile >outfile

or:

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.
Which is the crux - my code is optimised to feed all four execution
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... ;)


How do you know if your code fills all the execution units ?!

How can you be sure ?

Ofcourse one can time it and such but do you perhaps use any other tools to make sure it does what you think it does ???

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...)

I know AES ECB mode cannot encrypt pictures well, contours can still be recgonized.

I wonder if NSA picked Ryndael/AES because it was weak in this sense !

So seeing all these nasty NSA/CIA projects has casted big doubts on AES for me personally ! ;) =D

Bye,
  Skybuck =D



SubjectRepliesAuthor
o Re: The best way to stay ON TOPIC

By: Bernhard Schornak on Thu, 12 Nov 2020

14Bernhard Schornak
rocksolid light 0.7.2
clearneti2ptor