Duur nop?

Algemeen : Kijken in de datasheet hoeveel klokcycli een NOP gebruikt en dan (1/kristalfrequentie)*aantal klokcycli (van de NOP). Wel even controleren of de klok niet nog gedeeld wordt in de controller.

NOP is normaal gelijk aan T_cy (Cycle time)

Op 17 februari 2012 15:45:21 schreef Arco:
NOP is normaal gelijk aan T_cy (Cycle time)

Hangt helemaal van de processor af. Op een 6502 duurt een NOP 2 cycli, (maar da's dan ook de minimale tijd om welke instructie dan ook uit te voeren). IIRC had je op een avr ook 2 cycli voor een NOP nodig.

TS heeft het hier over PIC's...

Op 17 februari 2012 16:01:45 schreef alex278:
IIRC had je op een avr ook 2 cycli voor een NOP nodig.

Nee, nop op AVR is 1 cycle. Staat in de avr instruction set manual. Voor PIC32 zal ook wel zo'n soort manual zijn...

Je moet ermee opletten. Bijvoorbeeld op sommige ARM's is de duur van een NOP 0 of 1 cycles afhangkelijk welke instructie ervoor komt. Een PIC32 is ook vrij geavanceerd dus dat zou ook wel zoiets kunnen zijn.

Ik weet niet beter dan dat een nop een cycli duurt.

ik kijk in deze datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/61143E.pdf

en vindt hierin nergens een tabel met instructie cycles wel een tabel met instructies.

In de PIC32 CPU reference manual staat dat een NOP geen cycles gebruikt, de SSNOP gebruikt 1 cycle...

Welk nut heeft een nop die geen tijd kost om uit te voeren? Dan kun je toch net zo goed de volgende instructie 1 adres eerder zetten?

Om een bestaande instructie over te slaan bijvoorbeeld. Je kunt die dan vervangen door NOP's...
(Eigenlijk een placeholder dus...)

Maar wat dom dat d'r geen overzicht van de instructieset met opcodes, adresseermodes en tijden in die datasheet staat.

Een placeholder om makkelijk te kunnen patchen.

Andersom werkt het ook, bij het kraken van allerhande beveiligde software werd soms een conditionele sprong uitgenopt.

Alleen handig als je direct in de hexfile dingen wilt wijzigen dus?
In ASM kun je toch ook gewoon een regel uitcommenten? Lijkt me duidelijker dan de code wijzigen in NOP waar eerst iets anders stond...
En alsnog kan placeholden ook met een NOP die wel een cycle kost (Als het er erg veel zijn wordt je programma erg traag, maar wie gaat er nu -zeg- 500 NOPS ergens tussen typen? Kost alsnog maar maar 'n halve miliseconde op 1 MIPS).

Ik zie het voordeel nog niet echt van een NOP die geen cycles kost. Behalve dan dat het "netter" is dat een NOP ook écht niks doet, zelfs geen cycle "burnen".

Maar wat dom dat d'r geen overzicht van de instructieset met opcodes, adresseermodes en tijden in die datasheet staat.

Alle MIPS32 info (PIC32 is een MIPS32 MCU) staat op de MIPS site:
http://www.mips.com/products/product-materials/processor/mips-architec…

"Vroeger" met gewone CPU's was een nop altijd een gewone instructie die 1 of 2 cycles duurt.

Maar met tegenwoordige geavanceerde CPU's met pipelines, out of order execution, branch delay slots(MIPS) etc. moet je echt het manual erbij pakken om uit te vissen wat een 'nop' doet.

Dat een nop '0' cycles kost vindt ik vreemd, ook al zou er een pre-instruction decoder in de CPU zitten, die de nop's wegfiltert, is dat nog maar beperkt: als de werkelijke instruction pipeline leeg is gaat het toch tijd kosten.

P.S. De nop in een branch delay slot kost niks, ergens anders in de code wel!

@Lucky Luke: in de hexfile of gewoon direct in de binary. Vooral handig als je geen source hebt of tijdens het debuggen.

Een nop uitvoeren over 0 clocks wordt waarschijnlijk gedaan zoals een HC595 schuifregister werkt, met een korte puls korter dan 1 klokpuls die uit het xtal komt?

@RES, lees mijn vorige 'P.S.' eens dat is de reden dat het 'niks' kost.

Anders lees dit eens:
http://en.wikipedia.org/wiki/Delay_slot

Ik zie ook dat er zelfs een "load delay slot" is (was ik alweer vergeten).

Programmeren van MIPS cpu's direct in assembly is een nachtmerrie door deze trukkendozen.
Sommige assemblers doen execution reordering automatisch voor je (tenzij je het met een pragma uitzet).
Je loopt dan wel eens tegen allerlei verassingen aan dat de uiteindelijke assembly niet meer hetzelfde is als je source.

Op 18 februari 2012 12:37:38 schreef Arco:
[...]
Alle MIPS32 info (PIC32 is een MIPS32 MCU) staat op de MIPS site:
http://www.mips.com/products/product-materials/processor/mips-architec…

..in een van de meer dan 10 pdf'jes, en de 'instruction set quick reference' is het niet...

Op 18 februari 2012 13:06:15 schreef henri62:
Programmeren van MIPS cpu's direct in assembly is een nachtmerrie door deze trukkendozen.

Pipelined CPUs moet je ook niet meer in asm willen programmeren. Je gaat een FPGA ook niet bit-voor-bit "uithakken" (de Duitsers doen het wel, speichern). Je hebt tools nodig om de zaak efficient voor je uit te rekenen.

@henri hieronder: ja klopt. Anders kom je niet bij je registers, stack en zo. Gelukkig zijn dat maar kleine stukjes code als het goed is.

[Bericht gewijzigd door flipflop op zaterdag 18 februari 2012 15:50:02 (15%)]

Op 18 februari 2012 13:35:41 schreef flipflop:
[...]
Pipelined CPUs moet je ook niet meer in asm willen programmeren.

Soms is het wel noodzakelijk, bijvoorbeeld als je je master ISR moet maken of een trap handler, dat is in C bijna niet te doen omdat je niet precies weet wat die er van bakt.

Ook voor inner loops kan asm erg nuttig zijn, maar zelfs als je nooit direct in asm programmeert, vind ik dat een embedded systems programmeur het moet kunnen lezen en snappen, juist om te kunt bekijken en controleren wat de C compiler ervan gebakken heeft. Nu is het wel zo dat die compilers over het algemeen geen fouten maken, maar als een stuk code niet doet wat je wilt, of meer CPU tijd kost dan je had verwacht, is het lezen van de asm code vaak een goede manier om onderzoek te kunnen doen.

@Lucky Luke: hoewel je bij een AVR of PIC de code over het algemeen in flash hebt staan, zijn er ook genoeg (embedded) platforms waar je de code in RAM kunt of zelfs moet laden. Code in RAM kun je dan at run-time patchen, door de processor stil te leggen, de code te patchen, en de processor weer te starten of steppen. Daarbij is het vaak handig om code te vervangen door NOPs in plaats van de code alleen weg te halen, omdat de rest van de code dan opschuift.

Daarbij zijn NOPs ook "nuttig" voor exploits; voor stack overflow exploits wordt traditioneel een "landing zone" voor de instruction pointer gebruikt die bestaat uit NOPs, wat handig is omdat het vrijwel altijd een instructie is met de kleinst mogelijk lengte, en daarmee gelijk aan de breedte van de databus van de controller, waardoor je niet halverwege een instructie kunt landen.

Als je meer wilt leren over de werking van software, processors, besturingssystemen, etc., hoe daar door aanvallers misbruik wordt gemaakt en wat je daar tegen kunt toen, zou ik "the shellcoders handbook" aanraden. "The art of exploitation" schijnt ook wel goed te zijn, en voor een korte inleiding in stack overflow vulnerabilities is "smashing the stack for fun and profit" wel een goede.

[Bericht gewijzigd door SparkyGSX op zondag 19 februari 2012 01:02:25 (29%)]

Sparky, dank voor de uitleg Even kijken of ik het begrepen heb: Als de rest van de code opschuift schuiven adressen waar jumps naar toe moeten natuurlijk ook op en dat maakt het hopeloos ingewikkeld, vandaar dus die nop. Als de ene instructie breder is dan de andere zou je zelfs nog halverwege een instructie uit kunnen komen, dat gaat al helemaal niet goed. Alsnog zou zo'n NOP dan best 1 of een paar cycles mogen kosten, maargoed, misschien voor tijdkritische dingen handig dat er ook een NOP bestaat die geen cycles kost...