Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  nodelist  faq  login

MESSAGE ACKNOWLEDGED -- The Pershing II missiles have been launched.


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

SubjectAuthor
* Re: The best way to stay ON TOPICBernhard Schornak
+* Re: The best way to stay ON TOPICwolfgang kern
|`* Re: The best way to stay ON TOPICBernhard Schornak
| `* Re: The best way to stay ON TOPICwolfgang kern
|  `- Re: The best way to stay ON TOPICBernhard Schornak
+* Re: The best way to stay ON TOPICKerr-Mudd,John
|`- Re: The best way to stay ON TOPICBernhard Schornak
`* Re: The best way to stay ON TOPICHerbert Kleebauer
 `* Re: The best way to stay ON TOPICBernhard Schornak
  `* Re: The best way to stay ON TOPICskybuck2000
   `* Re: The best way to stay ON TOPICBernhard Schornak
    +* Re: The best way to stay ON TOPICwolfgang kern
    |`- Re: The best way to stay ON TOPICBernhard Schornak
    `* Re: The best way to stay ON TOPICskybuck2000
     `- Re: The best way to stay ON TOPICBernhard Schornak

1
Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Thu, 12 Nov 2020 11:58 UTC
References: 1
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Thu, 12 Nov 2020 12:58:11 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <roj82o$3h1$1@dont-email.me>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Nov 2020 11:59:20 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="cc2d2afb4a2a9740ad41e48ef400b88b";
logging-data="3617"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BxSjQMnMmczQbh1kvnKY7oZclv6AlYXqRZwkO+Qs5QA=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.1
Cancel-Lock: sha1:sg8fadsSWSXdSA5gx189ce3017U=
In-Reply-To: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
            .text
            /*
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              B2hex    byte => hexadecimal string
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              -> RCX   byte to convert (only the lowest byte is converted!)
                 RDX   EA target
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              <- RAX   converted byte [00LH]
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              BUFFER   0               1               2
                       0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF

                       01zz
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              average latency ~ 6 clock cycles (Bulldozer)
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            */
            .p2align   5,,31
            .globl     _B2hex
            .def       _B2hex; .scl 2; .type 32; .endef
     _B2hex:movzb      %cl,                 %eax
            movq       %rbx,                0x08(%rsp)      # use reserved area...
            movq       %rcx,                0x10(%rsp)
            movq       %rdi,                0x18(%rsp)
            andl       $0x0F,               %ecx            # RCX = 000L
            shrl       $0x04,               %eax            # RAX = 000H
            addl       $0x30,               %ecx            # RAX = 003H
            addl       $0x30,               %eax            # ECX = 003L
            shll       $0x08,               %ecx            # RCX = 3L00
            leal       0x07(%eax),          %ebx            # RBX = 004H
            leal       0x0700(%ecx),        %edi            # RDI = 4L00
            cmpl       $0x39,               %eax            # A...F?
            cmova      %ebx,                %eax            # => use
            cmpl       $0x3900,             %ecx            # A...F?
            cmova      %edi,                %ecx            # => use
            movq       0x08(%rsp),          %rbx
            addl       %ecx,                %eax            # RAX = result
            movq       0x18(%rsp),          %rdi
            movl       %eax,                0x00(%rdx)      # store result
            movq       0x10(%rsp),          %rcx
            ret


Greetings from Augsburg

Bernhard Schornak


Subject: Re: The best way to stay ON TOPIC
From: wolfgang kern
Newsgroups: alt.lang.asm
Organization: KESYS-development
Date: Thu, 12 Nov 2020 13:57 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.G9NBDoonMFnXA12AKvjHxw.user.gioia.aioe.org!not-for-mail
From: nowh...@never.at (wolfgang kern)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Thu, 12 Nov 2020 14:57:01 +0100
Organization: KESYS-development
Lines: 64
Message-ID: <rojf05$sa6$1@gioia.aioe.org>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me>
Reply-To: nowhere@never.at
NNTP-Posting-Host: G9NBDoonMFnXA12AKvjHxw.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.4.3
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
View all headers
On 12.11.2020 12:58, Bernhard Schornak wrote:
            .text
            /*
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~               B2hex    byte => hexadecimal string
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~               -> RCX   byte to convert (only the lowest byte is converted!)
                 RDX   EA target
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~               <- RAX   converted byte [00LH]
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~               BUFFER   0               1               2
                       0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF

                       01zz
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~               average latency ~ 6 clock cycles (Bulldozer)
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~             */
            .p2align   5,,31
            .globl     _B2hex
            .def       _B2hex; .scl 2; .type 32; .endef
     _B2hex:movzb      %cl,                 %eax
            movq       %rbx,                0x08(%rsp)      # use reserved area...
            movq       %rcx,                0x10(%rsp)
            movq       %rdi,                0x18(%rsp)
            andl       $0x0F,               %ecx            # RCX = 000L
            shrl       $0x04,               %eax            # RAX = 000H
            addl       $0x30,               %ecx            # RAX = 003H
            addl       $0x30,               %eax            # ECX = 003L
            shll       $0x08,               %ecx            # RCX = 3L00
            leal       0x07(%eax),          %ebx            # RBX = 004H
            leal       0x0700(%ecx),        %edi            # RDI = 4L00
            cmpl       $0x39,               %eax            # A...F?
            cmova      %ebx,                %eax            # => use
            cmpl       $0x3900,             %ecx            # A...F?
            cmova      %edi,                %ecx            # => use
            movq       0x08(%rsp),          %rbx
            addl       %ecx,                %eax            # RAX = result
            movq       0x18(%rsp),          %rdi
            movl       %eax,                0x00(%rdx)      # store result
            movq       0x10(%rsp),          %rcx
            ret

cmova reg,reg   ??? what's the opcode for this (not listed in my docs)

or is this just a test to see if I'm still alive ?  :)

Servas,
__
wolfgang


Subject: Re: The best way to stay ON TOPIC
From: Kerr-Mudd,John
Newsgroups: alt.lang.asm
Organization: dis
Date: Thu, 12 Nov 2020 15:19 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: notsay...@127.0.0.1 (Kerr-Mudd,John)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Thu, 12 Nov 2020 15:19:03 -0000 (UTC)
Organization: dis
Lines: 61
Message-ID: <XnsAC739BD26B48Badmin127001@144.76.35.198>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com> <roj82o$3h1$1@dont-email.me>
Injection-Date: Thu, 12 Nov 2020 15:19:03 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="2e8c68bbf662cdd525a938b60bb1a8dd";
logging-data="25828"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18JWbvqEcJx4jR1rqFcAKhrQyW4b9omfhE="
User-Agent: Xnews/2009.05.01
Cancel-Lock: sha1:xAaYAVZW9ltbsmwTL5arCxA3VF8=
X-Clacks-Overhead: GNU Terry Pratchett
View all headers
On Thu, 12 Nov 2020 11:58:11 GMT, Bernhard Schornak <schornak@web.de>
wrote:

            .text
            /*
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              ~~~~~~~~~~~~~~~~~~~~~~~~~ B2hex    byte => hexadecimal
              string
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              ~~~~~~~~~~~~~~~~~~~~~~~~~ -> RCX   byte to convert (only
              the lowest byte is converted!)
                 RDX   EA target
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              ~~~~~~~~~~~~~~~~~~~~~~~~~ <- RAX   converted byte [00LH]
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              ~~~~~~~~~~~~~~~~~~~~~~~~~ BUFFER   0               1   
                        2
                       0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF

                       01zz
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              ~~~~~~~~~~~~~~~~~~~~~~~~~ average latency ~ 6 clock
              cycles (Bulldozer)
              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              ~~~~~~~~~~~~~~~~~~~~~~~~~
            */
            .p2align   5,,31
            .globl     _B2hex
            .def       _B2hex; .scl 2; .type 32; .endef
     _B2hex:movzb      %cl,                 %eax
            movq       %rbx,                0x08(%rsp)      # use
            reserved area... movq       %rcx,              
            0x10(%rsp) movq       %rdi,                0x18(%rsp)
            andl       $0x0F,               %ecx            # RCX =
            000L shrl       $0x04,               %eax            # RAX
            = 000H addl       $0x30,               %ecx            #
            RAX = 003H addl       $0x30,               %eax          
            # ECX = 003L shll       $0x08,               %ecx        
              # RCX = 3L00 leal       0x07(%eax),          %ebx      
                # RBX = 004H leal       0x0700(%ecx),        %edi    
                  # RDI = 4L00 cmpl       $0x39,               %eax  
                    # A...F? cmova      %ebx,                %eax    
                  # => use cmpl       $0x3900,             %ecx      
                # A...F? cmova      %edi,                %ecx        
              # => use movq       0x08(%rsp),          %rbx
            addl       %ecx,                %eax            # RAX =
            result movq       0x18(%rsp),          %rdi
            movl       %eax,                0x00(%rdx)      # store
            result movq       0x10(%rsp),          %rcx
            ret


Greetings from Augsburg

Bernhard Schornak


Nice to see some asm (even if it's not nasm 8086!)

--
Bah, and indeed, Humbug.


Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Thu, 12 Nov 2020 16:22 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Thu, 12 Nov 2020 17:22:34 +0100
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <rojnie$mqj$1@dont-email.me>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me> <rojf05$sa6$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 12 Nov 2020 16:23:42 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="cc2d2afb4a2a9740ad41e48ef400b88b";
logging-data="23379"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wmiCF0QhD189hlh8tOjvNYcaRCBXQPE9LCwcU6mHSfg=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.1
Cancel-Lock: sha1:InTiKwQkjAMqwA/ku2eg1v5Aqkg=
In-Reply-To: <rojf05$sa6$1@gioia.aioe.org>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
wolfgang kern wrote:


On 12.11.2020 12:58, Bernhard Schornak wrote:

<snip>
            cmova      %ebx,                %eax            # => use
            cmpl       $0x3900,             %ecx            # A...F?
            cmova      %edi,                %ecx            # => use

cmova reg,reg   ??? what's the opcode for this (not listed in my docs)

or is this just a test to see if I'm still alive ?  :)


CMOVA is the same as

CMOVNBE reg16, reg/mem16
CMOVNBE reg32, reg/mem32
CMOVNBE reg64, reg/mem64

0F 47 /r          Move if not below or equal (CF = 0 and ZF = 0)

The best way to write branch free code. Should be faster on
Ryzen, but I never tested it again since I wrote that code.


Pfüat'Di

Bernhard


Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Thu, 12 Nov 2020 16:23 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Thu, 12 Nov 2020 17:23:07 +0100
Organization: A noiseless patient Spider
Lines: 18
Message-ID: <rojnjf$mqj$2@dont-email.me>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me> <XnsAC739BD26B48Badmin127001@144.76.35.198>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Nov 2020 16:24:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="cc2d2afb4a2a9740ad41e48ef400b88b";
logging-data="23379"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18rl89nxUQZHH6ZdAOrcn0hZq+Ou3FfMJjC7EndTQqJyg=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.1
Cancel-Lock: sha1:ZXLyvtDh3m1bviBnC+vihBfnpKw=
In-Reply-To: <XnsAC739BD26B48Badmin127001@144.76.35.198>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
Kerr-Mudd,John wrote:


On Thu, 12 Nov 2020 11:58:11 GMT, Bernhard Schornak <schornak@web.de>
wrote:

 <snip>

Nice to see some asm (even if it's not nasm 8086!)


Sorry, but I only know 'as' x86-64 slang. Maybe I learn the
really cool programming languages in my next life? ;)


Greetings from Augsburg

Bernhard Schornak


Subject: Re: The best way to stay ON TOPIC
From: Herbert Kleebauer
Newsgroups: alt.lang.asm
Organization: Aioe.org NNTP Server
Date: Thu, 12 Nov 2020 21:27 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.UtLocSGoFZHBjInbSXe2hg.user.gioia.aioe.org!not-for-mail
From: kle...@unibwm.de (Herbert Kleebauer)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Thu, 12 Nov 2020 22:27:29 +0100
Organization: Aioe.org NNTP Server
Lines: 138
Message-ID: <rok9c0$20j$1@gioia.aioe.org>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me>
NNTP-Posting-Host: UtLocSGoFZHBjInbSXe2hg.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.4.3
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
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?

 >                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 >                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?

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.


Subject: Re: The best way to stay ON TOPIC
From: wolfgang kern
Newsgroups: alt.lang.asm
Organization: KESYS-development
Date: Fri, 13 Nov 2020 05:08 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!aioe.org!.POSTED.G9NBDoonMFnXA12AKvjHxw.user.gioia.aioe.org!not-for-mail
From: nowh...@never.at (wolfgang kern)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Fri, 13 Nov 2020 06:08:29 +0100
Organization: KESYS-development
Lines: 31
Message-ID: <rol4d6$t7s$1@gioia.aioe.org>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me> <rojf05$sa6$1@gioia.aioe.org>
<rojnie$mqj$1@dont-email.me>
Reply-To: nowhere@never.at
NNTP-Posting-Host: G9NBDoonMFnXA12AKvjHxw.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.4.3
Content-Language: en-US
X-Notice: Filtered by postfilter v. 0.9.2
View all headers
On 12.11.2020 17:22, Bernhard Schornak wrote:
wolfgang kern wrote:


On 12.11.2020 12:58, Bernhard Schornak wrote:

<snip>
            cmova      %ebx,                %eax            # => use
            cmpl       $0x3900,             %ecx            # A...F?
            cmova      %edi,                %ecx            # => use

cmova reg,reg   ??? what's the opcode for this (not listed in my docs)

or is this just a test to see if I'm still alive ?  :)


CMOVA is the same as

CMOVNBE reg16, reg/mem16
CMOVNBE reg32, reg/mem32
CMOVNBE reg64, reg/mem64

0F 47 /r          Move if not below or equal (CF = 0 and ZF = 0)

The best way to write branch free code. Should be faster on
Ryzen, but I never tested it again since I wrote that code.

Yes of course, my memory messed it with the not existing CMOV reg,imm
Servas,
__
wolfgang


Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Fri, 13 Nov 2020 12:48 UTC
References: 1 2 3 4 5
Path: i2pn2.org!i2pn.org!aioe.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Fri, 13 Nov 2020 13:48:10 +0100
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <rolvcg$p09$1@dont-email.me>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me> <rojf05$sa6$1@gioia.aioe.org>
<rojnie$mqj$1@dont-email.me> <rol4d6$t7s$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 13 Nov 2020 12:49:20 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="da5c44991b5672b8aff512499c97f4ea";
logging-data="25609"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ajzOjET2Is39CnyrHNSFpzvG+ShRtpgtDQxbwWErVvQ=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.1
Cancel-Lock: sha1:Lw89tGWOIMeGccvrpuaqTxzWzSw=
In-Reply-To: <rol4d6$t7s$1@gioia.aioe.org>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
wolfgang kern wrote:


Yes of course, my memory messed it with the not existing CMOV reg,imm


Which still is on my wish-list, too!


Pfüat'Di

Bernhard


Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Fri, 13 Nov 2020 12:48 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Fri, 13 Nov 2020 13:48:41 +0100
Organization: A noiseless patient Spider
Lines: 199
Message-ID: <rolvdf$p09$2@dont-email.me>
References: <4c3ad920-2a44-4aad-adbb-695d379a2648n@googlegroups.com>
<roj82o$3h1$1@dont-email.me> <rok9c0$20j$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 13 Nov 2020 12:49:51 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="da5c44991b5672b8aff512499c97f4ea";
logging-data="25609"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fAJQTM0sbz27n5uM1YiYLdfgxkWAoI70aQB27dKsjCQ=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.1
Cancel-Lock: sha1:P/Hpfffr6knV1sYOfDsIOKCF0Go=
In-Reply-To: <rok9c0$20j$1@gioia.aioe.org>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
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... ;)

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


Greetings from Augsburg

Bernhard Schornak


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

Click here to read the complete article
Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Sat, 14 Nov 2020 16:03 UTC
References: 1 2 3 4 5
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Sat, 14 Nov 2020 17:03:23 +0100
Organization: A noiseless patient Spider
Lines: 96
Message-ID: <roov6j$ck9$1@dont-email.me>
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>
<f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 14 Nov 2020 16:04:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="af6fd57fa6f4e8ed19e30710ff57297a";
logging-data="12937"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/k1uFZ0DeOpGFiVEfKmIUUcFV9AQrKZbpBpxzWv0FL7A=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.1
Cancel-Lock: sha1:zp0rMM3W1HsXiZL8CXr3YW4ohec=
In-Reply-To: <f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
skybuck2000 wrote:


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:

<snip>

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 ?!


By reading the documentation and the optimisation guides, where AMD
tells us how many clock cycles an instruction needs to be executed,
and which execution pipe can handle which kind of instruction.


How can you be sure ?


I just use the strange equipotential ellipsoid on top of my cervix.
Seems to hold the control center of my body. (Might differ from one
lifeforms to another...)


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 ???


You will not get far with timing. I do this in my mind, but you can
draw a table with one column for each physical execution pipe, then
add as many rows as required to fill it with your code. Now fill as
many vertical boxes in the column as the current instruction needs.
Continue horizontally, until all columns were filled, then start at
the next free box at the leftmost column, again.

I hope, this explanation helps to understand the big picture.


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


AES is not really safe. I remember an article showing that it might
be hacked quite easily:

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

It is an older paper, so the conclusions might be outdated.

My (old) algorithm uses a 4,096 byte key which 'interacts' with the
input, so two identical bytes from the input probably will generate
two different output bytes (not necessarily, but most times).


Enjoy the weekend!

Bernhard Schornak


Subject: Re: The best way to stay ON TOPIC
From: wolfgang kern
Newsgroups: alt.lang.asm
Organization: KESYS-development
Date: Mon, 16 Nov 2020 23:33 UTC
References: 1 2 3 4 5 6
Path: i2pn2.org!i2pn.org!aioe.org!Er9Bhk9Ba/QqGzsJVhRIag.user.gioia.aioe.org.POSTED!not-for-mail
From: nowh...@never.at (wolfgang kern)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Tue, 17 Nov 2020 00:33:01 +0100
Organization: KESYS-development
Lines: 11
Message-ID: <rov28b$1p5a$1@gioia.aioe.org>
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>
<f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com>
<roov6j$ck9$1@dont-email.me>
Reply-To: nowhere@never.at
NNTP-Posting-Host: Er9Bhk9Ba/QqGzsJVhRIag.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.4.3
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: en-US
View all headers
On 14.11.2020 17:03, Bernhard Schornak wrote:
skybuck2000 wrote:
How can you be sure ?

I just use the strange equipotential ellipsoid on top of my cervix.
Seems to hold the control center of my body. (Might differ from one
lifeforms to another...)

:) I pissed myself by LMFAO
__
wolfgang


Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Wed, 18 Nov 2020 20:38 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Wed, 18 Nov 2020 21:38:10 +0100
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <rp40pu$d9a$1@dont-email.me>
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>
<f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com>
<roov6j$ck9$1@dont-email.me> <rov28b$1p5a$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 18 Nov 2020 20:39:26 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="89d1c53681645d3c6133fb1833cfcd24";
logging-data="13610"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18QdQ/D26VTcRPWv5UxCDNQo9k+iclbpUbs+C8EKlZIbw=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.4
Cancel-Lock: sha1:wU0nRz8P654CuoVSSQriABi+2s8=
In-Reply-To: <rov28b$1p5a$1@gioia.aioe.org>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
wolfgang kern wrote:


On 14.11.2020 17:03, Bernhard Schornak wrote:
skybuck2000 wrote:
How can you be sure ?

I just use the strange equipotential ellipsoid on top of my cervix.
Seems to hold the control center of my body. (Might differ from one
lifeforms to another...)

:) I pissed myself by LMFAO


....while I found a typo: Obviously, it should have been
"lifeform", not the plural "lifeforms" - double reading
sometimes seems to be not enough... ;)


Pfüat'Di

Bernhard


Subject: Re: The best way to stay ON TOPIC
From: skybuck2000
Newsgroups: alt.lang.asm
Date: Fri, 20 Nov 2020 22:07 UTC
References: 1 2 3 4 5 6
X-Received: by 2002:ac8:3a84:: with SMTP id x4mr8406498qte.55.1605910041843; Fri, 20 Nov 2020 14:07:21 -0800 (PST)
X-Received: by 2002:aca:4849:: with SMTP id v70mr8169670oia.103.1605910041593; Fri, 20 Nov 2020 14:07:21 -0800 (PST)
Path: i2pn2.org!i2pn.org!aioe.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr2.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: alt.lang.asm
Date: Fri, 20 Nov 2020 14:07:20 -0800 (PST)
In-Reply-To: <roov6j$ck9$1@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> <f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com> <roov6j$ck9$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8722883f-c155-416b-804d-50c244fddf48n@googlegroups.com>
Subject: Re: The best way to stay ON TOPIC
From: skybuck2...@hotmail.com (skybuck2000)
Injection-Date: Fri, 20 Nov 2020 22:07:21 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 97
View all headers
On Saturday, November 14, 2020 at 5:04:37 PM UTC+1, Bernhard Schornak wrote:
skybuck2000 wrote:


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:

<snip>

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 ?!
By reading the documentation and the optimisation guides, where AMD
tells us how many clock cycles an instruction needs to be executed,
and which execution pipe can handle which kind of instruction.
How can you be sure ?
I just use the strange equipotential ellipsoid on top of my cervix.
Seems to hold the control center of my body. (Might differ from one
lifeforms to another...)
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 ???
You will not get far with timing. I do this in my mind, but you can
draw a table with one column for each physical execution pipe, then
add as many rows as required to fill it with your code. Now fill as
many vertical boxes in the column as the current instruction needs.
Continue horizontally, until all columns were filled, then start at
the next free box at the leftmost column, again.

I hope, this explanation helps to understand the big picture.
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
AES is not really safe. I remember an article showing that it might
be hacked quite easily:

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

It is an older paper, so the conclusions might be outdated.

My (old) algorithm uses a 4,096 byte key which 'interacts' with the
input, so two identical bytes from the input probably will generate
two different output bytes (not necessarily, but most times).


Enjoy the weekend!

Bernhard Schornak

Interesting document.

I have one little question about it though, this seem to be a "draft" or "beta" version of this document.

Is there a final version ? And why not post it if there is a final version ?

Was the final version may redacted to remove vunerabilities ?

Is the final version not as good in details ?

Wondering...

Bye,
  Skybuck.


Subject: Re: The best way to stay ON TOPIC
From: Bernhard Schornak
Newsgroups: alt.lang.asm
Organization: A noiseless patient Spider
Date: Sat, 21 Nov 2020 00:19 UTC
References: 1 2 3 4 5 6 7
Path: i2pn2.org!i2pn.org!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: schor...@web.de (Bernhard Schornak)
Newsgroups: alt.lang.asm
Subject: Re: The best way to stay ON TOPIC
Date: Sat, 21 Nov 2020 01:19:54 +0100
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <rp9mfd$699$1@dont-email.me>
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>
<f49ce65e-23e8-4b24-bf14-3d704acaff66n@googlegroups.com>
<roov6j$ck9$1@dont-email.me>
<8722883f-c155-416b-804d-50c244fddf48n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 21 Nov 2020 00:19:57 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="3e769eb7895c0e4e021e4d81886bd1d9";
logging-data="6441"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/T51hPlN14+Apzrur/WzQVXTNRh3ynVRkq02cO2ir+9w=="
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101
Firefox/60.0 SeaMonkey/2.53.4
Cancel-Lock: sha1:nTrld60K0QyKo836kpGMWMhfn2o=
In-Reply-To: <8722883f-c155-416b-804d-50c244fddf48n@googlegroups.com>
X-Mozilla-News-Host: news://news.eternal-september.org
View all headers
skybuck2000 wrote:


Bernhard Schornak wrote:
skybuck2000 wrote:
Bernhard Schornak wrote:
Herbert Kleebauer wrote:
Bernhard Schornak wrote:

<snip>

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
AES is not really safe. I remember an article showing that it might
be hacked quite easily:

http://cr.yp.to/antiforgery/cachetiming-20050414.pdf

It is an older paper, so the conclusions might be outdated.

My (old) algorithm uses a 4,096 byte key which 'interacts' with the
input, so two identical bytes from the input probably will generate
two different output bytes (not necessarily, but most times).

Interesting document.

I have one little question about it though, this seem to be a "draft" or "beta" version of this document.

Is there a final version ? And why not post it if there is a final version ?

Was the final version may redacted to remove vunerabilities ?

Is the final version not as good in details ?

Wondering...


I stored that document when I gathered material about encryption
algorithms, and searched just for the title as part of my reply.
I neither know if there's any other document nor what the author
did publish since then.


Enjoy the weekend!

Bernhard Schornak


P.S.: No one hinders you to start your own research... ;)


1
rocksolid light 0.7.2
clearneti2ptor