Ich habe mir eben deine Anmerkung: "b_op scheint ein alias für bmiss_sel!=PC_NEXT" nochmal durchüberlegt: da hast du vollkommen recht, und das führt dazu das man sich das bit für b_op ohne kosten sparen kann da jede lut sowieso 4 eingänge hat man müste halt das "dont care" von bmiss_sel durch "bmiss_sel=PC_NEXT" ersetzen. die ersparnis bringt aber wahrscheinlich nur eine hand voll LUTs
g martin Benedikt Huber wrote:
On 17.05.2010, at 08:44, Elshuber Martin wrote:Hallo ret: ret liest from stack, daher gilt für stack-sel "don't care"Sorry, ich meinte wp_pred, aber jetzt ist es eh klar.call: ich habe bewust stacksel preds gewählt. grund:1) unser imem fast 4096 (2^12) wörter, der programm counter kan theoretisch 17 bit breit sein, wobei derzeit nur 12 genutzt werden. 2) stack-sel beeinflust nur die bits 17-31 (15 predikat bits) folglich ist es kein problem die rücksprung adresse und die predikate ein ein wort zu schreiben.Ah, ok, d.h. bei STACK_PRED werden PREDS und ALU[0..16] gepushed.3) folglich glit eigentlich bei call für stack-sel eigentlich "don't-care" da die bits 0-16 immer von der alu kommen 4) für geringe zusatzkosten (statt dont-care ein stack-pred für calls) werden zusätzlich die predikate gespeichert.Ah,ok. Ja, ich denke die Predicates automatisch zu pushen ist eine gute Idee.5) eine funktion kann daher entscheiden ob sie invariant gegenüber den predikaten bleiben will oder nicht indem sie entweder ret oder iret ausführt.Gut, gefaellt mir. Ich hab den 'fix' reverted. Danke fuer die Erklaerung. lg, benediktg martin Am 17.05.2010 00:30, schrieb Benedikt Huber:Hi Martin, frage zu call/ret in der Decode Stage: > type stack_sel_type is (STACK_ALU, STACK_PRED)a) Beim call sollte es doch STACK_ALU (als Z + immediate/ret_addr) und nicht STACK_PRED sein, oder? Hab ich jetzt mal geaendert. b) Ich verstehe, dass bei ireturn eigentlich auch die predicates gepopped werden sollen, aber mit der aktuellen Architektur geht das so nicht, oder?gute nacht, benedikt
