Domanda:
mi sapete indicare una guida per programmare in codice binario?
gnoll
2009-01-08 18:16:31 UTC
sono arrivato ad un livello piuttosto avanzato in linguaggi di programmazione e vorrei capire come facevano prima a creare programmi solo con il codice binario.
p.s. evitate di dirmi che è imposssibile...
Quattro risposte:
Ciripillo
2009-01-08 18:35:48 UTC
L'istruzione Assembler LDA #$1F in memoria per il processore puo' essere per esempio $41 $1F

Quindi in un'ipotetica scheda perforata con 8 possibili fori incolonnati, si poteva mettere nel calcolatore in binario:



01000001

00011111



Quindi con lunghe sequenze binarie comunicavi il programma da eseguire.

Lo fai anche adesso ma il linguaggio agevola il lavoro, ma come ben sai la logica del computer e' comunque binaria.



Ovviamente anche un solo numero o bit mancante manda in tilt tutta la sequenza e il programma corrispondente (come adesso del resto!).
Tizio 008
2009-01-09 01:14:18 UTC
santa pazienza. senza tornare indietro addirittura alle schede perforate, "bastava" un programmatore di eeprom (magari autocostruito!) e poi un manuale del processore per cui si intendeva scrivere il codice, e poi pazienza: inserire un codice dopo l'altro... (non proprio in binario... si poteva benissimo avere un tastierino numerico per inserire cifre direttamente in decimale o esadecimale... una comodità);



oggi i programmotri di eprom si interfacciano a un computer in senso moderno, e dunque si può "caricare" sulla eprom di tutto con poco sforzo.



ma se ci tieni a sperimentare la fatica certosina con equipaggiamenti moderni, puoi provare il seguente percorso:



a) procurati un buon manuale completo di opcode per il processore che vuoi usare (diciamo intel x86)

b) scrivi il tuo codice su carta usando il linguaggio assembly

c) sempre con carta e penna, converti ogni istruzione nel/nei byte/s corrispondenti, per comodità puoi scriverli in esadecimale...; ora hai una lunga sequenza di byte... e naturalmente questa è la parte critica

d) ora devi inserire quei byte per memorizzarli da qualche parte...; qui puoi inventarti una applicazione (magari scritta in un linguaggio a più alto livello:D) che ti permette di inserire da un tastierino grafico delle cifre; o peggio... una applicazione che simula la perforazione di schede, bit per bit (e quindi hai solo due "tasti", più almeno un altro "gestionale" per dire che hai finito)... in quest'ultimo caso, invece che averli scritti in esadecimale, potevi scriverli direttamente in binario...)... una volta che hai disposizione questa applicazione ad hoc, pazientemente inserisci i byte... questa applicazione li salverà su un file, che puoi intenderla anche come una rappresentazione di comodo di una scheda perforata, se hai "simulato" una scheda perforata [per inciso, ci sono schede perforate molto più evolute, che permettevano di inserire invece che singoli bit, direttamente qualcosa di più significativo; per esempio un buco in una ceta posizione poteva essere la lettera A, per dire... le schede sono solo un metodo di input, quello che può essere inserito è arbitrario e naturalmente dipendente dall'hw del lettore)

e) ora che hai la tua "scheda" o affine memorizata in un file, ... dovresti eseguire il codice... ma non puoi farlo così, immediatamente. allora o scrivi (un'altra) applicazione ad hoc il cui solo scopo è caricare in memoria il codice ed eseguirlo, o il "simulatore" di inserimento di cui al punto precedente non ha scritto nessun file, ma solo "byte" in memoria, sicché fornirà un altro "bottone" per dire "esegui" (e quello che succederà dipende dal tuo codice... naturalmente devi aver tenuto in considerazione il fatto di essere eseguito su un SO moderno... o devi fornire un emulatore di qualche altra cosa)... oppure, ti studi i formati degli eseguibili (PE su windows, ELF su molti altri sistemi, ecc.) e incorpori il tuo codice lì dentro.



il che è molto complicato, ma non impossibile. e inoltre così facendo puoi scrivere in questo modo primitivo una "vera" applicazione per il SO in uso, senza limiti, che invece hai se scrivi il codice così nudo (per esempio, non puoi usare le API del SO perché il binding è dinamico e fatto dal loader del sistema op. usando delle info memorizzate nel file eseguibile, dunque per un intel x86 una "banale"

call CreateWindowEx

non la puoi usare, perché non sai l'indirizzo "vero" della CreateWindowEx; normalmente, in un eseguibile il simbolo è scritto in chiaro (come "testo") e il loader risolve il riferimento sostituendo l'indirizzo opportuno nel codice, che prima di tale operazione contiene un indirizzo fittizio (per esempio, 0))



...
zedda_piras25
2009-01-09 01:39:00 UTC
30 o 40 anni fa si poteva programmare in binario perchè il numero di istruzioni delle cpu era estremamente ridotto rispetto a ora e soprattutto inviare un output ad una telescrivente non è proprio come creare una gui.

Al limite puoi programmare in assembly e comunque per piccole cose che per le quali ti serve l'assoluto controllo o non puoi fare con altri linguaggi



se vuoi saperne di più studia architettura degli elaboratori
Hank Moody
2009-01-09 01:02:55 UTC
se vuoi diverti ti con il codice macchina ecco un bel giochino ke noi abbiamo fatto all'esame di Programmazione di sistema:

Qui c'e la traccia

http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-s03/labs/L3/buflab.pdf

e qui i i files dovrebbe partire.

http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-s03/labs/L3/



Si tratta di fare un exploit usando il buffer overflow.



Dagli un occhiata.


Questo contenuto è stato originariamente pubblicato su Y! Answers, un sito di domande e risposte chiuso nel 2021.
Loading...