[PIC] Vraagje over het CPU gebeuren

Hoi allemaal :)

Ik heb een best wel ingewikkelde vraag (dat denk ik er zelf toch van).
De CPU van de µC beschikt over een two-stage pipeline en heeft twee instructiecycli nodig om één instructie te verwerken. Dit resulteert bij een vloeiend systeem in één instructie per instructiecyclus. Tot daar nog allemaal logisch. Maar als ik dan eens ga kijken wat er in die twee instructiecycli gebeurt kom ik toch wel tot een rare vaststelling. Zo heeft hij één instructiecyclus (4 clockcycli) nodig om de instructie op te halen. Vervolgens slaagt hij erin om binnen de volgende instructiecyclcus de instructie te latchen in het instructieregister, de instructie te decoderen, de operanden op te halen, de bewerking uit te voeren en de hele prul terug te schrijven. Dit lijkt me helemaal niet logisch.

Heeft er iemand enig idee wat hij dan allemaal niet moet doen in die 4 eerste clockcycli bij het ophalen van de instructie? Waarom dat zo lang duurt... Of duurt het ophalen zelf minder dan 4 clockcycli en worden de overige clockcycli opgevuld met "niets" zodat de pipeline kan werken?

Groeten

H-V

Ik zou de datasheet nog eens lezen, en de bijbehorende tekeningen want wat je nu zegt klopt niet.

Nee, ik ga dit niet overtypen ,staat er duidelijk genoeg in.
Hoofdstuk 3 van de 16F628 bijv.

je moet dat ding zien als ene schuifregister van 4 stappen
in de eerste stap gebeurt het laden van het commando
in de 2e stap wordt gekeken wat ( en of ) er nog iets nodig is
de derde stap voert uit en de vierde dumpt het resultaat ergens.

dus als dat ding ui treset komt zijn er x cyclis nodig om de eerste opdracht tot bij de verwekrende eenheid te laten komen

maar net doordat je dat spul streamlined gaat de doorvoer sneller. het is lopende band werk ( totdat er een branch moet gedaan worden. dan kan het zijn dat hetgeen al geladen is verkeerd is omdat naar de andere tak moet gesprongen worden. dan moet de pipeline worden 'geflushd'

Nou, om te staven wat ik dus zei, hier een stukje uit de Reference Manual:

The clock input (from OSC1) is internally divided by four to generate four non-overlapping
quadrature clocks, namely Q1, Q2, Q3, and Q4.

Er staat dus dat het kloksignaal nog eens door vier gedeeld wordt, zodat je vier apparte kloksignalen krijgt die achter elkaar volgen zonder te overlappen.

An "Instruction Cycle" consists of four Q cycles (Q1, Q2, Q3, and Q4). Fetch takes one instruction
cycle while decode and execute takes another instruction cycle.

Hierin staat dus dat het fetchen van een instructie één instructiecyclus in beslag neemt. Er staat eveneens dat één instructiecyclus uit vier klokcycli bestaat (zie bovenstaande quote waarom). Daarnaast staat er nog dat de overige troep, het decoderen, uitvoeren en wegschrijven nog eens één instructiecyclus in beslag neemt.

In the execution cycle, the fetched instruction is latched into the "Instruction Register (IR)" in
cycle Q1. This instruction is then decoded and executed during the Q2, Q3, and Q4 cycles. Data
memory is read during Q2 (operand read) and written during Q4 (destination write).

De tweede instructiecyclus waarin de hele nest wordt uitgevoerd gebeurt hetgeen in dit deel beschreven staat. Elke klokslag (en dus 1/4 van de instructiecyclus) wordt iets gedaan.

En nu kom ik terug bij mijn vraag:
Er staat ENKEL dat het fetchen van de instructie één instructiecyclus (en dus vier klokcycli) in beslag neemt. Er staat NIET in wat er allemaal gebeurt in die ene instructiecyclus waarin een instructie gefetched wordt. Het lijkt me zeer onlogisch dat hij 4 keer zo lang doet over het ophalen dan over het verwerken ervan.

Ik hoop dat het nu duidelijk is.

Terwijl het ene geladen wordt (fetch) wordt, wordt het andere uitgevoerd (execute).
Anders zou het idd zonde van de tijd zijn.

Zie de 'Clock/instruction cycle' en de 'Instruction pipeline flow' grafieken.

Je zit nog met de ouderwetse Von Neumann cyclus in gedachten.

[Bericht gewijzigd door Henry S. op ]

Op 3 februari 2007 00:10:18 schreef Henry S.:
Terwijl het ene geladen wordt (fetch) wordt, wordt het andere uitgevoerd (execute).
Anders zou het idd zonde van de tijd zijn.

Zie de 'Clock/instruction cycle' en de 'Instruction pipeline flow' grafieken.

Je zit nog met de ouderwetse Von Neumann cyclus in gedachten.

Maar neen...
Zover ben ik ook dat dankzij die pipeline er één instructie per instructiecyclus wordt uitgevoerd (als je een vloeiend systeem hebt), met uitzondering van het springen in de program counter.

Maar effectief gezien duurt het nog steeds twee instructiecycli om één instructie volledig uit te voeren.

Maar waarom heeft dat ding 4(!!) klokcycli nodig om een instructie te fetchen terwijl hij de instructie kan decoden in één cyclus en de operanden ophalen ook in één cyclus.

Edit:
En je spreekt daar over de oude von-Neumann architectuur, maar bij mijn weten wordt die nog altijd toegepast tussen het RAM en het cach van een computer, dus zo oud zou ik hem niet noemen.

[Bericht gewijzigd door High-Voltage op ]

Nee, effectief duurt het 1 cyclus! Alleen de eerste instructie duurt effectief 2 cycli.

Waarom er 4 ticks voor de fetch nodig zijn? Omdat de pipeline bezig is met de execute van de vorige fetch en je hebt er maar eentje.

Von Neumann is sterk verouderd, 1 cyclus, vaste databreedte, etc

Harvard is veel flexibeler door het opsplitsen van programma en data.

[Bericht gewijzigd door Henry S. op ]

Op 3 februari 2007 00:38:23 schreef Henry S.:
Nee, effectief duurt het 1 cyclus!

Nadat je pipeline opgang is gekomen is het equivalent inderdaad één instructie per cyclus die eruit rolt om het zo maar te omschrijven.
Maar het duurt nog steeds twee volledige instructiecycli om één instructie uit te voeren. Nu kan je mij zeggen wat je wil, maar daar kan je niet naast. Ok, omdat je de ene instructie met een overlap gelijktijdig uitvoert komt er, eens je systeem vertrokken is, één instructie per instructiecyclus uit.

Waarom er 4 ticks voor de fetch nodig zijn? Omdat de pipeline bezig is met de execute van de vorige fetch en je hebt er maar eentje.

Nee, hij is/was bezig met de execute van de huidge terwijl hij de nieuwe gaat fetchen, hij zal er nooit twee tegelijk fetchen.

Op 3 februari 2007 00:38:23 schreef Henry S.:
Von Neumann is sterk verouderd, 1 cyclus, vaste databreedte, etc

Harvard is veel flexibeler door het opsplitsen van programma en data.

Klopt volledig, maar het wordt wel nog constant toegepast in de huidige PC's, gewoon omdat Harvard te duur is.
Maar goed, er zitten nog zoveel fouten in de huidige PC's die gegroeid zijn uit het verleden, maar daar ging de discussie niet over.

[Bericht gewijzigd door High-Voltage op ]

Op 3 februari 2007 00:40:55 schreef High-Voltage:
[...]
Nadat je pipeline opgang is gekomen is het equivalent inderdaad één instructie per cyclus die eruit rolt om het zo maar te omschrijven.
Maar het duurt nog steeds twee volledige instructiecycli om één instructie uit te voeren. Nu kan je mij zeggen wat je wil, maar daar kan je niet naast. Ok, omdat je de ene instructie met een overlap gelijktijdig uitvoert komt er, eens je systeem vertrokken is, één instructie per instructiecyclus uit.

En dat is het dus effectief, 1 cycle.

]
Nee, hij is/was bezig met de execute van de huidge terwijl hij de nieuwe gaat fetchen, hij zal er nooit twee tegelijk fetchen.

Dat zeg ik... tov de fetch!

Een P4 heeft meerdere pipelines, en is verder niet te vergelijken met een RISC.

Het enige wat ik nog kan bedenken is dat de huidige instructie gelatched wordt, waardoor je één klokcyclus verliest, maar dan heb je er nog steeds drie over om je nieuwe instructie te fetchen, lijkt me ook maar overkill.

Wat wil je dan met de 3 overgebleven ticks doen? je kan de 3 instructies toch niet kwijt... Hoogsten pre-fetchen.

DAT is juist mijn vraag...
Je hebt daar drie klokcycli en je moet één instructie fetchen, dus ofwel gebeurt dat in één klokcyclus en staan de overige twee leeg, ofwel gebeurt dat in drie klokcycli, maar dan begrijp ik totaal niet hoe het komt dat het drie klokcycli duurt.

Omdat het gewoon de tijd is die er voor staat!
Maakt ook geen donder uit, er moet toch op de execute cycle gewacht worden.

Het enige effect is zo dat de meeste instructies effectief in cycle afgehandeld worden.

Wat jij ziet als een nadeel is alleen maar een voordeel tov een Von Neumann...