I floppy disk sono obsoleti, ma non per il programma nucleare USA

[maxnaldo]

quindi è solo Hollywood che ci mostra incredibili e fantascientifiche tecnologie nelle loro sale di controllo ?

in realtà il massimo della tecnologia utilizzata è un C64 ?

[YetAnotherNewBie]

Avevano provato nel 1983 ad installare presso il NORAD il sistema WOPR, ma non gli era andata troppo bene.
Da allora hanno deciso di non aggiornare più...

[s5otto]

Premetto le scuse ma avendo letto quanto sopra in tanti post ,m'è irresistibile la voglia di dire : io c'ero.

Beh! certo nulla di che!, anche tanti di voi c'erano non parliamo di 100 anni fà ...... se però penso che sul Data General CS-50 col cobol dovevo stare nei 24mb di programma ..... per cui si andava a distinguere quanto pesava meno l'istruzione SET A=B al posto della MOVE A TO B .

Il disco removibile era di questo tipo ... https://upload.wikimedia.org/wikiped...tridge.agr.jpg

...... che dite? glielo mando il curriculum

[Vi7o]

Chi ha detto che l'Assembly è obsoleto?
Istruzioni Assembly sono tuttora utilizzate su tutti i pc...in maniera trasparente all'utente...
Oltretutto l'Assembly è il secondo linguaggio più veloce...

[aled1974]

Originariamente inviato da fabio892

usano tali sistemi perchè sono immuni dall'emp di una bomba nucleare nemica.

sicuro sicuro?

i floppy sono magnetici, semmai sarebbe meglio un cd/dvd allora

ma il resto del pc che legge/scrive sti floppy come funziona? con circuiti elettronici o per magia?

ciao ciao

[cdimauro]

Originariamente inviato da Vi7o

Chi ha detto che l'Assembly è obsoleto?
Istruzioni Assembly sono tuttora utilizzate su tutti i pc...in maniera trasparente all'utente...

Sì, ma si usa di gran lunga di meno rispetto al passato, ed è ormai relegato a una nicchia.

Oltretutto l'Assembly è il secondo linguaggio più veloce...

Il primo qual è?

[Simonex84]

Originariamente inviato da cdimauro

Il primo qual è?

10101110101000101011110101010101010011.......

[cdimauro]

Lo immaginavo, ma... è veloce uguale.

[Simonex84]

Originariamente inviato da cdimauro

Lo immaginavo, ma... è veloce uguale.

Non avendo mai scritto nulla in binario non saprei, però in assembly si, in certi ambiti embedded è l'unica soluzione applicabile, i linguaggi di alto livello non vanno bene

[cdimauro]

Già. Pero con l'assembly traduci uno mnemonico in un equivalente binario. Diciamo che sostanzialmente non c'è alcuna differenza (perché preferisco non scendere in certi dettagli).

[massimo79m]

"Un'impiegata del Dipartimento della Difesa USA? Non proprio, ma il computer è lo stesso utilizzato oggi dal Pentagono nell'ambito del programma nucelare"

Nuculare, si pronuncia nuculare
https://www.youtube.com/watch?v=Zl4SmzIreSs

[jackseagull]

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.

[Vi7o]

Originariamente inviato da cdimauro

Già. Pero con l'assembly traduci uno mnemonico in un equivalente binario. Diciamo che sostanzialmente non c'è alcuna differenza (perché preferisco non scendere in certi dettagli).

Non proprio, l'Assembler traduce l'Assembly in Linguaggio Macchina...
traduce = perde tempo

[MiKeLezZ]

Originariamente inviato da jackseagull

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.

e allora perché li aggiornano tutti?

[cdimauro]

Originariamente inviato da Vi7o

Non proprio, l'Assembler traduce l'Assembly in Linguaggio Macchina...
traduce = perde tempo

E il linguaggio macchina come lo traduci in binario?

Posto che l'operazione di traduzione in ambo i casi si fa una volta, e una volta generati i binari si eseguono questi.

[Vi7o]

Originariamente inviato da jackseagull

la realtà è che tali sistemi sono MOLTO più sicuri degli attuali. É un fatto da considerare più che un opinione.

più che sicuri, forse sono molto più collaudati ma soprattutto più economici
nelle banche si usa il COBOL solo per sto motivo

un floppino con una puntina che va a graffiare fisicamente il disco magnetico(vi ricordate quanto casino facevano), non so quanto sia affidabile e veloce...sicuramente li backupperano in modalità usa e getta

Originariamente inviato da cdimauro

E il linguaggio macchina come lo traduci in binario?
Posto che l'operazione di traduzione in ambo i casi si fa una volta, e una volta generati i binari si eseguono questi.

Il Linguaggio Macchina è in binario...

[cdimauro]

No. Agli inizi era stampato su schede perforate.

Poi sono arrivati i listatoni con sequenze binarie o esadecimali, che infine generavano il binario.

In breve: una codifica per il linguaggio macchina c'è sempre stata, perché è necessaria (in qualche modo devi scriverlo quel codice).

[FedericoP.1992]

Non affiderei la mia vita ad un floppy. A quanto pare però è affidabile

[Vi7o]

Le macchine leggono solo il Linguaggio Macchina(binario), che poi "leggono" schede perforate(in binario) o listati(in binario) o cd(in binario) o pendisk(in binario) o nastri(in binario), dipende solo dall'interfaccia di lettura della suddetta macchina

Quindi in un ipotetica macchina che ha due ingressi di lettura:
1 - linguaggio macchina
2 - assembly

nel primo caso il codice sarà letto al volo, nel secondo sarà letto in assembly e tradotto in linguaggio macchina

[rockroll]

Originariamente inviato da Bellaz89

l'assembly di solito non viene interpretato.. di solito viene trasposto in binario per una sola volta. Non c'e' differenza sulle prestazioni rispetto a un file binario scritto a mano che rappresenta lo stesso programma. (Gli) L'assembly e' stato creato proprio per questo motivo!

Inoltre secondo me parlare di velocita' del linguaggio e' scorretto. La velocita' finale dipende da un infinita' di fattori e a volte scrivere tutto in assembly non produce il risultato migliore. Cosi' per fare un esempio non credo che esista nessuno che riesca a produrre a mano il codice assembly di un programma molto complesso che va piu' veloce di un analogo scritto in C/C++/Fortran/(InserisciLinguaggioImperativoStatico) con un compilatore ottimizzante moderno. Magari alcune piccole parti o funzioni ha senso che siano scritte in assembly, ma su tutto il programma e' una cosa senza senso e controproducente.

Premettendo che "io c'ero" (si, sono un vecchione che ha vissuto gli albori dell'informatica), vorrei dare alcune spiegazioni sul tema, perchè, per quanto basilari, vedo che ce n'è bisogno.

Un progamma in Assembly (ovvero Assembler), il cui codice sorgente (source) viene compilato una tantum per tradurlo in programma oggetto (Object ovvero Assoluto ovvero Codice Macchina ovvero Formato Binario), verrà poi sempre eseguito in questo formato, almeno fino a nuova compilazione per sopraggiunte modifiche del codice sorgente.
Ma non è vero che ogni riga di codice source corrisponda sempre one to one ad un'istruzione object, caso mai ogni istruzione source può avere questa corrispondenza. A seconda del compilatore adottato, alcune case hanno creato forme di Assembler più avanzate, dove una riga di codice può essere sviluppata in più istruzioni macchina, cioè si dono "inventati" alcune espressioni di codice sorgente aggiuntive, di uso generale ma magari anche personalizzate al campo di utilizzo verso cui questo compilatore è più o meno orientato. Ma anche parlando di compilatore base, standard, il programmatore stesso più che la casa produttrice può ricorrere all'uso di macroistruzioni, creandosi una libreria personalizzata ai suoi scopi: in questo caso le cosidette "macro" vengono preepanse nelle istruzioni source corrispondenti prima di essere passate alla fase di compilazione standard.
Non solo, ma possono esistere preconfezionate (generallizzate) oltre che preparate dai programmatori (personalizzate) intere librerie di subroutines precompilate, che svolgono funzioni ripetitive di frequente occorrenza, richiamabili opportunamente nel corso del programma. Sia in caso di macro che di "Call" (o anche "Functions" implicite, cambia solo la grafia) si tratta non certo di istruzioni base ma di espressioni source aggiuntive che il compilatore svilupperà traducendole in sequenze di istruzioni binarie a volte anche molto estese (in realtà l'aggancio ed incorporazione delle subroutine in formato oggetto avviene in una fase successive chiamata "Linkedit").
Ora è chiaro che sviluppi di macro e subroutines più o meno generalizzate (che in source si richiamano con una istruzione avanzata corredata da parametri), avranno un'efficienza più o meno grande a seconda dl livello di generalizzazione e sopratutto di accuratezza con le quali sono state realizzate, ma una cosa è certa: istruzioni di base one to one scritte da un buon programmatore che intenda ottimizzare al massimo il risultato ovvero la velocità di esecuzione, saranno sempre potenzialmente più effcienti di sviluppi di espansioni più o meno automatiche generate dal complatore, per ottimizzato che possa essere; spesso in fase di sviluppo macro o inclusione linkedit finiscono per introdursi intere sequenza spurie di codice binario che potrebbero servire in casi particolari, ma anche il solo riconoscerle e bypassarle oltre ad impostazione dei parametri vari per le chiamate e recupero del risultato, costa risorse aggiuntive a fondo perso. Una programmazione manuale, volendo, potrebbe evitarlo.
All'atto pratico tutto l'inut/output viene gestito da complesse macro, ed una parte non trascurabile dell'Object sono call con tanto di parametri. Se poi andassimo nei linguaggi molto più avanzati e molto più recenti, vedremmo un assoluto quasi interamente composto di impostazione parametri e call a librerie precotte da tutte le parti.
Alla faccia dell' efficienza; senza voler parlare dello scempio totale di risorse dei linguaggi attuali, che guazzano in programmazione strutturata, non procedurale, per finire in programmazione Object Oriented..., con tanto di vincoli e blocchi e regole e regolette ed espressioni cervellotiche che per la macchina non hanno proprio senso, una per tutte le classi di oggetti che ci/vi obbligano ad adottare, e che quale legame col codice macchina possano avere lo sannno solo i propugnatori di dette metodologie, che sacrificano l'efficenza macchina e pulizia e linerità e sinteticità della programmazione sull'altare di un malinteso scopo di produttività e leggibilità (e su quest'ultima, mi scappa da ridere...).