Back to the roots, machine code!

[Sir_Hendro]

Beste mede tweakers,

Ik begin een beetje nieuwsgierig te worden naar het laagste niveau om een computer aan te sturen, machine code. Nu snap ik dat een PC binary verwerkt maar ik zou graag meer willen leren hoe je iets simpels kunt maken zoals 'Hello Word' waarbij je dan de machine inschakelt en direct na de bios een zelfgemaakte code uitvoert ipv een OS te starten. Ik wil dan ook geen gebruik maken van assembly en echt puur binary / hex blijven gebruiken. Hierbij zal dan ongetwijfeld vele complicatie zitten zoals dat hardware waarschijnlijk niet direct aanspreekbaar is zoals het gebruik van een USB toetsenbord en dat het wellicht beter is om met een veel oudere PC te werken.

Overigens heb ik geen plannen om hier serieus iets mee te bereiken behalve het spelen met machine code uit nieuwsgierigheid. Het lijkt me gewoon leuk om 'Hello World' eens voor elkaar te krijgen en daarna misschien nog zoiets als een rekenmachine programma te maken (1+1=2 ect). Ofwel een beetje instructies uitvoeren, getallen onthouden in het geheugen en later weer verder bewerken.

Hebben jullie tips over boeken of online tutorials die hier meer informatie over hebben? Wat raden jullie aan om mee te beginnen als test PC? Een Raspberry pi of wellicht een veel ouder systeem? Vergeet niet dat het om puur binary gaat en dus gelieve geen assembly tutorials. Ik weet dat het gekke werk is, maar waarom niet? Ik heb tevens al veel ervaring in high level code zoals java en het schrijven van binary data.

I am curious!

[ Voor 6% gewijzigd door Sir_Hendro op 26-02-2016 10:25 ]

[Daos]

Assembly en machinecode zijn direct aan elkaar gekoppeld. Je begint dus met schrijven van je programma in assembly. Daarna vertaal je elke regel naar machinecode. Hoe deze vertaling eruit ziet, staat in de handleiding van je processor.

x86/x64 is vrij lastig. Misschien kan je beter starten met een microcontroller. Zelf heb ik het tijdens mijn studie moeten doen voor een 8051.

[Sir_Hendro]

Wat mij betreft mag het systeem bestaan uit een toetsenbord, een mini LCD die alleen maar characters kan weergeven en een microcontroller waarop ik vervolgens dan kan proberen iets simpels in elkaar te zetten zoals een reken machine of simpel weg 'hello world'.

Ik weet dat assembly en machine code met elkaar samen gaan maar je moet dan toch nog compilen en daarom de wens om zonder compiler direct de machine in binary te kunnen aansturen.

[dev10]

Nu snap ik dat een PC binary verwerkt maar ik zou graag meer willen leren hoe je iets simpels kunt maken zoals 'Hello Word' waarbij je dan de machine inschakelt en direct na de bios een zelfgemaakte code uitvoert ipv een OS te starten.

Dat klinkt als het schrijven van een kernel die niks anders doet dan 'Hello World' printen. Een goed startpunt daarvoor is http://wiki.osdev.org en dan met name http://wiki.osdev.org/Bare_Bones.

Ik weet dat assembly en machine code met elkaar samen gaan maar je moet dan toch nog compilen en daarom de wens om zonder compiler direct de machine in binary te kunnen aansturen.

Even vooropgezet dat ik vrij weinig ervaring hiermee heb, maar dit best interessant vind: is dit überhaupt mogelijk?

[Fish]

Waarom na het bios ? en niet in plaats van ?

[Sir_Hendro]

Dat mag ook, ik weet alleen niet of dat mogelijk is want je hebt dan echt niks. Ik zou dus waarschijnlijk nog erg veel code moeten uitvoeren om überhaupt met iets te kunnen communiceren als waarvan ik dacht dat de bios er voor zorgt dat je juist het uiterst minimale kunt doen met de beschikbare hardware. Wellicht zit ik er volledig naast. Zoals gezegd, ik heb nog geen ervaring met het werken uit letterlijk niets maar ik wil dit juist begrijpen en zelf wat kleins produceren. Waar het tot zover steeds op neer komt is:

This is a computer. It runs on binary using its transistors. You can use assembly to make a simpel 'hello world' OS. Hier zit toch nog een stap tussen, namelijk directe communicatie in binary. Dat is volgens mij echt de pure kern van PC aansturing en dat vind ik juist erg interessant.

Ofwel, leren hoe je dus met een pc moet omgaan vanuit niets. Ik zit momenteel te kijken naar een 8051 microcontroller developement board. Dat ziet er wel interessant uit.

[ Voor 35% gewijzigd door Sir_Hendro op 26-02-2016 11:00 ]

[Daos]

Je kan ook DOSBox gebruiken en een .COM maken. Daarin kan je direct je instructies zetten. Het heeft geen header of iets dergelijks.

Mijn eerdere reactie ging al over vertalen van assembly met de hand. Het is een 1-op-1 omzetting van assembly naar machinecode.

edit:
Er is dan ook niet 1 assembly. Elke processor heeft zijn eigen.

[ Voor 12% gewijzigd door Daos op 26-02-2016 11:07 ]

[Jiffy]

Wil je iets in assembly doen? Grijp dan eens terug naar de beroemde 8-bitters uit de jaren '80: de Commodore 64, MSX en nog een aantal anderen.

Die dingen waren gemáákt om in assembly geprogrammeerd te worden. In eerste instantie kun je een emulator gebruiken en denk je vervolgens 'Dit is retecool!' kun je altijd nog een échte machine opduiken.

* Jiffy heeft én gebruikt nog steeds een aantal van die oude gebakjes, juist voor dit soort nostalgische 'back to the roots' tripjes.

[dik_voormekaar]

Leuk, uit mijn sources archief van 1994:

code:

        .MODEL small
        .STACK 100h
        .DATA
hello   db      'Hello, World !',13,10,'$'
        .CODE
start:  mov     ax,@data
        mov     ds,ax
        mov     dx,offset hello
        mov     ah,9
        int     21h
        mov     ax,4c00h
        int     21h

        END     start

[Sir_Hendro]

Wellicht is een emulator wel de beste stap in het begin. Ik wil namelijk snel een binary image kunnen overschrijven door een nieuwe versie waarin alle code zit zodat je super snel de code kunt testen en uitbreiden / debuggen.

[ Voor 4% gewijzigd door Sir_Hendro op 26-02-2016 11:18 ]

[DexterDee]

dik_voormekaar schreef op vrijdag 26 februari 2016 @ 11:16:
Leuk, uit mijn sources archief van 1994:

Brings back memories
Maar strikt genomen is deze assembly code niet toepasbaar voor TS. Het maakt immers gebruik van software interrupt 21h en die is pas beschikbaar als command.com is ingeladen. Je hebt dus MS-DOS nodig om deze code te draaien.

Wat wel kan is rechtstreeks in de VGA video buffer schrijven. Je moet dan wel zelf de positie van je cursor bijhouden

Sir_Hendro schreef op vrijdag 26 februari 2016 @ 11:16:
Wellicht is een emulator wel de beste stap in het begin. Ik wil namelijk snel een binary image kunnen overschrijven door een nieuwe versie waarin alle code zit zodat je super snel de code kunt testen en uitbreiden / debuggen.

Over emulators gesproken, dit is wel een leuke speeltuin:
https://schweigi.github.io/assembler-simulator/

[ Voor 29% gewijzigd door DexterDee op 26-02-2016 11:25 ]

[farlane]

Alhoewel het best aardig is om een keer te doen, is de stap tussen machinecode ("opcodes") en assembly niet meer dan een "vertaaltabel" zoals Daos al aangeeft.
Zie hier bijvoorbeeld een tabel voor de instructies van de Zilog Z80 die in MSX1 machines werd gebruikt.

[Sir_Hendro]

Het leuke is dat ik tijdens mijn applicatie ontwikkeling steeds meer begin te zien dat eigenlijk ALLES gewoon gebaseerd is op getallen. Ik gebruik ook steeds minder hulpmiddelen in mijn applicaties om zaken eenvoudiger te maken voor beginners en alles gewoon zelf direct programmeer (denk hierbij aan functies in een programmeer taal). Ofwel, do this and do that is gewoon een mooier jasje van het vastzetten van een aantal variabelen wat ik ook zelf kan doen zonder die mooie jas, en dat vind ik leuk om steeds meer van dit soort jasjes te vinden die eigenlijk niet nodig zijn omdat je het zelf direct kan coderen.

DexterDee schreef op vrijdag 26 februari 2016 @ 11:21:
[...]
Over emulators gesproken, dit is wel een leuke speeltuin:
https://schweigi.github.io/assembler-simulator/

hey bedankt, dit is eigenlijk in principe precies wat ik zoek en een leuke basis om mee te beginnen voordat men overstapt op een echte pc. Ik ga hier eens mee spelen, thanks!

[ Voor 25% gewijzigd door Sir_Hendro op 26-02-2016 11:37 ]

[whoami]

Ik heb ooit nog zo'n boek gehad waarin allerhande van die dingen belicht werden (PC Underground ofzo heette het). Vanavond eens kijken of ik het nog liggen heb.

[Janoz]

Sir_Hendro schreef op vrijdag 26 februari 2016 @ 10:45:
Ik weet dat assembly en machine code met elkaar samen gaan maar je moet dan toch nog compilen en daarom de wens om zonder compiler direct de machine in binary te kunnen aansturen.

Compilen kun je het niet echt noemen. Het is eigenlijk gewoon een veredelde search and replace. Je wens is dan ook heel raar. Dat zal vast komen doordat je nog niet helemaal door hebt hoe assembly en machinecode er daadwerkelijk uit zien. (ook ingegeven door het feit dat je eerst iets wilt printen en daarna iets wilt berekenen. die eerste taak is juist veel lastiger )

Ga eerst eens wat omspelen met assembly. Vul wat registers, verplaats wat tussen registers en geheugen en probeer hier eens wat bewerkingen op te doen.

[dik_voormekaar]

DexterDee schreef op vrijdag 26 februari 2016 @ 11:21:
[...]

Brings back memories
Maar strikt genomen is deze assembly code niet toepasbaar voor TS. Het maakt immers gebruik van software interrupt 21h en die is pas beschikbaar als command.com is ingeladen. Je hebt dus MS-DOS nodig om deze code te draaien.

[...]

Klopt natuurlijk, maar in DOSbox zou het moeten kunnen. Source compileren met tasm en tlink en klaar.
Ga het toch eens proberen vanavond.

[Sir_Hendro]

Ik heb ook het gevoel dat hoe meer ik te weten kom over hoe alles onder de motorkap wordt uitgevoerd des te beter mijn high level code wordt. Met high level code kan je uiteraard erg makkelijk programmeren maar als dat je basis is wordt je wel snel erg overvallen door de vele functies die beschikbaar zijn als waar low level code erg beperkt is zowel qua code als qua functies per code. Je moet dus meer programmeren om hetzelfde te bereiken maar lijkt mij juist daarom wel makkelijker om te leren. Plus als je echt weet hoe de kern functioneert kun je daarna de high level code efficiënter schrijven om dat gene te bereiken wat je wilt maken.

[M-ThijZ]

Dit is wel een heel wollig verhaal. Waarom pak je niet gewoon een microcontroller ... Arduino bordje?

[jeanj]

tijdens mijn studie gebruikten we een emulator voor MIPS (RISC), voglens mij deze

en een tutorial

[ Voor 40% gewijzigd door jeanj op 26-02-2016 12:00 ]

[Fish]

M-ThijZ schreef op vrijdag 26 februari 2016 @ 11:52:
Dit is wel een heel wollig verhaal. Waarom pak je niet gewoon een microcontroller ... Arduino bordje?

Niks wolligs, gewoon een tweaker in hart en nieren. Dit zijn de mensen die ik leuk vind op het forum. En zoekt een aangrijpingspunt

ok, een emulator pakken is makkelijker, maar volgens mij is dat niet de essentie die hij zoekt

[Laurens-R]

voordat je naar een echte pc stapt, zou ik je adviseren qemu te gebruiken als emulator. Simpelweg omdat deze een aantal debugging features heeft (zoals een live register view) die vmWare, Hyper-V etc niet bieden.

Je kan je bootsector code dan ook simpelweg naar een image wegschrijven en die vervolgens als bootdrive gebruiken in qemu. http://wiki.osdev.org heeft voldoende voorbeelden daarover.

[Sir_Hendro]

Wat ik tot zover heb gevonden (sommige slechts op aanname):

Een cpu is een aantal bits. Dit bepaald wat voor nummers hij maximaal per cycle kan verwerken.

8 bit cpu doet 0 tot 255
16 bit cpu doet 0 tot 65535
32 bit cpu doet 0 tot 2147483647

Bij 32 bit zie je een maximum getal van 2147483647 wat neer komt op 2GB wat dus ook maximale is wat we zien in een 32 bit OS qua geheugen aansturing. Omdat de cpu geen groter getal kan verwerken is het dus niet mogelijk zonder trucjes door het 2GB limit te breken, de rest is gewoon OUT OF RANGE.

Verder is een de cpu denk ik een soort doolhof bestaande uitschakelingen die ervoor zorgen dat men uitkomt bij de getallen die binnen het bereik van het aantal bits van de cpu vallen. Waarschijnlijk zitten er nog veel meer functies in een cpu maar dit is dan denk ik het belangrijkste. Vervolgens ga je dus rekenen en je tussen stappen opslaan in het geheugen en vervolgens later weer verder bewerken.

Je hebt dus een rekenmachine. Echter kun je nu al deze berekeningen in een mooier jasje steken waardoor een berg code een functie zal worden om bijvoorbeeld iets weer te geven op het scherm. Hoe luxer de jas des te meer er wordt bereikt en dat wanneer we kijken na hedendaagse high level code er een hele berg low code aan iedere high level code functie hangt.

Zo heb ik zelf al vele interessante programma's geschreven waaronder een aantal clones van bekende dure software pakketten evenals een leuke PCM Synthesizer (en nog veel meer). Alles erg leuk en interessant en tijdens al deze projecten is de wens om eens onder de high level code te gaan kijken alleen maar groter geworden.

[ Voor 15% gewijzigd door Sir_Hendro op 26-02-2016 12:55 ]

[naftebakje]

Ik denk ook dat het iets te die-hard is om een PC te willen programmeren zonder compiler.

Wat relatief vlot haalbaar is (en een goed inzicht geeft in wat de compiler allemaal voor je regelt) is een 8-bits PIC microcontroller programmeren, de 16Fxx reeks. Deze heeft maar 35 instructies, waarmee je alles moet geregeld krijgen; en het is terug te vinden hoe deze exact naar '1' en '0' vertaald worden (wordt 14-bits, bestaande uit 8-bits data en rest instructie.

Wil je bijvoorbeeld 2 getallen optellen, dan ga je je getal in het ene werkregister wat ie rijk is stoppen (want geen ruimte voor 2e getal in je instructie), volgende instructie het 2e getal optellen bij het werkregister, en dan de vlaggen controleren of je gen overflow hebt.

[EJlol]

Misschien is dit ook wel interessant voor TS:
https://www.coursera.org/learn/build-a-computer

In deze (gratis) course wordt je geleerd om een (versimpelde) computer helemaal op te bouwen uit NAND-poorten. Uiteindelijk zal je daar ook een compiler maken om je assembly code om te zetten naar machine code. Aangezien het om een versimpelde versie van een computer gaat, zal je niet direct hier iets aan hebben. Echter geeft het wel een goed inzicht hoe een computer werkt, en ik vermoed dat deze course een hoop vragen van je zal beantwoorden.

[TunderNerd]

Ik merk aan alles, dat je totaal geen idee hebt wat er onder water allemaal gebeurd. Wat jij wilt is niet bijster lastig zolang je maar aan het begin begint. Ikzelf heb dit allemaal op de opleiding gehad in mijn eerste jaar Electrotechniek. De logische stappen zijn ongeveer:
1. Logische poorten
2. Flip flops, en grotere schakelingen met logische poorten
3. eerste programmeren in PROMS (juist, die met ultraviolet licht weer gewist worden)
4. een PIC uit de 16f famillie pakken (16f628)

Vergeet ook niet een paar boeken over ALU's, registers etc. handig om dit rond punt 3 te gaan lezen. Succes!

[Sir_Hendro]

EJlol schreef op vrijdag 26 februari 2016 @ 12:29:
Misschien is dit ook wel interessant voor TS:
https://www.coursera.org/learn/build-a-computer

In deze (gratis) course wordt je geleerd om een (versimpelde) computer helemaal op te bouwen uit NAND-poorten. Uiteindelijk zal je daar ook een compiler maken om je assembly code om te zetten naar machine code. Aangezien het om een versimpelde versie van een computer gaat, zal je niet direct hier iets aan hebben. Echter geeft het wel een goed inzicht hoe een computer werkt, en ik vermoed dat deze course een hoop vragen van je zal beantwoorden.

Wat ik zo lees op de site klinkt allemaal erg veel belovend. Vooral het feit dat er een emulator wordt gemaakt vind ik erg goed. Indien mogelijk ga ik deze dan in mijn eigen java SDK schrijven (zij zullen vast iets anders gebruiken) en dan lekker op binary niveau werken in het geheugen (daar heb ik al veel ervaring mee).

//edit
Ik dacht dat het om een series van online video tutorials zou gaan maar zo te lezen is het niet direct gratis beschikbaar en moet je wacht tot de volgende live stream sessie beschikbaar is om mee te doen.

[ Voor 10% gewijzigd door Sir_Hendro op 26-02-2016 13:44 ]

[Fish]

Sir_Hendro schreef op vrijdag 26 februari 2016 @ 12:09:
Wat ik tot zover heb gevonden (sommige slechts op aanname):

Een cpu is een aantal bits. Dit bepaald wat voor nummers hij maximaal per cycle kan verwerken.

Nee dat is afhankelijk van de instructie (en threads)

8 bit cpu doet 0 tot 255
16 bit cpu doet 0 tot 65535
32 bit cpu doet 0 tot 2147483647

Uhm het gaat daar om perceptie
2^8 = 256 Als je bij nul begint ga je van 0.. 255
2^16 = 65536

2^32 = 4294967296
Jouw getal gaat uit van een parity bit en dan is het -2147483648 tot 2147483648

Bij 32 bit zie je een maximum getal van 2147483647 wat neer komt op 2GB wat dus ook maximale is wat we zien in een 32 bit OS qua geheugen aansturing. Omdat de cpu geen groter getal kan verwerken is het dus niet mogelijk zonder trucjes door het 2GB limit te breken, de rest is gewoon OUT OF RANGE.

Je bent nogal met "getallen" bezig. en zo werkt het niet. je hebt een Adresbus met een bepaalde breedte (in bits) maar je hent ook de instructies die een bepaalde bitbreedte kunnen hebben. In het laatste geval wordt er ook gewerkt met een carry(over) bit waarin de volgende instructie daar rekening mee kan houden.
Zo heb je ook floating point bewerkingen waar je veel verder kunt gaan de de gezette bitlimieten, het gaat alleen te koste van je preciesie

Verder is een de cpu denk ik een soort doolhof bestaande uitschakelingen die ervoor zorgen dat men uitkomt bij de getallen die binnen het bereik van het aantal bits van de cpu vallen. Waarschijnlijk zitten er nog veel meer functies in een cpu maar dit is dan denk ik het belangrijkste. Vervolgens ga je dus rekenen en je tussen stappen opslaan in het geheugen en vervolgens later weer verder bewerken.

Je "slaat niets op" in het geheugen, je werkt continu in het geheugen. elke bewerking is een geheugenbewerking. (registers zijn ook geheugens)

Je hebt dus een rekenmachine. Echter kun je nu al deze berekeningen in een mooier jasje steken waardoor een berg code een functie zal worden om bijvoorbeeld iets weer te geven op het scherm. Hoe luxer de jas des te meer er wordt bereikt en dat wanneer we kijken na hedendaagse high level code er een hele berg low code aan iedere high level code functie hangt.

Elke instructie is natuurlijk al een soort functie, alleen erg low level.

Zo heb ik zelf al vele interessante programma's geschreven waaronder een aantal clones van bekende dure software pakketten evenals een leuke PCM Synthesizer (en nog veel meer). Alles erg leuk en interessant en tijdens al deze projecten is de wens om eens onder de high level code te gaan kijken alleen maar groter geworden.

Heh succes

[BikkelZ]

Ik heb nog een paar Commodores liggen met cartridges, daar doe ik wel eens wat dingetjes mee. Een Commodore 64 is zo simpel dat je echt een mentaal model kunt maken van wat waar in je geheugen staat en wat je er mee aan stuurt.

[Fish]

De c64 is ideaal

je schrijft je code, en die kun je direct starten

sys49152 anyone ?

[Daos]

Dat kan je natuurlijk ook doen, (Q)Basic gebruiken. Voorbeeldje: http://www.petesqbsite.co...torials/tutorials/asm.txt

edit:
Je kan dus in een QBasic-programma je machinecodes zetten en die uitvoeren. Snel en makkelijk.

[ Voor 29% gewijzigd door Daos op 26-02-2016 13:51 ]

[Jiffy]

Fish schreef op vrijdag 26 februari 2016 @ 13:18:
De c64 is ideaal

je schrijft je code, en die kun je direct starten

sys49152 anyone ?

Yes, dat is de klassieke vrije 4 K vanaf lokatie $c000 (=49152) waar iedereen handig z'n progseltjes in ging zetten om z'n standaard basicgeheugen van 38 K vrij te houden.

Maar nogmaals: machines zoals de C-64 of een MSX zijn qua structuur zó simpel dat het prima mogelijk is letterlijk het hele systeem uit je hoofd te leren.

Zie het als het sleutelen aan een klassieke VW Kever als je meer te weten wilt komen over de basics van een auto.

[ Voor 26% gewijzigd door Jiffy op 26-02-2016 13:54 ]

[DexterDee]

Sir_Hendro schreef op vrijdag 26 februari 2016 @ 12:09:
Wat ik tot zover heb gevonden (sommige slechts op aanname):

Een cpu is een aantal bits. Dit bepaald wat voor nummers hij maximaal per cycle kan verwerken.
32 bit cpu doet 0 tot 2147483647

Bij 32 bit zie je een maximum getal van 2147483647 wat neer komt op 2GB wat dus ook maximale is wat we zien in een 32 bit OS qua geheugen aansturing. Omdat de cpu geen groter getal kan verwerken is het dus niet mogelijk zonder trucjes door het 2GB limit te breken, de rest is gewoon OUT OF RANGE.

Ehrm... 32 bit is 4294967296 wat resulteert in 4 GB adresseerbare ruimte.

En ter leering ende vermaeck, een extreem simpel OS. Ik noem het "SirHendroOS"

code:

    BITS 16

start:
    mov ax, 07C0h           ; Reserveer 4K stack space na deze bootloader
    add ax, 288             ; (4096 + 512) / 16 bytes per paragraaf
    mov ss, ax
    mov sp, 4096

    mov ax, 07C0h           ; Zet data segment op waar we ingeladen zijn
    mov ds, ax


    mov si, text_string     ; Zet string positie in SI
    call print_string       ; Roep print routine aan

    jmp $                   ; Eeuwige loop :)


    text_string db 'Welcome bij SirHendroOS', 0


print_string:               ; Routine: print string in SI op het scherm
    mov ah, 0Eh             ; int 10h 'print char' BIOS functie

.repeat:
    lodsb                   ; Haal karakter van string
    cmp al, 0
    je .done                ; Als karakter 0 is dan is, dan einde string
    int 10h                 ; Anders print het karakter
    jmp .repeat

.done:
    ret


    times 510-($-$$) db 0   ; Bootsector padden met nullen tot 512 bytes
    dw 0xAA55               ; Standaard PC boot signature

Tijd om het OS te "builden" met nasm (op linux uiteraard ):

nasm -f bin -o sirhendro.bin sirhendro.asm

De -f vlag is belangrijk. We willen een kale binary, niet een linux executable

Nu moeten we nog een floppydisk image maken om het OS vanaf te booten:

dd status=noxfer conv=notrunc if=sirhendro.bin of=sirhendro.flp

Als je floppydisks heel ouderwets vindt, kun je er ook een CD image van maken:

mkisofs -o sirhendro.iso -b sirhendro.flp cdiso/

Als alles goed is gegaan kun je nu je floppydisk of CD in een emulator of op een echte PC booten

[.oisyn]

Sir_Hendro schreef op vrijdag 26 februari 2016 @ 12:09:
Wat ik tot zover heb gevonden (sommige slechts op aanname):

Een cpu is een aantal bits. Dit bepaald wat voor nummers hij maximaal per cycle kan verwerken.

Dit is onwaar. Er is totaal geen relatie tussen het aantal bits van de CPU en de throughput. Over het algemeen slaat het aantal bits van de CPU louter op de grootte van een "machine word" - de standaard integer registers hebben deze grootte. Dat wil overigens niet zeggen dat hij niet kan rekenen met grotere getallen - je zou een 64 bits getal bijvoorbeeld over 2 32-bits registers kunnen verdelen, en er dan mee rekenen.

Een hedendaagse processor is in staat meerdere instructies tegelijk te verwerken in dezelfde cycle. En dan heb je meestal ook nog SIMD waarbij je dezelfde berekening loslaat op meerdere inputs tegelijk.

Bij 32 bit zie je een maximum getal van 2147483647 wat neer komt op 2GB wat dus ook maximale is wat we zien in een 32 bit OS qua geheugen aansturing. Omdat de cpu geen groter getal kan verwerken is het dus niet mogelijk zonder trucjes door het 2GB limit te breken, de rest is gewoon OUT OF RANGE.

Nou is het 4294967295 zoals eerder vermeld (2³² - 1), maar dat wil niet zeggen dat hij niet meer kan. De adresbus bevat meestal meer bits dan in een 32-bit register passen om op die manier meer dan 4GB geheugen aan te spreken. Vervolgens moet je op een of andere manier dat grotere getal kunnen vormen. Bijvoorbeeld door registers te combineren, de start-offset te coderen in een een of andere descriptor, of dmv paging een deel van het gehuegen te mappen in de 4GB address range.

[Daos]

Met het voorbeeld van DexterDee kan je de volgende dingen doen om meer inzicht te krijgen:

Een hexdump van de binary

code:

$ od -txC -Ax sirhendro.bin
000000 b8 c0 07 05 20 01 8e d0 bc 00 10 b8 c0 07 8e d8
000010 be 18 00 e8 1a 00 eb fe 57 65 6c 63 6f 6d 65 20
000020 62 69 6a 20 53 69 72 48 65 6e 64 72 6f 4f 53 00
000030 b4 0e ac 3c 00 74 04 cd 10 eb f7 c3 00 00 00 00
000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa

Hier zie je ruwe data die de processor instructies geeft om de dingen te doen die DexterDee wil (eerste kolom geeft het adres weer). Dit is dus de machinecode.


Disassembly van de binary

code:

$ ndisasm.exe sirhendro.bin
00000000  B8C007            mov ax,0x7c0
00000003  052001            add ax,0x120
00000006  8ED0              mov ss,ax
00000008  BC0010            mov sp,0x1000
0000000B  B8C007            mov ax,0x7c0
0000000E  8ED8              mov ds,ax
00000010  BE1800            mov si,0x18
00000013  E81A00            call word 0x30
00000016  EBFE              jmp short 0x16
(puinhoop veroorzaakt door string verwijderd)
00000033  3C00              cmp al,0x0
00000035  7404              jz 0x3b
00000037  CD10              int 0x10
00000039  EBF7              jmp short 0x32
0000003B  C3                ret

De binary kan je dus weer terug toveren naar assembly. Hiermee zie je dat er een 1-op-1 mapping is en deze mapping wordt hierboven ook weergegeven (eerste kolom is weer adres; tweede machinecode; derde assembly).

Als je nu met de hand machinecode gaat schrijven en je wilt bv een "cmp al,0x0" doen, dan moet je met je hex-editor "3C00" schrijven naar je bestand. Zie ook de handleidingen: http://www.intel.com/cont...re-developer-manuals.html

Opcode    Instruction    Description
3C ib     CMP AL, imm8   Compare imm8 with AL.

[downtime]

Sir_Hendro schreef op vrijdag 26 februari 2016 @ 12:09:
Wat ik tot zover heb gevonden (sommige slechts op aanname):

Een cpu is een aantal bits. Dit bepaald wat voor nummers hij maximaal per cycle kan verwerken.

8 bit cpu doet 0 tot 255
16 bit cpu doet 0 tot 65535
32 bit cpu doet 0 tot 2147483647

Bij 32 bit zie je een maximum getal van 2147483647 wat neer komt op 2GB wat dus ook maximale is wat we zien in een 32 bit OS qua geheugen aansturing. Omdat de cpu geen groter getal kan verwerken is het dus niet mogelijk zonder trucjes door het 2GB limit te breken, de rest is gewoon OUT OF RANGE.

Je zit ernaast. Zoals .oisyn ook al aangeeft geeft het aantal bits van een CPU alleen maar aan wat de (maximale) grootte van een register is. Meestal (maar niet altijd) zijn maximale registergrootte en de breedte van de databus (wat bepaalt hoeveel bits gelijktijdig uit RAM gelezen kunnen worden) gelijk. Soms heb je bovendien registers van verschillende groottes.
Het aantal bytes wat direct geadresseerd kan worden is afhankelijk van de breedte van de adresbus. Databus en adresbus zijn niet altijd even breed. Vroege ARM CPU's kenden volgens mij een 26-bit adresbus zodat je in één cycle een opdracht en een parameter (bv een pointer naar een geheugenlocatie) kon inlezen. Maar er is ook niks op tegen om dat te splitsen. Dus eerst een 32-bits opdracht gevolgd door een 32-bits parameter.

Stel je een hypothetische 32-bits CPU voor die een 24-bits adresbus heeft. Bij elke cycle wordt een "woord" van 32-bits ingelezen. Het zou best kunnen dat dat woord een "opdracht" van 8 bits en een parameter van 24-bits bevat. In die 8 bits zou bijvoorbeeld de opdracht "LOAD FROM RAM IN REGISTER #1" kunnen bevatten en in de resterende 24-bit past dan misschien het geheugenadres waar de waarde staat die geladen moet worden. En er is misschien ook een 8-bits opdracht "LOAD VALUE IN REGISTER #1" waarbij de resterende 24-bit de waarde bevat. Etc.

Het is dus allemaal wat complexer dan je denkt. Wel heel interessant maar eerlijk gezegd denk ik dat programmeren in hex je snel gaat vervelen. In de praktijk zul je dan toch gewoon assembler schrijven (da's tenminste een beetje leesbaar) en aan de hand van vertaaltabellen zelf naar hex omzetten. Da's erg dom werk, ik heb het (30 jaar geleden) wel eens gedaan om een korte assembler routine te schrijven zonder een assembler.

Vergis je niet. Assembler is niet als een hogere programmeertaal waar het eindresultaat soms heel weinig lijkt op de code die je hebt geschreven. Assembler is een 1:1 vertaling van een leesbare naar een puur binaire weergave. Er wordt verder niks slims met je code gedaan.

[SBTweaker]

Als je echt de basis wilt zou ik een simpel moederbord rekenmachintje maken met leds dus zonder software, dat is de echte basis. Zelf in me eerste jaar hbo informatica gedaan voor vrije studieruimte is een erg leuk experiment en dan zie je echt se laagste laat (stroom naar data).

Fun fact roller coaster tycoon 2 is geheel door 1 persoon gemaakt, in assembly, IN EEN JAAR!

[RobIII]

SBTweaker schreef op vrijdag 26 februari 2016 @ 19:56:

Fun fact roller coaster tycoon 2 is geheel door 1 persoon gemaakt, in assembly, IN EEN JAAR!

More likely ≈ twee jaar en dat was een ervaren assembly programmeur

Fish schreef op vrijdag 26 februari 2016 @ 13:13:

Jouw getal gaat uit van een parity bit en dan is het -2147483648 tot 2147483648

Je bedoelt een sign bit, een parity bit is iets anders

[ Voor 39% gewijzigd door RobIII op 27-02-2016 02:56 ]

[Dets]

Misschien zo iets? http://www.instructables....ur-own-z80-microcomputer/
Heel vroeger op school hadden we iets vergelijkbaars toen we met assembler begonnen. Ik zat toen met een boek pseudocode naar hex om te zetten en kon het dan invoeren en testen.

[H!GHGuY]

Lees even dit artikel:
https://lwn.net/Articles/658511/

Hier maken ze met behulp van kvm een mini-prog om 2getallen op te tellen. exact wat je wil en aan te passen naar wens.

[Fish]

RobIII schreef op vrijdag 26 februari 2016 @ 20:22:
[...]


Je bedoelt een sign bit, een parity bit is iets anders

Sorry

Excuus, dat bedoelde ik idd ....

[naftebakje]

SBTweaker schreef op vrijdag 26 februari 2016 @ 19:56:
Als je echt de basis wilt zou ik een simpel moederbord rekenmachintje maken met leds dus zonder software, dat is de echte basis. Zelf in me eerste jaar hbo informatica gedaan voor vrije studieruimte is een erg leuk experiment en dan zie je echt se laagste laat (stroom naar data)....

Als electronicus ben ik daar niet mee akkoord, want je weet nog niet hoe die instructies in de hardware verwerkt worden. Daarvoor moet je met een FPGA aan de slag, hardware gaan coderen tot je een werkende processor hebt.
Dan kan je ter intro even deze game gaan spelen, plakje silicium doteren op de goeie plekken om logische schakelingen te maken

[Sir_Hendro]

Deze video vind ik ook erg goed qua uitleg over hardware en aansturing. Hier heb ik toch weer wat dingen van opgepikt:

[Super_ik]

Deze gast op youtube legt ook zeer duidelijk uit hoe een cpu werkt: https://m.youtube.com/channel/UCS0N5baNlQWJCUrhCEo8WlA

Hij schrijft een programma direct in binary en laat zien hoe de bits door de cpu heen gaan.