Egyéb: Assembly, Ada...

Sziasztok!

Van egy kb. 30 éves program amit próbáltam virtualbox, és vmware alatt is futtatni. A hostra még feltelepítettem a com0com virtuális port emulátort. (putty segítéségével látom is hogy COM1 tükröz COM2 re, oda vissza, gépelgettem terminálablakban). Emulált Windows al is kipróbáltam, hogy a hozzáadott com1 et látom a host gép com2 portján.

A problémám, hogy a futtatót dos alapú program kommunikációját sehogy nem látom. Probáltam COM1 sé COM2 paraméterrel. A programban nem sok az infó.

Hogyan tudnám elfogni virtuális gépben???

Kiolvasott asm FÁJLBAN ILYEN SZÖVEGEK VANNAK:

;=== CPU 8251 PROGRAMSZAVAI ES CIMEI ===
;
MOD51    EQU    0EEH    ; 9600,8 BIT,NINCS,2 STOP,x16        ( 1110 1110 )
COM51    EQU    37H    ; COMMAND SZO                ( 0011 0111 )
RES51    EQU    40H    ; RESET SZO                ( 0100 0000 )
SIODAT    EQU    0F0H    ; ADATREGISZTER CIME
SIOCOM    EQU    0F1H    ; PARANCSREGISZTER CIME
;
;=== CPU 8255 PROGRAMSZAVA ES CIMEI ===
;
CPUMOD    EQU    81H    ; CPU KARTYA 8255-OS PARANCS SZAVA    ( 1000 0001 )
;
CPUAP    EQU    0F8H    ; CPU KARTYA 8255-OS 'A' PORT CIME
CPUBP    EQU    0F9H    ; CPU KARTYA 8255-OS 'B' PORT CIME
CPUCP    EQU    0FAH    ; CPU KARTYA 8255-OS 'C' PORT CIME
CPUPP    EQU    0FBH    ; CPU KARTYA 8255-OS PARANCS CIME
;
;=== CPU 8253 PROGRAMSZAVAI ES CIMEI ===;
;
TIM0P    EQU    36H    ; 0-AS TIMER PARANCS SZAVA        ( 0011 0110 )
TIM0A    EQU    0DH    ; 0-AS TIMER ALSO BYTE ( 1=68H, 2=0DH, 4=1AH )
TIM0F    EQU    00H    ; 0-AS TIMER FELSO BYTE
;
TIM1P    EQU    70H    ; 1-ES TIMER PARANCS SZAVA        ( 0111 0000 )
TIM1A    EQU    50H    ; 1-ES TIMER ALSO BYTE
TIM1F    EQU    0C3H    ; 1-ES TIMER FELSO BYTE
;
TIM2P    EQU    0B1H    ; 2-ES TIMER PARANCS SZAVA        ( 1011 0001 )
TIM2PO    EQU    81H    ; 2-ES TIMER OLVASA PARANCS SZAVA    ( 1000 0001 )
TIM2A    EQU    14H    ; 2-ES TIMER ALSO BYTE
TIM2F    EQU    00H    ; 2-ES TIMER FELSO BYTE
;
TIM0C    EQU    0E8H    ; 0-AS TIMER CIME
TIM1C    EQU    0E9H    ; 1-ES TIMER CIME
TIM2C    EQU    0EAH    ; 2-ES TIMER CIME
TIMCC    EQU    0EBH    ; TIMER PARANCS CIME
;
;=== NYOMOGOMBOK ES ERZEKELOK LEKERDEZES CIMEI ===
;
INMOD    EQU    9BH    ; INPUT KARTYA 8255-OS PARANCS SZAVA    ( 1001 1011 )
;
OUTAP    EQU    30H    ; ALSO 8 BIT CIME
OUTBP    EQU    31H    ; FELSO 4 BIT ES MASODKIJELZO CIME
OUTCP    EQU    32H    ; MASODKIJELZO CIME
OUTPP    EQU    33H    ; PARANCS CIME
;
APNY    EQU    9CH    ; NYOMOGOMB ALSO 8 BIT CIME
BPER    EQU    9DH    ; ERZEKELO ALSO 8 BIT CIME
CP03NY    EQU    9EH    ; NYOMOGOMB FELSO 4 BIT CIME
CP47ER    EQU    9EH    ; ERZEKELO FELSO 4 BIT CIME
NY_ERP    EQU    9FH    ; NYOMOGOMB ES ERZEKELO PARANCS CIME
;
;=== OUTPUT 8255 PROGRAMSZAVA ES CIMEI ===
;
OUTMOD    EQU    80H    ; OUTPUT KARTYA 8255 PROGRAMSZAVA    ( 1000 0000 )
;
OUT1AP    EQU    20H    ; 1. 8255-OS 'A' PORT CIME
OUT1BP    EQU    21H    ; 1. 8255-OS 'B' PORT CIME
OUT1CP    EQU    22H    ; 1. 8255-OS 'C' PORT CIME
OUT1PP    EQU    23H    ; 1. 8255-OS PARANCS CIME
;
OUT2AP    EQU    24H    ; 2. 8255-OS 'A' PORT CIME
OUT2BP    EQU    25H    ; 2. 8255-OS 'B' PORT CIME
OUT2CP    EQU    26H    ; 2. 8255-OS 'C' PORT CIME
OUT2PP    EQU    27H    ; 2. 8255-OS PARANCS CIME
;
OUT3AP    EQU    28H    ; 3. 8255-OS 'A' PORT CIME
OUT3BP    EQU    29H    ; 3. 8255-OS 'B' PORT CIME
OUT3CP    EQU    2AH    ; 3. 8255-OS 'C' PORT CIME
OUT3PP    EQU    2BH    ; 3. 8255-OS PARANCS CIME
;
OUT4AP    EQU    2CH    ; 4. 8255-OS 'A' PORT CIME
OUT4BP    EQU    2DH    ; 4. 8255-OS 'B' PORT CIME
OUT4CP    EQU    2EH    ; 4. 8255-OS 'C' PORT CIME
OUT4PP    EQU    2FH    ; 4. 8255-OS PARANCS CIME
;
;=== A/D 8255 PROGRAMSZAVA ES CIMEI ===
;
MODEW    EQU    83H    ; A/D KARTYA 8255-OS PARANCS SZAVA    ( 1000 0011 )
LSB    EQU    50H    ; 1. PROGRAM SZO
MSB    EQU    30H    ; 2. PROGRAM SZO
BSZ    EQU    08H    ; 3. PROGRAM SZO
;
AD1AP    EQU    40H    ; 1. A/D KARTYA 8255-OS 'A' PORT CIME
AD1BP    EQU    41H    ; 1. A/D KARTYA 8255-OS 'B' PORT CIME
AD1CP    EQU    42H    ; 1. A/D KARTYA 8255-OS 'C' PORT CIME
AD1PP    EQU    43H    ; 1. A/D KARTYA 8255-OS PARANCS CIME
;
AD2AP    EQU    48H    ; 2. A/D KARTYA 8255-OS 'A' PORT CIME
AD2BP    EQU    49H    ; 2. A/D KARTYA 8255-OS 'B' PORT CIME
AD2CP    EQU    4AH    ; 2. A/D KARTYA 8255-OS 'C' PORT CIME
AD2PP    EQU    4BH    ; 2. A/D KARTYA 8255-OS PARANCS CIME
;

Egyébbe tettem jobb ötlet híján, retro kérdés következik :)

A kérdésem túl régi és túl specifikus, vagy az is lehet hogy egész egyszerűen nem látom a fától az erdőt, de talán valaki tud segíteni és fényt hozni.

Az eredetileg (és valós módban utána is) 20 bites címzéssel rendelkező x86 processzorok, jelen esetben a 8088 és 8086ra gondolok, műkődképesek DOS 1.0 - DOS 6.22 rendszer mindegyikével. Az 1 megabyteos eredeti memória klasszikus felosztása hogy van a Conventional Memory, ami 0-640K (10x64K - ez mindenre elég, világos), aztán van az UMA, az Upper Memory Area, ami 384k méretű és elvileg mindig ennyi és mindig ott (?) (640K-1024K). Verziótól függően ebben lehet TSR, DEVICE, de még a DOS egy része is.

A kérdésem az, hogy mi van azokban az esetekben, amikor 1MB-nál kevesebb volt az elérhető RAM? többek közt volt 128K, 384K, 512K, 640K méretű kiszerelés is az IBM PCből. Ilyenkor hol van vagy hogy értelmezendő az UMA?  

Fény útjának modellezése 3D-s kép rendereléséhez, mindez kevesebb, mint 512 bájtban. Ugyanaz az Oscar Toledo követte el, akinek a világ legkissebb sakkprogramját is köszönhetjük (ami természetesen C-ben íródott és IOCCC nyertes ;-) ).

A raytracker forrása és qemu-ban indítható binárisa elérhető itt:
https://github.com/nanochess/RayTracer

Mint bármelyik boot szektor, Assembly-ben íródott és csak valós módú utasításokat használ, ezért MS-DOS .com programnak is lefordítható. A fordításhoz a Netwide Assembler szükséges.
A megjelenítés érdekessége, hogy palettás módot használ, mindössze 256 színnel (azaz fix színekkel dolgozik, nincs true color mixing).

Korábban csinált már raycasting-ot is boot szektorban (az, amire a Doom is épül, nem azonos a raytracinggel).
https://en.wikipedia.org/wiki/Ray_casting
https://en.wikipedia.org/wiki/Ray_tracing_(graphics)

Bár sok értelme nincs, mégis hatalmas pacsi Oscar-nak! Na, ő az igazi szent őrült, nem én :-)

Elegem lett a sok nagyszájúból, ezért úgy döntöttem, lehetőséget adok nektek a gyakorlatban is bizonyítani, és egy versenyre hívlak ki Titeket!

Amennyiben nem érkezne egyetlen működőképes beadvány sem, vagy a C nyerne, akkor azt úgy kell érteni, hogy valójában a gyakorlatban egyik csodanyelv sem képes leváltani a C-t, és továbbiakban nem hangoztathatjátok ezt a HUP-on. Ha nem a C nyerne, akkor pedig vice versa, megígérem, hogy nem fogom a továbbiakban az orrotok alá dörgölni, hogy felültetek a hypenak és bedőltetek a marketing bullshitnek. Ez így fair, nem?

https://gitlab.com/bztsrc/langcontest

A feladat: egy olyan rendszerprogram írása, ami nem csinál mást, mint másodpercenként eggyel növel egy számlálót a képernyőn. Elég egyszerű, nem lehet probléma bármilyen nyelven megírni ezt, igaz?

A verseny szabályait igyekeztem úgy kialakítani, hogy azok a lehető legegyenlőbb feltételeket biztosítsák, bármilyen nyelvről és fordítóról is lett légyen szó, és igazságos összehasonlítási alapot szolgáltassanak:

- architektúrának a 64 bites x86-ot választom, mert arra minden nyelvhez biztos van fordító és könnyedén tesztelhető, ráadásul tele van hozzá doksival a net
- mivel nincs oprendszer, a betöltőt biztosítom, emiatt nem kell aggódni, nektek csak egyetlen lefordított rendszerprogramot kell csinálni
- bármilyen nyelv használható, az Assembly-t leszámítva (a betöltő teszteléséhez egy Assembly-ben írt referencia implementációt biztosítok)
- inline Assembly nem, csak az adott nyelv natív utasításkészlete használható, a forrásnak hordozhatónak kell lennie (azaz hiba nélkül le kell fordulnia többféle architektúrán, akkor is, ha úgysem működne ott)
- nem használható semmi olyan kulcsszó vagy opció, ami kikapcsolja a nyelv alap funkcióit, mert az úgy már nem a csodanyelv lenne (pl Rust-ban az unsafe/unmanaged, vagy C++ alatt az -fno-exceptions/-fno-rtti nem megendegett)
- bármilyen más kulcsszó, parancssori opció használható, akár fordítóspecifikus, architektúraspecifikus is (például hívási, optimalizálási, ellenőrzési, kódgenerálási, linkelési stb., bármi más mehet, csak a nyelv alapkészletét tilos leszűkíteni)
- bármilyen fordító megengedett, ami képes az adott nyelvet lefordítani (például Go esetén gcc-go/golang, C esetén gcc/Clang stb., semmilyen megkötés nincs a fordítóra)
- bármilyen szabványos függvénykönyvtár használható, ami a nyelvvel és a fordító telepítésével együtt érkezik vagy Ti írjátok, de harmadik féltől származó, netről letöltött nem (ha a nyelvnek van bare metal változata, természetesen azt is ér használni)
- bármilyen fordítási segédprogram megengedett, olyan is, amit külön kell telepíteni vagy saját fejlesztésű (például interface bindolók, fejléc generálók, linker szkriptek, binutils, make/mk/cmake/ant/scons/meson/ninja/azanyjakinyja stb.)
- a lefordított program nem lehet nagyobb, mint amit egyetlen BIOS hívással be lehet tölteni a lemezről (65024 bájt)
- a képernyőre VGA teletype módban kell írni (ASCII karakter (0x30 - 0x39) + attribútum (0x07 fehér) párosokból álló tömb a 0xB8000 fizikai címen a Video RAM-ban)
- a pollozás nem megengedett, mert az nem lenne sem hatékony, sem energiatakarékos, sem pontos
- a program megírására 1 hónap áll rendelkezésre
- egy program többször is módosítható és többször is beadható ez idő alatt, a legutolsó fog számítani (lehet reagálni a mások által beadott pályaművekre, és lehet újabb optimalizációkkal előrukkolni)
- a nyertes az a program, ami a legkevesebb segédprogramot, kulcsszót és specifikus opciót használja az adott nyelv készletéből (magyarán ami a legkevésbé gányolt), ezen kívül pedig ami legkissebb bájtméretű, működő binárist produkálja, holtverseny esetén meg ami a kevesebb memóriát fogyasztja futás időben (vermet is beleértve)

A felsorolt limitációk a hardveres futási környezet sajátosságai (long mód, BIOS betöltés, VGA képernyő), ezek nem megkerülhetőek, muszáj alkalmazkodni hozzájuk.
Elvileg a 64 bites long mód nem tartozna ide, de ennélkül már a verseny indulása előtt nyerne a C és elvérezne az összes többi csodanyelv... :P De jófej leszek és esélyt adok nektek, így legyen hát 64 bit only.

A függvénykönyvtárakra vonatkozó megkötés azért került bele, hogy csak a nyelv maga számítson. Standard lib használható, de el is hagyható, 3rd party lib viszont tilos, mert az már nem a nyelv része.

Hogy a fordítási környezetből adódó eltéréseket is kiiktassuk, két betöltőt is biztosítok: az első ELF binárist tölt be, és SysV ABI-t használ:

cat boot_elf.bin programod.elf > disk.img

A másik pedig PE/COFF binárist és MS fastcall ABI-t (pont, mint az UEFI):

cat boot_pe.bin programod.exe > disk.img

Mindkét esetben az elkészült virtuális lemezt qemu alatt, a következő paranccsal kell tudni futtatni:

qemu-system-x86_64 disk.img

Hogy a programokba tényleg ne kelljen Assembly betét, a betöltő a bináris fejlécében megadott linkcímekre másolja a szegmenseket, kinullázza a bss-t, beállítja a vermet lefele növekvően 640K-ra, az alacsonyszintű CPU utasításokhoz pedig interfészt és wrapper függvényeket biztosít, mielőtt a belépési pontot meghívná.
Relokációt nem végez, a programot linkeljétek valaholva a 96K és 640K vagy az 1M és 2M közé, ahová jólesik, és több szegmensből is állhat akár.

Az interfészt pontosan ugyanúgy kell használni, mint UEFI esetén, csak itt más függvényeket tartalmaz. Ennek a C nyelvű definíciója:

typedef struct {
  void (*load_idt)(const void *buffer, const uint16_t size);  /* betölti a megszakításkezelőket */
  void (*enable_interrupts)(void);                            /* engedélyezi a megszakításokat */
  void (*disable_interrupts)(void);                           /* letiltja a megszakításokat */
  void (*iretq)(const int localsize);                         /* visszatér a megszakításkezelőből */
} almost_efi_system_table_but_not_quite_t;

A program belépési pontja egy mutatót kap paraméterül erre a struktúrára, pontosan úgy, mint UEFI-nél.
EDIT: mivel sokan sírtatok, ezért módosítás: az összes paraméternél kiírtam, hogy const, ha ez nem lett volna egyértelmű, és ezeknél a függvényeknél, és szigorúan csakis ezeknél az interfész által biztosított függvényeknél használható Rust alatt az unsafe. VAGY Az interfészt egyáltalán nem kötelező használni, le is implementálhatjátok ezt a négy függvényt Rust-ban, ekkor azonban nem lesz külsős függvényhívás, így ilyenkor tilos az unsafe.

Továbbá, hogy még a hardverprogramozási készségek se számítsanak, és tényleg csak a nyelveket mérjük össze, a betöltő megteszi azt a szívességet is, hogy előre felprogramozza a megszakításvezérlőt valamint a PIT-et másodpercenkénti 100 IRQ megszakításra, azonban nem kezd megszakításokat generálni, míg az enable_interrupts() függvényt meg nem hívjátok.
Hasonlóan az iretq() hívás gondoskodik a megszakításvezérlőben az IRQ nyugtázásáról is, így azzal sem kell törődnötök. A load_idt() híváshoz segítségként, 32 kivételfajta van és 16 IRQ, a kódszelektor a 32-es, a megszakításkapu attribútuma meg a 0x8E.

Itt az alkalom, hogy bizonyítsátok, a Go, Rust vagy bármelyik másik agyonhypeolt csodanyelv valóban képes lehet a C leváltására! Én állítom, hogy nem, bizonyítsátok be, hogy tévedek! Versenyre fel!

Üdv!

Érdekelne, ha valaki használ-e itt wise-ot, milyen díjak merülhetnek fel használat közben. Nézegettem az oldalukat, de maradt bennem egy kérdés. Ha HUF számláról HUF-ra utalnék annak mi a díja?

Illetve kártyás fizetés hogyan megy?

Létezik virtuális kártya is, hogy pl. NFC-s telefonnal lehessen fizetni, vagy mindenképpen kell fizikai kártya amit aztán hozzá tudok adni pl. Google Pay-hez?

Az Erste betéti kártyájától akarok megszabadulni, mert lassan ott tartunk, hogy évi 10 rugó.

Ha jól működne, akkor átdobom a gubát wise-ra, erstének meg visszaadom a kártyát. Egyék meg.
A hitelkártya még egyelőre fenntartható költségekkel üzemel, de nem sokat fogok rajta évente szerintem. Ezt is újra kell számolnom majd.

Már régebb óta gondolkodom a dolgon, de az apropót most ez a cikk adta.

Azt hogyan tudom ellenorizni egy AVR assembly forraskodban, `avr-as` segitsegevel forditvan hogy milyen architekturara is forditjuk? Peldaul: `avr-as -mmcu=avr31 -o xyz.o xyz.s` es akkor a *.s-ben meg ilyesmik lennenek, mint:

.if (avr3 | avr31 | avr5)
.set SOMETHING, 8
.else
.set SOMETHING, 4
.endif

Es akkor ezen fenti parancsnal a SOMETHING erteke 8 legyen merthogy AVR31-es az architektura. Szoval mit is irjak az elso `.if ...` sor helyere ha epp a fenti architekturakra gondol a kolto... Konkretan ezalapjan probalkoztam, meg az itt elpottyintett avr-as understands the same -mmcu= options as avr-gcc mondat alapjan biztam benne hogy egy `.if (AVR_ARCH == 31)` pl jo lehet, de sajnos nem :/

Koszi, A.

Sziasztok,

kiváncsi volnék személyes tapasztalatokra Rust nyelven leszállított szoftvereket/szolgáltatásokat illetően. Miben van felhasználva, hobbi fejlesztés vagy termék? Megérte Rust-ban dolgozni? Ha igen, miért? Melyik nyelvet váltotta ki?

Érdekelne az is, milyen IDE (integrált fejlesztői környezet) használata vált be Rust-hoz?

Köszönöm!

Sziasztok. 

Használja valaki a címben említett programot? 

Az egyik ügyfél szeretne teljesen automatikus analízis végezni, a végén pedig egy riportot készíteni. A gond az, hogy nem tudjuk meg oldani azt, hogy a létrehozott file név végére oda rakjon valamit, például a dátumot, időt, akármit. Ha létre hozom a makrót, be állítom, hogy rakja a kívánt filenév mögé a dátumot és le futtatoom, csinálja,ha közben szeretném rögzíteni akkor "Unable to save file path" hibát dob. 

Köszi! 

Nemrég találkoztam szembe a V nyelvvel és úgy látom nagyon gyors tempóban fejlődik. Azt írják, hogy 80%-ban Go, egyszerű szintaxis, gyors a fordítás, van web része stb...
Van aki használja esetleg? Tapasztalatok, vélemények? Itt van egy csomó példa róla. Igazából az (is) érdekelne, hogy Go vagy inkább V?

Adott egy XML adatformátum aminek a problémás része így néz ki:

<parent0>data</parent0>
<parent1>
    <child id=\"1\" man=\"0\">Olivia</child>
    <child id=\"2\" man=\"0\">Sara</child>
    <child id=\"3\" man=\"1\">Jack</child>
</parent1>
<parent2>123456</parent2>

A parent0 és parent2 adatokkal nincs gond. Azt fel tudom dolgozni. 
A parent1-ben lévő adatokból viszont vagy csak a neveket tudom egy tömbbe tenni, vagy a paramétereket struct-ként majd tömbbe.

Van-e valami mód arra, hogy a structban megjelenjen az egyes child-ek adatjai is, ne csak a paraméterek?

serde_xml_rs-t használok.
 

Tippem szerint valahogy meg kellene mondani hogy a benne lévő adat (a nevek) a struct-ban milyen néven van benne.