Perché non è byte | bit l'unico costruito nel tipo di dati?

Dimentichiamo per il momento che i processori hanno hardware specifico per manipolare sequenze di byte di una particolare dimensione. Dimentichiamo per il momento che i processori hanno hardware specifico per operare su specifiche interpretazioni di sequenze di byte (registri a virgola mobile, registri SEE, ecc.).

A che serve questa astrazione dal punto di vista dell'utente? Dopo tutto, il linguaggio di programmazione esiste per la comodità del programmatore. Se l'astrazione non sta facendo qualcosa di utile per il programmatore, allora l'astrazione potrebbe anche non esserci.

Quindi l'unico tipo fondamentale fornito dalla lingua è un byte. E quindi ogni altro tipo è una forma di sequenza di byte. OK.

Non vogliamo che programmatori diversi dichiarino forme diverse dello stesso tipo come float o int32 o altro. Dopotutto, il float a 4 byte di una persona non sarebbe interoperabile con il float di 4 byte di qualcun altro. Non solo, diversi programmatori sprecheranno molto tempo ad implementare la stessa cosa.

Quindi la libreria standard per un tale linguaggio non avrebbe altra scelta che includere sequenze e operazioni generalmente utili su di essi. Ci sarebbe un equivalente di float , double , int , ecc.

Quindi, che cosa hai ottenuto rispetto a quando questi tipi di lingue sono stati forniti? Devi comunque fornirli, in ogni caso.

I linguaggi di programmazione (che non sono assemblaggio e persino assemblaggio in una certa misura) esistono per fornire utili astrazioni all'utente. Consentono all'utente di programmare un modello astratto piuttosto che i capricci specifici di un sistema, consentendo al compilatore di eseguire il lavoro meccanico di traduzione del modello astratto in un sistema reale.

Tuttavia, un modello astratto può talvolta intralciare trasformazioni ottimali. A volte, è perché il modello astratto definisce troppo. Ad esempio, Java definisce praticamente tutto ciò che riguarda i suoi tipi di base. float è garantito come valore in virgola mobile a 32 bit IEEE-754. Il che significa che se vuoi eseguire un programma Java su una piattaforma che non ha il supporto IEEE-754 nell'hardware, devi emulare il codice matematico in virgola mobile.

Per contro, C / C ++ non dice nulla su cosa float fornisce oltre al fatto che può avere valori che non sono numeri interi. In quanto tale, un compilatore per l'hardware che non ha il supporto IEEE-754 potrebbe convertire le operazioni float in una forma di matematica a virgola fissa. Oppure fai qualcosa di insolito, ma qualcosa di più veloce dell'emulazione software di IEEE-754.

Il tuo modello astratto fallisce nell'altra direzione. Specifica così poco che in realtà è sottostimato rispetto all'hardware, rendendo così più difficile la conversione in operazioni hardware. L'hardware può agire a livello di byte, ma le CPU effettive operano a livello di registro: gruppi di byte con un significato particolare. Esistono anche diversi tipi di registri con diversi tipi di operazioni su di essi.

Considera cosa succede se il tuo sistema di array di bit è basato su byte a 8 bit, e poi lo porti su un sistema in cui la CPU usa 9 bit byte (e sì, è così una cosa reale). C e C ++ supportano tali sistemi, proprio perché non specificano le cose a livello di bit. Un int potrebbe essere un oggetto a 4 byte, ma sarebbe di 36 bit. Il tuo int32 sarebbe inutile su tale sistema, in quanto l'hardware non può supportarlo in modo efficace.

Trovare la giusta astrazione per alte prestazioni, una che è abbastanza alta per essere un'astrazione utile per il programmatore, abbastanza alta da coprire un sacco di hardware, ma abbastanza bassa da non intralciare il programmatore, è molto difficile lavoro.

Poiché i processori hanno operazioni specifiche per int s, e specificamente per float s. Il compilatore deve sapere quale operazione scegliere come target.

E voglio dire, anche se avessi adding per una serie di bit, aggiungendo 0110 e 0001 hai molto significati diversi se 0001 è trattato come un float piuttosto che un int - per non parlare operazioni effettive richieste per calcolarlo.

E nel tuo codice di esempio, hai ancora hai ints ... Hai appena aggiunto ulteriori passaggi per crearne uno.

So why did all those programming languages decided to provide multiple built-in data types

Poiché i tipi predefiniti come int , float , byte e char vengono utilizzati in quasi tutti i casi d'uso - e si scopre che gli standard sono una comodità per tutti.

Se ognuno usasse la propria variante, scrivere un codice che usi librerie di tipi diversi, scambiare dati tra programmi, ecc. sarebbe praticamente impossibile, o almeno estremamente ingombrante e soggetto a errori.

Di conseguenza, i programmatori spenderebbero un sacco di tempo a ricercare i bug a causa di incompatibilità sul livello base dei tipi di dati, invece di risolvere il problema attuale.

But if we look closely, they are just arbitrary arrays of bits,

In realtà, se guardi da vicino questo non è vero. Sono matrici di bit molto specifiche, a volte con un significato molto speciale:

• int ha un'interpretazione firmata e non firmata, il bit più significativo nell'interpretazione firmata indica + o -

• float , double è in genere un'implementazione dello standard IEEE 754 su numeri in virgola mobile . non arbitrario affatto

• char stringhe di byte hanno un significato in alcune codifiche come Ascii, UTF8 o Unicode

• byte , int , long fanno garanzie sull'intervallo di valori che possono contenere

Quindi avere questi comuni e ben definiti tipi di dati incorporati è una buona cosa.

Ci sono stati linguaggi che, come suggerisci, forniscono solo un singolo tipo di dati e quindi hanno operazioni in cui la codifica prevista dei dati viene fornita come parte dell'operazione, piuttosto che essere determinata dal tipo della variabile così com'è nella maggior parte delle lingue moderne. Il più noto di questi era probabilmente B, il predecessore di C (in effetti, C può essere considerato come "B con tipi variabili", almeno in modo approssimativo). B aveva solo un tipo di dati - una parola macchina (che, sulla macchina per cui era stata progettata, era 18 bit ... nota che la nostra ossessione moderna per i multipli di 8 bit non è sempre stata universale!) che potrebbe essere interpretato come un intero o un puntatore a seconda di come lo hai usato (non supportava affatto il punto mobile).

La ragione per cui non ne vediamo più molti è che sono difficili da lavorare, e aggiungere altri tipi è (1) molto semplice e (2) rende il codice più facile da leggere e scrivere. Credo che l'ultimo noto programma scritto in B sia stato AberMUD nel 1987 (il suo autore principale è passato a lavorare con C poco dopo, e divenne uno dei contributori più noti del kernel Linux).

Hai ragione che i tipi numerici sono solo modelli di bit. Ma i processori sono ottimizzati per determinate operazioni su determinati modelli di bit. Ad esempio i processori x86 hanno registri di dimensioni 8, 16 e 32 bit, operatori aritmetici corrispondenti a queste dimensioni e la memoria viene indirizzata in blocchi di 8 bit, noti come byte. Ad esempio, non c'è supporto per l'aggiunta a 19 bit. Naturalmente potrebbe essere supportato dal compilatore, ma poi trasformato in aggiunta a 32 bit a livello di codice macchina - ma non ci sarebbe alcun punto.