🚀 go-pugleaf

"JanS" <jan_steckel@hotmail.com> wrote in message
news:FCtOb.17745$Hs.3845245@phobos.telenet-ops.be...

> Ik heb mij al een tijdje het volgende afgevraagd:
> Als er een nieuwe compiler gemaakt wordt, wordt die toch in een bepaalde
> taal geschreven (in welke eigenlijk?) . Goed, maar in welke taal is dan de
Soms in dezelfde taal als die hij compileert (GNU's C compiler
bijvoorbeeld). Als je een keer een compiler hebt, kun je hem hergebruiken
voor nieuwere versies van zichzelf.

> eerste compiler geschreven? assembler? Ok, maar hoe hebben ze dan dat
> assembler programma omgezet naar de hex-string die de (micro)processor
> begrijpt? Daar is toch ook een soort compiler voor nodig... Ik vraag mij
> echt af hoe ze dat gedaan hebben.
Hoe het precies ging zou ik niet weten, maar ooit werkte men met
ponskaarten, en ongetwijfeld is het in kleinere stappen naar steeds
complexere systemen gegaan, waarbij het simpele systeem een steeds complexer
systeem compileert.

Bij het schrijven van een compiler (en OS, etc) voor een nieuwe processor
gebruikt men vaak een cross-compiler - je ontwikkelt en compileert op een
geavanceerder systeem, maar er komt dan code uit die op een simpele
processor draait. Moet ook wel, want sommige processoren zijn niet echt
geschikt om compilers op te draaien.

Hi
Bedankt voor het antwoord.
Als er iemand meer details zou kunnen geven, altijd welkom...
Wat ik mij nog afvraag... Stel: ik zou een OS willen ontwikkelen (wat heel
theoretisch is, aangezien ik net de basis van programmeren kan) Waar zou ik
moeten beginnen, hoe zit dat allemaal in elkaar? Raadsels...

Jan

JanS schreef:
> Hi
> Bedankt voor het antwoord.
> Als er iemand meer details zou kunnen geven, altijd welkom...
> Wat ik mij nog afvraag... Stel: ik zou een OS willen ontwikkelen (wat heel
> theoretisch is, aangezien ik net de basis van programmeren kan) Waar zou ik
> moeten beginnen, hoe zit dat allemaal in elkaar? Raadsels...

Koop je een boek over besturingssystemen. Wij hebben bij de cursus 
besturingssystemen deze gebruikt:

http://cs-www.cs.yale.edu/homes/avi/os-book/osc/index.html

Meer praktisch is deze van dezelfde auteur(s):

http://cs-www.cs.yale.edu/homes/avi/os-book/aosc/index.html

Mvg,

-- 
Jo Vermeulen
Student Computer Science at the tUL
email: jo@lumumba.luc.ac.be
www: http://lumumba.luc.ac.be/jo

Jo Vermeulen <jo@lumumba.luc.ac.be> wrote:
>Koop je een boek over besturingssystemen. Wij hebben bij de cursus 
>besturingssystemen deze gebruikt:
>
>http://cs-www.cs.yale.edu/homes/avi/os-book/osc/index.html
>
>Meer praktisch is deze van dezelfde auteur(s):
>
>http://cs-www.cs.yale.edu/homes/avi/os-book/aosc/index.html
>
Vergeet deze van Stallings niet:
Operating Systems: Design and Implementation
Zijn al goede OS'en mee geschreven ;-)
-- 
Aquila
"May the source be with you"

"JanS" <jan_steckel@hotmail.com> wrote in message
news:L1vOb.17862$7N7.3717217@phobos.telenet-ops.be...
> Hi
> Bedankt voor het antwoord.
> Als er iemand meer details zou kunnen geven, altijd welkom...
> Wat ik mij nog afvraag... Stel: ik zou een OS willen ontwikkelen (wat heel
> theoretisch is, aangezien ik net de basis van programmeren kan) Waar zou
ik
> moeten beginnen, hoe zit dat allemaal in elkaar? Raadsels...
>
> Jan
>
>
Beste Jan,
Het is ingewikkeld om het allemaal tot in details uit te leggen. Ik ga
proberen een eenvoudige uitleg te geven. Experts Dont kill me als ik de
dingen heel erg simplifiseer.
De hardware is zogemaakt dat het de basis instructies kan verwerken. Dus
elke microprocessor heeft een instructieset. Dat is "hardwarematig". Kijk bv
op de sites van Intel en Amd. Dus  een"assembler programma" is in feite
basis instructies gezet op een bepaalde volgorde. Als illustratie probeer ik
het opstarten van een oude pc uit te leggen.
Wanneer je de knop omdraait krijgt de circuit "stroom". Het is zo ontworpen
dat het dan overgaat in een bepaalde toestand. Het voert een routine "POST"
uit dat hardwarematig gecodeerd is. Na deze routine wordt de BIOS ingeladen
en de bootstraploader wordt geactiveerd. Deze zoekt op de beschikbare
schijven naar de bootable partitie en laat
de bootloader van de OS. De bootloader laadt dan op zijn beurt het OS.

Natuurlijk is het opstartprocess tegenwoordig wat ingewikkelder door
ontwikkeling in de electronica, maar dan wordt het te ingewikkeld om het
simpel uit te leggen. Een ander voorbeeld van de overgang software/hardware
zijn de device drivers. Deze drivers vertallen een aanvraag van de OS naar
de basis instructie set van de microchip op de kaart of in de device.
Naast de aanbevolen literatuur in de andere reacties is het ook handig om
"microcomputer systeemarchitectuur" geschreven door kempen en M Stevens te
lezen.

Maar vergis je niet want achter elke OS zit een behoorlijk stuk wiskunde. Oa
wachtrij theorien en optimalisatie.

Groeten,
Mart

JanS wrote:

> Hi
> Ik heb mij al een tijdje het volgende afgevraagd:
> Als er een nieuwe compiler gemaakt wordt, wordt die toch in een bepaalde
> taal geschreven (in welke eigenlijk?) . Goed, maar in welke taal is dan de
> eerste compiler geschreven? assembler? Ok, maar hoe hebben ze dan dat
> assembler programma omgezet naar de hex-string die de (micro)processor
> begrijpt? Daar is toch ook een soort compiler voor nodig... Ik vraag mij
> echt af hoe ze dat gedaan hebben.
> 
> Hopelijk weet iemand het, of een paar links.
> Jan

De eerste pc's hadden schakelingen ipv geheugen, die je dus manueel kon
resetten met een switch (eerst voor elke geheugenplaats een eigen switch,
daarna een systeem met een tellertje).

Er zijn programmeurs geweest die rechtstreeks in machinetaal programmeerden.
Je kan je inbeelden hoe rap je op zo'n plaats een bitje verkeerd zet.

bv http://www.charlieanderson.com/images/Various/what.jpg

Oelewapperke

On 2004-01-18 14:44:16 (+0100), Jo Vermeulen <jo@lumumba.luc.ac.be> wrote:
> JanS schreef:
> > Bedankt voor het antwoord.
> > Als er iemand meer details zou kunnen geven, altijd welkom...
> > Wat ik mij nog afvraag... Stel: ik zou een OS willen ontwikkelen (wat heel
> > theoretisch is, aangezien ik net de basis van programmeren kan) Waar zou ik
> > moeten beginnen, hoe zit dat allemaal in elkaar? Raadsels...
> 
> Koop je een boek over besturingssystemen. Wij hebben bij de cursus 
> besturingssystemen deze gebruikt:
> 
> http://cs-www.cs.yale.edu/homes/avi/os-book/osc/index.html
> 
> Meer praktisch is deze van dezelfde auteur(s):
> 
> http://cs-www.cs.yale.edu/homes/avi/os-book/aosc/index.html

Ook een goed boek is ``The Design and Implementation of the 4.4BSD Operating
System'' van McKusick en co.  Hoofdstuk 2 ervan kan je online lezen:

  <http://www.freebsd.org/doc/en/books/design-44bsd/index.html>

 - Philip

-- 
Philip Paeps                              Please don't send me replies
                                           by email, I read the group.

   A fool and his money soon go partying.

On 2004-01-19 09:19:43 (+0000), mart <No@Spam.com> wrote:
> Het is ingewikkeld om het allemaal tot in details uit te leggen. Ik ga
> proberen een eenvoudige uitleg te geven. Experts Dont kill me als ik de
> dingen heel erg simplifiseer.

Beetje aanvullen :-)

> Als illustratie probeer ik het opstarten van een oude pc uit te leggen.

Niet 'oud', op ongeveer alle (x86) machines die je tegenkomt gaat het zo...

> Wanneer je de knop omdraait krijgt de circuit "stroom". Het is zo ontworpen
> dat het dan overgaat in een bepaalde toestand.

Bij het onder stroom zetten van de processor bevatten bepaalde registers goed
gedocumenteerde waarden.  Vooral de instruction pointer is belangrijk (op x86
wordt die op 0xfffffff0 gezet), want die wijst naar het adres van de volgende
functie die moet uitgevoerd worden.  Op x86 wordt de processor ook in zgn.
'real mode' (vs. 'protected mode') gestart, wat er onder andere voor zorgt dat
je je fysieke address space ziet.

> Het voert een routine "POST" uit dat hardwarematig gecodeerd is. Na deze
> routine wordt de BIOS ingeladen en de bootstraploader wordt geactiveerd.
> Deze zoekt op de beschikbare schijven naar de bootable partitie en laat de
> bootloader van de OS. De bootloader laadt dan op zijn beurt het OS.

Bijna juist :-)  De volgorde is een beetje anders.  De hardware zorgt ervoor
dat de instruction pointer door de BIOS gezet wordt naar het adres van de POST
functie, de POST zet dan het boot device en gooit het bootrecord daarvan in
memory en stuurt de execution daarheen.  Op x86 staat in het bootrecord ook
nog een partition table (op een vaste plaats waarvan het adres me even
ontgaat), waarvan ��n partitie een bootable bit mag hebben.  De code in het
bootrecord zorgt er dan voor dat de bootloader uit die partitie in memory
gegooit wordt, en stuurt de execution door naar daar.  De bootloader wordt
geacht iets te weten over filesystems en zwiert de kernel (of tegenwoordig
meer het geval: een iets meer geavanceerde bootloader) in memory.  Daarna
wordt *eindelijk* de kernel geladen :-)

> Natuurlijk is het opstartprocess tegenwoordig wat ingewikkelder door
> ontwikkeling in de electronica, maar dan wordt het te ingewikkeld om het
> simpel uit te leggen.

Niet echt.  Het principe op x86 is nog steeds hetzelfde voor de P4 als voor de
i386.  Enige echte verschil tegenwoordig is dat de meeste bootloaders in
protected mode draaien met een beetje extra magie zodat de kernel later de
descriptor table enzo kan aanpassen.  Zo ingewikkeld is het allemaal niet.

Op andere architecturen is het wel een stuk prettiger werken...  Als je bv.
een Alpha van de disk boot, verwacht de SRM alleen dat de bootloader 'ergens'
staat en stelt ook geen echte beperkingen op de grootte ervan.  Op de eerste
512b van je disk zet je in 0x480 hoe groot je bootloader is, in 0x488 zet je
waar hij begint, 0x496 is altijd 0, en in 0x504 zet je een checksum van de
eerste 63b.  Als de SRM de checksum correct verklaart, leest hij het aantal
sectors opgegeven in 0x480 te beginnen van wat er in 0x488 staat, en mapt ze
in memory op 0x20000000 en begint de zaak vrolijk uit te voeren.  Kous af.

> Een ander voorbeeld van de overgang software/hardware zijn de device
> drivers. Deze drivers vertallen een aanvraag van de OS naar de basis
> instructie set van de microchip op de kaart of in de device.

Mjah.  De kernel doet de vertaling tussen hardware en software, en drivers
zijn gewoon kernel 'services'.  Tegenwoordig zitten de meeste kernels redelijk
vol met abstractielayers waardoor een driver niet echt veel magische toeren
moet uitsteken.

> Maar vergis je niet want achter elke OS zit een behoorlijk stuk wiskunde. Oa
> wachtrij theorien en optimalisatie.

Voor simpele hardware zou dat normaal moeten meevallen.  Niet dat ik voor mijn
plezier even een kernel zou willen schrijven...

 - Philip [die er nogal regelmatig van beschuldigd wordt het woord 'gewoon'
           op schandalige manieren te misbruiken]

-- 
Philip Paeps                              Please don't send me replies
                                           by email, I read the group.

   Bad law is more likely to be supplemented than repealed.