EP1461699A2 - Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung - Google Patents

Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung

Info

Publication number
EP1461699A2
EP1461699A2 EP02798357A EP02798357A EP1461699A2 EP 1461699 A2 EP1461699 A2 EP 1461699A2 EP 02798357 A EP02798357 A EP 02798357A EP 02798357 A EP02798357 A EP 02798357A EP 1461699 A2 EP1461699 A2 EP 1461699A2
Authority
EP
European Patent Office
Prior art keywords
resource
resources
allocated
program
occupied
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP02798357A
Other languages
English (en)
French (fr)
Inventor
Carsten Noeske
Ralf Herz
Franz-Otto Witte
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
TDK Micronas GmbH
Original Assignee
TDK Micronas GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by TDK Micronas GmbH filed Critical TDK Micronas GmbH
Publication of EP1461699A2 publication Critical patent/EP1461699A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals

Definitions

  • the invention relates to a method for managing resources for a computer device with the preamble features of claim 1 and
  • Both programming concepts use the "stack" very intensively, a memory or data structure in which data is stored as if on a stack.
  • the basic principle of the "stack” is that the last value placed on the stack 5 is the first one again must be removed from it. For example, when a subroutine is called, the return address for the subroutine is put on the stack.
  • the use of the stack is very versatile, but its use requires frequent memory access, which is due to the associated latency and also due to the resulting high power consumption, as well as the limited bandwidth of the processor buses as a bottleneck for the
  • the described grievance is characterized above all by the fact that a programmer using modular or object-oriented techniques, in particular iterations or recursions, cannot have any information about the state of the processor's resources at the time of its routine.
  • the object of the invention is to propose a method and a device for managing resources for a computer device which enable efficient management of the available resources.
  • This task is accomplished through the procedure for managing
  • the starting point here is a method for managing resources for a computer device, in which a multiplicity of resources are available for executing programs, at least some of the resources being temporarily or permanently occupied by such an executed program.
  • the allocation of resources has steps that are known per se. After requesting at least one of the resources to be allocated for the program, these are usually the saving of the resource to be allocated for its later restoration or restoration. After saving the resource to be assigned, the requested one Resource assigned to the requesting program, which then occupies the corresponding resource.
  • the step of checking the occupancy status of the resource to be assigned is inserted after the request for at least one of the resources. Depending on the result of the check, if the resource to be assigned is fully or partially occupied, the process of saving and then assigning and occupying the resource will proceed. If the resource to be assigned is not occupied, i.e. H. is free, the step of saving the resource to be assigned is omitted and instead the allocation of the assigned resource is advanced.
  • the program can be a software code, but in a broader sense it also includes permanently stored programs, which are used, for example, when connecting a
  • Hardware device to a computer trigger actions in the computer or in its computer device from the permanent memory of the hardware device.
  • a corresponding device for managing resources for a computer device accordingly has at least one memory location as a pointer memory location for storing a pointer value, in particular an address of the resource set, at least one availability counter with availability information for specifying the amount of available resources, a resource determination device to evaluate and update the Position of the pointer and the availability information, a resource allocation device for occupying and / or releasing the resources and a stack storage device for accommodating the content of resources occupied at the time of a resource request.
  • the device has a decision device for deciding whether a requested resource is free or occupied, whereupon the decision device, in particular in the form of a resource calculator, the requested resource in the case of a
  • the resource is assigned to the requesting device or the requesting program after the transfer of the previously occupied resource to the stacking device so that the resource content is secured, as is known per se.
  • the individual listed devices can also be partially or all integrated as hardware, functions or programs in a processor.
  • Local hardware resources of the computer including any form of processors with available processor resources, are advantageously assigned as resources.
  • resources for example accumulators, registers and pointers as resources
  • the various types of resources are subdivided into .0 resource classes and expediently administered separately from one another.
  • storage locations are provided for storing resource pointers, which refer to the corresponding resource classes.
  • resource pointers which refer to the corresponding resource classes.
  • an interrupt logic sends an interrupt in these cases, i. H. an interrupt signal, to interrupt the program run for the duration of the batch storage or after the run for the restoration.
  • the resource management is therefore a unit that monitors the state of the resources during runtime and enables the program / programmer to use hardware resources in an efficient manner by requesting them from the processor.
  • the requested resources are not used locally, they are allocated immediately, i.e. without unnecessary security and restoration measures. Only if a local
  • Fig. 1 schematically selected components of a
  • Resource management is based on the idea of expanding the memory stack with the elements of a resource class.
  • Resource classes here refer to similar resources, such as accumulators, which are interchangeable in terms of their function.
  • This arrangement has active circuit elements, such as an arithmetic logic unit 3, an instruction decoder 4 and an interrupt logic 5.
  • a memory 1 for storing one or more indicator values
  • an availability counter 2 for storing one or more availability information
  • a memory 7 as a resource class memory
  • a stack memory device 6 stack memory device 6 (stack) for receiving or Save the content of resources.
  • the various Memory devices 1, 2, 7, 6 can also be individual memory sections of a single or a plurality of higher-level memories.
  • a local resource pointer 1 is used for each resource class, with the property that its addressing takes place in a ring and / or in a modular manner over the amount of resources.
  • the processor in particular a higher-level processor or the arithmetic unit 3, advantageously accesses elements of a resource class always relative to the resource pointer 1 and also in a ring-shaped or modular manner.
  • availability information also referred to as FreePointer
  • the availability counter 2 which indicates how many of the total available components of a local resource class are available, that is, not by previous ones
  • a local resource arithmetic unit 3 is also provided for each resource class, which evaluates and updates the position of the resource pointer and the content of the FreePointer.
  • Instructions for requesting or releasing resources are implemented in the instruction decoder 4 of the processor.
  • Interrupt logic 5 is used when the local resources of at least one class are insufficient for a request.
  • the resource class memory 7, which is used to assign resource classes, is also advantageously provided.
  • Various resources for example registers, pointers or accumulators, are combined within a resource class, which may be represented multiple times in the system and can therefore be advantageous for joint administration.
  • a resource management process is started by making a resource request in the program running in the processor or in the computer device, which is evaluated by the instruction decoder 4.
  • the request information for the one or mostly several resources contains in particular the number of required resources of a class, which is expediently always less than or equal to the total number of local resource elements and the type of the resource class. Resources of several classes can advantageously be requested with one command.
  • the number of resources required is then passed on from the instruction decoder 4 to the resource arithmetic unit 3, which reduces the availability counter 2 by the number of resources requested and reduces the resource pointer in the pointer memory location 1 by the corresponding value.
  • the resource request is thus completed by the corresponding resource allocation to the requesting program.
  • a release of resources after, for example, processing of the program which has requested and been assigned the resource takes place in a complementary form, ie the values of both counters 1, 2 are increased again.
  • the interrupt routine can be operated on the basis of software or hardware. In the arrangement shown, it is represented by the interrupt logic 5, which is connected to the arithmetic unit 3 and the memory 1 for the pointer.
  • the value of the availability counter 2 is then set to zero.
  • FIG. 2 shows a practical example of a resource management cycle.
  • the instruction that is output by the instruction decoder 4 is given in each case.
  • the second column shows from top to bottom the chronological sequence of the occupancy of the requested resource (accumulators usage).
  • the resource has 8 storage locations, above which
  • Storage locations each show the value of pointer storage location 1 for the access point to free storage locations.
  • Unfilled boxes mean free storage spaces, filled boxes mean occupied storage spaces.
  • the third column shows the respective value of the availability counter or the occupancy pointer (AllocPointer), thus showing an offset.
  • the fourth column shows the value of the FreePointer, i.e. H. the value of the availability information in the availability counter 2 for this resource.
  • the last column shows the occupancy status in the stack of the stack storage device 6.
  • a first procedural step it is assumed that the resource is unoccupied or free.
  • the value of the allocation memory or pointer is correspondingly 0, so that the first resource 0 is allocated when a request is made would.
  • the availability information is accordingly equal to the value of the available storage spaces, that is to say 8, and the stack in the stack storage device 6 is empty.
  • the storage space in the stack storage device 6 remains unoccupied.
  • Availability information in the availability counter 2 is set to 0 and the occupancy pointer remains at the value 5.
  • the resource storage locations to be allocated or allocated are saved in the stack storage device 6, the resource locations to the right of the new occupancy pointer location are saved.
  • the stack storage device 6 After a further request from, for example, seven resource storage locations (Allocres (7)), the stack storage device 6 is backed up again, seven values of the resource being backed up.
  • the individual are then processed requesting programs or facility requirements and thus the release of resources.
  • this is done in the opposite way to the previous storage.
  • the circuit arrangement or the software running on it recognizes how many values are to be restored from the stack memory device 6 on the basis of the information about the number of values saved together with the values. This number is also used to determine the new availability information or the new FreePointer.
  • Availability counter FreePointer

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung zum Durchführen des Verfahrens und zum Verwalten von Ressourcen für eine Rechnereinrichtung, in der für das Ausführen von Programmen eine Vielzahl von Ressourcen verfügbar ist, wobei zumindest ein Teil der Ressourcen durch ein solches ausgeführtes Programm temporär oder dauerhaft belegt wird, mit den Schritten: a Anfordern zumindest einer der Ressourcen zum Zuweisen für das Programm, c Sichern der zuzuweisenden Ressource zu deren späteren Restaurierung, d Zuweisen der angeforderten Ressource zu dem Programm und e Belegen der zugewiesenen Ressource durch das Programm. Die Ressourcen-Verwaltung wird vorteilhaft verbessert durch b das Prüfen des Belegungszustands der zuzuweisenden Ressource und b1 entweder, falls die zuzuweisende Ressource nicht belegt ist, Fortschreiten mit dem Belegen der zugewiesenen Ressource e, b2 oder, falls die zuzuweisende Ressource belegt ist, Fortschreiten mit dem Sichern c und anschliessendem Zuweisen d und Belegen e der zugewiesenen Ressource.

Description

Beschreibung
Verfahren und Vorrichtung zum Verwalten von Ressourcen für eine Rechnereinrichtung
Die Erfindung bezieht sich auf ein Verfahren zum Verwalten von Ressourcen für eine Rechner-Einrichtung mit den oberbegrifflichen Merkmalen des Patentanspruchs 1 bzw. eine
LO Vorrichtung zum Verwalten von Ressourcen für eine Rechner- Einrichtung mit den oberbegrifflichen Merkmalen des Patentanspruchs 6. Es handelt sich somit insbesondere um eine Vorrichtung zur Verwaltung von Hardwareressourcen wie Register, Zeigern o.a. für die Optimierung der Rechenleistung
L5 von Prozessoren.
Bei der Entwicklung neuer Programmiertechniken und Programmiersprachen hat sich in den letzten Jahren eine deutliche Tendenz in Richtung einer modularen und
_0 objektorientierten Programmierung herausgebildet. Die
Vorteile der objektorientierten Programmierung liegen weniger in der erzielbaren Rechenleistung, als vielmehr in der Strukturierung und Wartbar eit von großen Softwareprojekten. Der Modularisierungsaspekt wird durch Zusammenfassung von
-5 logischen Blöcken zu Unterprogrammeinheiten mit einer definierten Startadresse, die von unterschiedlichen Programmpositionen aus aufgerufen werden kann, berücksichtigt. Der Aspekt der Objektorientierung manifestiert sich im Wesentlichen durch die Zusammenfassung
-0 von Datenbereichen und Unterprogrammen zu Objekten, von denen mehrere Instanzen eines gleichartigen Objekttyps erzeugt werden können, erweitert durch unterschiedliche Zugriffsbeschränkungen und Objektvererbungsmethoden, wie. dies z.B. in Bjarne Stroustroup „The C++ Programming LanguageλΛ .
55 beschrieben ist. Beide Programmierungskonzepte nutzen sehr intensiv den „Stack", eine Speicher- bzw. Datenstruktur, bei der Daten wie auf einem Stapel abgelegt werden. Das Grundprinzip des „Stacks" besteht darin, dass der zuletzt auf den Stapel 5 gelegte Wert jeweils als erster wieder von ihm entnommen werden muss. So wird zum Beispiel bei einem Unterprogrammaufruf die Rücksprungadresse für das Unterprogramm auf den Stapel gelegt .
.0 Der Einsatz des Stacks ist sehr vielseitig, jedoch bedingt sein Einsatz einen häufigen Speicherzugriff, was sich wegen der damit verbundenen Latenzzeit und auch wegen des dadurch bedingten hohen Stromverbrauchs, sowie der beschränkten Bandbreite der Prozessorbusse als Flaschenhals für den
.5 Datendurchsatz und die „Performance" des Rechenwerks auswirkt .
Um diese Nachteile zu vermeiden, werden häufig in der Realisierung von Rechnereinrichtungen bzw. Rechenwerken !0 lokale Ressourcen wie Akkumulatoren, Register oder Zeiger eingesetzt, welche die Nachteile des Stacks nicht aufweisen.
Der Einsatz von lokalen Ressourcen stellt jedoch im Zusammenhang mit modularen Programmierungstechniken ein
-5 Problem dar, das sich dahingehend äußert, dass zur Zeit der Compilierung eines Programmes der aktuelle Zustand bzw. die Belegung der Hardwareressourcen, nicht bekannt ist. Um dennoch mit modularen Strukturen arbeiten zu können, muss vom Programmierer eines Unterprogramms oder vom Compiler
10 sichergestellt werden, dass sich die Ressourcen entweder in einem zurückgesetzten Zustand befinden oder dass die Ressourcen vor Aufruf des Unterprogramms auf den beschriebenen Stack gesichert - und nach dessen Abarbeitung wieder restauriert werden. Letzteres Verfahren wird bei 5 heutigen Prozessoren standardmäßig angewandt. Die
Programmteile zum Retten lokaler Ressourcen werden auch als „Spill-Code" bezeichnet. Wie leicht einsehbar ist, wird durch den Spill-Code vor allem bei kurzen Unterprogrammen ein Teil der durch die Bereitstellung der Hardware-Ressourcen erwarteten Leistungssteigerung wieder kompensiert. Als besonderer Nachteil ist zu sehen, dass hier lokale Ressourcen quasi auf Verdacht aufwendig gesichert werden müssen, auch wenn diese eigentlich verfügbar wären.
Der beschriebene Missstand, ist vor allem dadurch gekennzeichnet, dass ein Programmierer bei Verwendung modularer oder objektorientierter Techniken, insbesondere bei Iterationen oder Rekursionen, keine Informationen darüber haben kann, in welchem Zustand sich die Ressourcen des Prozessors zur Laufzeit seiner Routine befinden.
Die Aufgabe der Erfindung besteht darin, ein Verfahren bzw. eine Vorrichtung zum Verwalten von Ressourcen für eine Rechner-Einrichtung vorzuschlagen, welche eine effiziente Verwaltung der verfügbaren Ressourcen ermöglichen.
Diese Aufgabe wird durch das Verfahren zum Verwalten von
Ressourcen für eine Rechner-Einrichtung mit den Merkmalen des Patentanspruchs 1 bzw. durch eine Vorrichtung zum Verwalten von Ressourcen für eine Rechner-Einrichtung mit den Merkmalen des Patentanspruchs 6 gelöst.
Ausgegangen wird dabei von einem Verfahren zum Verwalten von Ressourcen für eine Rechner-Einrichtung, in welcher für das Ausführen von Programmen eine Vielzahl von Ressourcen verfügbar ist, wobei zumindest ein Teil der Ressourcen durch ein solches ausgeführtes Programm temporär oder dauerhaft belegt wird. Das Zuweisen der Ressourcen weist für sich bekannte Schritte auf. Dies sind nach dem Anfordern zumindest einer der Ressourcen zum Zuweisen für das Programm üblicherweise das Sichern der zuzuweisenden Ressource zu deren späteren Restaurierung bzw. Rückspeicherung. Nach dem Sichern der zuzuweisenden Ressource wird die angeforderte Ressource dem anfordernden Programm zugewiesen, welches dann die entsprechende Ressource belegt.
Zur effizienteren Verwaltung der Ressourcen wird nach der Anforderung zumindest einer der Ressourcen der Schritt des Prüfens des Belegungszustands der zuzuweisenden Ressource eingefügt. Abhängig von dem Prüfungsergebnis wird für den Fall, dass die zuzuweisende Ressource ganz oder teilweise belegt ist, mit dem Sichern und anschließenden Zuweisen und Belegen der Ressource fortgeschritten. Falls die zuzuweisende Ressource nicht belegt, d. h. frei ist, wird der Schritt des Sicherns der zuzuweisenden Ressource ausgelassen und anstelle dessen mit dem Belegen der zugewiesenen Ressource fortgeschritten .
Entsprechend werden Ressourcen nur dann gesichert, wenn dies tatsächlich erforderlich ist. In den Fällen, dass die Sicherung entfallen kann, entfällt auch eine Vielzahl von Speicherschritten, d. h. Datenaustauschmaßnahmen, welche einerseits zeitintensiv und andererseits Rechnerkapazität beanspruchend wären.
Das Programm kann dabei ein Softwarecode sein, im weiteren Sinne sind aber auch festgespeicherte Programme darunter zu verstehen, welche beispielsweise beim Anschluss einer
Hardware-Einrichtung an einen Computer aus deren Festspeicher der Hardware-Einrichtung heraus Aktionen in dem Computer bzw. in dessen Rechnereinrichtung auslösen.
Eine entsprechende Vorrichtung zum Verwalten von Ressourcen für eine Rechnereinrichtung weist entsprechend zumindest einen Speicherplatz als Zeiger-Speicherplatz zum Abspeichern eines Zeigerwertes, insbesondere einer Adresse der Ressourcen-Menge, zumindest einen Verfügbarkeitszähler mit einer Verfügbarkeitsinformation zum Angeben der Menge der verfügbaren Ressourcen, eine Ressourcen- Bestimmungseinrichtung zum Auswerten und Aktualisieren der Position des Zeigers und der Verfügbarkeitsinformation, eine Ressourcen-Belegungseinrichtung zum Belegen und/oder Freigeben der Ressourcen und eine Stapel-Speichereinrichtung zum Aufnehmen des Inhalts von zum Zeitpunkt einer Ressourcen- 5 Anforderung belegten Ressourcen auf. Zur Verbesserung der Ressourcen-Verwaltung weist die Vorrichtung eine Entscheidungseinrichtung zum Entscheiden auf, ob eine angeforderte Ressource frei oder belegt ist, woraufhin die Entscheidungseinrichtung, insbesondere in Form eines 0 Ressourcen-Rechners, die angeforderte Ressource im Fall einer
I freien und bislang nicht belegten Ressource direkt zuweist-. Alternativ wird die -Ressource nach der Übergabe der zuvor belegten Ressource an die Stapeleinrichtung, so dass der Ressourcen-Inhalt gesichert wird, der anfordernden 5 Einrichtung bzw. dem anfordernden Programm zugewiesen, wie dies für sich genommen bekannt ist. Dabei können die einzelnen aufgeführten Einrichtungen auch teilweise oder alle als Hardware, Funktionen oder Programme in einem Prozessor integriert sein. 0
Vorteilhafte Ausgestaltungen sind Gegenstand abhängiger Ansprüche.
Vorteilhafterweise werden als Ressource lokale Hardware- 5 Ressourcen des Rechners, worunter auch jegliche Form von Prozessoren mit verf gbaren Prozessor-Ressourcen zahlen, zugewiesen. Bei einer Vielzahl verschiedenartiger Ressourcen, beispielsweise Akkumulatoren, Registern und Zeigern als Ressourcen, werden die verschiedenartigen Ressourcen in .0 Ressourcen-Klassen untergliedert und zweckmaßigerweise getrennt voneinander verwaltet. Entsprechend werden Speicherplätze zum Abspeichern von Ressourcen-Zeigern bereitgestellt, welche auf die entsprechenden Ressourcen- Klassen verweisen. Vorteilhafterweise werden bei der < 5 Verfahrensweise nur die Ressourcen adressiert, welche über eine Ressourcen-Verwaltung bzw. den zentralen Prozessor zuvor für bestimmte Aufgaben, insbesondere Programme, angefordert wurden.
Da für den Fall, dass eine angeforderte Ressource belegt ist und entsprechend durch die Stapel-Speichereinrichtung zu sichern ist, Zeit benötigt wird, sendet eine Unterbrechungslogik in diesen Fällen einen Interrupt, d. h. ein Unterbrechungssignal, aus, um den Programmablauf für die Dauer der Stapelspeicherung bzw. nach Ablauf für die Restaurierung zu unterbrechen.
Die Ressourcen-Verwaltung ist daher eine Einheit, die den Zustand der Ressourcen während der Laufzeit überwacht und es dem Programm/Programm!erer ermöglicht, auf effiziente Art Hardware-Ressourcen zu verwenden, indem diese vom Prozessor angefordert werden.
Sind die angeforderten Ressourcen lokal nicht belegt, so werden diese sofort zugeteilt, d.h. ohne unnötige Sicherungs- und Restaurierungsmaßnahmen. Nur dann, wenn eine lokale
Ressource zur Laufzeit belegt sein sollte, wird die sonst standardmäßig durchgeführte Sicherung durchgeführt.
Die Ressourcen-Verwaltung bewirkt somit bei ausreichenden lokalen Ressourcen eine deutliche Reduktion unnötiger
Datentransfers. Damit wird die Rechenleistung erhöht, bzw. die Leistungsaufnahme des Rechenwerks reduziert. Es ist nicht ungewöhnlich, dass ohne eine derart vorgeschlagene Ressourcen-Verwaltung über 30% der Rechenzeit für die Ausführung von „Spill-Code" benötigt wird.
Die Vorteile des Einsatzes lokaler Ressourcen bleiben bestehen, auch wenn nicht alle gleichzeitig über den Standard-Instruktionscode adressiert werden können. Es genügt vollkommen, nur die lokalen Ressourcen zu adressieren, die über die Ressourcen-Verwaltung für eine bestimmte Aufgabe angefordert werden können. Damit kann wertvoller Platz im Instruktionscode des Prozessors eingespart werden, was den Speicherplatzbedarf von Programmen reduziert.
Ein Ausführungsbeispiel wird nachfolgend anhand der Zeichnung näher erläutert. Es zeigen:
Fig. 1 schematisch ausgewählte Komponenten einer
Schaltungsanordnung einer Vorrichtung zum Verwalten von Ressourcen für eine Rechnereinrichtung und
Fig. 2 Belegungszustände von Speichern und
Parameterzustände bei einem beispielhaften Ressourcen-Verwaltungs-Zyklus .
Die Funktion der Ressource-Verwaltung basiert auf der Idee, den Speicherstapel um die Elemente einer Ressourcen-Klasse zu erweitern. Als Ressourcen-Klassen werden hier gleichartige Ressourcen, wie zum Beispiel Akkumulatoren bezeichnet, die bezüglich ihrer Funktion austauschbar sind.
Die Funktion der Ressourcen-Verwaltung ergibt sich durch eine Kombination verschiedener Komponenten, die im Folgenden aufgelistet sind. Fig. 1 stellt schematisch ausgewählte Komponenten einer Rechnereinrichtung oder eines
Prozessorkerns mit integrierten oder daran angeschlossenen Schaltungskomponenten dar, welche für das Verständnis der Ressourcen-Verwaltung vorteilhaft sind. Diese Anordnung weist dabei aktive Schaltungselemente, wie ein Rechenwerk 3, einen Instruktio'nsdecoder 4 und eine Unterbrechungslogik 5 auf.
Ferner sind teilweise aktive' oder passive Schaltungselemente bereitgestellt, wie ein Speicher 1 zum Abspeichern eines oder mehrerer Zeigerwerte, ein Verfügbarkeitszähler 2 zum Abspeichern einer oder mehrerer Verfügbarkeitsinformationen, ein Speicher 7 als Ressourcen-Klassenspeicher und eine Stapel-Speichereinrichtung 6 (Stack) zum Aufnehmen bzw. Sichern des Inhalts von Ressourcen. Die diversen Speichereinrichtungen 1, 2, 7, 6 können auch einzelne Speicherabschnitte eines einzigen oder mehrerer übergeordneter Speicher sein.
Hervorzuheben sind die nachfolgenden Schaltungskomponenten und ihre Funktionen.
1. Für jede Ressourcen-Klasse wird ein lokaler Ressourcen- Zeiger 1 eingesetzt, mit der Eigenschaft, dass seine Adressierung ringförmig und/oder modular über der Ressourcen-Menge erfolgt. Ein Zugriff des Prozessors, insbesondere eines übergeordneten Prozessors oder des Rechenwerks 3 auf Elemente einer Ressourcen-Klasse erfolgt vorteilhafterweise immer relativ zum Ressourcen-Zeiger 1 und ebenfalls ringförmig bzw. modular.
2. Weiterhin wird im Verfügbarkeitszähler 2 für jede Ressourcen-Klasse eine Verfügbarkeitsinformation, auch als FreePointer bezeichnet, abgelegt, die angibt, wie viele der insgesamt verfügbaren Komponenten einer lokalen Ressourcen- Klasse verfügbar, das heißt nicht durch vorhergehende
Vorgänge belegt sind.
3. Für jede Ressourcen-Klasse wird weiterhin ein lokales Ressourcen-Rechenwerk 3 bereitgestellt, das die Position des Ressourcen-Zeigers und den Inhalt des FreePointers auswertet und aktualisiert.
4. Im Instruktionsdekoder 4 des Prozessors werden Befehle zur Anforderung bzw. Freigabe von Ressourcen implementiert.
5. Eine Unterbrechungslogik 5 kommt zur Anwendung, wenn die lokalen Ressourcen wenigstens einer Klasse bei einer Anforderung nicht ausreichend sind.
6. Außerdem gibt es eine Stack-Einrichtung 6, welche den
Inhalt von lokalen Ressourcen aufnimmt, wenn bei einer Anforderung durch das Ressourcen-Rechenwerk 3 festgestellt wird, dass nicht genügend lokale Ressourcen einer Klasse vorhanden sind.
7. Vorteilhafterweise wird auch der Ressourcen- Klassenspeicher 7 bereitgestellt, welcher zur Zuordnung von Ressourcen-Klassen dient. Innerhalb einer Ressourcen-Klasse werden verschiedenartige Ressourcen, beispielsweise Register, Zeiger oder Akkumulatoren zusammengefasst , die unter Umständen mehrfach in dem System vertreten sind und daher eine gemeinsame Verwaltung vorteilhaft werden lassen.
Ein Ressourcen-Verwaltungsvorgang wird dadurch gestartet, dass in dem im Prozessor oder in der Rechnereinrichtung laufenden Programm eine Ressourcen-Anforderung erfolgt, die vom Instruktionsdekoder 4 ausgewertet wird.
Die Anforderungsinformation für die eine oder zumeist mehreren Ressourcen enthält dabei insbesondere die Anzahl der benötigten Ressourcen einer Klasse, die zweckmäßigerweise immer kleiner oder gleich der Gesamtzahl der lokalen Ressource-Elemente ist und den Typ der Ressourcen-Klasse. Vorteilhafterweise können mit einem Befehl Ressourcen mehrerer Klassen angefordert werden.
Die Anzahl der benötigten Ressourcen wird dann vom Instruktionsdekoder 4 an das Ressourcen-Rechenwerk 3 weitergegeben, das den Verfügbarkeitszähler 2 um die Anzahl der angeforderten Ressourcen reduziert und den Ressourcen- Zeiger im Zeiger-Speicherplatz 1 um den entsprechenden Wert reduziert .
Bleibt nach Abschluss dieser Operation der Wert des Verfügbarkeitszeigers positiv, ist die Ressourcen-Anforderung damit durch die entsprechende Ressourcen-Zuweisung an das anfordernde Programm abgeschlossen. Eine Freigabe von Ressourcen nach z.B. Abarbeitung des Programms, das die Ressource anfordert und zugewiesen bekommen hat, erfolgt in komplementärer Form, d. h. die Werte beider Zähler 1, 2 werden wieder erhöht.
Wird der Wert des Verfügbarkeitszählers nach Abschluss der Operation negativ, so müssen Elemente der lokalen Ressourcen auf den Stapel der Stapel-Speichereinrichtung 6 gerettet werden. Dieser Rettungsvorgang benötigt einige Takte und erfordert demzufolge eine Unterbrechung des normalen
Programmablaufs. Daher wird eine Unterbrechungsanforderung (Interrupt) ausgelöst, bei der eine spezielle Routine angesprungen wird, in der die notwendigen Rettungsmaßnahmen programmiert sind. Diese Routine wertet den Verfügbarkeitszähler 2 aus und sichert, beginnend mit der
Position des Ressourcen-Zeigers, die negative Anzahl der im Verfügbarkeitszähler 2 angegebenen Speicherzellen auf dem Stapel bzw. Stack. Als letzte Information wird die Anzahl der geretteten Ressourcen auf den Stack gerettet .
Die Unterbrechungsroutine kann auf Basis von soft- oder Hardware betrieben werden. Bei der dargestellten Anordnung wird sie durch die Unterbrechungslogik 5 repräsentiert, die mit dem Rechenwerk 3 und dem Speicher 1 für den Zeiger in Verbindung steht.
Der Wert des Verfügbarkeitszählers 2 wird anschließend auf Null gesetzt.
Bei der Freigabe von Ressourcen wird jetzt zunächst das oberste Element des Stacks ausgewertet. Falls dort ein Wert ungleich Null steht, ist wieder eine Unterbrechungsroutine aufzurufen, die nun komplementäre Operationen durchführt, d.h. die Restauration der lokalen Ressourcen und die Korrektur der Verfügbarkeits- und Ressourcen-Zeigerwerte . Bei der praktischen Ausführung der Ressourcen-Verwaltung kann es vorkommen, dass bei tief verschachtelten Programmen alle lokalen Ressourcen belegt sind und bei jeder Anforderung Stackoperationen erforderlich sind.
Dies kann jedoch durch Einfügung einer manuellen Ressourcen- Freigabe an „strategisch sinnvollen" Stellen, wie zum Beispiel am Beginn großer Programmblöcke, problemlos verhindert werden. Am Ende eines solchen Blockes wird der vorherige Zustand wieder hergestellt.
Fig. 2 stellt ein praktisches Beispiel eines Ressourcen- Verwaltungs-Zyklus dar. In der ersten Spalte ist jeweils die Anweisung (instruction) angegeben, welche vom Instruktionsdecoder 4 ausgegeben wird.
Die zweite Spalte zeigt von oben nach unten die zeitliche Abfolge der Belegung der beispielhaft angeforderten Ressource (accumulators usage) . Beim dargestellten Beispiel weist die Ressource 8 Speicherplätze auf, wobei oberhalb dieser
Speicherplätze jeweils der Wert des Zeiger-Speicherplatzes 1 für den Zugriffspunkt auf freie Speicherplätze dargestellt ist. Nicht gefüllte Kästchen bedeuten freie Speicherplätze, gefüllte Kästchen bedeuten belegte Speicherplätze.
Die dritte Spalte gibt den jeweiligen Wert des Verfügbarkeitszählers bzw. des Belegungszeigers (AllocPointer) an, zeigt somit einen Versatz. Die vierte Spalte gibt den Wert des FreePointers an, d. h. den Wert der Verfügbarkeitsinformation im Verfügbarkeitszähler 2 für diese Ressource. Die letzte Spalte zeigt den Belegungszustand im Stapel (Stack) der Stapel-Speichereinrichtung 6 an.
In einem ersten Verfahrensschritt wird davon ausgegangen, dass die Ressource unbelegt bzw. frei ist. Entsprechend ist der Wert des Belegungsspeichers bzw. Zeigers 0, so dass die erste Ressource 0 bei einer Anforderung vergeben werden würde. Die Verfügbarkeitsinformation ist entsprechend gleich dem Wert der verfügbaren Speicherplätze, also 8, und der Stapel in der Stapel-Speichereinrichtung 6 ist leer.
Nach einer Belegungsanforderung für fünf Ressourcen- Speicherplätze (Allocres (5) ) werden die fünf höherwertigsten Bit dem anfordernden Programm oder der anfordernden Einrichtung zugewiesen, woraufhin der Wert des Belegungszeigers auf drei und der Wert der Verfügbarkeitsinformation ebenfalls auf drei gesetzt wird.
Der Speicherplatz in der Stapel-Speichereinrichtung 6 bleibt weiterhin unbelegt.
Nach einer weiteren Ressourcen-Anforderung für sechs Ressourcen-Speicherplätze (Allocres (6)) beträgt der Wert des Belegungszeigers, d. h. des Zeiger-Speicherplatzes 3-6 = 5 und der Wert der Verfügbarkeitsinformation nach Abzug des angeforderten Wertes 6 von den verfügbaren Ressourcen-Plätzen 3 nunmehr -3. Es werden somit drei Ressourcen-Speicherplätze mehr angefordert, als in der Ressource verfügbar sind.
Entsprechend werden in für sich bekannter Art und Weise drei Ressourcen-Speicherplätze in der Stapel-Speichereinrichtung 6 gesichert . Daraufhin wird der Wert der
Verfügbarkeitsinformation im Verfügbarkeitszähler 2 auf 0 gesetzt und der Belegungszeiger bleibt auf dem Wert 5. Bei dem Sichern der zu vergebenden bzw. zuzuweisenden Ressourcen- Speicherplätze in die Stapel-Speichereinrichtung 6 werden die Ressourcen-Plätze rechts des neuen Belegungszeigerplatzes gesichert .
Nach einer weiteren Anforderung von beispielsweise sieben Ressourcen-Speicherplätzen (Allocres (7)) wird eine erneute Sicherung in der Stapel-Speichereinrichtung 6 vorgenommen, wobei sieben Werte der Ressource gesichert werden.
Bei dem dargestellten beispielhaften Ressourcen-Verwaltungs- Zyklus erfolgt anschließend die Abarbeitung der einzelnen anfordernden Programme bzw. Einrichtungsanforderungen und somit die Freigabe der Ressourcen. Dies erfolgt bezüglich der Rückspeicherung bzw. Restaurierung in umgekehrter Verfahrensweise zu der vorherigen Speicherung.
Zuerst werden somit sieben Ressourcen-Speicherplätze freigegeben, d. h. die sieben ersten Werte der Stapel - Speichereinrichtung 6 in die Ressource zurückgeschrieben. In für sich bekannter Art und Weise erkennt die Schaltungsanordnung bzw. die darauf laufende Software anhand der zusammen mit den Werten gesicherten Information über die Anzahl der Werte, wie viele Werte aus der Stapel- Speichereinrichtung 6 zurückzuspeichern sind. Diese Anzahl wird zugleich für die Bestimmung der neuen Verfügbarkeitsinformation bzw. des neuen FreePointers verwendet .
Nach Abarbeitung des entsprechenden Programms erfolgt eine Rückspeicherung der nächsten sechs Werte aus der Stapel- Speichereinrichtung 6 und eine entsprechende Neuberechnung der Verfügbarkeitsinformation, welche nunmehr den Wert 3 erhält. Letztendlich erfolgt nach Abarbeitung des zugeordneten Programms die Abarbeitung des letzten Ressourcen anfordernden Programms, so dass abschließend sowohl die Stapel-Speichereinrichtung 6 als auch die Speicherplätze der Ressource frei von gespeicherten Werten sind.
Dargestellt ist in den drei letzten Zeilen jeweils die Belegung der Ressource zu Beginn der Rückspeicherung, während für den Belegungszeiger (AllocPointer) und den
Verfügbarkeitszähler (FreePointer) die Berechnungen und Werte zum Abschluss der Rückspeicherung und Abarbeitung angegeben sind.

Claims

Patentansprüche
1. Verfahren zum Verwalten von Ressourcen für eine Rechnereinrichtung, in der für das Ausführen von Programmen eine Vielzahl von Ressourcen verfügbar ist, wobei zumindest ein Teil der Ressourcen durch ein solches ausgeführtes Programm temporär oder dauerhaft belegt wird, mit den Schritten: a) Anfordern zumindest einer der Ressourcen zum Zuweisen für das Programm, c) Sichern der zuzuweisenden Ressource zu deren späteren Restaurierung, d) Zuweisen der angeforderten Ressource zu dem Programm und e) Belegen der zugewiesenen Ressource durch das Programm, g e k e n n z e i c h n e t durch b) das Prüfen des Belegungszustands der zuzuweisenden Ressource und bl) entweder, falls die zuzuweisende Ressource nicht belegt ist, Fortschreiten mit dem Zuweisen und Belegen der zugewiesenen Ressource (d, e) b2) oder, falls die zuzuweisende Ressource belegt ist, Fortschreiten mit dem Sichern (c) und anschließendem Zuweisen (d) und Belegen (e) der zugewiesenen Ressource.
2. Verfahren nach Anspruch 1, bei dem als Ressource lokale Hardware-Ressourcen des Rechners zugewiesen werden.
3. Verfahren nach Anspruch 1 oder 2, bei dem nur die Ressourcen adressiert werden, welche über eine Ressourcen- Verwaltung für bestimmte Aufgaben angefordert werden können.
4. Verfahren nach einem vorstehenden Anspruch, bei dem gleichartige Ressourcen jeweils eigenen Ressourcen-Klassen zugeordnet werden.
5. Verfahren nach Anspruch 4, bei dem jeder der Ressourcen-
Klassen ein Ressourcen-Zeiger zugeordnet wird, dessen Adressierung ringförmig modular über der Ressourcen-Menge erfolgt .
6. Vorrichtung zum Verwalten von Ressourcen für eine Rechnereinrichtung, in welcher für das Ausführen von
Programmen eine Vielzahl von Ressourcen verfügbar ist, wobei zumindest ein Teil der Ressourcen durch ein solches ausgeführtes Programm temporär oder dauerhaft belegt wird, mit - zumindest einem Speicherplatz als Zeiger-Speicherplatz (1) zum Abspeichern eines Zeigerwertes (AllocPointer) , insbesondere zum Abspeichern einer Adresse oder Position der Ressourcen-Menge,
- zumindest einem Verfügbarkeitszähler (2) mit einer Verfügbarkeitsinformation (FreePointer) zum Angeben der Menge der verfügbaren Ressourcen,
- einer Ressourcen-Bestimmungseinrichtung, insbesondere einem Rechenwerk (3) zum Auswerten und Aktualisieren des Zeigerwertes und der Verfügbarkeitsinformation, - einer Ressourcen-Belegungseinrichtung zum Belegen und/oder Freigeben der Ressourcen und
- einer Stapel-Speichereinrichtung (6) zum Aufnehmen des Inhalts von Ressourcen, g e k e n n z e i c h n e t durch eine - Entscheidungseinrichtung (3) zum Entscheiden, ob eine angeforderte Ressource frei oder belegt ist und zum entweder direkten Zuweisen einer freien Ressource oder zum Zuweisen einer zuvor belegten Ressource nach Übergabe der zuvor belegten Ressource an die Stapel-Speichereinrichtung (6) .
7. Vorrichtung nach Anspruch 6 mit einer Unterbrechungslogik (5) zum Unterbrechen der Zuweisung einer Ressource zu einem anfordernden Programm, falls die verfügbaren Ressourcen bei einer Anforderung nicht ausreichend sind.
8. Vorrichtung nach Anspruch 6 oder 7 mit zumindest zwei, insbesondere einer Vielzahl von Speicherplätzen (1, 2, 7) zum Abspeichern jeweils eines verschiedenen Speicherwertes, wobei die Speicherwerte auf Adressen verschiedener Ressourcen verweisen.
9. Vorrichtung nach Anspruch 8 , bei der die verschiedenen Ressourcen verschiedenen Ressourcen-Arten angehören, die zu jeweils einer Ressourcen-Klasse zusammengefasst sind.
EP02798357A 2001-12-21 2002-12-20 Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung Withdrawn EP1461699A2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10163695 2001-12-21
DE10163695 2001-12-21
PCT/EP2002/014657 WO2003054699A2 (de) 2001-12-21 2002-12-20 Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung

Publications (1)

Publication Number Publication Date
EP1461699A2 true EP1461699A2 (de) 2004-09-29

Family

ID=7710678

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02798357A Withdrawn EP1461699A2 (de) 2001-12-21 2002-12-20 Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung

Country Status (4)

Country Link
US (1) US20050149939A1 (de)
EP (1) EP1461699A2 (de)
AU (1) AU2002363892A1 (de)
WO (1) WO2003054699A2 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8973008B2 (en) * 2005-05-10 2015-03-03 Oracle America, Inc. Combining different resource types
GB2473194A (en) * 2009-09-02 2011-03-09 1E Ltd Monitoring the performance of a computer based on the value of a net useful activity metric
DE102010025774A1 (de) 2010-07-01 2012-01-05 Giesecke & Devrient Gmbh Verfahren zur Herstellung eines Inlays für einen tragbaren Datenträger und Inlay
CN106598737A (zh) 2016-12-13 2017-04-26 腾讯科技（深圳）有限公司 一种实现硬件资源分配的方法及装置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4658351A (en) * 1984-10-09 1987-04-14 Wang Laboratories, Inc. Task control means for a multi-tasking data processing system
US4811208A (en) * 1986-05-16 1989-03-07 Intel Corporation Stack frame cache on a microprocessor chip
US4829425A (en) * 1986-10-21 1989-05-09 Intel Corporation Memory-based interagent communication mechanism
US4992938A (en) * 1987-07-01 1991-02-12 International Business Machines Corporation Instruction control mechanism for a computing system with register renaming, map table and queues indicating available registers
US5206951A (en) * 1987-08-21 1993-04-27 Wang Laboratories, Inc. Integration of data between typed objects by mutual, direct invocation between object managers corresponding to object types
US5297283A (en) * 1989-06-29 1994-03-22 Digital Equipment Corporation Object transferring system and method in an object based computer operating system
US5465363A (en) * 1993-12-30 1995-11-07 Orton; Debra L. Wrapper system for enabling a non-multitasking application to access shared resources in a multitasking environment
US5710727A (en) * 1994-05-04 1998-01-20 National Instruments Corporation System and method for creating resources in an instrumentation system
US6125394A (en) * 1997-06-06 2000-09-26 At&T Corporation Computer system having a plurality of resources and utilizing a selection mechanism to select the resources based upon historical loading
US5860018A (en) * 1997-06-25 1999-01-12 Sun Microsystems, Inc. Method for tracking pipeline resources in a superscalar processor
US6219783B1 (en) * 1998-04-21 2001-04-17 Idea Corporation Method and apparatus for executing a flush RS instruction to synchronize a register stack with instructions executed by a processor
US6427163B1 (en) * 1998-07-10 2002-07-30 International Business Machines Corporation Highly scalable and highly available cluster system management scheme
US6801995B1 (en) * 1998-08-04 2004-10-05 Agere Systems, Inc. Method for optimally encoding a set of instruction codes for a digital processor having a plurality of instruction selectable resource types and an associated optimized set of instruction codes
US6608893B1 (en) * 1998-08-12 2003-08-19 Bellsouth Intellectual Property Corporation Networks, systems and methods for routing data traffic within a telephone network based on available resources
US6665701B1 (en) * 1999-08-03 2003-12-16 Worldcom, Inc. Method and system for contention controlled data exchange in a distributed network-based resource allocation
US6606721B1 (en) * 1999-11-12 2003-08-12 Obsidian Software Method and apparatus that tracks processor resources in a dynamic pseudo-random test program generator
US6523173B1 (en) * 2000-01-11 2003-02-18 International Business Machines Corporation Method and apparatus for allocating registers during code compilation using different spill strategies to evaluate spill cost
US7096469B1 (en) * 2000-10-02 2006-08-22 International Business Machines Corporation Method and apparatus for enforcing capacity limitations in a logically partitioned system
US6901446B2 (en) * 2001-02-28 2005-05-31 Microsoft Corp. System and method for describing and automatically managing resources

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GUEI-YUAN LUEH: "Issues in Register Allocation by Graph Coloring", 1996, pages 1 - 30, Retrieved from the Internet <URL:http://citeseer.ist.psu.edu/cache/papers/cs/3282/http:zSzzSzwww.cs.cmu.eduzSzafszSzcszSzprojectzSziwarpzSzarchivezSzfx-paperszSzcmu-cs-96-171.pdf/lueh96issues.pdf> [retrieved on 20071128] *
See also references of WO03054699A3 *

Also Published As

Publication number Publication date
AU2002363892A8 (en) 2003-07-09
WO2003054699A3 (de) 2004-02-26
US20050149939A1 (en) 2005-07-07
WO2003054699A2 (de) 2003-07-03
AU2002363892A1 (en) 2003-07-09

Similar Documents

Publication Publication Date Title
DE102007025397B4 (de) System mit mehreren Prozessoren und Verfahren zu seinem Betrieb
DE3889578T2 (de) Vorrichtung zur Sicherung und Rückspeicherung einer Registerinformation.
DE2251876C3 (de) Elektronische Datenverarbeitungsanlage
DE4220698C2 (de) Verfahren zum Betreiben einer Datenverarbeitungsanlage
DE2847216A1 (de) Datenverarbeitungssystem mit mehrprogrammbetrieb
DE112014000340B4 (de) Vorablesezugriff auf Daten für einen Chip mit einem übergeordneten Kern und einem Scout-Kern
EP0635792A2 (de) Verfahren zur Koordination von parallelen Zugriffen mehrerer Prozessoren auf Resourcenkonfigurationen
DE3886756T2 (de) Betriebsmittelzugriff für Multiprozessorrechnersystem.
DE2101949A1 (de) Verfahren zum Schutz von Datengruppen in einer Multiprocessing-Datenverarbeitungsanlage
DE69816714T2 (de) Instrumentationsanordnung für eine Maschine mit nichtuniformen Speicherzugriffen
EP0764906A2 (de) Verfahren zum Betreiben eines durch ein Realzeit-Betriebssystem gesteuerten Realzeit-Computersystems
DE102009004726A1 (de) Systeme und Verfahren zum Verfolgen von Befehlszeigern und Datenzugriffen
DE102020133748B4 (de) Fahrzeugsteuergerät mit synchronem treiber
DE3650160T2 (de) Sonderzweckprozessor zur Übernahme vieler Betriebssystemfunktionen in einem grossen Datenverarbeitungssystem.
DE102018202446A1 (de) Verfahren zum Modularisieren einer Softwarearchitektur
WO2003054699A2 (de) Verfahren und vorrichtung zum verwalten von ressourcen für eine rechnereinrichtung
DE102004059972B4 (de) Thread-Scheduling-Verfahren, und Thread-List-Scheduler-Vorrichtung
EP0265636A1 (de) Multiprozessor mit mehreren mit Cache-Speichern ausgerüsteten Prozessoren und einem gemeinsamen Speicher
DE102007015507B4 (de) Prozessor mit einem ersten und einem zweiten Betriebsmodus und Verfahren zu seinem Betrieb
DE69032835T2 (de) Prozedurzustandsdeskriptorsystem für digitale Datenprozessoren
DE10155486B4 (de) Anordnung zur Verarbeitung von Zustandsinformationen externer Einheiten
DE102018123563B4 (de) Verfahren zur Zwischenkernkommunikation in einem Mehrkernprozessor
DE10260103A1 (de) Verfahren und Vorrichtung zur Änderung von Software in einem Steuergerät sowie entsprechendes Steuergerät
DE19827914C1 (de) Anwendungsspezifischer integrierter Schaltkreis mit einem RISC-Prozessor zur Bearbeitung definierter Sequenzen von Assembler Befehlen
DE10245367A1 (de) Prozessor mit expliziter Angabe über zu sichernde Informationen bei Unterprogrammsprüngen

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040327

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LI LU MC NL PT SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK RO

RIN1 Information on inventor provided before grant (corrected)

Inventor name: WITTE, FRANZ-OTTO

Inventor name: HERZ, RALF

Inventor name: NOESKE, CARSTEN

17Q First examination report despatched

Effective date: 20061207

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091028