Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 11
  1. #1

    [ASSEMBLY] windows?

    Salve ragazzi!
    Mi sono appena messo a studiare assembly (e quindi funzionamento del processore e dintorni).
    Mi è sorto un dubbio, se ogni tipologia di processore ha un suo assembly diverso (e quindi un suo diverso linguaggio macchina), perchè un eseguibile di windows (EXE), che dovrebbe contenere del linguaggio macchina, funziona su tutti i computer con tale SO?
    Contiene forse istruzioni che poi il sistema operativo rigira opportunamente a seconda del processore in uso? E in questo caso, che senso ha imparare l'assembly quando i nostri exe non conterranno linguaggio eseguito direttamente dal processore?

  2. #2
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,472

    Re: [ASSEMBLY] windows?

    Originariamente inviato da VisRoboris
    se ogni tipologia di processore ha un suo assembly diverso (e quindi un suo diverso linguaggio macchina), perchè un eseguibile di windows (EXE), che dovrebbe contenere del linguaggio macchina, funziona su tutti i computer con tale SO?
    Sino a Windows 8, qualsiasi versione di Windows per desktop (7, Vista, XP, ...) gira sempre su una precisa piattaforma con un unico processore (x86, poi x64).

    Originariamente inviato da VisRoboris
    Contiene forse istruzioni che poi il sistema operativo rigira opportunamente a seconda del processore in uso?
    L'eseguibile contiene chiamate alle DLL che fanno parte del sistema operativo Windows.

    Originariamente inviato da VisRoboris
    E in questo caso, che senso ha imparare l'assembly quando i nostri exe non conterranno linguaggio eseguito direttamente dal processore?
    Il programma viene eseguito dal processore (con il controllo del sistema operativo), ma sono i "servizi" a cui si appoggia ad appartenere a Windows (altrimenti ciascun applicativo dovrebbe riscrivere tutte le funzioni per accedere alle risorse, al disco, ecc.).
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  3. #3
    Utente di HTML.it L'avatar di oregon
    Registrato dal
    Jul 2005
    residenza
    Roma
    Messaggi
    36,480

    Re: [ASSEMBLY] windows?

    Originariamente inviato da VisRoboris
    Mi è sorto un dubbio, se ogni tipologia di processore ha un suo assembly diverso (e quindi un suo diverso linguaggio macchina), perchè un eseguibile di windows (EXE), che dovrebbe contenere del linguaggio macchina, funziona su tutti i computer con tale SO?
    La risposta più immediata (e corretta) è che Windows gira su computer dotati di una CPU di una medesima famiglia ...
    No MP tecnici (non rispondo nemmeno!), usa il forum.

  4. #4
    Quindi windows non funziona su un processore non intel?

  5. #5
    Moderatore di Programmazione L'avatar di alka
    Registrato dal
    Oct 2001
    residenza
    Reggio Emilia
    Messaggi
    24,472
    Originariamente inviato da VisRoboris
    Quindi windows non funziona su un processore non intel?
    No, fatto salvo Windows 8 con Win RT.
    MARCO BREVEGLIERI
    Software and Web Developer, Teacher and Consultant

    Home | Blog | Delphi Podcast | Twitch | Altro...

  6. #6
    grazie ragazzi

  7. #7
    Per gli AMD che mi dite?
    Forse processori amd e intel hanno lo stesso linguaggio macchina?

  8. #8
    Originariamente inviato da VisRoboris
    Per gli AMD che mi dite?
    Forse processori amd e intel hanno lo stesso linguaggio macchina?
    Sì, sono tutti compatibili con l'architettura IA-32 (per le versioni a 32 bit), per cui "parlano" tutti lo stesso assembly. Tuttavia in realtà la questione è più complicata.

    Rispetto all'originale architettura x86 le istruzioni di base sono rimaste le stesse, anche se man mano sono state aggiunte delle estensioni, come i vari set di istruzioni aggiuntivi (MMX, i vari SSE, le istruzioni per supporto alla virtualizzazione,...) e nuove modalità di funzionamento (un processore x86 attualmente appena acceso "emula" se non erro un 8086, e passa in modalità diverse su richiesta del sistema operativo).
    Un programma "per processori x86" può contare sempre sul set di istruzioni di base, e ormai si dà per assodata la presenza di diversi set di estensioni (un caso tipico è SSE2, supportato da praticamente tutti i processori recenti); eventualmente si distribuiscono degli eseguibili diversi per processori più vecchi.
    Un'altra soluzione è verificare "al volo" (tipicamente con l'istruzione CPUID) se il processore supporta certe estensioni o meno, in un caso si eseguirà il codice che usa le estensioni, nell'altro quello senza (se non erro il compilatore Intel è in grado di gestire questa roba in automatico).
    Questo approccio è d'obbligo se quello che si cerca di fare richiede delle estensioni diverse a seconda che ci si trovi su processori AMD e Intel; un esempio sono le estensioni per la virtualizzazione, per cui ci sono due set di istruzioni (e di approcci) differenti, per cui il software di virtualizzazione userà approcci diversi a seconda del processore.

    La questione x86 a 64 bit (spesso chiamata x86_64 o x64) è a sua volta leggermente incasinata, dato che le estensioni a 64 bit all'architettura IA32 sono state inventate da AMD (per cui spesso si parla di architettura AMD64), per poi essere riproposte da Intel (chiamate con diversi nomi fino a stabilizzarsi su Intel64) in termini praticamente identici ma leggermente differenti sotto alcuni aspetti. Fortunatamente le differenze si concentrano solo in questioni che interessano solo il sistema operativo, che suppongo usi un approccio come quello indicato sopra per aggirare il problema.

    Programmi pensati per architettura x86 a 32 bit girano senza problemi su x86_64 perché la CPU è in grado di "fare finta" di essere una CPU a 32 bit, per cui non è necessaria alcuna modifica (per lo stesso motivo per cui è possibile tuttora eseguire programmi x86 a 16 bit su processori a 64 bit).

    La cosa paradossale è che gli attuali processori x86 non c'entrano niente con quella che era l'architettura di una volta, e l'assembly x86 è quasi esclusivamente un layer di compatibilità: ormai all'interno della CPU di fatto gira un processore RISC che elabora le micro-istruzioni corrispondenti alle macro-istruzioni (stile CISC) x86, e "dentro" sono nascosti un sacco di "trucchi" (branch predictor, instruction reordering, ...) tali per cui sembra che il processore esegua le istruzioni così come sono scritte, ma di fatto "di nascosto" riordina, esegue pezzi di codice contemporaneamente e/o speculativamente e fa ogni sorta di strane ottimizzazioni.

    Ovviamente, dato che, a seconda della famiglia di processori considerata, quello che sta "sotto al cofano" cambia, l'ottimizzazione diventa una questione estremamente complicata: poche istruzioni assembly non corrispondono necessariamente a codice efficiente, e spesso soluzioni apparentemente meno efficienti risultano molto più veloci di altre più compatte.

    Sì, l'architettura x86 è un gran casino.
    Amaro C++, il gusto pieno dell'undefined behavior.

  9. #9
    Mi hai chiarito le idee, grazie! ;D
    Per spingere al massimo il mio computer, l'idea che mi ha spinto a studiare l'assembly, dovrei quindi poter programmare usando quelle micro-istruzioni ? Purtroppo sono tenute segrete e inaccessibili. Quale orribile sensazione nasce dalla consapevolezza dell'impossibilità di avere il totale controllo sulla propria macchina.

  10. #10
    No, le microistruzioni sono un dettaglio implementativo del processore (tra l'altro non vengono neanche usate per tutte le istruzioni), e non vengono rese pubbliche perché cambiano di processore in processore - se venissero usate, allora sì che sarebbe un casino e ci vorrebbe un binario diverso per ogni processore. Leggi ad esempio qui, la questione è spiegata abbastanza bene.

    Tieni comunque presente che ormai praticamente nessuno scrive più interi programmi in assembly su architettura x86; in genere se si ha bisogno di performance notevoli si scrive il codice in un linguaggio compilato - tipicamente C o C++, linguaggi abbastanza vicini alla macchina, i cui compilatori hanno ottimizzatori estremamente sviluppati, scritti da persone che conoscono bene cosa è lento e cosa è veloce sui processori attuali.
    Se comunque si hanno problemi di prestazioni si effettua il profiling per vedere in quali zone conviene lavorare. Quando tutto il resto fallisce, solo se si sa esattamente cosa si sta facendo si ricorre all'assembly, limitato ai punti critici del programma.
    Amaro C++, il gusto pieno dell'undefined behavior.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.