Mit wievielen Rechenschritten muss ich rechnen, wenn ich eine Division in einem RISC Prozessor ablaufen lasse. Ich habe schon gegoogelt und die diversen Algorithmen gesehen. Wie sieht es aber nach deren Umsetzung in Maschinencode aus? (gleich im vorraus: Ich bin Hochsprachenfan und habe zum ersten mal ein Problem mit einer so Zeitkritischen Frage)
Stefan R. schrieb: > Mit wievielen Rechenschritten muss ich rechnen, wenn ich eine Division > in einem RISC Prozessor ablaufen lasse. Das kommt ganz drauf an, was der Prozessor kann. Wenn er z.B. bereits dividieren kann, muss man es nicht über subtrahieren nachbauen. Also, welchen RISC willst du verwenden?
Schreib ein Testprojekt für deinen Zielprozessor und lass dir dann dein C-Programm als asm-listing ausgeben. Was muss denn da geteilt werden? Teilen durch eine Konstante lässt sich meist mit ein bisschen Schieben und Addieren/Subtrahieren in wenigen Schritten selber lösen. Bei Schiebung auf 8bit Prozessoren um mehr als 8 Bit, wenn der Prozessor immer nur um 1 Bit Schieben kann, kann man dem Compiler im wahrsten Sinne des Wortes auf die Sprünge helfen, indem man die 16- oder 32-Bit Variable als Union aufzieht und so einfachst auf die einzelnen Bytes zugreifen kann. mfg mf
Zielprocessor wären ein NIOSII oder LEON3. Frage die ich beantworten muss: Kann ich bei einem Takt vom maximal 100MHz eine bestimmte Rechenoperation in einer vorgegebenen Zeit (20ns) durchführen? (8-Bit Variable durch 8-Bit Variable) Eigentlich ist mir klar, dass es nicht geht. Ich brauche aber eine stichhaltige Erklärung für mein Fazit. Ein Testprogramm wäre zu aufwendig. Die Zeit habe ich leider nicht.
LEON3: - Hardware multiply, divide and MAC units Bei 100MHz Takt wären 20ns = 2 Takte. Im Datenblatt schauen, ob der Core die Division in maximal 2 Takten packt.
Floh schrieb: > LEON3: > - Hardware multiply, divide and MAC units Wenn ich hier nachlese http://www.lothar-miller.de/s9y/categories/24-Rechnen frage ich mich, wie Herr Gaisler das hinbekommen hat. Entweder er verbrät unglaublich Resourcen oder es ist nur die halbe Wahrheit... > Bei 100MHz Takt wären 20ns = 2 Takte. > Im Datenblatt schauen, ob der Core die Division in maximal 2 Takten > packt. Ob man so rechnen kann? Meine uralt Assemblerkenntnisse sagen: Ich tippe in C++ ein c=a/b; -Wenn der Programmierer des Compielers sorgfältig gearbeitet hat -Wenn der Prozessor nicht belastet ist -Wenn ich den Resourcenbedarf des OS ignoriere -Die Daten bereits im Cache stehen und nicht aus dem Hauptspeicher gelesen werden müssen kommt mindetstens eine Routine im Stil von Lade a aus Speicherstelle 1 in Register x Lade b aus Speicherstelle 2 in Register y Dividiere Inhalt Register x durch Inhalt Register y Schreibe den Inhalt der Akku in Speicher 3 Das wären 4 Schritte. Kann ich so argumentieren?
>wie Herr Gaisler das hinbekommen hat. Entweder er >verbrät unglaublich Resourcen oder es ist nur die halbe Wahrheit The GRFPC requires approximately 4,000 LUTs on a Virtex-II FPGA ersteres...
Stefan R. schrieb: > Das wären 4 Schritte. > Kann ich so argumentieren? Könnte man, wenn deine Argumentation aber an 2 Takten hängt wird's eng... der NIOS-II unterstützt z.B. pipelineing, es könnte also sein, das zwar der Initialaufwand 4 Takte bedeutet, danach aber in jedem Takt eine Division durchgeführt wird. Zum NIOS gibt es auch jedenfall aber eine Befehlsreferenz wo steht wie lange der für die einzelnen Operationen benötigt (hab ich für meine Diplomarbeit benötigt). Zum dem unterstützt der auch Custominstructions, wen mal also ganz fies sein will und Platz keine Rolle spielt, hängst du da eine Lockuptabelle dran die die beiden 8 bit Werte als index verwendet (du kannst dann sogar beide Operanden in eines der 32 bit Register liegen lassen) und bist im nächtem Takt fertig wenn alles glatt läuft. Stefan R. schrieb: > Wenn der Programmierer des Compilers sorgfältig gearbeitet hat Man kann auch inline ASM für den NIOS verwenden.
Vielen Dank für den Tipp. Hier steht es genau beschrieben: Mit meiner Hardware brauche ich 5 Cycles für eine Division mit dem Nios 2 /f und es steht auch genau darin, unter welchen Bedingungen pipelining das ganze Beschleunigen kann. Read the f******g manual ;-)
Noch schlimmer siehts beim LEON3 aus: 35 Cycles für SDIV/UDIV
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.