Rabbit + Coder + encode-Skript

[Helmut Schellong]

Ich bin mächtig zufrieden!
Mein Verschlüsselungs-Skript ist fertig.

Ich kann 'rabbit.bish datei.c rcrccc' angeben, wenn ich will, um zwei
verschiedene Encoder 6-mal arbeiten zu lassen.
Das Ziel hat dann z.B. den Namen: 'datei.c.ercrccc'.

Zum Dekodieren wird die Endung isoliert und umgedreht: cccrcr
und es wird auch mit umgedrehten Schlüssel-Reihenfolgen gearbeitet.

Niemand - auch die NSA nicht - wird meine multiple Verschlüsselung knacken können.


497] rabbit.bish rabbit.c rc
in-file: rabbit.c
sha256 rabbit.c ...
SHA256 (rabbit.c) = d40bf735f3a149f52976a6fa82e38fc64d29d676ee437908cd91527990a724bb
rabbit: 5814 Bytes
coder -en -c C[ic] /usr/rabb2894a /usr/rabb2894b ...
RENAME: /usr/rabb2894b
TO: /usr/rabbit.c.erc
UNLINK: /usr/rabb2894a

498] rabbit.bish /usr/rabbit.c.erc d
in-file: /usr/rabbit.c.erc
coder -d -c C[ic] /usr/rabbit.c.erc /usr/rabb2898a ...
rabbit: 5814 Bytes
RENAME: /usr/rabb2898b
TO: /usr/rabbit.c
sha256 /usr/rabbit.c ...
SHA256 (/usr/rabbit.c) = d40bf735f3a149f52976a6fa82e38fc64d29d676ee437908cd91527990a724bb
UNLINK: /usr/rabb2898a

Uc.m1][!i/l_x!M]8q}ng|fU_[%@hcLm~\%B/_v[%M8eFj6.ytI8rfTmoQD]KiK}J]@;[]
cIUlmyh;~~a2TcnJV`;`v8QhdJa688[ebiLKv1y~9g\8cI-@,8rd<K2ejxn9WJt\;V^%wT
LI^]aM}GxL_~~[9didVvUq\Ks[gyhVoo6D\t8r}F2Hsj|<jTha_ca}8`wIBmGo2b@.8_;V
jjsBm8f|ja~J%WK6DgbryQi,ign2lG(WhaW9[ydte1v}8EoiU;o1lQx,~9(}iig/l;DC91
WI,MD;eQW`b9UC~Uy,V6CaicM,mDJtJi9}x]@~}}lmhDc`aV,Ixr|v!KIy!eMytf2-I/Dy
ecVmE<g;WB-.3sG6<Bv6G3Csfd%ElDyILV(r-B3.eQ\LHEGf.VT1neBD`cUeh^(I6e-]x^
M}6sgUiIr/9c][;cmUW9Dyvmi<l^(9V(}92t<LGUWDy9K[FEm<Hg<;igDo2[qjKmyymyHr
lFg[Lh,e_~oWd2[|m~KC3g}%aFLj_Es/3q@BBWKI^M6|`,I][yt99(o8fD9xFqGc[;G/]2
f_e[H<WyI9d8}UhM}Vfd/jDLiIVvv^Qmxt`_m1]@w}^<Wg,wbKr6`.\`w_@@,e^E@xa8rm
mh/FbiFgch[\i<%Cttn3fW](e\rL~9n|!bHfTblFQhT98@.x(;CoK1ffJDnC!_.n(Hr3F]
TyF2rQVhnwj`[%CoTtdCsonx3Eo3fG\gJT;jDa,nwc^vw_sq}~TEf^[w8eCKD<~wi%^|tm
eCgL(9<gdV^B.!naGW/acmBbK9HJL8w.y;.wTy(/gH6.ov%,`[n9MhEertx6Mi9C\/<-<9
Ww6`3t|V}39Ci^xjMqqws-J-W3c1CdgGEoIW\WViyyDK@%Ct6Kv,[I%U-g@KBK8t([e`|W
HeT|CL[WIx!93fmU.T-%b2L~!Lab8b;v@eU2GHQD!x2ij`adU`m`g;dc%WD\KwT6w]cjq3
nB!q!y[[Qd(x|6t(KbW(mF/`odWj63f\v;KBDHG/H;\9m!e-nL@],dHUCcetnrGGcEhVEB
~MJcq^qmV.Vjl.,V@cy}6`fC|v%.<t^1.xoogceKh\%\<Ist/J6_Lbw8]qw}V<ccwHotrl
6ibGy-Tix(6gBiVJ.w^Udw-[V/CQd]dmrdd@o\e1]fQy9Jgt.@2UsijT\!6V9F8arFC21v
3mTCosU/tD1%|bJTtcn;tl8f~xDCv/<In^;V}ym~H]E<_jfI;C@fwEE,V\gfj\exKn[L[-
,E~~^23MJwc<}B`BHnVWB6Ca,lFJh!VnCL|9(@qsM}cm8WUgsFVn@DoUmj^]m|\F\hngwg
g^JI}T|VGU\-_KE_GUbff6G.1`LcmryJ96_K!2%9f^ebUttF]W((1nTlvj~TqxgU\GbQd;
n,|qKw^jxnsx^s!h1T,m.<gKI_Q.mW~8B.%9%J;TB/<lx[UKdQK~%qCo6`_~e1<x69gIBt
jvELGl@U~h1]ie^;KraW|j8UTagt|d`j^ab!G|%QUhFL!!|8L6t6sV%r..}9`J~]|i\onJ
9b~Q\(VFwxe@sdI1(Hh2ao!_}3Mi]^weqjy}jGeEL/|i!d,Fa(UFt-LfrnLv8(K;ehaG3w
redc9o%K,%Q2g|ML1-Et/(tTBG`w1.yQsDV|6G1sVI~v~q;wx(is2c.vxE,TDrEr~,(qeF


--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
http://www.schellong.de/c.htm http://www.schellong.de/c2x.htm http://www.schellong.de/c_padding_bits.htm
http://www.schellong.de/htm/bishmnk.htm http://www.schellong.de/htm/rpar.bish.html http://www.schellong.de/htm/sieger.bish.html
http://www.schellong.de/htm/audio_proj.htm http://www.schellong.de/htm/audio_unsinn.htm http://www.schellong.de/htm/tuner.htm
http://www.schellong.de/htm/string.htm http://www.schellong.de/htm/string.c.html
http://www.schellong.de/htm/schaltungen.htm http://www.schellong.de/htm/rand.htm http://www.schellong.de/htm/bsd.htm

[jo...@schily.net]

In article <sdsj36$dui$1...@solani.org>,

Helmut Schellong <r...@schellong.biz> wrote:
>
>Ich bin mächtig zufrieden!
>Mein Verschlüsselungs-Skript ist fertig.
>
>Ich kann 'rabbit.bish datei.c rcrccc' angeben, wenn ich will, um zwei
>verschiedene Encoder 6-mal arbeiten zu lassen.
>Das Ziel hat dann z.B. den Namen: 'datei.c.ercrccc'.
>
>Zum Dekodieren wird die Endung isoliert und umgedreht: cccrcr
>und es wird auch mit umgedrehten Schlüssel-Reihenfolgen gearbeitet.
>
>Niemand - auch die NSA nicht - wird meine multiple Verschlüsselung knacken können.

Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung baut, die
er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
knackendes erschaffen...

--
EMail:jo...@schily.net Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL: http://schilytools.sf.net/ http://cdrecord.org/private/

[Thomas Koenig]

jo...@schily.net <jo...@schily.net> schrieb:

> Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung baut, die
> er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
> knackendes erschaffen...

Ich verschlüssessele meine Daten mit 128 Runden ROT13, das ist
unknackbar !!11!!1

[jo...@schily.net]

In article <sdtvof$6di$1...@newsreader4.netcologne.de>,

Thomas Koenig <tko...@netcologne.de> wrote:
>jo...@schily.net <jo...@schily.net> schrieb:

>> Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung baut, die
>> er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
>> knackendes erschaffen...
>
>Ich verschlüssessele meine Daten mit 128 Runden ROT13, das ist
>unknackbar !!11!!1

Ich kann Deinen Artikel wegen der Verschlüsselung auch nicht lesen....

Aber noch besser ist die Vollbitverschlüselung, die man hier sehen kann:

https://web.archive.org/web/20140222145812/http://kryptochef.de/

und Kryptochef.de ist immerhin so wichtig, daß er von Bruce Schneier erwähnt
wurde.

Dabei hat das mit der Verschlüsselung auf Computern schon in den 1950ern
angefangen:

Professor: "So the American government went to IBM to come up with an
encryption standard, and they came up with..."

Student: "EBCDIC!"

[Helmut Schellong]

On 07/29/2021 12:00, jo...@schily.net wrote:
> In article <sdsj36$dui$1...@solani.org>,
> Helmut Schellong <r...@schellong.biz> wrote:
>>
>> Ich bin mächtig zufrieden!
>> Mein Verschlüsselungs-Skript ist fertig.
>>
>> Ich kann 'rabbit.bish datei.c rcrccc' angeben, wenn ich will, um zwei
>> verschiedene Encoder 6-mal arbeiten zu lassen.
>> Das Ziel hat dann z.B. den Namen: 'datei.c.ercrccc'.
>>
>> Zum Dekodieren wird die Endung isoliert und umgedreht: cccrcr
>> und es wird auch mit umgedrehten Schlüssel-Reihenfolgen gearbeitet.
>>
>> Niemand - auch die NSA nicht - wird meine multiple Verschlüsselung knacken können.
>
> Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung baut, die
> er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
> knackendes erschaffen...
>

.
Das trifft ja auf mich nicht zu, denn z.B. den Rabbit-Algorithmus, den
Spritz-Algorithmus, etc., habe ICH nicht geschaffen!
Diese Algorithmen werden weltweit eingesetzt für Verschlüsselungen.

Und, Bruce Schneider meint nicht DAS, was ich mit dem Skript betreibe!
Sondern er meint Chiffre-Algorithmen.
Ich bin auch kein Krypto-Anfänger.

Übrigens halte ich nichts von solchen /Sprüchen/.
Das ist in der Anwendung ignorierendes, oft unzutreffendes Geblubber.

Und Rabbit:
-----------
https://kryptografie.de/kryptografie/chiffre/rabbit.htm
Rabbit war Kandidat beim eStream Projekt des ECRYPT-Netzwerkes,
einem Kryptowettbewerb, der von 2004 bis 2008 lief und das Ziel
verfolgte, Vorschläge für neue Stromchiffren entgegenzunehmen,
kryptologisch zu untersuchen und zu bewerten und so empfehlenswerte
Verfahren zu finden.
Neben Salsa20 belegte Rabbit den ersten Platz bei den Software-Verfahren.
Rabbit ist für die Implementierung in Software optimiert.
Rabbit ist für kommerziellen und nicht-kommerziellen Gebrauch freigegeben.

Was _ich_ verwende, hat Premium-Qualität!
Rabbit hat seit 2003 KEINE Schwäche gezeigt, ist nicht geknackt worden.
Rabbit allein!

[Helmut Schellong]

On 07/29/2021 12:41, jo...@schily.net wrote:
> In article <sdtvof$6di$1...@newsreader4.netcologne.de>,
> Thomas Koenig <tko...@netcologne.de> wrote:
>> jo...@schily.net <jo...@schily.net> schrieb:
>>> Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung baut, die
>>> er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
>>> knackendes erschaffen...
>>
>> Ich verschlüssessele meine Daten mit 128 Runden ROT13, das ist
>> unknackbar !!11!!1
>
> Ich kann Deinen Artikel wegen der Verschlüsselung auch nicht lesen....
>
> Aber noch besser ist die Vollbitverschlüselung, die man hier sehen kann:
>
> https://web.archive.org/web/20140222145812/http://kryptochef.de/
>
> und Kryptochef.de ist immerhin so wichtig, daß er von Bruce Schneier erwähnt
> wurde.
>
> Dabei hat das mit der Verschlüsselung auf Computern schon in den 1950ern
> angefangen:
>
> Professor: "So the American government went to IBM to come up with an
> encryption standard, and they came up with..."
>
> Student: "EBCDIC!"
>

All diese /Sprüche/ sind dummes Geblubber, auf die es gar nicht ankommt.
Und der verlinkte Artikel enthält von oben bis unten bekloppten Quatsch.
Auch ROT13 ist von Kryptographie grundlegend meilenweit entfernt.

[Bonita Montero]

Am 29.07.2021 um 13:29 schrieb Helmut Schellong:
> On 07/29/2021 12:00, jo...@schily.net wrote:
>> In article <sdsj36$dui$1...@solani.org>,
>> Helmut Schellong  <r...@schellong.biz> wrote:
>>>
>>> Ich bin mächtig zufrieden!
>>> Mein Verschlüsselungs-Skript ist fertig.
>>>
>>> Ich kann  'rabbit.bish datei.c rcrccc'  angeben, wenn ich will, um zwei
>>> verschiedene Encoder 6-mal arbeiten zu lassen.
>>> Das Ziel hat dann z.B. den Namen: 'datei.c.ercrccc'.
>>>
>>> Zum Dekodieren wird die Endung isoliert und umgedreht: cccrcr
>>> und es wird auch mit umgedrehten Schlüssel-Reihenfolgen gearbeitet.
>>>
>>> Niemand - auch die NSA nicht - wird meine multiple Verschlüsselung
>>> knacken können.
>>
>> Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung
>> baut, die
>> er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
>> knackendes erschaffen...
>>
> .
> Das trifft ja auf mich nicht zu, denn z.B. den Rabbit-Algorithmus, den
> Spritz-Algorithmus, etc., habe ICH nicht geschaffen!
> Diese Algorithmen werden weltweit eingesetzt für Verschlüsselungen.
>
> Und, Bruce Schneider meint nicht DAS, was ich mit dem Skript betreibe!
> Sondern er meint Chiffre-Algorithmen.
> Ich bin auch kein Krypto-Anfänger.

Doch, sicher. Denn fähige Kryptologen sind Mathematiker.
Da Du keiner bist bist Du Krypto-Anfänger.

[Helmut Schellong]

Das wäre unwirksam!
Eine Runde (statt 128) ist bei _diesem_ Algorithmus nicht weniger wirksam.

Hingegen das, was ich mache, ist enorm wirksam!
Nämlich _grundlegend unterschiedliche_ Encoder hintereinander zu schalten.
Dies dürfte das denkbar wirksamste überhaupt sein.

Beim Knacken wird nämlich versucht, den verwendeten Algorithmus
herauszufinden, wobei sichtbar gewordene Ursprungsdaten, auch Fetzen
davon, den Weg zeigen.
Bei meiner Methode ist dieser Weg versperrt, denn man stößt auf
eine tiefere Schicht, die z.B. der Rabbit hinterlassen hat.
Falls also eine tiefere Ebene erreicht wurde, ist dies nicht erkennbar!

[Helmut Schellong]

.
Dummes Zeug.

[Thomas Koenig]

Helmut Schellong <r...@schellong.biz> schrieb:

> On 07/29/2021 12:26, Thomas Koenig wrote:
>> jo...@schily.net <jo...@schily.net> schrieb:
>>> Bruce Schneier sagt: Wenn ein Krypto-Anfänger eine Verschlüsselung baut, die
>>> er für unknackbar hält, hat er typischerweise etwas besonder einfach zu
>>> knackendes erschaffen...
>>
>> Ich verschlüssessele meine Daten mit 128 Runden ROT13, das ist
>> unknackbar !!11!!1
>>
> Das wäre unwirksam!

Na sowas. Jetzt schockst du mich aber.

Vielleicht sollte ich 256 Runden nehmen stattdessen?

[Helmut Schellong]

.
Ach was. Alles wie Jacke und Hose.

[Andreas Boehm]

Moin,

BM> Doch, sicher. Denn f„hige Kryptologen sind Mathematiker.
BM> Da Du keiner bist bist Du Krypto-Anf„nger.

Man verwechsele Intelligenz nicht mit Bildung...

viele Gr áe
Andi


Subspace-Channel closed on Stardate [-26]3056.38

[Bonita Montero]

Am 31.07.2021 um 02:00 schrieb Andreas Boehm:
> Moin,
>
> BM> Doch, sicher. Denn f„hige Kryptologen sind Mathematiker.
> BM> Da Du keiner bist bist Du Krypto-Anf„nger.
>
> Man verwechsele Intelligenz nicht mit Bildung...

Ein Mathe-Studium zu bewältigen ist nicht nur Bildung.
Ohne einen IQ >= 110, besser höher, kommste da nicht durch.

[Helmut Schellong]

.
Mein IQ liegt zwischen 130 und 140.

Man benötigt kein Mathematik-Studium, um erfolgreich
Krypto-Algorithmen entwickeln zu können.

Ich habe zwar keinen wirklich markttauglichen Krypto-Algorithmus
bisher entwickelt, aber ich kenne mich analytisch mit dem Verhalten
von numerischen Algorithmen ziemlich gut aus.
Außerdem implementierte ich viele solche Algorithmen, und
habe sehr viel damit /gespielt/.

Gestern habe ich den Keccak-Algorithmus implementiert.
Das ist der Nachfolger der heute üblichen SHA256:SHA512, die
genauer SHA2-256/512 sind. Keccak ist SHA3-XXX (2015).

https://de.wikipedia.org/wiki/SHA-3

Referenz-Implementierungen sind immer (auch) in C.

Ich werde diese und auch Rabbit in die Shell bish implementieren.
Dadurch erhalte ich ein Tor zu meinen verschlüsselten Inhalten
auf meiner Cloud. Inzwischen sind da 12 GB drauf.

Die Shell kann ich unverschlüsselt in der Cloud speichern.
Schließlich biete ich sie als Download an.

405] a.out -c 'sha256 -2 bsh.c'
SHA2-256 (bsh.c) = ef8b9134960a0146035394076811c0326ceadbde79b0d2bb91ab6856af4e94ac
406] a.out -c 'sha256 -3 bsh.c'
SHA3-256 (bsh.c) = b53f707be01babd044ca312e68e5816d39f1b5ca6c629cfce6473785b4b41795
407]

[jo...@schily.net]

In article <se38h8$uha$1...@solani.org>,

Helmut Schellong <r...@schellong.biz> wrote:

>Gestern habe ich den Keccak-Algorithmus implementiert.

>Das ist der Nachfolger der heute üblichen SHA256:SHA512, die

>genauer SHA2-256/512 sind. Keccak ist SHA3-XXX (2015).
>
>https://de.wikipedia.org/wiki/SHA-3
>
>Referenz-Implementierungen sind immer (auch) in C.

Das ist seit 5,5 Jahren in mdigest von den Schilytools.

Bevor Du etwas inkompatibles baust, solltest Du Dich mal umsehen...

[Bonita Montero]

Am 31.07.2021 um 12:27 schrieb Helmut Schellong:
> On 07/31/2021 09:04, Bonita Montero wrote:
>> Am 31.07.2021 um 02:00 schrieb Andreas Boehm:
>>> Moin,
>>>
>>>   BM> Doch, sicher. Denn f„hige Kryptologen sind Mathematiker.
>>>   BM> Da Du keiner bist bist Du Krypto-Anf„nger.
>>>
>>> Man verwechsele Intelligenz nicht mit Bildung...
>>
>> Ein Mathe-Studium zu bewältigen ist nicht nur Bildung.
>> Ohne einen IQ >= 110, besser höher, kommste da nicht durch.
>>
> .
> Mein IQ liegt zwischen 130 und 140.

Klar, deswegen bist Du auch so geistig unflexibel und
starrköpfig.

> Man benötigt kein Mathematik-Studium, um erfolgreich
> Krypto-Algorithmen entwickeln zu können.

Doch, mit einem Informatik-Studium kommt man da nicht weit.

> Ich habe zwar keinen wirklich markttauglichen Krypto-Algorithmus
> bisher entwickelt, aber ich kenne mich analytisch mit dem Verhalten
> von numerischen Algorithmen ziemlich gut aus.

Ja, genauso wie mit C-Aliasing.

[Bonita Montero]

Am 31.07.2021 um 12:37 schrieb jo...@schily.net:
> In article <se38h8$uha$1...@solani.org>,
> Helmut Schellong <r...@schellong.biz> wrote:
>
>> Gestern habe ich den Keccak-Algorithmus implementiert.
>> Das ist der Nachfolger der heute üblichen SHA256:SHA512, die
>> genauer SHA2-256/512 sind. Keccak ist SHA3-XXX (2015).
>>
>> https://de.wikipedia.org/wiki/SHA-3
>>
>> Referenz-Implementierungen sind immer (auch) in C.
>
> Das ist seit 5,5 Jahren in mdigest von den Schilytools.
>
> Bevor Du etwas inkompatibles baust, solltest Du Dich mal umsehen...

Wenn zwei Deppen sich um die Rangordnung streiten gewinnt keiner.

[Helmut Schellong]

On 07/31/2021 12:37, jo...@schily.net wrote:
> In article <se38h8$uha$1...@solani.org>,
> Helmut Schellong <r...@schellong.biz> wrote:
>
>> Gestern habe ich den Keccak-Algorithmus implementiert.
>> Das ist der Nachfolger der heute üblichen SHA256:SHA512, die
>> genauer SHA2-256/512 sind. Keccak ist SHA3-XXX (2015).
>>
>> https://de.wikipedia.org/wiki/SHA-3
>>
>> Referenz-Implementierungen sind immer (auch) in C.
>
> Das ist seit 5,5 Jahren in mdigest von den Schilytools.
>
> Bevor Du etwas inkompatibles baust, solltest Du Dich mal umsehen...
>

.
Verstehe ich nicht;
Meine Implementierung erzeugt die Referenz-Hashes.
Mehr geht nicht.

[Helmut Schellong]

On 07/31/2021 12:39, Bonita Montero wrote:
> Am 31.07.2021 um 12:27 schrieb Helmut Schellong:
>> On 07/31/2021 09:04, Bonita Montero wrote:
>>> Am 31.07.2021 um 02:00 schrieb Andreas Boehm:
>>>> Moin,
>>>>
>>>>   BM> Doch, sicher. Denn f„hige Kryptologen sind Mathematiker.
>>>>   BM> Da Du keiner bist bist Du Krypto-Anf„nger.
>>>>
>>>> Man verwechsele Intelligenz nicht mit Bildung...
>>>
>>> Ein Mathe-Studium zu bewältigen ist nicht nur Bildung.
>>> Ohne einen IQ >= 110, besser höher, kommste da nicht durch.
>>>
>> .
>> Mein IQ liegt zwischen 130 und 140.
>
> Klar, deswegen bist Du auch so geistig unflexibel und
> starrköpfig.

Blubber, blubber.

>> Man benötigt kein Mathematik-Studium, um erfolgreich
>> Krypto-Algorithmen entwickeln zu können.
>
> Doch, mit einem Informatik-Studium kommt man da nicht weit.

Ich habe nicht Informatik studiert, sondern ein stark
mathematik-lastiges anderes Fach.

>> Ich habe zwar keinen wirklich markttauglichen Krypto-Algorithmus
>> bisher entwickelt, aber ich kenne mich analytisch mit dem Verhalten
>> von numerischen Algorithmen ziemlich gut aus.
>
> Ja, genauso wie mit C-Aliasing.

.
Dein starres Alzheimer-Geblubber.

Du würdest wohl selbst zu Dennis Ritchie sagen: "Das ist falsch, Du Depp!"

[Bonita Montero]

>> Doch, mit einem Informatik-Studium kommt man da nicht weit.

> Ich habe nicht Informatik studiert, sondern ein stark
> mathematik-lastiges anderes Fach.

Wenn neue Krypto-Verfahren ausgearbeitet werden, dann werden die
jahrelang von absoluten Koryphähen evaluiert; dazu kannst Du dich
sicher nicht ansatzweise zählen. Du kannst sowas höchstens inmple-
mentieren, aber das ist ja keine Kunst. Das kann jeder FI-AE - ohne
zu verstehen was da mathematisch hintersteckt.

>>> Ich habe zwar keinen wirklich markttauglichen Krypto-Algorithmus
>>> bisher entwickelt, aber ich kenne mich analytisch mit dem Verhalten
>>> von numerischen Algorithmen ziemlich gut aus.

>> Ja, genauso wie mit C-Aliasing.

> Dein starres Alzheimer-Geblubber.
> Du würdest wohl selbst zu Dennis Ritchie sagen: "Das ist falsch, Du Depp!"

Ich wag zu bezweifeln, dass zu Zeiten als Dennis Ritchie sich C
ausgedacht hatte die Aliasing-Regeln so weit ausgearbeitet waren
wie ich dir entsprechend dem C99-Standard mehrfach erklärte und
wie Du die mehrfach mit absoluter Dummheit ignoriertest.

[Bonita Montero]

> Ich wag zu bezweifeln, dass zu Zeiten als Dennis Ritchie sich C
> ausgedacht hatte die Aliasing-Regeln so weit ausgearbeitet waren

> wie ich dir entsprechend dem C99-Standard mehrfach erklärte ...
Achne, war C11 (6.5.7).

[jo...@schily.net]

In article <se3b24$178$1...@solani.org>,

Helmut Schellong <r...@schellong.biz> wrote:
>On 07/31/2021 12:37, jo...@schily.net wrote:

>> Bevor Du etwas inkompatibles baust, solltest Du Dich mal umsehen...
>>
>.
>Verstehe ich nicht;
>Meine Implementierung erzeugt die Referenz-Hashes.
>Mehr geht nicht.

Dein Problem ist eigentlich immer eine inkompatible Kommandozeile.

sha2-256 hat außer der Ausgabebreite nichts gemeinsam mit sha3-256.
Warum baust Du OPtionsn -2 -3 ein?
Ich finde jedenfalls, daß eine Zusammenfassung nur Sinnvoll ist, wenn das
Programm mehr unterschiedliche Algorithmen unterstützt.

Aber gut, das scheint ja nur auf Deinen Shell zuzutreffen.

[Helmut Schellong]

.
Ich habe gar nichts ignoriert, sondern erklärt, daß alle Beteiligten
außer mir hier den entsprechenden Absatz im Standard falsch interpretierten
und dies immer noch tun!
Das liegt an ungenügendem Wissen zur englischen Sprache.

Der Absatz 6.5Expressions:7 bezeichnet dort Zugriffe z.B. mittels
korrespondierender Typen (long::ulong) als ein ALIASING!
Für einen Englischsprachigen ist es das auch.
Einfach, weil es ZWEI Typen betrifft.

Jedoch das Aliasing, das wirklich gemeint ist, ist beim Schlüsselwort
'restrict' erklärt!

void f(int n, int * restrict p, int * restrict q)
//...
extern int d[100];
f(50, d + 50, d); // valid
f(50, d + 1, d); // undefined behavior

UB liegt vor wegen unerlaubtem Aliasing!
BEIDE Pointer arbeiten mit den SELBEN Array-Elementen.
Sie kommen sich gegenseitig in die Quere.
'restrict' zwingt den Programmierer, wenn dieser 'restrict' angibt,
eben kein unerlaubtes Aliasing zu programmieren.
'restrict' erlaubt dem Compiler, hemmungslos und ohne Prüfungen
zu optimieren.
DAS ist ALIASING!

[Helmut Schellong]

On 07/31/2021 13:43, jo...@schily.net wrote:
> In article <se3b24$178$1...@solani.org>,
> Helmut Schellong <r...@schellong.biz> wrote:
>> On 07/31/2021 12:37, jo...@schily.net wrote:
>
>>> Bevor Du etwas inkompatibles baust, solltest Du Dich mal umsehen...
>>>
>> .
>> Verstehe ich nicht;
>> Meine Implementierung erzeugt die Referenz-Hashes.
>> Mehr geht nicht.
>
> Dein Problem ist eigentlich immer eine inkompatible Kommandozeile.

Was hat denn die Kommandozeile mit den Algorithmen zu tun?
Irgendwie ist Deine Argumentation /krank/!

> sha2-256 hat außer der Ausgabebreite nichts gemeinsam mit sha3-256.

Beides sind offizielle sha256-Algorithmen, vom NIST standardisiert.
Sie gehören zur sha-Familie.

> Warum baust Du OPtionsn -2 -3 ein?

Weil diese vier sha-Kommandos auf offiziellen sha-Algorithmen basieren.
Es gibt die Versionen 1, 2 und 3.
Bei grep kann auch Option -E angegeben werden, um eine andere Version
von Regulären Ausdrücken zu wählen.
Das ist exakt das Gleiche.

> Ich finde jedenfalls, daß eine Zusammenfassung nur Sinnvoll ist, wenn das
> Programm mehr unterschiedliche Algorithmen unterstützt.
>
> Aber gut, das scheint ja nur auf Deinen Shell zuzutreffen.
>

.
Hochgradig seltsame Argumentation.

Es sind etwa 10 verschiedene Algorithmen implementiert.

[Bonita Montero]

Nein, Du tust das.

> Das liegt an ungenügendem Wissen zur englischen Sprache.
>
> Der Absatz 6.5Expressions:7 bezeichnet dort Zugriffe z.B. mittels
> korrespondierender Typen (long::ulong) als ein ALIASING!
> Für einen Englischsprachigen ist es das auch.
> Einfach, weil es ZWEI Typen betrifft.
>
> Jedoch das Aliasing, das wirklich gemeint ist, ist beim Schlüsselwort
> 'restrict' erklärt!

Nein, der C-Standard definiert den Begriff gar nicht.
Aber beides ist richtig und in beiden Fällen spricht man
üblicherweise von Aliasing. Type-Punning ist aber korreter
für das was wir meinen.

[Bonita Montero]

Hier, kannste mal nachlesen was man unter strict aliasing rule
versteht. Das Wort Aliasing ist also in dem Zusammenang passend.
https://www.google.com/search?client=firefox-b-d&q=strict+aliasing+rule

[Helmut Schellong]

On 07/31/2021 18:05, Bonita Montero wrote:
> Am 31.07.2021 um 17:04 schrieb Helmut Schellong:
>> On 07/31/2021 13:25, Bonita Montero wrote:

[...]

>>> wie ich dir entsprechend dem C99-Standard mehrfach erklärte und
>>> wie Du die mehrfach mit absoluter Dummheit ignoriertest.
>> .
>> Ich habe gar nichts ignoriert, sondern erklärt, daß alle Beteiligten
>> außer mir hier den entsprechenden Absatz im Standard falsch interpretierten
>> und dies immer noch tun!
>
> Nein, Du tust das.

Nein, ich habe das schon durchgearbeitet, als ich 2005 begann,
meine C-Bücher zu schreiben.

>> Das liegt an ungenügendem Wissen zur englischen Sprache.
>>
>> Der Absatz 6.5Expressions:7 bezeichnet dort Zugriffe z.B. mittels
>> korrespondierender Typen (long::ulong) als ein ALIASING!
>> Für einen Englischsprachigen ist es das auch.
>> Einfach, weil es ZWEI Typen betrifft.
>>
>> Jedoch das Aliasing, das wirklich gemeint ist, ist beim Schlüsselwort
>> 'restrict' erklärt!
>
> Nein, der C-Standard definiert den Begriff gar nicht.

Richtig, das Wort ist durch die Englische Sprache definiert.

Ich sagte auch nicht, daß der C-Standard das Wort 'Aliasing' definiert.
Der Standard erklärt aber ausführlich die Bedeutung des Aliasing
im Zusammenhang mit 'restrict' mittels vieler Beispiele über zwei Seiten.

A translator is free to ignore any or all aliasing
implications of uses of restrict.

[Helmut Schellong]

.
Ich habe das doch schon vor Monaten gepostet, und ich sagte
neulich, daß ich das vor Monaten postete.

-fstrict-aliasing
Allow the compiler to assume the strictest aliasing rules
applicable to the language being compiled. For C (and C++), this
activates optimizations based on the type of expressions. In
particular, an object of one type is assumed never to reside at the
same address as an object of a different type, unless the types are
almost the same. For example, an "unsigned int" can alias an
"int", but not a "void*" or a "double". A character type may alias
any other type.

Pay special attention to code like this:

union a_union {
int i;
double d;
};

int f() {
union a_union t;
t.d = 3.0;
return t.i;
}

The practice of reading from a different union member than the one
most recently written to (called "type-punning") is common. Even
with -fstrict-aliasing, type-punning is allowed, provided the
memory is accessed through the union type. So, the code above
works as expected. However, this code might not:

int f() {
union a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}

Similarly, access by taking the address, casting the resulting
pointer and dereferencing the result has undefined behavior, even
if the cast uses a union type, e.g.:

int f() {
double d = 3.0;
return ((union a_union *) &d)->i;
}
-----------------------------------------------------------------------

Der Punkt ist, daß es gar keinen technischen Grund gibt, warum
Castings von groß auf klein und umgekehrt nicht makellos
funktionieren sollen.
Mit Ausnahme von Misalignment und Padding-Bits.
Wenn diese beiden Zustände nicht vorliegen, muß jegliches
Casting unbedingt funktionieren!

Das ist am Assembler erkennbar: mov rax, qword ptr [rsi]

Das funktioniert unbedingt, egal, welcher Typ an der
Adresse rsi vorliegt.
(Der Zugriff darf nicht außerhalb eines Objektes erfolgen.)

[Bonita Montero]

Am 31.07.2021 um 20:16 schrieb Helmut Schellong:
> On 07/31/2021 18:05, Bonita Montero wrote:
>> Am 31.07.2021 um 17:04 schrieb Helmut Schellong:
>>> On 07/31/2021 13:25, Bonita Montero wrote:
> [...]
>>>> wie ich dir entsprechend dem C99-Standard mehrfach erklärte und
>>>> wie Du die mehrfach mit absoluter Dummheit ignoriertest.
>>> .
>>> Ich habe gar nichts ignoriert, sondern erklärt, daß alle Beteiligten
>>> außer mir hier den entsprechenden Absatz im Standard falsch
>>> interpretierten
>>> und dies immer noch tun!
>>
>> Nein, Du tust das.
>
> Nein, ich habe das schon durchgearbeitet, als ich 2005 begann,
> meine C-Bücher zu schreiben.

Ich habe dir die Aliasing-Regeln genannt und Du vestößt
durchgehend mit deinem Code dagegen.

> Ich sagte auch nicht, daß der C-Standard das Wort 'Aliasing' definiert.
> Der Standard erklärt aber ausführlich die Bedeutung des Aliasing
> im Zusammenhang mit 'restrict' mittels vieler Beispiele über zwei Seiten.

Es geht nicht um restrict, sodnern das was an als Aliasing oder oft
auch als Type Punning bezeichnest. Das was Du machst ist lediglich
als union legal.
Nochmal: Du kannst einen Typen als sein signed / unsigned Gegenstück
aliasen (oder type-punnen oder wie man das auch nennen würde). Du kannst
es als char-Array aliasen oder umgekhehrt ein char-Array als einen be-
liebigen typen aliasen (das erlaubt Serialisierung in beide Richtungen).
Alles andere ist nicht legal und Du meinst es besser zu wissen weil Du
ein Volltrottel bist.
Nicht nur das was restrict macht ist Aliasing, sondern verschiedene
Typen durch den selben Pointer anzusprechen ist ebenfalls Aliasing,
was Du daran erkennen kannst, dass man diesbezüglich von der strict
aliasing rule spricht. Du kannst danach googeln und hunterte Seiten
finden die alle das sagen was ich dazu sage.

[Bonita Montero]

Am 31.07.2021 um 20:53 schrieb Helmut Schellong:

> Der Punkt ist, daß es gar keinen technischen Grund gibt,
> warum Castings von groß auf klein und umgekehrt nicht
> makellos funktionieren sollen.

Die meisten Compiler können solche Sauereien wie Du sie machst
erkennen und bewahren sich davor, entsprechend dem Standard sich
mehr an Optimierungen rauzunehmen, aber sie müssen es nicht.

> Mit Ausnahme von Misalignment und Padding-Bits.

Das Thema strict aliasing hat mit Padding Bits Null zu tun.

> Das ist am Assembler erkennbar:  mov  rax, qword ptr [rsi]

Man kann aus dem Verhalten eines Compilers nicht ableiten was
der Standard vorschreibt.

[Thomas Koenig]

Helmut Schellong <r...@schellong.biz> schrieb:

> Der Punkt ist, daß es gar keinen technischen Grund gibt, warum
> Castings von groß auf klein und umgekehrt nicht makellos
> funktionieren sollen.

Andere Registertypen?

[Helmut Schellong]

Was soll das heißen?

Alle Datenregister, die ich je kennenlernte, sind vollkommen normal.
Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind.
Und wenn ein Register 32 Bits hat, kann aus dem Mem oder einem
anderen Register 32 Bits dahin kopiert oder verknüpft werden.
Was soll da irgendwie nicht gehen?

[Thomas Koenig]

Helmut Schellong <r...@schellong.biz> schrieb:

> On 07/31/2021 21:19, Thomas Koenig wrote:
>> Helmut Schellong <r...@schellong.biz> schrieb:
>>
>>> Der Punkt ist, daß es gar keinen technischen Grund gibt, warum
>>> Castings von groß auf klein und umgekehrt nicht makellos
>>> funktionieren sollen.
>>
>>
>> Andere Registertypen?
>>
> Was soll das heißen?
>
> Alle Datenregister, die ich je kennenlernte, sind vollkommen normal.
> Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind.
> Und wenn ein Register 32 Bits hat, kann aus dem Mem oder einem
> anderen Register 32 Bits dahin kopiert oder verknüpft werden.
> Was soll da irgendwie nicht gehen?

Ich geh jetzt mal von x86_64 aus... Dein Prozessor kann
Floating-Point-Arithmetik mit den general purpose registern,
%rax und co?

[Helmut Schellong]

.
Was ist das für eine Argumentation?
Intel hat definiert, daß rax ein Universal-Integer-Register mit 64 Bit ist.
Gleitkomma-Operationen sind dafür nicht definiert, so wie für xmm#
keine XOR-Operation verknüpft ist.
Ich kann aber in rax einen double-Wert speichern.
Das macht der Compiler dauernd - zwecks kopieren!

[Thomas Koenig]

Helmut Schellong <r...@schellong.biz> schrieb:
> On 08/01/2021 08:45, Thomas Koenig wrote:
>> Helmut Schellong <r...@schellong.biz> schrieb:
>>> On 07/31/2021 21:19, Thomas Koenig wrote:
>>>> Helmut Schellong <r...@schellong.biz> schrieb:
>>>>
>>>>> Der Punkt ist, daß es gar keinen technischen Grund gibt, warum
>>>>> Castings von groß auf klein und umgekehrt nicht makellos
>>>>> funktionieren sollen.
>>>>
>>>>
>>>> Andere Registertypen?
>>>>
>>> Was soll das heißen?
>>>
>>> Alle Datenregister, die ich je kennenlernte, sind vollkommen normal.
>>> Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind.
>>> Und wenn ein Register 32 Bits hat, kann aus dem Mem oder einem
>>> anderen Register 32 Bits dahin kopiert oder verknüpft werden.
>>> Was soll da irgendwie nicht gehen?
>>
>> Ich geh jetzt mal von x86_64 aus... Dein Prozessor kann
>> Floating-Point-Arithmetik mit den general purpose registern,
>> %rax und co?
>>
> .
> Was ist das für eine Argumentation?

Lies nochmal durch, was du oben geschrieben hast: "Alle

Datenregister, die ich je kennenlernte, sind vollkommen normal.
Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind."

Weisst du, was eine signaling NaN ist?

> Intel hat definiert, daß rax ein Universal-Integer-Register mit 64 Bit ist.
> Gleitkomma-Operationen sind dafür nicht definiert, so wie für xmm#
> keine XOR-Operation verknüpft ist.

Also welches von den beiden ist jetzt ein "vollkommen normales"
Register? "verknüpfen" mittels floating point-Addition scheint
ja doch nicht zu gehen mit dem eax.

> Ich kann aber in rax einen double-Wert speichern.
> Das macht der Compiler dauernd - zwecks kopieren!

Jep.

Wenn aber der Compiler z.B. einen Floating-Wert in einem
floating-point-Register gespeichert hat (soll zwecks Rechnung
vorkommen) und über eine Zeiger eines anderen Typs wird die
Speicherstelle geändert, aus dem er sich den Wert geholt hat,
was soll der Compiler dann machen?

[Bonita Montero]

Am 01.08.2021 um 12:33 schrieb Thomas Koenig:

> Lies nochmal durch, was du oben geschrieben hast: "Alle
> Datenregister, die ich je kennenlernte, sind vollkommen normal.
> Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind."
>
> Weisst du, was eine signaling NaN ist?

Ein SNaN kannst Du beliebig laden und speichern. Erst wenn Du
damit rechnest, dann kommt es ggf. zu einem Trap (IEEE-754 Traps
sind optional), und das auch nur wenn diese konfiguriert sind.

[Stefan Kanthak]

"Thomas Koenig" <tko...@netcologne.de> schrieb:

Pack diesen VOELLIG ahnungslosen, merkbefreiten und komplett
verstrahlten Dilettanten ENDLICH ins Killfile!

> Helmut Schellong <r...@schellong.biz> schrieb:
>> On 08/01/2021 08:45, Thomas Koenig wrote:
>>> Helmut Schellong <r...@schellong.biz> schrieb:
>>>> On 07/31/2021 21:19, Thomas Koenig wrote:
>>>>> Helmut Schellong <r...@schellong.biz> schrieb:
>>>>>
>>>>>> Der Punkt ist, daß es gar keinen technischen Grund gibt, warum
>>>>>> Castings von groß auf klein und umgekehrt nicht makellos
>>>>>> funktionieren sollen.
>>>>>
>>>>>
>>>>> Andere Registertypen?
>>>>>
>>>> Was soll das heißen?
>>>>
>>>> Alle Datenregister, die ich je kennenlernte, sind vollkommen normal.
>>>> Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind.
>>>> Und wenn ein Register 32 Bits hat, kann aus dem Mem oder einem
>>>> anderen Register 32 Bits dahin kopiert oder verknüpft werden.
>>>> Was soll da irgendwie nicht gehen?
>>>
>>> Ich geh jetzt mal von x86_64 aus... Dein Prozessor kann
>>> Floating-Point-Arithmetik mit den general purpose registern,
>>> %rax und co?
>>>
>> .
>> Was ist das für eine Argumentation?
>
> Lies nochmal durch, was du oben geschrieben hast: "Alle
> Datenregister, die ich je kennenlernte, sind vollkommen normal.
> Sie haben n Bits, wobei alle Bitkombinationen erlaubt sind."
>
> Weisst du, was eine signaling NaN ist?

Hierzugrupp geht's um C, nicht um IEEE 754. Wie waer's mit
"trap representation"

>> Intel hat definiert, daß rax ein Universal-Integer-Register mit 64 Bit ist.
>> Gleitkomma-Operationen sind dafür nicht definiert, so wie für xmm#
>> keine XOR-Operation verknüpft ist.

AUTSCH! Das hat AMD definiert, NICHT Intel.
Meine AMD und Intel-Prozessoren kennen komische Instruktionen
wie PXOR, PSLRQ, PSLLD, ANDPS, ANDNPD, ...

> Also welches von den beiden ist jetzt ein "vollkommen normales"
> Register? "verknüpfen" mittels floating point-Addition scheint
> ja doch nicht zu gehen mit dem eax.
>
>> Ich kann aber in rax einen double-Wert speichern.
>> Das macht der Compiler dauernd - zwecks kopieren!
>
> Jep.
>
> Wenn aber der Compiler z.B. einen Floating-Wert in einem
> floating-point-Register gespeichert hat (soll zwecks Rechnung
> vorkommen) und über eine Zeiger eines anderen Typs wird die
> Speicherstelle geändert, aus dem er sich den Wert geholt hat,
> was soll der Compiler dann machen?

Petting? Anti-Aliasing?

Stefan
--
<https://www.duden.de/rechtschreibung/Kanthaken>

[Helmut Schellong]

Ich hatte rax und rsi genannt.
Es ist offensichtlich, daß ich Integer-Register meinte.

>> Intel hat definiert, daß rax ein Universal-Integer-Register mit 64 Bit ist.
>> Gleitkomma-Operationen sind dafür nicht definiert, so wie für xmm#
>> keine XOR-Operation verknüpft ist.
>
> Also welches von den beiden ist jetzt ein "vollkommen normales"
> Register? "verknüpfen" mittels floating point-Addition scheint
> ja doch nicht zu gehen mit dem eax.

Siehe unten.
Ich habe viele solche ASM-Funktionen entwickelt.
Datum steht drinnen.
Ich habe also echt Ahnung davon.

>> Ich kann aber in rax einen double-Wert speichern.
>> Das macht der Compiler dauernd - zwecks kopieren!
>
> Jep.
>
> Wenn aber der Compiler z.B. einen Floating-Wert in einem
> floating-point-Register gespeichert hat (soll zwecks Rechnung
> vorkommen) und über eine Zeiger eines anderen Typs wird die
> Speicherstelle geändert, aus dem er sich den Wert geholt hat,
> was soll der Compiler dann machen?
>

.
fld, fst und fstp arbeiten nur mit GK-Registern st(i) und Mem.

Wenn ich doubleobj += 1.0; programmiere, komme ich doch
gar nicht dazwischen.
Ich kann nur danach *(int*)&doublevalue = 123; machen, und habe
dadurch den Inhalt des double wahrscheinlich verfälscht.

Ich kann das double-Objekt auch dauerhaft per Cast als int
oder etwas anderes bis 64 Bit benutzen.

Allerdings *(uint64_t*)&doublevalue = 0; funktioniert, weil
alle Bits 0 eines double-Objektes repräsentieren den Wert 0.0 .

Selbstverständlich führt der Compiler alle diese Operationen aus.

--------------------------------------------------------
pow87.asm/ 773533721 0 0 100600 595 `
; sc/25.1.91
TITLE pow87
.386
.387
.MODEL small
ASSUME es:DGROUP
PUBLIC _pow87
.DATA
.DATA?
;$CW DW 2 DUP (?)
.CONST
;$zwei DD 2.0
eins DD 1.0
.CODE
_pow87 PROC
; b = 8
; e = 16
;
; fstcw $CW+2
fld QWORD PTR [esp+12]
; mov ax, $CW+2
; or ah, 00000011B
; mov $CW, ax
fld QWORD PTR [esp+4]
ftst
fstsw ax
; fldcw $CW
fwait
sahf
ja SHORT $Ypos
fucompp
fldz
; fldcw $CW+2
ret
ALIGN 4
$Ypos:
fyl2x
fld st
frndint
fxch
fsub st, st(1)
; fdiv $zwei
f2xm1
fadd eins
; fmul st, st
fscale
fstp st(1)
; fldcw $CW+2
ret
ALIGN 4
_pow87 ENDP
END

powi87.asm/ 776477899 0 0 100600 596 `
; sc/19.11.91
TITLE powi87
.386
.387
.MODEL small
PUBLIC _powi87
.CODE
_powi87 PROC
fld1
fld QWORD PTR [esp+4] ;bas
mov eax, [esp+12] ;exp
push ebx
push ecx
xor ebx, ebx
or eax, eax
jz SHORT $ende
jns SHORT $sloop
fdivr st, st(1)
neg eax
ALIGN 4
$sloop:
shr eax, 1
inc ebx
jnc SHORT $sloop
mov ecx, ebx
dec ecx
jng SHORT $bit0
fld st
$qloop:
fmul st, st
dec ecx
jg SHORT $qloop
fmulp st(2), st
or eax, eax
jnz SHORT $sloop
jmp SHORT $ende
ALIGN 4
$bit0:
fst st(1)
or eax, eax
jnz SHORT $sloop
$ende:
fstp st
pop ecx
pop ebx
ret
ALIGN 4
_powi87 ENDP
END

[Helmut Schellong]

On 08/01/2021 18:17, Stefan Kanthak wrote:
> "Thomas Koenig" <tko...@netcologne.de> schrieb:

>
>>> Intel hat definiert, daß rax ein Universal-Integer-Register mit 64 Bit ist.
>>> Gleitkomma-Operationen sind dafür nicht definiert, so wie für xmm#
>>> keine XOR-Operation verknüpft ist.
>
> AUTSCH! Das hat AMD definiert, NICHT Intel.

Das weiß ich, aber in den Intel-Datenbüchern ist das als
Intel®64 komplett beschrieben, ohne AMD zu nennen.
Die Zeichenfolge 'AMD' taucht in den Intel-Instr.-Datenbüchern nicht auf.

Intel hat AMD quasi erlaubt, das zu entwickeln und überhaupt
X86 zu verwenden.
Die Vereinbarung ist dergestalt, daß Intel AMD64 als eigene
Marke Intel®64 darstellen darf.
AMD64 basiert ja schließlich auf den X86-Definitionen (ax,al,ah,eax,..).

> Meine AMD und Intel-Prozessoren kennen komische Instruktionen
> wie PXOR, PSLRQ, PSLLD, ANDPS, ANDNPD, ...

Diese Gruppe mit 'P' kenne ich generell.
Es gibt noch viele weitere.
Soll ich deren Bezeichner alle posten?

Auf meinem alten Prozessor Core2Duo verwendet clang jedenfalls
kein XOR mit xmm#, nur MOV. Ich hatte das extra geprüft.

[Thomas Koenig]

"Alle Datenregister, die ich kenne" bezieht sich ausschließlich auf
Integer-Register?

Deine Ausdrucksweise ist - höflich gesagt - bemerkenswert unpräzise.

>
>>> Intel hat definiert, daß rax ein Universal-Integer-Register mit 64 Bit ist.
>>> Gleitkomma-Operationen sind dafür nicht definiert, so wie für xmm#
>>> keine XOR-Operation verknüpft ist.
>>
>> Also welches von den beiden ist jetzt ein "vollkommen normales"
>> Register? "verknüpfen" mittels floating point-Addition scheint
>> ja doch nicht zu gehen mit dem eax.
>
> Siehe unten.
> Ich habe viele solche ASM-Funktionen entwickelt.
> Datum steht drinnen.
> Ich habe also echt Ahnung davon.
>
>>> Ich kann aber in rax einen double-Wert speichern.
>>> Das macht der Compiler dauernd - zwecks kopieren!
>>
>> Jep.
>>
>> Wenn aber der Compiler z.B. einen Floating-Wert in einem
>> floating-point-Register gespeichert hat (soll zwecks Rechnung
>> vorkommen) und über eine Zeiger eines anderen Typs wird die
>> Speicherstelle geändert, aus dem er sich den Wert geholt hat,
>> was soll der Compiler dann machen?
>>
> .
> fld, fst und fstp arbeiten nur mit GK-Registern st(i) und Mem.

[...]

Folgendes Problem:

Zwei Pointer zeigen auf die gleiche Adresse, einer int, einer float.
Der Compiler hat den float-Wert schon in ein Register geladen,
danach speichert das Programm einen Wert über den int-pointer
dahin.

Was soll passieren?

[Helmut Schellong]

On 08/01/2021 22:14, Thomas Koenig wrote:
> Helmut Schellong <r...@schellong.biz> schrieb:
>> On 08/01/2021 12:33, Thomas Koenig wrote:

[...]

>> Ich hatte rax und rsi genannt.
>> Es ist offensichtlich, daß ich Integer-Register meinte.
>
> "Alle Datenregister, die ich kenne" bezieht sich ausschließlich auf
> Integer-Register?

Isoliert nicht. Jedoch hatte ich den Kontext rax,rsi direkt dabei
genannt, als einführendes Beispiel.

> Deine Ausdrucksweise ist - höflich gesagt - bemerkenswert unpräzise.

Denke ich nicht. Man will gerne isolieren, für gewisse Zwecke.
Man darf jedoch nicht den Kontext ignorieren.
Genau deshalb steht der Kontext da.

[...]

>> fld, fst und fstp arbeiten nur mit GK-Registern st(i) und Mem.
>
> [...]
>
> Folgendes Problem:
>
> Zwei Pointer zeigen auf die gleiche Adresse, einer int, einer float.
> Der Compiler hat den float-Wert schon in ein Register geladen,
> danach speichert das Programm einen Wert über den int-pointer
> dahin.
>
> Was soll passieren?

>Das ist erneut eine falsche zeitliche Abfolge.
Der Compiler lädt ein float nur in ein Register, wenn er damit sofort
eine Berechnung durchführen will.
Das Resultat speichert der Compiler zurück.

Erst danach kann in C eine weitere Operation vorgenommen werden:
Nichts passiert, falls der Wert per int* eine gültige float-Repräsentation ist.
Ist sie das nicht, kann bei Benutzung als float eine Exception ausgelöst werden.
(Ich kenne NaN seit etwa 1983.)

int *ip= (int*)&flo; *ip= 0x123abc;

Man muß wissen, was man tut.
Gemacht habe ich so etwas nur als Test.

[Bonita Montero]

Am 01.08.2021 um 21:46 schrieb Helmut Schellong:

> Auf meinem alten Prozessor Core2Duo verwendet clang jedenfalls
> kein XOR mit xmm#, nur MOV. Ich hatte das extra geprüft.

Guck dir das mal an:

void f( double &d )
{
for( double a = 0.0; a <= 1000.0; ++a )
d += a;
}

Disassembly:

"?f@@YAXAEAN@Z":
movsd xmm2, qword ptr [rcx]
xorpd xmm0, xmm0
^^^^^^^^^^^^^^^^^^
...

clang 11.

[Helmut Schellong]

On 08/02/2021 08:35, Bonita Montero wrote:

.
Er macht es trotzdem nicht bei mir.
Vielleicht hat mein Core2Duo noch nicht diese Instruktion.

xor a,a ist übrigens a=0.

Ich habe bei Rabbit (in der bish) die Verwendung von __int128
herausgenommen, weil ich die Shell auch unter Windows kompiliere
und dieser Typ dem dortigen Compiler unbekannt ist.
Clang hatte eh umgebaut auf 2x64 Bit.

[Helmut Schellong]

On 08/02/2021 08:35, Bonita Montero wrote:

.
XORPD xmm1, xmm2/mem

So ist das im Datenbuch.
Es gibt nicht mem als Ziel: buf[ns] ^= s;
Nur RM, nicht auch MR, wie bei MOVAP.
Deshalb nimmt clang XORPD wohl nicht, weil da 2x64 günstiger ist.

[Helmut Schellong]

On 07/28/2021 23:44, Helmut Schellong wrote:
>
> Ich bin mächtig zufrieden!
> Mein Verschlüsselungs-Skript ist fertig.
>
> Ich kann  'rabbit.bish datei.c rcrccc'  angeben, wenn ich will, um zwei
> verschiedene Encoder 6-mal arbeiten zu lassen.
> Das Ziel hat dann z.B. den Namen: 'datei.c.ercrccc'.
>
> Zum Dekodieren wird die Endung isoliert und umgedreht: cccrcr
> und es wird auch mit umgedrehten Schlüssel-Reihenfolgen gearbeitet.
>
.
Verschlüsselungs-Skript:
http://www.schellong.de/htm/rabbit.bish.html

[Bonita Montero]

Am 02.08.2021 um 12:55 schrieb Helmut Schellong:
> On 08/02/2021 08:35, Bonita Montero wrote:
>> Am 01.08.2021 um 21:46 schrieb Helmut Schellong:
>>
>>> Auf meinem alten Prozessor Core2Duo verwendet clang jedenfalls
>>> kein XOR mit xmm#, nur MOV. Ich hatte das extra geprüft.
>>
>> Guck dir das mal an:
>>
>> void f( double &d )
>> {
>>      for( double a = 0.0; a <= 1000.0; ++a )
>>          d += a;
>> }
>>
>> Disassembly:
>>
>> "?f@@YAXAEAN@Z":
>>      movsd    xmm2, qword ptr [rcx]
>>      xorpd    xmm0, xmm0
>>      ^^^^^^^^^^^^^^^^^^
>>      ...
>>
>> clang 11.
> .
> XORPD  xmm1, xmm2/mem
>
> So ist das im Datenbuch.
> Es gibt nicht mem als Ziel:  buf[ns] ^= s;
> Nur RM, nicht auch MR, wie bei MOVAP.
> Deshalb nimmt clang XORPD wohl nicht, weil da 2x64 günstiger ist.

Darum gings aber nicht, sondern um das Nullen eines XMM-Registers
mit xors/pd/s. Dass Du am Thema vorbeidedest lässt mich daran zwei-
feln, dass Du einen IQ von 130 - 140 haben sollst.

[Helmut Schellong]

Spinnerige Argumentation!

Zuvor ging es überhaupt gar nicht um das Nullen eines xmm-Registers!
Es ging auch gar nicht um das Nullen per XOR!

Folgendes schrieb ich bereits dazu:

|Vielleicht hat mein Core2Duo noch nicht diese Instruktion.
|xor a,a ist übrigens a=0.

Du redest am Thema vorbei.
Es geht um den Typ __int128.
In über 10 Rabbit-Postings steht dieser Typ.

07/27/2021 01:10 :
|Der 'Rabbit' ist empfehlenswert.
|Ich habe in C den Typ __int128 verwendet, um den Ausgabeblock
|128 Bit auf einen Schlag mit den Dateidaten XORen zu können.
|buf[ns++] ^= s, nb-=16;

[Bonita Montero]

LOL. "Ich mach' mir die Welt Widdewidde wie sie mir gefällt ..."
würde zu dir passen.

[Thomas Koenig]

Helmut Schellong <r...@schellong.biz> schrieb:
> On 08/01/2021 22:14, Thomas Koenig wrote:
>> Helmut Schellong <r...@schellong.biz> schrieb:
>>> On 08/01/2021 12:33, Thomas Koenig wrote:
> [...]
>>> Ich hatte rax und rsi genannt.
>>> Es ist offensichtlich, daß ich Integer-Register meinte.
>>
>> "Alle Datenregister, die ich kenne" bezieht sich ausschließlich auf
>> Integer-Register?
>
> Isoliert nicht. Jedoch hatte ich den Kontext rax,rsi direkt dabei
> genannt, als einführendes Beispiel.
>
>> Deine Ausdrucksweise ist - höflich gesagt - bemerkenswert unpräzise.
>
> Denke ich nicht. Man will gerne isolieren, für gewisse Zwecke.
> Man darf jedoch nicht den Kontext ignorieren.
> Genau deshalb steht der Kontext da.

Wer sich so ungenau ausdrückt, erweckt den Eindruck, nicht
genau zu wissen, wovon er spricht. Versuche einfach in Zukunft,
sowas zu vermeiden.

> [...]
>>> fld, fst und fstp arbeiten nur mit GK-Registern st(i) und Mem.
>>
>> [...]
>>
>> Folgendes Problem:
>>
>> Zwei Pointer zeigen auf die gleiche Adresse, einer int, einer float.
>> Der Compiler hat den float-Wert schon in ein Register geladen,
>> danach speichert das Programm einen Wert über den int-pointer
>> dahin.
>>
>> Was soll passieren?
>>Das ist erneut eine falsche zeitliche Abfolge.
> Der Compiler lädt ein float nur in ein Register, wenn er damit sofort
> eine Berechnung durchführen will.
> Das Resultat speichert der Compiler zurück.

Du verstehst offensichtlich sehr wenig davon, wie Compiler
funktionieren, trotz deiner ständigen Beteureungen, da
ein Experte zu sein.

Nur für Mitlesende:

Compiler versuchen nach Möglichkeit, mittels ausgefeilten
Algorithmen, die Register Spills (also Wert zwischenspeichern und
später wieder zurückladen) zu minimieren, vor allem natürlich in
Schleifen. Er wird die Werte also so lange im Register set lassen
wie möglich und sinnvoll (d.h. wenn da andere Werte in die Register
reinmüssen) und solange die Regeln der Sprache das nicht verbieten.

Und die aliasing-Regeln von C sagen halt gerade, dass z.B. auf Werte
über einen int-Pointer nicht über einen float-pointer zugegriffen
werden darf, so dass der Compiler das zu Optimierungszwecken tun
darf.

> Erst danach kann in C eine weitere Operation vorgenommen werden:

Du verwechelst das Verhalten von Implementierungen mit bestimmten
Optionen mit dem, was ein Programm darf.

[Helmut Schellong]

On 08/02/2021 21:07, Thomas Koenig wrote:
> Helmut Schellong <r...@schellong.biz> schrieb:
>> On 08/01/2021 22:14, Thomas Koenig wrote:
>>> Helmut Schellong <r...@schellong.biz> schrieb:
>>>> On 08/01/2021 12:33, Thomas Koenig wrote:
>> [...]

[... ... ...]

> Du verwechelst das Verhalten von Implementierungen mit bestimmten
> Optionen mit dem, was ein Programm darf.
>

Ich kann mit Deinen Ausführungen kaum etwas anfangen.
Diese sind kurz, ungenau und diffus, und der bisherige Verlauf
ist kaum mehr erkennbar.

Am besten ist es, Du zeigst zukünftig C-Code und
formulierst dazu genaue Meinungsabfragen, etc.

[Rolf Buenning]

Helmut Schellong <r...@schellong.biz> schrieb:

> On 07/28/2021 23:44, Helmut Schellong wrote:
>>

> Verschlüsselungs-Skript:
> http://www.schellong.de/htm/rabbit.bish.html

Error 404 - Not found
>
>

[Helmut Schellong]

Ich hatte nach Änderung in ein falsches Verzeichnis hochgeladen.
Es muß jetzt mit dem URL oben funktionieren - habe es gerade probiert.