Bináris programozás

Sziasztok !

Már egy ideje foglalkoztat ez a téma, de eddig elég eltérő infókat találtam erről a témáról. Érdekelne, hogy van e és ha igen akkor lehet e kettes számrendszerbe (bináris számrendszerbe) programozni. Programoznak e egyáltalán ilyen módon? Azt tudom, hogy ez a processzor nyelve és ehhez a legközelebb az "assembly" áll. Mégis kíváncsi vagyok, van e olyan elvetemült ember(ek), akik ezt használják. Állítólag ez egy "Helló" kiírás a képernyő közepére.

"011100000011111101010100010111110110101011011011100000011111
1010101000011110101110101000111110100000011010100101010111010
0001100100101000101001000000111111010101100110111101011111100
101010 "

Bár lefuttatni nem sikerült, pedig fordító program se kell elméletileg hozzá. Tudd erről a témáról valaki bővebbet mondani? Esetleg van valami tankönyv? Próbálkozót valaki ezzel a nyelvel? Egyáltalán létezik ilyen nyelv?

Válaszokat előre is köszönöm.

Hozzászólások

április 1?
csak szólok: már elmúlt

"Azt tudom, hogy ez a processzor nyelve"
Rosszul tudod. Tanuljál, olvass hozzá.

Hasznodra válna, ha megtanulnál assembly-ben programozni egy mikrokontroller családot, akkor kitisztulna a fejedben ez az egész. Annyit segítek, hogy a bináris ábrázolás valóban a fizikai megvalósítást tükrözi, ennek viszont folyománya, hogy ez nem egyetemes valami, hanem mindig attól függ, milyen hardware-en értelmezed. Nézz utána még a kombinációs hálózatoknak, aztán a szinkron szekvenciális hálózatoknak, ezek tervezésének. Ha ezeket megérted, akkor már nem fogsz ilyesmit kérdezni. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem vagyok gondolatolvasó, nem tudom, mire gondol. Az vicces, hogy egy bináris szekvenciáról bátran kijelenti, hogy az mit csinál. Attól függően, milyen hardware-t terveznek alá, az bármit csinálhat. Akár azt is, amit mond.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jogos. Amúgy én is max olyat láttam, hogy hexában nézték és módosították a bináris kódot, esetleg Ascii-ként, ha valamit gyorsan kellett hekkelni, de közvetlenül a procitervezőn kívűl nem hiszem, hogy bárki foglalkozna direktben a bináris reprezentációval.
Remélhetőleg az illető nem így ascii-ként mentette el a bináris számsort, mert akkor nem csoda, hogy nem megy :D. Én négy bitenként hexa számjegyekre alakítanám, majd egy hexa editorral menteném, de lehet ennek is van buktatója és még ez is hülyeség, amit én írok.

Persze, odáig rendben, hogy binárist csinálsz belőle. Aztán? Min futtatod? Z80-on, valamelyi PIC családon? Melyiken? Még a programmemória szélessége sem azonos az egyes PIC-eken, van, amelyik 12, van, amelyik 14 bites, de van 16 bites, meg fene tudja, nem nézem meg tovább. Vagy 80C32-n? Egy Atmelen? Intel, AMD, ARM, Renesas, Hitachi? Netán egy FPGA-ból vagy CPLD-ből kialakított szinkron szekvenciális hálózat?

Amúgy néha kell foglalkozni a bináris reprezentációval. Például akkor, ha épp egy assemblert írsz. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

"Remélhetőleg az illető nem így ascii-ként mentette el a bináris számsort, mert akkor nem csoda, hogy nem megy :D."

Nem tudom, hogy hogyan lett csinálva. Én is úgy találtam egy fórumon. Az ottani illető állította...
Ezért kérdeztem rá itt, hogy ti mit tudtok erről a témáról.

Annyit mondok róla, hogy a kérdésfelvetés ebben a formában elégtelen. Lóg a levegőben. Olyan ez, mintha azt kérdezném a 83 sok, vagy kevés? Hát ugye környezeti hőmérsékletnek, ott, ahol élünk, Celsius fokban cseppet sok, Kelvinben kevés, szisztolés vérnyomásnak Hgmm-ben kevés, hálózati frekvenciának Hz-ben sok, és ezt a sort akármeddig folytathatnám. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

+1. Mikrokontrollerre ilyen bitpillegető programokat (amit aztán oszcilloszkóppal lehet mérni, vizualizálni) lehet írni úgy, hogy megtervezed az assemblyt, és aztán táblázatok alapján átírod utasítás kódokra (ezt csinálja egyébként az ASM fordító is, de párszor poénból ki lehet próbálni), majd ezeket beírod egy fájlba hexában, majd felégeted a procira, és lám működik. Például itt el lehet kezdeni: arduino.cc (locsemege persze azt mondaná, hogy inkább csinálj saját HW-t :-)

Anno párologtatókat programoztam bináris nyelven, de az réges régen volt, egy messzi-messzi galaxisban...

Ha ilyesmi kihívásra vágysz, ajánlom a brainfuck nevű nyelvet.
-----
A problémáim velem kezdődtek és utánam megmaradnak. Ez az én hozzájárulásom az Emberiség Nagy Művéhez.

Igen nézegettem ezt a programnyelvet és ehhez hasonlókat. Találtam is minta programokat a "Brainfuck"-hoz de azt még nem találtam meg hogyan lehet futtatni a programot.
Sőt ! Találtam a Brainfuckhoz hasonló rejtett programnyelveket is.
https://esolangs.org/wiki/Hello_world_program_in_esoteric_languages

Mára már millió interpreter van hozzá, a legegyszerűbb js implementációkon gyakorolni, pl: https://copy.sh/brainfuck/

De igazából adott nyelven interpretert írni is érdemes gyakorlat lehet, nem túl nagy az utasításkészlet.

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Az egyszeru interpreterrol csak annyit, a Brainfuck mar eleve azert jott letre, hogy koegyszeru legyen. Az eredeti cel egy olyan minimalista Turing-teljes nyelv volt, amire a letezo legkisebb forditot lehet irni.

Ez a fordito Amigara keszult el, 1993-bol szarmazo 2.0-s verzioja a mai napig letoltheto az Aminetrol, es kiprobalhato pl. UAE-n (emulatoron):
http://aminet.net/package/dev/lang/brainfuck-2

A fordito(!) 240 byte (amibol 64 byte az Amiga exe header), es termeszetesen Motorola 68k gepi kodot es AmigaOS binarisokat fordit. Innen jon az eredeti Brainfuck limitacio is, hogy csak 30K memoria erheto el, mivel a 68000 CPU elojeles 16 bites offszetet kepes cimezni egy adott cimhez kepest (azaz plusz/minusz 32K-t).

Szoval Brainfuckra nem interpretert irunk, mert az lame, hanem forditot. Lehet nekikezdeni. ;)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Ja. De ez ahogy nezem durvan belehekkel az ELF headerbe, es ujradefinialja a mezoit kodkent, hogy kisebb lehessen. Ami eleg beteg, de persze egyben zsenialis is, de emiatt nem biztos hogy 1:1-ben osszehasonlithato. Meg hat 68k-n a minimum utasitashossz es a displacementek merete is 2 byte, szoval ez "kozismert", hogy a 8 bites utasitasokkal is rendelkezo x86 jobban fekszik az extrem meretoptimalizalashoz.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Látogass el a https://gcc.godbolt.org/# oldalra. Itt bal oldalon megadott kódot C vagy C++ nyelven, jobb oldalon jelenít meg lefordítva, assembly nyelven. Ott lesz fent egy gomb, 11010 felirata. Arra ha rányomsz, kijön hexában a dolog. Na, ha itt a hexa számjegyeket átírod 4 bináris számmá, az lesz az adott program bináris változata.

Valóban nem. Mi egyetemen assembly-t egy "játék" nyelven tanultuk: DIY Calculator volt a hardver, egy kis emulátor igazából. Ennek volt néhány regisztere, meg pár bájt memóriája, alapvető utasításokkal. Pont annyira volt elég, hogy egy félév alatt megértse az ember, hogy alacsony szinten mi az hogy függvényhívás, paraméter átadás, rekurzió, megszakításkezelés, perifériák kezelése. Bár tényleg nem sok tapasztalatom van mikrokontrollerekkel (Arduino, Tiva Launchpad amik megfordultak nálam, ezeket is magas szintű nyelven birizgáltam) szerintem az assembly tanulást ma is ott kezdeném el.

" Próbálkozót valaki ezzel a nyelvel? "
Próbálkózhatnál kicsit jobban a magyar nyelvel.

Mert az állítólag az anyanyelved.
Utána jöhetnek idegen nyelvek.
Aztán ha már meg tudod értetni magad a világban, akkor jöhetnek a kitalált nyelvek.

Mmmppmmffpffmpp fmpmpp mfmppfpppmpmppfpmffmmffp, mmmffpfmp úmfmffm mfpífpmpmmápmp, mfpppfmfmffm mmmfmmfmmmppppmmmppmfffm fpmmmmmfmffm mfmépfmmff pmpómpmú pfmpffppfmfmpffmmmppmppfffpáfmm.
És ez nem az.

Tulajdonképpen lehet. Annyit érdemes rajta pontosítani, hogy nem kellemes kettes számrendszert használni, mert olyankor egy byte-nyi adat leírásához 8 számjegyre van szükséged, ezért helyette a tömörebb 16-os számrendszert érdemes bevetni, akkor byte-onként elég két karakter.

Mivel fogalmam sincs, mennyit foglalkoztál processzorok belső felépítésével, működésükkel, de a kérdésed arra enged következtetni (ha nem átverésnek szántad), hogy nem sokat, és azt is régen :), ezért megpróbálom leírni, hogy nagyjából hogyan kell elképzelned az egészet. Ne várj pontos, minden részletre kiterjedő magyarázatot, csak egy kis útraindítót :)

Kell egy táblázat, ami tartalmazza az adott CPU, pl. egy Z80 utasításkészletét, úgy, hogy soronként az egyik oszlopban látható egy utasítás (ezt hívják mnemoniknak), mellette egy oszlopban meg az adott utasítás kódja, de akár lehet több ilyen oszlop is, az egyikben binárisan, a másikban hexadecimálisan, egy harmadikban meg akár decimálisan is szerepelhet az érték. Az egyszerűség kedvéért tételezzük fel, hogy egy utasítás egy byte-ból áll. Amikor az adott CPU "elindul", a programmemória egy adott helyéről (talán a legtöbb típus a legelső memóriacímről) beolvas egy kódot, amit mi utasításnak hívunk. Ezt "értelmezi", valamit csinál ezután - rövidebben szólva végrehajtja az utasítást :), majd megnöveli a programszámláló értékét eggyel. A programszámlálóra azért van szükség, hogy valahonnan tudja a CPU, hogy a következő utasítást melyik memóriarekeszből kell beolvasnia, vagyis a program counter (PC) szolgál arra, hogy meg lehessen címezni a programtároló megfelelő rekeszét.

Most egyelőre ne foglalkozzunk azzal, hogy hova kerül az utasítás, mit csinál a hatására a CPU, mi lesz az eredménye egy utasításnak, ez az eredmény hova kerül, mert ehhez a belső felépítésről kéne tudnod ezt-azt. Ha igazán meg akarod érteni a dolgot, akkor úgyis utána kell olvasnod egy keveset (igazából sokat).

Te kitalálsz egy programot (ha működőt akarsz, akkor előtte eléggé bele kell ásnod magad az adott CPU lelkivilágába), ezt leírod, majd az egyes utasításokat helyettesíted a megfelelő kóddal. Ezeket a kódokat szépen beírod egy hexa editorral egy fájlba, majd a fájl tartalmát beletöltöd valahogy a CPU-ba. Régebben EPROM-ba, ma már a mikrovezérlő belső flash-ébe, de ha mindezt egy olyan CPU-n tudod csinálni, amin fut már egy működő oprendszer, akkor ott valamilyen alkalmas módon végre tudod hajtani a programodat (MS-DOS alatt pl. elnevezed a fájlt, legyen pl. a neve valami.com, majd lefuttatod).

Ezer éve az IBM XT-n úgy lehetett a merevlemezvezérlővel a HDD-t inicializálni, hogy MS-DOS alatt kiadtad a debug utasítást, majd ebben elindítottad azt a programot, amit a vezérlő EPROM-ja tartalmazott. Ehhez ezt kellett beírni (a "-" a debug programban a prompt): -g=c800:5. Ez csak egy példa, a VGA-vezérlőt is lehetett hasonló módon újraindítani.

Természetesen ennek az egész bohóckodásnak manapság semmi értelme a tanuláson kívül, igazából már assembly-ben is csak nagyon kevesen programoznak a nagyon sok programozóból, mivel kevés esetben van rá szükség.

Vannak, akik szerint jelentősége van annak, ki mikor regisztrált ide. PP user 11 év és 31 hete tag ezzel a kérdéssel. A bináris sztring csonka, nem egész byte-okból áll, valahol van benne egy fél byte. Vagy elnézte a naptárt vagy...

Egyébként lehet így programozni, csak eléggé perverz módja a dolognak. Én még láttam olyat, hogy regisztereket írtak így át illetve a memóriában pár byte-ot javítottak le így futó operációs rendszerben! De azok más idők voltak, akkor egy processzor egy nagy szekrény méretével vetekedett és a mérnöki pulton tárcsás kapcsolókkal lehetett megcímezni az operatív memóriát is. A mikroprocesszorok terjedésének kezdetén láttam olyan home made eprom programozót, ahol az egyes memória rekeszek értékét is binárisan kellett beírni úgy, hogy nyolc billenőkapcsolóval beállította az ember a biteket 1-re vagy 0-ra, majd egy nyomógombbal beégette az értéket és lépett egyet a címző áramkör. Nem tudom, hogy valaha beírt-e valaki így 16 kbyte-ot vagy sem, de embert próbáló feladat lehetett (volna). DOS-os korszakban magam is írtam át egytől pár tucatig terjedő számú byte-ot programban, de azt már általában hexadecimálisan végeztük segédprogramokkal. Manapság ennek nem sok értelme van. Az idézett bináris szerintem semmit értelmeset nem csinál, a hello biztos nincs benne.

Érdekesség, hogy egyes mikroprocesszoroknál a PC értéke is módosítható a MOV utasítással, amit csak a compiler védett azzal, hogy illegális utasításnak címkézte, de ha DB nn formában szerepelt a kódban, akkor simán végrehajtásra került és ugrott a program az adott címre szépen.

0111 0000 0011 1111 0101 0100 0101 1111 0110 1010 1101 1011 1000 0001
70 3F 54 5F 6A DB 81
1111 1010 1010 0001 1110 1011 1010 1000 1111 1010 0000 0110 1010 0101
FA A1 EB A8 FA 06 A5
0101 1101 0000 1100 1001 0100 0101 0010 0000 0111 1110 1010 1100 1101
5D 0C 94 52 07 EA CD
1110 1011 1111 0010 1010
EB F2 D

Az én DOS-os programjaim egységesen 50000 bytosak voltak. Grafikával, scanner driverrel,
adatbáziskezeléssel, saját ablakfelülettel, menürendszerrel. Overlay technikát használtam.
Az elején gépi kódban konkrétan a memória területre írtam be az utasításokat (pl kézzel
kiszámoltam a jmp hosszát), aztán tértem át assemblyre.

Iskolának nagyon jó! Ha megvannak az alaprutinjaid, akkor nem sokkal lassabb így programozni,
mint mondjuk C-ben, ráadásul a mai processzorokon van néhány olyan utasítás, amit
magasabb szintű nyelvben nem tudsz direktben kiadni.

Azt hiszem a topikindító nem a gépi kódra gondolt

> Sol omnibus lucet.

ráadásul a mai processzorokon van néhány olyan utasítás, amit magasabb szintű nyelvben nem tudsz direktben kiadni.

A., a C/C++, Pascal es a hasonlo "szinten" dolgozo forditos nyelvekben van inline assembler
B., SIMD compiler intrinsics (pl.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

A C és C++ szabvány nem tartalmaz inline assemblerre lehetőséget.

A Pascal nyelv szabványa sem engedi ezt meg.

Ezeket legfeljebb egyes implementációk fordítóinak szabványon felüli kiterjesztései engedik ezt meg.
Ne tegyünk úgy (nagyon rossz), ha egy implementációt (gcc vagy clang vagy freepascal) összekeverünk magával a nyelvvel.

De, a C es C++ szabvany megemliti az inline assembler lehetoseget, mint common extension ill. conditionally supported declaration de nyilvan az implementacios detail az platform (es fordito) specifikus.

A Pascal ennel bonyolultabb, leven a ket legelterjedtebb fordito a bolygon (a Delphi es az FPC) vagy a Delphi altal definialt dialektussal kompatibilis, vagy kivalaszthato a tamogatott standard/dialektus. Lenyeg, hogy az "ISO" szabvanynak joval kevesebb hatasa van a mai Pascalra, mint pl. C eseteben, es pl. az FPC assembler szintaxist is valt, ha inline assemblert tartalmazo Delphi kodot akarsz vele leforditani. (Ahogy egyebkent egy rakas mas nyelvben is van, hogy kb. a tool definialja a nyelvet, legfeljebb utolag ranyaltak valami cimket hogy ez X szabvany.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Sőt intrinsic megoldásai is vannak a GCC-nek például a SIMD utasításokra. Lásd: /usr/lib/gcc/x86_64-linux-gnu/6/include/
De bármelyiket is használod, elveszíted a C előnyét. Legalábbis azt hogy ARM-on és x86-on is ugyanazt a kódot tudd fordítani.

Egyébként nekem a C-ből az assembly-hez képest a carry direktben való átvétele hiányzott már több alkalommal.

Igen, belinkeltem az Intel-fele intrinsic-eket en is, a GCC-e ugyanaz pepitaban... Nyilvan ertelmes ember assemblyt/SIMD intrinsic-et csak arra hasznal, hogy platform es/vagy CPU-specifikus optimalizaciokat tegyen a kritikus pontokra, opcionalisan a generikus implementacio MELLE... A hulyeken meg ugyse lehet segiteni.

Amugy a carry atvitele pl. mihez kellett volna? Nekem csomo olyan eset jut eszembe erre, amit mindenkinek jobb ha a fordito intez... (Pl. ALU-nal szelesebb aritmetika az adott gepen).

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Annak idején én is írtam direktben C64 grafikát és bár nem jutottam olyan messzire, mint te, de tanulni nagyon jó volt. Tulajdonképpen örülök, hogy az első számítógépem egyszerű volt és nem olyan összetett, mint a maiak. Szerencsések vagyunk, szerintem.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

...A mikroprocesszorok terjedésének kezdetén láttam olyan home made eprom programozót, ahol az egyes memória rekeszek értékét is binárisan kellett beírni úgy, hogy nyolc billenőkapcsolóval beállította az ember a biteket 1-re vagy 0-ra, majd egy nyomógombbal beégette az értéket és lépett egyet a címző áramkör. ...

Hajdanán én is építettem egy ilyen manuális EPROM programozót. DIP kapcsolósor volt a címzés és az adat bevitel is. Vagyis minden bitet kézzel kapcsolgattam. Egy 74123-as TTL IC volt a monostabil multivibrátor (mennyire más értelme van ma ennek a szónak), ami a beégető impulzust adta egy gombnyomásra. Pár száz byteot beégettem így, de nagyon tetszett a dolog. Ha elrontottam jöhetett a kvarclámpa a törléshez és kezdhettem elölről.
Aztán megépítettem az 1982-es Rádiótechnika újság "mikroprocesszoros házi számítógép készítése" sorozatban közölt gépet. Na azzal megtanultam a számítógépek belső működésének fantasztikus világát. Szép emlékek ezek na.

Nagyon buta vagyok, mert a topikban többször is előforduló "párologtató"-t sehogy sem értem. :(

Köszönöm!

Valamikor a 90-es években a sógornőm lánya leültetett a tv elé (amikor megtudta, hogy nekem a Star Wars kimaradt az életemből), mondván, hogy ez alapmű, minden kultúrembernek ismernie kell! Hát kb. negyedórát bírtam ki, aztán megfutamodtam. Tudom, hogy rengeteg rajongója van, nem akarok senkit megsérteni, de szerintem baromság az egész.

Bele a kettes számrendszerbe programozni? Vagy mit szeretnél?

Köszönöm, mindenkinek a válaszát. Megtudtam amit szerettem volna.

Ezt nem nyelvnek hívják, hanem gépi kódnak. Van, aki csinált poénból ilyet is, de 16-os számrendszerben szokták tolni. Lényegében az ASM-et kell hozzá fejből tudni, hogy melyik utasításnak mi a gépi kódja (ez egy vagy több bájtból álló sorozat). Aztán ezt utána olyan számrendszerben ábrázolod, amilyenben akarod.

A Hello Word kiírása oprendszerfüggő is. Egyébként ha van türelmed, ezt a programot írd ki valami scriptel bináris fájlba, és egy disassemblerrel fejsd vissza. Úgy már olvashatóbb alakot ölt. Visszafelé is lehet, egy akármilyen futtatható binárishoz keresel olyan viewert, amelyik nem nem csak hexában jeleníti meg, hanem bináris formában is.

Egyébként a példaként beírt bináris kódod nem tűnik értelmesnek, mivel eleve nem 8-cal osztható bitből áll, de ha csak azt a részt nézem, ami a 8-nak többszöröse, akkor ezt kaptam egy online disassemblerrel:

jo 0x00000041
push esp
pop edi
push 0xffffffdb
cmp edx,0xfaa8eba1
push es
movs DWORD PTR es:[edi],DWORD PTR ds:[esi]
pop ebp
or al,0x94
push edx
pop es
.byte 0xea
int 0xeb
repnz

melyik utasításnak mi a gépi kódja (ez egy vagy több bájtból álló sorozat)

Nem igaz. Egyáltalán nem biztos, hogy 8-cal osztható bit a szószélesség. Nézd például ennek az adatlapnak a 328. oldalától! Ebben a példában 14 bites szervezésű a flash.

Amit írtál, az 80x86, ha jól látom, de megannyi CPU létezik, s lehet olyan, amelyre nézve értelmes. De, ha nem is, lehet olyan hardware-t tervezni alá, amelyben értelmessé válik a kód.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

042577043114000001000000000000000000000000002503000002000003000032002503000032002503000004000000030671041400131005146442022600000040000001146623053600067550071040067165020163064164020145067165067153073557020156071551060440020156062151067551027164000012

011111110100010101001100010001100000000100000001
000000010000000000000000000000000000000000000000
000000000000000000000000000000000000001000000000
000000110000000000000001000000000000000000000000
100000001000000000000100000010000011010000000000
000000000000000011000000000000000000000000000000
000000000000000000000000000000000011010000000000
001000000000000000000010000000000010100000000000
000001000000000000000011000000000000000100000000
000000000000000000000000000000000000000000000000
000000001000000000000100000010000000000010000000
000001000000100010011101000000000000000000000000
100111010000000000000000000000000000010100000000
000000000000000000000000000100000000000000000000
000000010000000000000000000000001010000000000000
000000000000000010100000100100000000010000001000
101000001001000000000100000010000000011100000000
000000000000000000000111000000000000000000000000
000001100000000000000000000000000000000000010000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000010111010000001110000000000000000
000000001011100110100000100100000000010000001000
101110110000000100000000000000000000000010111000
000001000000000000000000000000001100110110000000
101110000000000100000000000000000000000011001101
100000000000000000000000000000000100100001100101
011011000110110011000011101100110000101000000000
001011100111001101101000011100110111010001110010
011101000110000101100010000000000010111001110100
011001010111100001110100000000000010111001100100
011000010111010001100001000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000101100000000
000000000000000000000001000000000000000000000000
000001100000000000000000000000001000000010000000
000001000000100010000000000000000000000000000000
000111010000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000
000100000000000000000000000000000000000000000000
000000000000000000010001000000000000000000000000
000000010000000000000000000000000000001100000000
000000000000000010100000100100000000010000001000
101000000000000000000000000000000000011100000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000000000010000000000
000000000000000000000000000000000000000000000000
000000010000000000000000000000000000001100000000
000000000000000000000000000000000000000000000000
000000000000000000000000000000001010011100000000
000000000000000000010111000000000000000000000000
000000000000000000000000000000000000000000000000
000000000000000000000001000000000000000000000000
00000000000000000000000000000000

Üdv,
Marci

000111111000101100001000000000000010111011001001
111011110101100000000010000000111010101101110111
111101010111000101100011011001000110010001100100
100000000000000100100110000001100110011000000110
000100001010111110100001100000011000010111000011
000001000100100010011111100000011000101010011011
001100000010100000000000111001010011010000011000
010110001010000011110010011000000000000001010100
000000111100001010001011100000000100110000010000
011001100000010110001001000010010011000010000000
111001011001011110000000111100000000010000010110
000011100001000000010110000001001011001001000001
100110000000110100101010100011110000110001110110
100000010010010001110110100000100101010011101101
000001100110100111011011110000010000001000100100
110011100011011011101100000001100100100111101101
011000000000010010110011000110010001100000111100
010100100111001101110010000011100110111101010110
110010000100101111001101010011100100110101010001
110010000010110001010110111001000110001011010000
001010111100111000101000001011100010100100101010
010010010100110001100010110100000010101101001001
101011010010100001100001110100000100101101001001
001011000100100101100100001000000001011001110000
001100110100000011011100110010000000011011110101
001001111101000000001010000001100010010100100100
011110011001100000010011000001011010000111101010
100110000110000101111110100000011000101011000001
000000000000101110010100100001101010100110000001
100000011010110101000000001011001000111011000100
100001111000010100101110000000000010000011101110
000111101000110001101100000000010000000000000000

Így éjszaka awk-ban írtam egy konverziót pár perc alatt, lehet, hogy rossz. Aztán virtuális gépben futtattam az eredményt, miután a file parancs azt mondta, ez egy 32 bites ELF bináris. Saját host-on nyilván nem, nehogy tréfás legyen a dolog, s bukjam a $HOME-omat például. :) Viszont azt mondja, hogy exec format error. Egy UTF-8-as Helló-t azért vélek felfedezni benne. A konverzióm beteg?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jól van, megvan mind a két üzenet. :) Amúgy az xxd-t nem tudtam rászedni a közvetlen konverzióra, ezt írja a manual:

       -b | -bits
              Switch to bits (binary digits) dump, rather than hexdump.   This
              option  writes octets as eight digits "1"s and "0"s instead of a
              normal hexadecimal dump. Each line is preceded by a line  number
              in  hexadecimal and followed by an ascii (or ebcdic) representa‐
              tion. The command line switches -r, -p, -i do not work with this
              mode.

Szóval azt csináltam, hogy maradt az awk scriptem, csak %02x formában írattam ki a konvertált értékeket, amit aztán az xxd-be pipe-olva -r -p kapcsolókkal tettem binárissá. Meg zebránál kellett egy gzip -dc is. :)
Ez ugyan picit off - bár nem is annyira -, közvetlenül awk-ból hogyan írnál byte-ot? Úgy értem, a teljes 0 - 0xff értékkészleten.

Szerk.: Különben a tied miért 1-es exit code-dal tér vissza? Ehhez volt kedved, tudatos?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csak tesztelt kódot szoktam közzétenni. (Idézet magamtól.)
Ha tudni szeretnéd mit csinálsz, akkor LANG=C.ISO-8859-1 (POSIX). Tehát nem az awk magától, hanem Te kéred meg az awk-t, hogy wchar-t használjon. Nem az én linuxom! ;)

Ja, és bináris adatot csak C-ben szoktam írni.

Teljesen jogos:

LC_ALL=C awk 'BEGIN{printf("%c", 255);}' | od -An -tx1
 ff

A saját kódod nálad nyilván működött, de nem általános, mert környezeti változótól függ, hogy jó lesz, vagy sem. Tanulságos, tehát lehet awk-val binárist írni, csak megfelelő környezeti változóval kell hívni.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nincs kedvem takarítani. :) Meg aztán izgatta a fantáziámat, így egy virtuális gépben lévő Fedora 26 még csak alfa kiadáson futtattam. Mert OK, hogy nem feltételezek semmi rosszat, de poénból lehetne írni például olyasmit, hogy rekurzív file törlés, fórumra paste-elni binárisan, az elsődleges gépen futtatva aztán szomorú lenne az a nap. ;)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A topicon felbuzdulva meg szerettem volna csinalni ezt:
HelloWorld.java > HelloWorld.class > HelloWorld.asm > HelloWorld.o > HelloWorld

A HelloWorld.class-bol ezt tudtam eloallitani: https://gist.github.com/anonymous/48b8c101234dbb75b93dc057936bafcb

Innen ugye igy mennek tovabb:

nasm -f elf HelloWorld.asm
ld -s -o HelloWorld HelloWorld.o

De nyilvanvaloan a fentebbi kod nem valid assembly kod. A kerdesem az, hogy mit kell kivagdosni belole, hogy leforduljon?
En azt gondolnam, hogy a 2. es a 3. oszlop kell nekem, de nem vagyok benne biztos, hogy akkor egyaltalan mukodne.

Egyebkent ezt az oldalt hasznaltam a class > asm eloallitasara: https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly
Es ezt a parancsot adtam ki: java -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter HelloWorld > HelloWorld.asm

Btw nincs olyan kapcsolo ami egybol valid assembly kodot ad ki?

Komolyan Java-ból akarsz fordítgatni? Nem lehetetlen, csak minek. Pláne, hogy egy Win32-es bináris Hello World-re rá is lehet guglizni (http://stackoverflow.com/questions/1023593/how-to-write-hello-world-in-…):
; ----------------------------------------------------------------------------
; helloworld.asm
;
; This is a Win32 console program that writes "Hello, World" on one line and
; then exits. It needs to be linked with a C library.
; ----------------------------------------------------------------------------

global _main
extern _printf

section .text
_main:
push message
call _printf
add esp, 4
ret
message:
db 'Hello, World', 10, 0

Alább álljon a hello world alacsony szinten Linux esetére x86 és ARM architektúrára. Ez egyébként C szintaktikával írva:


  write(1, msg, msglen);
  exit(0);

alacsonyszintű Linux rendszerhívásokkal ekvivalens.


.data
msg:
     .ascii      "Hello, x86!\n"
    len = . - msg

.text
.globl _start
_start:
    movl     $1,%ebx
    movl     $msg,%ecx
    movl     $len,%edx
    movl     $4,%eax
    int      $0x80

    movl     $0,%ebx
    movl     $1,%eax
    int      $0x80

Fordítása:
$ as hello.S -o hello.o
$ ld hello.o -o hello -s


.data
msg:
     .ascii      "Hello, ARM!\n"
    len = . - msg

.text
.globl _start
_start:
    mov     %r0, $1
    ldr     %r1, =msg
    ldr     %r2, =len
    mov     %r7, $4
    swi     $0

    mov     %r0, $0
    mov     %r7, $1
    swi     $0


#!/usr/bin/awk -f

BEGIN {
    data="000000000010000000000000001000010000000001001011\
          000000000110010100000000011010000000000001101001\
          000000000110101100000000011011000000000001101101\
          000000000110111000000000011100000000000001110011\
          000000000111010000000000011101100000000011101001\
          000000001111101000000000111111001111111100000010\
          000000110000011100000111000000110000100000000011\
          000010110000000000000100000011110000101100001101\
          000011100000110000000101000000000001000000001001\
          000010010000001100001010000000110000011000000011\
          0000110000000001";
    b=0;
    bcnt=7;
    p=0;
    prn=0;
    i=1;
    while (i<=length(data)) {
        c=substr(data, i++, 1);
        if (c !~ /[01]/) {
            continue;
        }
        b=or(lshift(b, 1), and(c, 1));
        if (!bcnt--) {
            if (b==255) {
                prn=1;
            } else {
                if (prn) {
                    printf("%c", or(lshift(chr[2*b], 8), chr[2*b+1]));
                } else {
                    chr[p++]=b;
                }
            }
            b=0;
            bcnt=7;
        }
    }
    printf("\n");
}

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE