NL1019876C2 - Systeem en werkwijze voor het laden van een programmacode in een inrichting alsmede een werkwijze voor het voeden van een programmacode aan een inrichting. - Google Patents

Description

Systeem en werkwijze voor het laden van een programmacode in een inrichting alsmede een werkwijze voor het voeden van een programmacode aan een inrichting.

De onderhavige uitvinding heeft betrekking op een systeem voor het laden van ten 5 minste een deel programmacode vanuit een broninrichting in een doelinrichting die elektronische verwerkingsmiddelen en geheugenmiddelen omvat, waarbij de broninrichting is ingericht om op basis van het deel programmacode een althans in hoofdzaak volledige interne representatie voor de doelinrichting te vormen, en waarbij overdrachtsmiddelen zijn voorzien om de in hoofdzaak volledige interne representatie 10 van het deel programmacode naar de doelinrichting over te brengen en in het geheugen daarvan te plaatsen.

Hoewel niet uitsluitend gaat het daarbij voornamelijk om computersystemen en ander rekentuig dat is voorzien van centrale verwerkingsmiddelen in de vorm van één of meer 15 microprocessors in combinatie met het noodzakelijke werkgeheugen. Het werkgeheugen omvat daarbij gewoonlijk een combinatie van willekeurig toegankelijk vluchtig geheugen, zogenaamd random access memory (RAM), dat bijzonder snel toegankelijk is voor zowel schrijf- als leesbewerkingen doch bij het wegvallen van een voedingsspanning alle daarin opgeslagen informatie verliest, tezamen met niet-vluchtig 20 leesgeheugen, dat in het algemeen minder kostbaar doch ook trager toegankelijk en niet willekeurig schrijfbaar is, maar waarin opgeslagen data behouden blijven bij het wegvallen van een voedingsspanning.

Om de verwerkingsmiddelen van een dergelijke inrichting met een programmacode te 25 voeden wordt gewoonlijk allereerst een broncode handmatig samengesteld volgens de syntax van een gekozen programmeerplatform. Deze broncode kenmerkt zich door een hoge mate van menselijke leesbaarheid. Op basis van deze broncode wordt met een zogenaamde compiler of interpreter een programmacode gegenereerd. Bij een compiler gaat het daarbij om een eenmalige vertaalslag, waarna het programma steeds op basis 30 van dezelfde programmacode zal worden uitgevoerd, terwijl bij een interpreter de broncode bij iedere uitvoering van het programma telkenmale opnieuw wordt omgezet naar een voor de verwerkingsmiddelen geschikte programmacode. Ook bestaan er 1019876 -2- tussenvormen waarbij een eerste vertaalslag eenmalig wordt uitgevoerd en de uiteindelijke omzetting naar daadwerkelijke programmacode vanuit een tussencode plaatsvindt, soms aangeduid als P-code, bytecode of objectcode.

5 Bij de omzetting van broncode naar programmacode kan gewoonlijk een aantal stappen worden onderscheiden. In eerste instantie vindt een lexicale analyse van de broncode plaats die voornamelijk tot doel heeft om een syntactische structuur in de broncode aan te brengen. In een opvolgende stap wordt gecontroleerd of in die structuur de voorgeschreven syntax correct, dat wil zeggen volgens de regels van de betreffende 10 programmeertaal, is toegepast. Vervolgens wordt een semantische analyse uitgevoerd op de syntax-structuur om daaruit een doelcode de genereren. Uiteindelijk kan de doelcode nog worden geoptimaliseerd in de zin dat deze sneller zal worden uitgevoerd dan wel minder geheugen zal gebruiken, of beide. AI naar gelang de specifieke ontwikkelomgeving is de doelcode reeds de programmacode of dient deze nog een 15 relatief eenvoudige vertaalslag te ondergaan om de uiteindelijke programmacode op te leveren.

De programmacode wordt in het werkgeheugen van de inrichting geladen en van daaruit uitgevoerd. Bij dit laden vindt soms nog een belangrijke laatste stap plaatst, namelijk 20 het zogenaamde linken. Daarbij worden verwijzingen in de programmacode naar verdere programmadelen, zoals bijvoorbeeld variabelen, procedures en methoden, gekoppeld aan hardwarematige geheugenadressen alwaar de betreffende variabele of methode kan worden teruggevonden. Het kan hierbij gaan om interne verwijzingen naar variabelen en methoden die binnen de broncode zelf zijn gedefinieerd, maar ook om 25 externe verwijzingen naar variabelen en methoden die in een al of niet meegeleverde dan wel zelfstandig ontwikkelde softwarebibliotheek zijn gedefinieerd. De specifieke geheugenadressen waarnaar in de uiteindelijke programmacode dient te worden verwezen, zijn inrichting-afhankelijk en worden gewoonlijk in deze linkstap realtime achterhaald en in de programmacode verwerkt.

1019876 30 -3-

Een sterk opkomend programmeerplatform is het in de jaren tachtig door de Amerikaanse onderneming Sim Microsystems Ine. ontwikkelde Java. Java wordt net als andere programmeertalen gecompileerd, zij het niet naar een uiteindelijke programmeercode maar naar een tussenliggende byte-code, aangeduid als class-file.

5 Deze byte-code wordt geëxecuteerd door de zogenaamde Java Virtuele Machine (JVM). Dit is een software processor die de onderliggende hardware volledig afschermt. Bijgevolg kan één en dezelfde Java-bytecode in iedere hardware-omgeving worden uitgevoerd, vooropgesteld dat voor die hardware-omgeving een Java Virtuele Machine beschikbaar is en deze is geladen. Deze eigenschap maakt Java bij uitstek geschikt voor 10 applicaties die op uiteenlopende platformen dienen te werken, aangeduid als cross-platform applicaties, zoals bijvoorbeeld de bladerprogramma’s (browsers) voor het Internet. Dergelijke bladerprogramma’s maken gebruik van een meegeleverde Java Virtuele Machine om daarmee in plaats van met de werkelijke hardware-processor samen te werken.

15

Dankzij deze platform-onafhankelijkheid wordt Java inmiddels op grote schaal toegepast voor Intemet-applicaties, zowel voor de browser zelf als voor diverse plug-ins en add ons, en het is vooral deze eigenschap waaraan Java zijn populariteit te danken heeft. Inmiddels vormt Java ook in toenemende mate een platform voor op een bepaalde 20 gewenste functionaliteit toegesneden inrichtingen van uiteenlopende aard die niets, althans minder met het Internet van doen hebben. Het gaat hierbij met name om allerhande specifieke terminals met een toegesneden hardware- en softwareomgeving om op basis van de geladen programmacode een bepaalde toegesneden functionaliteit te bieden zoals betaalterminals voor elektronisch betalingsverkeer, terminals voor 25 toegangscontrole en identificatie, zogenaamde set-top boxen, die televisie van additionele multimedia- en communicatiefuncties beogen te voorzien, spelcomputers, parkeerterminals en dergelijke meer. Daarnaast zijn ook kleine draagbare computers, aangeduid als PDA naar het Engelstalige Personal Digital Assistant en telefoontoestellen voor mobiele communicatie, zoals bijvoorbeeld GSM, GPRS en het 30 toekomstige UMTS, met een zichzelf voortdurend inhalend mogelijkhedenpakket sterk in opkomst.

101987® -4-

Het gaat hierbij om wat wordt aangeduid als embedded systemen. Typerend voor deze systemen is een toegesneden software- en hardware omgeving met betrekkelijk beperkte geheugenmiddelen, die bovendien voor een betrekkelijk gering deel uit willekeurig toegankelijk en relatief snel vluchtig geheugen (RAM) bestaan en voor het overige deel 5 elektronisch wisbaar en programmeerbaar leesgeheugen (EPROM) omvatten dat weliswaar niet-vluchtig is maar waarin gewoonlijk niet zondermeer snel en bitsgewijs kan worden geschreven. Om daarin zo efficiënt mogelijk met de aanwezige systeembronnen om te gaan, zijn dergelijke inrichtingen gewoonlijk voorzien van een van overbodige franje ontdaan operating system, dat zich bij voorkeur in het niet-10 vluchtige leesgeheugen van de inrichting bevindt samen met de programmacode van de vereiste applicatiesoftware. Daarbij is de inrichting gewoonlijk zodanig geconfigureerd dat het operating systeem en de standaard applicaties direct vanuit dit leesgeheugen uitvoerbaar zijn, zodat de inrichting, na te zijn ingeschakeld, direct klaar is voor gebruik. Het operating system en de applicatiesoftware zijn aldus als het ware ingebed 15 in en verweven met de hardware van de inrichting, wat de naamgeving van dergelijke systemen verklaart.

Een andere belangrijke eigenschap van Java wordt aangeduid als Tate binding’. Dit houdt in dat naar tal van functies, methoden, variabelen en andere programma-entiteiten 20 in de broncode slechts behoeft te worden verwezen om over de daardoor geboden functionaliteit te kunnen beschikken, maar dat het daadwerkelijk laden van die programma-entiteiten en het alloceren van het daarvoor benodigde werkgeheugen wordt uitgesteld totdat bij executie van de code daadwerkelijk een aanroep daarvan plaatsvindt. Mocht het programmaverloop van de code niet leiden tot een dergelijke 25 aanroep, wordt de betreffende entiteit dus in het geheel niet geladen en daarvoor niet onnodig geheugen vrijgehouden. Niet alleen wordt aldus zeer doeltreffend en efficiënt omgesprongen met het beschikbare werkgeheugen, ook kan aldus de initiële laadtijd van de applicatie belangrijk worden verkort.

30 Late-binding heeft echter ook een nadeel, dat zich vooral in embedded systemen laat gevoelen. Een voorwaarde daarvoor is namelijk dat een uitgebreide Java software- 1 0 19876 -5- bibliotheek in ongebonden en vrij toegankelijke vorm in het geheugen van de doelinrichting beschikbaar is om op ieder moment tijdens executie van de programmacode daaruit de functies, methoden en variabelen te kunnen aanroepen, zodra daarnaar in de programmacode wordt verwezen. De gerefereerde classes, methoden, 5 velden en dergelijke worden onderling en met de virtuele machine gebonden tot een geheel dat in het vluchtige RAM geheugen van de doelinrichting wordt geplaatst.

Voor desktop systemen vormt dit doorgaans geen wezenlijke beperking, maar de betrekkelijk beperkte geheugencapaciteit van embedded systemen is gewoonlijk 10 ontoereikend om daarin zowel de programmacode uit te voren als de Java Virtuele

Machine, een volledige Java software bibliotheek en verdere applicatiesoftware te laden. Specifiek voor dergelijke embedded systemen is dan ook onder de naam JavaCodeCompact een ontwikkelgereedschap uitgebracht waarmee het laden en linken van de programmacode zoveel mogelijk vooraf en gescheiden van de uiteindelijke 15 doelinrichting kunnen worden uitgevoerd, nadat de noodzakelijke vertaalslagen door een JAVA-compiler werden uitgevoerd. In dat geval behoeft louter het geheel van met elkaar en met de virtuele machine gebonden classes, methoden, velden en dergelijke als het ware als geheugenkaart in de doelinrichting te worden opgeslagen. Deze volledige interne representatie van de programmacode kan daarbij in een niet-vluchtig deel van 20 het geheugen van de doelinrichting worden geplaatst en is van daaruit rechtstreeks uitvoerbaar. Op deze wijze kan de hoeveelheid geheugen, die in de doelinrichting voor de executie van de programmacode vrij aanwezig dient te zijn, belangrijk worden beperkt.

25 Normaal zorgt de Java virtuele machine (JVM) eerst tijdens de uitvoering voor het lokaliseren, linken en laden van alle te gebruiken class-files en voor het dynamisch alloceren van de voor de verschillende componenten benodigde interne datastructuren. De virtuele machine creëert en beheert daarbij een interne representatie op basis van de aangeboden programmacode. Daarbij worden verwijzings-tabellen aangelegd, waarin 30 alle verwijzingen naar variabelen en aanroepen van programmacode, met name externe classes, binnen een lopende applicatie worden bij gehouden. De JVM ververst deze tabel 1019876 -6- voortdurend al naar gelang meer of minder classes dynamisch dienen te worden gebonden. Een groot deel van de runtime geheugenconsumptie van het schaarse willekeurig schrijfbare geheugen (RAM) door een Java-applicatie is te wijten aan deze dynamische geheugenallocatie.

5

Om deze aanspraak op vrijelijk toegankelijk geheugen te beperken, maakt JavaCodeCompact het mogelijk om, reeds in de ontwikkelomgeving en dus off-line, vooraf alle vereiste classes te laden en te linken met de Java virtuele machine en aldus een volledig werkende interne representatie van de programmacode vooraf op te zetten. 10 De ‘geheugenkaart’ die hieruit resulteert, wordt vervolgens als geheel naar het leesgeheugen van het embedded systeem overgeheveld en is daarna van daaruit direct uitvoerbaar. Aldus wordt RAM geheugen in belangrijke mate gespaard en wordt dit voornamelijk nog slechts aangesproken voor de opslag van voortdurende variërende variabelen. Doordat de bytecode en alle variabelen, methoden en classes, waarnaar in de 15 programmacode direct of indirect wordt verwezen, vooraf worden gelinkt en vooraf in combinatie met de Java virtuele machine tot een dergelijke interne representatie worden gevormd, is het niet langer nodig verwijzingen daarnaar dynamisch te achterhalen en te beheren zodat ook het anders daarvoor benodigde RAM-geheugen althans grotendeels wordt bespaard. Bovendien blijft het embedded systeem in deze opzet vrij van 20 overbodige classes en componenten en bevat het precies datgene dat nodig is om de taken uit te voeren.

In dit laatste voordeel schuilt evenwel ook een nadeel. Doordat niet langer dynamisch wordt gebonden, dienen alle applicaties tezamen met de virtuele machine vooraf als 25 geheugenkaart volledig te worden uitgelegd, om vervolgens als compleet en vast geheel naar het systeem te worden overgebracht. Dit proces dient te worden gevolgd voor ook maar de kleinste wijziging in één van de bij een applicatie betrokken classes, variabelen, methoden en dergelijke. Met name indien de overdracht naar het systeem van afstand dient te worden gerealiseerd, kan dit, uitgaande van de veelal beperkte bandbreedte van 30 bestaande telecommunicatievoorzieningen, betrekkelijk tijdrovend zijn. Indien met verschillende versies van dezelfde applicatie wordt gewerkt en bovendien verdere 1019876 -7- applicaties (van derden) in de terminal zijn geladen, afgestemd op de hardwareomgeving en softwarebehoeften van de terminal, wat in de praktijk regelmatig voorkomt, dient bovendien van tevoren de specifieke softwareconfïguratie van de terminal exact bekend te zijn om te verzekeren dat de juiste geheugenkaart in de 5 terminal wordt geschreven. Met name indien veel onderling verschillende terminals vanuit een centrale werkomgeving dienen te worden vernieuwd, vergt dit een uitgebreide zo niet onmogelijke administratie en discipline. Ook dient voldoende vrije geheugenruimte in de inrichting beschikbaar te zijn voor het laden van de nieuwe geheugenkaart. Met het oog op toekomstige updates dient tevens voldoende 10 geheugenruimte vrij beschikbaar te blijven, waardoor het voordeel van

JavaCodeCompact, gelegen in een geringere geheugenconsumptie, althans voor een deel teniet wordt gedaan, althans in de gevallen die met enige regelmaat een update van de softwareomgeving vergen.

15 Met de onderhavige uitvinding wordt onder meer beoogd in een systeem van de in de aanhef genoemde soort te voorzien waaraan deze bezwaren niet althans in belangrijk mindere mate kleven.

Om het beoogde doel te bereiken heeft een systeem van de in de aanhef genoemde soort 20 volgens de uitvinding als kenmerk dat de broninrichting is ingericht om een nog onvolledige interne representatie van het deel programmacode tezamen met verwijzingsinformatie te genereren, welke verwijzingsinformatie de doelinrichting in staat stelt om verwijzingen in de programmacode vast te stellen en achteraf in te vullen, dat de overdrachtsmiddelen in staat en ingericht zijn om de nog onvolledige interne 25 representatie van de programmacode en de verwijzingsinformatie naar de doelinrichting over te brengen, en dat de doelinrichting in staat is en is ingericht om op basis van de daarin overgebrachte verwijzingsinformatie vanuit de onvolledige interne representatie een volledige interne representatie van de programmacode te vormen. Ook in dit geval wordt een interne representatie van de programmacode naar de inrichting overgebracht 30 zodat in de inrichting zelf geen verdere omzettingen en in het bijzonder geen linkstappen meer behoeven te worden uitgevoerd en de programmacode vanuit

1Q198XS

-8- leesgeheugen uitvoerbaar is. Doch anders dan bij het hiervoor beschreven Java Code Compact zijn de specifieke adressen van de verdere programmadelen waarnaar in de programmacode wordt verwezen en andere onderlinge verbanden van verschillende programmaonderdelen (nog) niet definitief ingevuld. In plaats daarvan wordt 5 verwijzingsinformatie meegeleverd die de laadmiddelen in staat stellen om in samenwerking met de verwerkingsmiddelen de desbetreffende informatie naderhand te bepalen en in de interne representatie van de code te verwerken.

De uitvinding berust daarbij op het inzicht dat slechts deze laatste stap gedetailleerde 10 kennis behoeft omtrent de specifieke hardware en softwareomgeving binnen de inrichting en dat afgezien daarvan de geheugenkaart van de programmacode tezamen met de verwijzingsinformatie volledig van te voren kunnen worden opgezet zonder rekening te behoeven houden met de specifieke hardware- en softwareomgeving van de uiteindelijke inrichting waarin de programmacode wordt ondergebracht. De laatste stap, 15 dat wil zeggen het daadwerkelijk alloceren, coderen en invullen van geheugenadressen en andere verwijzingsinformatie, is echter inrichting-afhankelijk en wordt dan ook in de inrichting zelf uitgevoerd. De verwijzingsinformatie blijft al of niet in oorspronkelijke vorm in de doelinrichting aanwezig en kan daardoor ook naderhand worden aangewend om deze adresinformatie te (her)construeren. Bij een vernieuwing, aanvulling of 20 anderszins verandering van de geladen softwareconfiguratie behoeft daardoor uitsluitend het gewijzigde deel daarvan tezamen met de daarbij behorende verwijzingsinformatie naar de inrichting te worden overgebracht. In de inrichting zorgen de laadmiddelen in samenwerking met de verwerkingsmiddelen vervolgens voor een (her)bepaling van alle adresinformatie op basis van de nieuwe en de daarin 25 gehandhaafde verwijzingsinformatie om deze vervolgens conform in de interne representatie van zowel de nieuwe als de gehandhaafde programmacode te verwerken. De in de inrichting aanwezige softwareconfiguratie kan aldus bijzonder efficiënt worden beheerd.

30 Een bijzondere uitvoeringsvorm van het systeem volgens de uitvinding heeft als kenmerk de broninrichting is ingericht om de string-verwijzingen in het deel 1019876 -9- programmacode in een eerste bestand onder te brengen en de interne representatie van de programmacode tezamen met overige verwijzingsinformatie in een afzonderlijk tweede bestand en dat de overdrachtsmiddelen in staat zijn beide bestanden naar de doelinrichting over te brengen. De uitgangscode voor de broninrichting kan daarbij 5 bestaan in een broncode, opgezet volgens de voorgeschreven syntax van het toegepaste programmeerplatform, doch kan ook een metacode omvatten, aangeduid als p-code, bytecode of objectcode, die al een eerste vertaalslag onderging. Op basis hiervan wordt conform de uitvinding een ruwe, namelijk nog niet volledig ingevulde, interne representatie gevormd die is afgestemd op de uiteindelijke doelinrichting. Uitgaande 10 van een JAVA-platform is deze interne representatie doeltreffend voor iedere doelinrichting die eenzelfde Java Virtuele Machine ondersteunt. De ruwe interne representatie is althans in belangrijke mate vrij van specifieke string-informatie. Deze wordt in een afzonderlijk bestand ondergebracht terwijl daartussen en de interne representatie een relationele koppeling wordt gelegd. De ruwe interne representatie 15 wordt tezamen met verwijzingsinformatie in een tweede bestand geplaatst. In voorkomende gevallen omvat de doelinrichting een interne administratie van string-informatie die aldus bijzonder efficiënt met het eerste bestand kan worden aangevuld, waarna het eerste bestand in principe overbodig is geworden en kan vervallen. Een verdere bijzondere uitvoeringsvorm van het systeem volgens de uitvinding heeft dan 20 ook als kenmerk dat de doelinrichting is ingericht om het aangeboden bestand met string-verwijzingen te verweven met een interne administratie van overige string-verwijzingen.

In een verdere bijzondere uitvoeringsvorm heeft het systeem volgens de uitvinding als 25 kenmerk dat de string-verwijzingen in versleutelde vorm in de doelinrichting liggen opgeslagen, in het bijzonder gecodeerd volgens een HASH-algoritme en meer in het bijzonder dat de string-verwijzingen volgens een door de doelinrichting gehanteerd HASH-algoritme zijn versleuteld en als zodanig in een of meer door de doelinrichting bij gehouden HASH-tabellen of andere datastructuren zijn verwerkt. Door codering, in 30 het bijzonder volgens een HASH-algoritme, kan de voor de stringinformatie benodigde geheugenruimte belangrijk worden beperkt, terwijl bovendien een aanzienlijk snellere *. u 1 ó è 76 -10- toegang kan worden bereikt in vergelijking met ongecodeerde informatie. In een bijzondere uitvoeringsvorm wordt de gecodeerde informatie daarbij in een of meer HASH-tabellen of andere datastructuren ondergebracht volgens een algoritme dat (ook) door de doelinrichting zelf wordt toegepast. Hierdoor wordt daarbij naadloos 5 aangesloten en kan het separate bestand met aan de nieuwe programmacode verbonden stringinformatie naderhand vervallen.

De doelinrichting is in staat om op basis van de aangeboden ruwe interne representatie en de bijbehorende en meegeleverde verwijzingsinformatie een volledige geheugenkaart 10 samen te stellen zoals die rechtstreeks door de verwerkingmiddelen in de doelinrichting kan worden uitgevoerd. In een bijzondere uitvoeringsvorm heeft het systeem volgens de uitvinding in dit verband dan ook als kenmerk dat de geheugenmiddelen van de doelinrichting een willekeurig toegankelijk, vluchtig geheugen omvatten alsmede een elektronisch schrijfbaar, niet-vluchtig leesgeheugen en dat de programmacode althans 15 grotendeels in het leesgeheugen is geladen. De programmacode is in dit geval vanuit het niet-vluchtige leesgeheugen uitvoerbaar, ook wel aangeduid als EPROM (Erasable Programmable Read Only Memory), zonder noodzaak van het laden van een kopie daarvan in het vluchtige, willekeurig toegankelijk geheugen, ook wel aangeduid als RAM (Random Access Memory). Hierdoor wordt in belangrijke mate bespaard op de 20 voor de programmacode noodzakelijk ruimte in de geheugenmiddelen, in het bijzonder op het relatief kostbare RAM. Bovendien is de programmacode, dankzij het niet-vluchtige karakter van het leesgeheugen, aldus ongevoelig voor eventuele onderbrekingen van een voedingsspanning van de inrichting, die daardoor steeds in een gedefinieerde bedrijfstoestand verkeert.

25

Op zichzelf bestaan er verschillende soorten programeerbaar leesgeheugen. Een vorm die de laatste j aren sterk in opkomst is geraakt is het zogenaamde flash-geheugen, aangeduid als Flash-EPROM. Dit geheugen kan weliswaar bitsgewijs worden geprogrammeerd, maar slechts bloksgewijs worden gewist. Deze wisbeperking heeft 30 belangrijke voordelen als het gaat om de celgrootte en derhalve de compactheid en kostprijs van het geheugen. In de praktijk betekent dit dat bijvoorbeeld een logische “1" 1019876 -11- wel bitsgewijs kan worden geschreven, maar dat een logische “0" steeds behalve op de bestemde geheugenplaats tevens in de omringende geheugenplaatsen van eenzelfde geheugenblok terecht komt, of omgekeerd. Aldus is het leesgeheugen dus niet willekeurig schrijfbaar. Om binnen het systeem volgens de uitvinding voor de 5 uitvoering van de programmacode niettemin van dergelijk compact leesgeheugen uit te kunnen gaan, heeft een bijzondere uitvoeringsvorm van het systeem volgens de uitvinding als kenmerk dat de doelinrichting is voorzien van initialisatiemiddelen die zijn ingericht om op basis van in de doelinrichting aanwezige en als zodanig gehandhaafde verwijzingsinformatie te bestemder plaatse in het leesgeheugen delen in 10 de programmacode te initialiseren opdat aldaar informatie vrij schrijfbaar is. Het initialiseren heeft tot gevolg dat bij voorbeeld op de aangegeven plaatsen alle geheugenadressen een logische “0" bevatten bij geheugen waarin slechts een logische “1" willekeurig schrijfbaar is, dan wel een logische “1" bij willekeurige schrijfbaarheid van een logische “0". Aldus kunnen naderhand alsnog de exacte verwijzingen in de in 15 het leesgeheugen geplaatste programmacode worden aangebracht, zodat de programmacode volledig vanuit leesgeheugen uitvoerbaar blijft.

Een verdere voorkeursuitvoeringsvorm van het systeem volgens de uitvinding heeft als kenmerk dat de doelinrichting is voorzien van defragmentatiemiddelen die zijn ingericht 20 om programmacode in de doelinrichting zoveel mogelijk aansluitend in het leesgeheugen van de doelinrichting te plaatsen. Bij het defragmenteren worden voor de programmacode zoveel mogelijk aaneengesloten geheugenblokken gealloceerd om verbrokkeling zoveel mogelijk te vermijden. Dit bevordert niet alleen de executiesnelheid van de programmacode, maar verminderd bovendien de totale 25 geheugenconsumptie van de programmacode. In de praktijk betekend dit dat geheugenblokken worden verschoven om vervolgens weer zoveel mogelijk aaneengesloten te worden neergelegd.

Een bijzondere voorkeursuitvoeringsvorm van het systeem volgens de uitvinding heeft 30 in dit verband als kenmerk dat de defragmentatiemiddelen de initialisatiemiddelen omvatten. Bij het defragmenteren worden de programmablokken gewoonlijk via een i ü l ö 6 7 6 -12- geheugenbuffer in het vrij toegankelijke deel van het werkgeheugen al of niet naar een nieuwe geheugenlocatie gebracht. Door aldus daarbij en-passant te bestemder plaatse het geheugen te initialiseren zijn daarvoor geen extra bewerkingsstappen vereist en behoeft het leesgeheugen minder vaak te worden aangesproken van de levensduur 5 daarvan ten goede komt.

Dankzij de uitvinding behoeft bij een wijziging in de softwareconfiguratie van de doelinrichting deze niet langer in zijn geheel te worden vervangen, doch slechts het gewijzigde deel daarvan. Dit leidt onder meer tot een belangrijke ontlasting van de 10 overdrachtsmiddelen. In een verdere bijzondere uitvoeringsvorm is het systeem volgens de uitvinding dan ook gekenmerkt doordat de broninrichting en doelinrichting althans tijdelijk, al of niet gelijktijdig, door ten minste één communicatieverbinding aan elkaar zijn gekoppeld en dat de overdrachtsmiddelen gegevensuitwisseling over de communicatieverbinding mogelijk maken. Aldus kan de inrichting in het bijzonder via 15 een al of niet openbaar en al of niet draadgebonden telecommunicatienetwerk van de noodzakelijke programmacode worden voorzien en is beheer op afstand mogelijk. De programmacode kan dan op afstand worden aangepast en door-ontwikkeld in een toegesneden ontwikkelomgeving, waarna het veranderde deel programmacode tezamen met de bijbehorende verwijzingsinformatie via het telecommunicatienetwerk 20 desgewenst over verscheidene inrichtingen en zonder nadere menselijke interventie kan worden gedistribueerd. Doordat dankzij de uitvinding slechts het veranderde deel programmacode aldus behoeft te worden ge-upload, en niet de gehele programmacode, is dit ook bij een telecommunicatienetwerk met een beperkte bandbreedte praktisch uitvoerbaar. De aard van het daarbij toegepaste telecommunicatienetwerk is voor het 25 systeem volgens de uitvinding in beginsel weinig relevant. Zo kan het telecommunicatienetwerk een vaste telecommunicatieverbinding omvatten dan wel deel uitmaken van een publiek geschakeld telefoonnetwerk, maar bijvoorbeeld ook worden gevormd door een lokaal of meer uitgebreid computernetwerk (LAN of WAN), in het bijzonder het Internet.

30 1019876 -13-

De uitvinding zal navolgend nader worden toegelicht aan de hand van een specifiek uitvoeringsvoorbeeld en een bijbehorende tekening. In de tekening toont: figuur 1 een schematische voorstelling van een systeem waarmee op conventionele wijze volgens de stand der techniek programmacode in 5 een doelinrichting wordt geladen; figuur 2 een schematische voorstelling van een systeem waarmee volgens de stand der techniek een interne representatie van een programmacode in een doelinrichting wordt geladen; figuur 3 een schematische voorstelling van een inrichting waarin met behulp van 10 een uitvoeringsvorm van een systeem volgens de uitvinding een interne representatie van een programmacode in een doelinrichting wordt geladen; figuur 4 een meer gedetailleerd schema van een eerste deel van het systeem van figuur 3; en 15 figuur 5 een meer gedetailleerd schema van een tweede deel van het systeem van figuur 3;

Overeenkomstige delen zijn in de figuren zoveel mogelijk met eenzelfde verwijzingscijfer aangeduid.

20 Hoewel in het navolgende voorbeeld van een Java omgeving wordt uitgegaan, zij opgemerkt dat al hetgeen ten aanzien daarvan wordt beschreven mutatis mutandis eveneens geldt voor andere software-omgevingen. Java wordt net als andere programmeertalen gecompileerd, zij het niet naar een uiteindelijke programmeercode maar naar een tussenliggende byte-code, aangeduid als class-file. Deze byte-code wordt 25 geëxecuteerd door de zogenaamde Java Virtuele Machine (JVM). Dit is een software processor die de onderliggende hardware volledig afschermt. Bijgevolg kan één en dezelfde Java-bytecode in iedere hardware-omgeving worden uitgevoerd, vooropgesteld dat voor die hardware-omgeving een Java Virtuele Machine beschikbaar is en deze is geladen. Deze eigenschap maakt Java bij uitstek geschikt voor applicaties die op diverse 30 platformen dienen te werken, aangeduid als cross-platform applicaties, en is een belangrijke reden voor de snel groeiende populariteit van dit programmeerplatform.

1019876 -14-

Inmiddels wordt Java behalve voor een PC-omgeving in toenemende mate ingezet voor de ontwikkeling van applicaties ten behoeve van meer toegesneden inrichtingen van uiteenlopende aard, zoals bijvoorbeeld betaalterminals voor elektronisch betalingsverkeer, settop boxen, parkeerterminals, telefooncentrales, persoonlijke 5 handcomputers (PDA’s), spelcomputers en degelijke meer. Het gaat hierbij om wat wordt aangeduid als embedded systemen. Typerend voor deze systemen is een veelal toegesneden hardwareomgeving, voorzien van een veelal beperkte geheugenruimte die bovendien deels vluchtig geheugen (RAM) en deels niet-vluchtig geheugen (EPROM) omvat, tezamen met een specifieke software omgeving bestaande uit een min of meer 10 toegesneden operating system in combinatie met specifieke applicatiesoftware. De standaard applicatiesoftware en het operating system zijn daarbij gewoonlijk in het niet-vluchtige deel van het geheugen geladen, om bij een onverhoedse onderbreking in de voedingsspanning van de inrichting niet verloren te gaan.

15 Nieuwe of vernieuwde software wordt gewoonlijk van buitenaf in een dergelijke embedded inrichting geladen. Hierbij wordt gebruik gemaakt van een geschikte communicatie-interface uiteenlopend van een directe verbinding bijvoorbeeld via een seriële RS232 of vergelijkbare interface tot een al of niet tijdelijke telecommunicatieverbindingen via een openbaar telefoonnetwerk, een al of niet lokaal 20 computernetwerk en het Internet. In de figuren 1-3 is dit schematisch weergeven, waarbij 10 het off-line systeem aangeeft van waaraf nieuwe c.q. vernieuwde programmacode naar een daartoe bestemde inrichting 20 wordt overgebracht via een geschikte interface 30. Deze inrichting heeft de hiervoor beschreven architectuur van een embedded systeem met deels niet vluchtige geheugen 21 en deels vluchtige 25 geheugen 22. Het niet-vluchtige geheugen 21 omvat herschrijfbaar leesgeheugen (EPROM), in dit geval van het zogenaamde Flash type. Voor het vluchtige geheugen 22 wordt commercieel verkrijgbaar RAM-geheugen toegepast, waarin twee hoofdklassen zijn te onderscheiden, te weten statisch (SRAM) en dynamisch (DRAM) willekeurig toegankelijk geheugen, die elk in een breed scala van uitvoeringsvormen binnen het 30 kader van de uitvinding toepasbaar zijn.

1 01 9 87 6 -15-

Nadat, gebruikmakend van een geschikte JAVA-compiler, vanuit een broncode de respectieve bytecodes van de bij een nieuwe c.q. vernieuwde applicatie behorende classes 50 zijn gevormd, worden de classes in het niet-vluchtig deel 21 van de geheugenmiddelen geschreven, zie figuur 1. In dat deel van het geheugen staan, behalve 5 het operating system 100, ook de JAVA Virtuele Machine 200 en een bijbehorende Java software bibliotheek 300. Alle programmacode van de uit te voeren applicaties bevindt zich nu in het niet-vluchtige geheugen 21. Bij het starten van de virtuele machine 200 worden de overgebrachte classes 50, inclusief de nieuw toegevoegde, behorende bij de programmacode gelinkt met de daarin aangeroepen classes 40 uit de software 10 bibliotheek 300 en met de virtuele machine. Daarbij worden referenties naar variabelen en methoden ingevuld en vervolgens door de virtuele machine 200 voortdurend beheerd. Dit geheel van onderling en met de Java Virtuele Machine gebonden classes 45,55 wordt in het vluchtige geheugen 22 geladen en is van daaruit uitvoerbaar. Na iedere onderbreking in de voedingsspanning dient dit proces nogmaals geheel te worden 15 doorlopen om de programmacode weer in het vluchtige geheugen 22 te kopiëren en om de administratie van verwijzingen over en weer opnieuw op te zetten. Zodra tijdens de executie van de applicatie een nog niet gebonden class wordt aangeroepen, zoekt de virtuele machine 200 de bijbehorende code in de software-bibliotheek 300 om deze vervolgens alsnog te binden en wederom een kopie daarvan in het vluchtige te plaatsen. 20 Dit proces wordt ‘late binding’ genoemd en maakt Java-applicatie bijzonder flexibel en efficiënt.

Een bezwaar van de hiervoor geschetste procedure is dat daarvoor behalve de virtuele machine 200 tevens een omvangrijke ongebonden software bibliotheek 300 in het 25 geheugen 21,22 van de inrichting beschikbaar dient te zijn, terwijl daarnaast een kopie van de daadwerkelijk gerefereerde classes, methoden, velden en dergelijke met de virtuele machine zijn gelinkt en als zodanig ook in het vluchtige geheugen staan, wat relatief veel geheugenruimte kost. Bovendien is de applicatie niet rechtstreeks vanuit het niet-vluchtige geheugen 21 uitvoerbaar, maar dient een kopie 45,55 van de daarbij 30 betrokken programmacode in het vluchtige geheugen 22 te worden geladen alvorens uitvoerbaar te zijn. Niet alleen vertraagd dit de opstarttijd, wat met name na een

'f “1 4 M Q \? Q V \J D *2 *ü> 'j -J

-16- onderbreking in de voedingsspanning nadelig is, ook wordt van meet af aan het vluchtige geheugen 22 voor een belangrijk deel daardoor in beslag genomen. Om aan deze nadelen tegemoet te komen is een software-gereedschap ontwikkeld en voor het publiek beschikbaar gesteld dat wordt aangeduid als “Java Code Compact”. Hierbij 5 worden de nieuwe of vernieuwde classes 50 reeds off-line, dat wil zeggen buiten de uiteindelijke doelinrichting 20, met de Java virtuele machine 200 gelinkt en worden alle verwijzingen naar variabelen, methodes en classes vooraf volledig gelegd. Het resultaat is als het ware een geheugenkaart 400, zie figuur 2, van de inrichting 20 zoals die anders run time zou zijn gevormd. Deze interne representatie 400 van de programmacode bevat 10 de gehele ‘run time’-omgeving van de inrichting en wordt als zodanig in zijn geheel naar het niet vluchtige geheugen 21 van de inrichting 20 overgebracht. De daarin opgenomen programmacode behoeft niet of nauwelijks verdere stappen om in de inrichting 20 te kunnen worden uitgevoerd en is dan ook rechtstreeks vanuit het niet-vluchtige deel 21 van het geheugen uitvoerbaar.

15

De voordelen van het hier beschreven proces zijn legio. Doordat de programmacode rechtstreeks vanuit het niet-vluchtige geheugen 21 uitvoerbaar is en met name niet meer behoeft te worden gelinkt en in het vluchtige deel 22 van het geheugen behoeft te worden geladen kan de applicatie na een spanningsuitval weer betrekkelijk snel 20 operationeel zijn. Maar belangrijker nog, behoeft geen kopie van de programmacode in het vluchtige deel 22 van het geheugen te worden geladen, zodat de totale geheugenconsumptie van de programmacode belangrijk lager is dan in het aan de hand van figuur 1 beschreven geval. Slechts de daadwerkelijk aangeroepen classes, methoden, velden en dergelijke zijn in de interne representatie 400 opgenomen en louter 25 deze geheugenkaart wordt naar de doelinrichting overgebracht, zodat ook in dit opzicht geheugenruimte wordt uitgespaard.

Het-proces van figuur 2 kent echter ook nadelen. Doordat de bibliotheek classes 300 niet meer in de inrichting beschikbaar zijn, is ‘late binding’ niet langer mogelijk en dienen in 30 plaats daarvan alle verwijzingen reeds van meet af aan te worden ingevuld. Bovendien dient bij iedere verandering in de programmacode, hoe gering ook, de totale 1019876 -17- geheugenkaart 400 weer geheel opnieuw te worden uitgelegd en weer volledig naar de inrichting te worden overgebracht. Het moge duidelijk zijn dat dit veel vergt van de communicatie-interface 30. Met name indien de inrichting via een telecommunicatie-verbinding met een relatief beperkte bandbreedte van afstand van een nieuwe 5 programmacode dient te worden voorzien, maakt dit het proces bijzonder tijdrovend. Maar ook vereist één en ander een exacte en volledige administratie van alle in de inrichting 20 aanwezige applicatie-software, tot en met het versienummer nauwkeurig, om te verzekeren dat naderhand steeds de juiste geheugenkaart 400 in de inrichting wordt geschreven. Indien ook derden applicatiesoftware aan de inrichting toevoegen, is 10 dit laatste praktisch ondoenlijk.

Om ook deze bezwaren te ondervangen wordt conform de onderhavige uitvinding in het off-line systeem 10 de class files 50 bestand voor bestand verwerkt tot een bestand 65 met daarin een nog niet geheel volledige interne representatie voor de Java Virtuele 15 Machine 200 van het betreffende class file 50, hierna aangeduid als ROM Class File (RCF), waaruit slechts de informatie mist waarvoor specifieke kennis van de uiteindelijke inrichting 20 is vereist. Het gaat hierbij met name om verwijzingsinformatie naar verdere programmadelen zoals externe classes, methodes en variabelen die in de programmacode worden aangeroepen en waarvan de specifieke 20 adressen in het geheugen van de inrichting 20 nog niet bekend zijn. Hoewel deze informatie in het off-line systeem 10 niet voorhanden is, wordt wel reeds een volledige administratie aangelegd van de plaats en soort van iedere nog nader in te vullen verwijzing in code van een ROM Class File 65 en als zodanig ondergebracht in een bijbehorend bestand 66, hierna aangeduid als Link Info File (LIF). Bovendien wordt de 25 Constant Pool gesplitst en alle UTF8 data in dit Link Info File 66 opgeslagen. Alle andere Constant Pool data bevindt zich in het ROM Class File 65. Aldus worden in het off-line systeem 10 alle voorbereidingen getroffen die kunnen worden getroffen zonder specifieke kennis van de uiteindelijke inrichting 20 waarin de programmacode dient te worden geplaatst.

ü U ü b o i lo.

30 -18-

De ROM Class Files 65 en bijbehorende Link Info Files 66 worden via de interface 30 naar de inrichting 20 overgebracht. In de inrichting 20 is de Java Virtuele Machine 200 aangevuld met een software gereedschap 210, hier na te noemen de Romiser, die in staat is om de aangeboden ROM Class Files 65 en Link Info Files 66 te verwerken en zowel 5 daarin als in de bestaande software-omgeving in de inrichting de verwijzingen in de verschillende classes over en weer te actualiseren, waarbij de interne representatie 45 van die classes in het niet-vluchtige deel 21 van het geheugen staan en ook de volledige interne representatie 56 van het overgebrachte ROM Class File 65 in het niet-vluchtige deel 21 van het geheugen wordt geplaatst. Hiertoe wordt door de Romiser 210 gebruik 10 gemaakt van de verwijzingsinformatie die, in het systeem volgens de uitvinding, in de doelinrichting beschikbaar is en wordt aangevuld met verwijzingsinformatie die is opgenomen in het Link Info File 66 en het zojuist overgebrachte, nog onvolmaakte ROM Class File 65. Eén en ander zal hierna nog in detail nader worden beschreven. Daarna is het Link Info File 66 overbodig en kan dit uit het geheugen 21 van de 15 inrichting worden verwijderd. De uiteindelijke situatie is in figuur 3 weergegeven en verschilt hoegenaamd niet van die van figuur 2. Ook in dit geval wordt bijzonder efficiënt omgesprongen met de nu eenmaal beperkte geheugencapaciteit van de inrichting 20 en is de programmacode rechtstreeks uit het niet-vluchtige deel van het geheugen uitvoerbaar. Doch anders dan bij het aan de hand van figuur 2 beschreven 20 geval behoeft bij een wijziging of aanvulling van de programmacode slechts de ROM Class Files 65 van de gewijzigde of nieuwe classes vergezeld van bijbehorende Link Info Files 66 naar de inrichting de worden overgebracht, zodat de interface 30 in belangrijke mate wordt ontlast, en vindt in de inrichting de laatste verwerkingsstap plaats waarbij voor het eerst inrichting-specifieke informatie is vereist. De uiteindelijke 25 interne representatie van de nieuwe of gewijzigde code wordt aldus in de inrichting 20 zelf aangepast aan de specifieke software- en hardware-omgeving daarin, zodat daarmee in het off-line systeem 10 geen rekening behoeft te worden gehouden en dus ook geen administratie daarvan is vereist. Dit maakt het proces volgens de uitvinding aanmerkelijk efficiënter en robuuster dan het proces dat aan de hand van figuur 2 werd 30 beschreven.

1019876 -19-

In het onderhavige voorbeeld van het systeem volgens de uitvinding wordt de programmacode in essentie in twee fasen in de inrichting geladen. De eerste fase daarvan speelt zich buiten de inrichting, off-line, af en is in figuur 4 in meer detail schematisch weergegeven. In de eerste plaats wordt de programmacode omgezet naar 5 een interne representatie voor de specifieke processoromgeving in de uiteindelijke inrichting. In dit voorbeeld, waarbij wordt uitgegaan van een implementatie in een inrichting op basis van een Java Virtuele Machine die de onderliggende hardware afschermt, is dit de interne representatie zoals die anders door de Java Virtuele Machine zou zijn opgezet, zij het dat daarin verwijzingen en andere inrichting-specifieke 10 informatie nog niet definitief is ingevuld. Hierbij is zoveel mogelijk aansluiting gezocht bij het bestaande en gecertificeerde Java Code Compact gereedschap 51, uit oogpunt van efficiëntie maar voornamelijk ook uit oogpunt van compatibiliteit.

De invoer daarvoor is een in een doorsnee Java-ontwikkelomgeving geschreven Class-15 file 50. Dit Class-file dient bijvoorbeeld ter vervanging van een oude versie daarvan of als aanvulling in een bestaande software-omgeving van een externe inrichting. Het nieuwe class-file 50 wordt toegevoerd aan een Class File Parser 52 van een min of meer standaard Java Code Compact gereedschap 51 om daarvan een objectstructuur 53 te vormen die de interne representatie van het class-file voor een Java Virtuele Machine 20 omvat. In deze objectstructuur 53 zijn alle interne structuren van het class-file 50 aanwezig. Deze Java Code Compact code 53 dient als invoer voor een codeprocessor 61 die het hart van de eerste fase van het systeem volgens de uitvinding vormt. De codeprocessor 61 vult de door Java Code Compact geleverde objectcode 53 aan met verwijzingsinformatie die naderhand de doelinrichting in staat zal stellen om zowel 25 interne als externe verwijzingen in de bytecode op ieder gewenst moment te herberekenen en in te vullen. Deze verwijzingsinformatie wordt deels 62 tezamen met de in hoofdzaak oorspronkelijke byte code 53 ondergebracht in een zogenaamd ROM Class File 65 en deels 63 apart opgeslagen in een separaat bestand 66, hierna te noemen het Link Info File. Daarbij wordt gebruik gemaakt van geschikte bestandschrijvers 64 30 om de door de codeprocessor gegenereerde uitvoer naar een bestand te schrijven dat 1019376 -20- naderhand in de inrichting voor het daar opererende bestandsbeheersysteem toegankelijk is.

Het aldus verkregen ROM Class-file 65 is nog onopgelost. Weliswaar zijn alle 5 structuren van een interne representatie voor de Java Virtuele Machine van het class file daarin aanwezig, zoals een ClassClass, een methodeblok, veldblokstructuren met inbegrip van Java bytecode en een constant pool, maar alle string data (UTF8) is weggelaten en programma-pointers zijn nog niet ingevuld. Deze laatste informatie is inrichting-afhankelijk en kan daarom in dit stadium nog niet worden toegevoegd. In 10 plaats daarvan wordt verwijzingsinformatie aangemaakt op basis waarvan deze verwijzingen en string data later te allen tijde kunnen worden gereconstrueerd. Deze verwijzingsinformatie wordt over het ROM Class File 65 en het Link Info File 66 verdeeld. Het Link Info File omvat alle string informatie tezamen met een patch table of anderszins collectie waarin specifieke adressen in het ROM Class-file zijn bij gehouden 15 waar de HASH-code voor bepaalde strings nog dient te worden ingevoegd. Daarnaast genereert de codeprocessor 61 een relocatietabel of anderszins een collectie opgenomen waarin per pointer de soort, grootte (aantal bytes) en plaats waar deze zich in het ROM Class File bevindt is bij gehouden om in een later stadium daadwerkelijk te kunnen worden ingevuld. Deze relocatie-informatie wordt later in de doelinrichting aangewend 20 om het nieuwe ROM Class File 65 met de reeds in een doelinrichting aanwezige ROM Class Files te kunnen linken.

In de relocatietabel kan een vijftal relocatie-typen worden onderscheiden. In de eerste plaats zijn er interne relocaties die een herberekening van interne absolute pointers 25 mogelijk maken. Een interne relocatie omvat een offset paar van een offset in het ROM Class File waar de betreffende pointer dient te staan in combinatie met een offset waar in het ROM Class File het adres dient te staan waarnaar de pointer dient te verwijzen. Daarnaast zijn er veld, methode en interface methode relocaties die een herberekening van veldblok en methodeblok pointers mogelijk maken op basis van symbolische 30 informatie. Deze symbolische informatie wordt opgeslagen in de vorm van een HASH-tabel index die naderhand in de doelinrichting nader wordt bepaald. In de derde plaats 1019876 -21- zijn er class relocaties die het mogelijk maken om een ClassClass pointer uit symbolische informatie opnieuw te kunnen berekenen. Ook zijn er string relocaties aanwezig in de relocatietabel die door de codeprocessor 61 wordt aangemaakt. Deze string relocatie omvatten ook HASH-tabel indices die het mogelijk maken om achteraf 5 de daarmee geassocieerde string pointers vast te stellen. Tot slot bevat de gegenereerde relocatietabel nog een collectie patch entries die offsets in de code aangeven die bij een hierna nog nadere te behandelen unlink stap dienen te worden gewist om in een daarop volgende link stap te worden geactualiseerd. De relocatietabel wordt althans hoofdzakelijk ondergebracht in het ROM Class File 65 en is daardoor met betrekking tot 10 ieder ROM Class File beschikbaar in een systeem waarin het betreffende ROM Class File wordt of werd geladen.

Ook relevante gegevens uit de Java constant pool worden in de verwijzingsinformatie verwerkt. String-informatie vindt daarbij een plaats in het Link Info File 66 terwijl de 15 overige constant pool entries in het Rom Class File 65 worden ondergebracht. Naar deze laatsten kan in de byte code van het Rom Class File 65 direct worden verwezen. Wel worden deze directe verwijzingen in de constant pool hemummerd om de code in dit opzicht te optimaliseren. Deze hemummering wordt in de byte code van het ROM Class File 65 doorgevoerd tezamen met andere eventueel nog mogelijke optimalisaties van de 20 code.

Met het oog op een implementatie in een (Flash) EPROM-omgeving worden de nog niet ingevulde plaatsen in het ROM Class File op een zodanige bitwaarde gebracht dat daarin, eenmaal geladen in een EPROM, alsnog de gewenste informatie bits-gewijs kan 25 worden geschreven. Concreet betekent dit bijvoorbeeld dat te bestemder plaatse in het ROM Class File 65, afhankelijk van de EPROM-architectuur, louter logische enen of nullen staan die later desgewenst bitsgewijs op hun tegenwaarde kunnen worden gebracht. Het ROM Class File 65 en Link Info File 66 vormen de uitvoer van de off-line fase van het systeem volgens de uitvinding en omvatten tezamen alle informatie die 30 nodig is om in de inrichting zelf de tweede fase van het systeem mogelijk te maken.

1019 8 ï 'o -22-

In dit voorbeeld wordt uitgegaan van een implementatie van de programmacode in een inrichting die geheel door een chipcard wordt gevormd. De chipkaart is hier uitgevoerd als standaard SIM module volgens de betreffende ITA normering en ondergebracht in een daarop afgestemd kaartslot van een verdere inrichting. Deze verdere inrichting is 5 bijvoorbeeld een betaal terminal. De SIM-module omvat een microprocessor tezamen met geheugenmiddelen die voor de processor toegankelijk zijn. De geheugenmiddelen omvatten daarbij deels willekeurig toegankelijk, vluchtig (RAM) geheugen en deels programmeerbaar (EPROM) leesgeheugen dat niet-vluchtig is en daardoor zijn geheugeninhoud bij een onverhoopte onderbreking in de voedingsspanning vast houdt. 10 De voedingsspanning wordt geleverd door de standaard interface die in het kaartslot is opgenomen en die tevens middelen omvat voor gegevens- en commando-uitwisseling met de verdere inrichting. Door de SIM-module in een master-slave verhouding met de verdere inrichting te bedrijven kan deze laatste aldus volledig worden aangestuurd. De SIM-module vormt daarbij een autonoom opererende eenheid die op basis van een 15 daarin geladen Java Virtuele Machine en daarop afgestemde applicatie-software functioneert. De verdere inrichting, hier een betaalterminal, kan eventueel een aantal van dergelijk kaartsloten omvatten om een overeenkomstig aantal van dergelijke SIM-modules te kunnen herbergen. Aldus kan de functionaliteit daarvan naar believen worden uitgebreid en opgewaardeerd.

20

Om aan de applicatiesoftware van de SIM-module iets te kunnen toevoegen of te veranderen worden de in de eerste fase van het systeem off-line gecreëerde ROM Class File 65 en Link Info File 66 via een geschikte communicatieverbinding naar de SIM module overgebracht. De communicatieverbinding kan een rechtstreekse 25 draadverbinding zijn, bijvoorbeeld via een RS232 seriële interface of een universele seriële bus verbinding, maar ook een al of niet permanente telecommunicatieverbinding omvatten via een openbaar geschakeld telefoonnetwerk, een toegesneden datanetwerk, of via een al of niet lokaal computernetwerk, in het bijzonder het Internet. In dit geval wordt uit oogpunt van beveiliging uitgegaan van een toegesneden datanetwerk dat de 30 betaalterminal bij regulier bedrijf aan een bankserver of dergelijke koppelt. Via dit netwerk en een daarop afgestemde communicatie-interface 67 worden het Rom Class 1019876 -23-

File 65 en het Link Info File 66 naar de SIM module overgebracht en daarbij gedownload in het Flash EPROM geheugen van de inrichting. Beide bestanden dienen vervolgens als invoer voor de tweede fase in het proces volgens de uitvinding. De (software) architectuur 70 van de SIM module die verantwoordelijk voor de verdere 5 verwerking en afhandeling is in figuur 5 schematisch weergegeven. Daarbij is een zevental achtereenvolgende stappen te onderscheiden.

In de eerste plaats, stap 71, worden alle string-informatie in het Link Info File 66 verweven met de reeds in de doelinrichting aanwezige en door de Java Virtuele Machine 10 beheerde interne HASH tabel of tabellen. Alle strings uit het Link Info File 66 worden ingelezen en opgeslagen in één of meer van dergelijke gewoonlijk reeds aanwezige HASH-tabellen. Daarbij wordt voor iedere string een unieke index gegenereerd, de HASH-code. Deze HASH-codes worden ter bestemder plaatse in het ROM Class File 65 ingevoegd. De relevante locaties zijn per string in het Link Info File 66 15 gespecificeerd en deze specificatie wordt eveneens in de interne HASH tabel(len) overgenomen. Typisch bevinden dergelijke HASH-codes zich in de relocatietabel, methodeblokken en veldblokken in het ROM Class File.

Een tweetal HASH-tabellen dat door de Java Virtuele Machine wordt beheerd, wordt in 20 deze stap met name aangesproken, te weten de naam/type HASH tabel en de string HASH tabel. In de naam/type HASH-tabel slaat de Java Virtuele Machine methodenamen en veldnamen op tezamen met bijbehorende handtekening informatie. In dit voorbeeld worden tevens de class en interface namen in deze tabel verwerkt. In de string HASH tabel worden door de Java Virtuele Machine ondermeer alle string-25 constanten opgeslagen die in een Java programmacode voorkomen. Door aldus de informatie uit het Link Info File onder te brengen en te verweven met deze HASH-tabellen wordt naadloos aangesloten bij de Java-omgeving in de inrichting en bovendien een dubbele administratie vermeden, waardoor bij de uitvoering van de programmacode niet alleen geheugenruimte maar ook kostbare processortijd wordt uitgespaard.

i0 1 M87i 30 -24-

Nadat aldus de informatie uit het Link Info File in de interne HASH-tabellen en het ROM Class File is verwerkt, is dit bestand verder overbodig geworden en wordt het dan ook verwijderd om verdere geheugenruimte uit te sparen. De HASH-tabellen zelf worden als bestanden in het niet vluchtige Flash geheugen van de inrichting opgeslagen 5 en zijn van daaruit rechtstreeks aanspreekbaar. Een specifiek daarvoor opgezet bestandsbeheersysteem FSS (Flash File System) zorgt voor de toegangs- en bestandsadministratie in dit deel van het geheugen.

Vervolgens wordt, stap 72, de hoeveelheid geheugenruimte berekend die nodig is voor 10 de volgende stappen in de verwerking van het ROM Class File die geheugenruimte vergen. Het gaat hierbij niet alleen om de geheugenconsumptie van het ROM Class File 65 en de HASH-tabel(len), maar ook om de grootte van door de Virtuele Machine gecreëerde methode tabellen en array class files en de tijdelijke overhead geheugenruimte die bij sommige processtappen onvermijdelijk is. Bij voorkeur wordt 15 tevens rekening gehouden met een voorafgaande vorming van een tijdelijke back up van de bestaande software-omgeving van de doel-inrichting. Mocht bij de verwerking een exceptie worden opgeworpen of het laden van de nieuwe programmacode anderszins niet succesvol verlopen, kan dankzij een dergelijke back-up steeds de vorige werkende toestand van de inrichting worden hersteld. Nadat aldus een inschatting is gemaakt van 20 de voor de totale programmacode benodigde geheugenruimte, wordt een partitie van ten minste die grootte gereserveerd om daarin de programmacode onder te brengen. Deze ruimte zal worden aangeduid als de codepartitie in het Flash geheugen. De resterende Flash geheugenruimte vormt een datapartitie waarin voor, tijdens en na executie vrijelijk data kunnen worden opgeslagen.

25

Alleen als de beschikbare geheugenruimte het toelaat, wordt de verwerking voortgezet. Allereerst, stap 73, bereidt het systeem de doelinrichting voor met het oog op de nieuwe of gewijzigde software-omgeving. Alle bestaande methode tabellen en array classes werden voor de oude software-omgeving specifiek opgezet en dienen dus te worden 30 herberekend en opnieuw bepaald nu een nieuw ROM Class File wordt geïmplementeerd. Deze oude files zijn daardoor nutteloos geraakt en worden dan ook 1019876 -25- eveneens verwijderd om ook deze geheugenruimte vrij te maken. De inmiddels opnieuw gegenereerde en met de informatie uit het Link Info File 66 aangevulde HASH-tabellen worden in deze stap naar de code-partitie overgebracht. Voor ieder ROM Class File dat reeds in de code-partitie aanwezig is, wordt bepaald of deze in de nieuwe software-5 omgeving dient te worden gehandhaafd dan wel dient te worden verwijderd. Na eventueel een back-up te hebben gemaakt van de te verwijderen ROM Class Files kunnen deze veilig in de codepartitie worden gewist. Ook het nieuwe ROM Class File 65 wordt in de codepartitie geplaatst. Aldus worden oude en overbodige ROM Class Files uit de codepartitie verwijderd en kan de daardoor ingenomen geheugenruimte 10 worden vrijgegeven.

Indien de codepartitie in de nieuwe software-omgeving kleiner is dan in de oude situatie wordt het surplus aan geheugenruimte aan de datapartitie vrijgegeven voor overig gebruik door de doelinrichting. Indien daarentegen meer geheugen nodig is voor de 15 codepartitie, wordt dit aan de datapartitie onttrokken en voor de codepartitie gealloceerd. Overigens is het mogelijk dat, afhankelijk van het bestandsbeheersysteem, de door verwijderde bestanden ingenomen geheugenruimte na verwijdering niet onmiddellijk weer aangesproken kan worden voor opslag van andere gegeven. In voorkomende gevallen is daarvoor eerst een reclaim-procedure nodig. Indien dat het 20 geval is wordt allereerst een reclaim uitgevoerd op alle verwijderde bestanden alvorens geheugenruimte aan de datapartitie te onttrekken.

Alle voor de nieuwe software-omgeving vereiste ROM Class Files en HASH-tabellen staan nu in de codepartitie maar alle verwijzingen en aanroepen in de programmacode 25 van althans een aantal van deze ROM Class Files refereren nog aan de oude software-omgeving. Zo bevatten bijvoorbeeld de geheugenlocaties waar pointers zijn opgenomen nog de oorspronkelijke pointer-waarde. Omdat de ROM Class Files in een deel van het Flash geheugen staan, kunnen op de betreffende locaties niet zondermeer nieuwe waarden worden geschreven. Om dit mogelijk te maken voorziet het systeem volgens de 30 uitvinding in een initialisatie-procedure waarbij op basis van in de ROM Class File opgenomen relocatie-informatie op alle plaatsen waar verwijzingen voorkomen die fs 4 -.’1 Q Ή) ίΞ5

ii y 5 o G tl Q

-26- dienen te worden geactualiseerd de bytewaarde van de betreffende geheugenplaatsen wordt teruggesteld op een waarde die daarna bitsgewijs kan worden beschreven. Afhankelijk van de specifieke geheugenarchitectuur houdt dit in dat op deze plaatsen bijvoorbeeld louter logische nullen of juist enen worden geschreven, zodat later daarin 5 bitsgewijs eventueel de tegenwaarde kan worden ondergebracht. Dit is een belangrijke stap in het proces conform de uitvinding omdat dit in staat stelt de ROM Class Files in Flash geheugen te plaatsen en niettemin naderhand de juiste verwijzingsinformatie daarin op te nemen, zodat een volledig vanuit Flash geheugen executeerbaar geheel wordt verkregen.

10

Door de uitgevoerde verwijderingen een verplaatsingen van losse bestanden kan de codepartitie in meer of mindere mate verbrokkeld raken, wat nadelig is voor de geheugenconsumptie en de uitvoeringssnelheid. Daarom wordt een defragmentatie uitgevoerd waarbij alle noodzakelijk ROM Class Files, dat wil zeggen zowel de reeds 15 aanwezige, te handhaven ROM Class Files als het nieuwe ROM Class File 65, zoveel mogelijk aaneengesloten in het geheugen worden geplaatst. In dit uitvoeringsvoorbeeld van het systeem volgens de uitvinding wordt tijdens deze verschuiving van de ROM Class Files in de codepartitie tevens de in de voorgaande alinea beschreven initialisatie uitgevoerd. Ieder bestand in de codepartitie wordt onderzocht op de aanwezigheid 20 daarin van een relocatietabel. Indien die wordt gevonden, wordt deze volledig gescand en (offset) geheugenplaatsen vastgesteld waarin lege, initiële waarden dienen te worden geschreven. De actuele data worden ter plaatse aangepast door de RAM-buffer, die tijdens de verschuiving en defragmentatie van het bestand de bytewaarde tijdelijk vasthoudt om deze elders in de codepartitie opnieuw te kunnen schrijven, bij deze 25 geheugenplaatsen tussentijds te wissen. Door aldus de defragmentatie en initialisatie van de codepartitie te combineren behoeft het Flash geheugen minder vaak te worden aangesproken wat de levensduur bevordert.

De waarden van alle pointer-locaties en andere verwijzingsgegevens, zoals bijvoorbeeld 30 class velden en variabelen, in de ROM Class Files zijn aldus gewist en geïnitialiseerd op een waarde die bitsgewijs schrijven toelaat. De waarden die uitgaande van de actuele 1019876 -27- software-omgeving ter plaatse dienen te worden ingevuld worden in de nu volgende stap 74 (herberekend en te bestemder plaatse ingevuld. In eerste instantie worden alle interne pointers, dat wil zeggen verwijzingen naar en in het ROM Class File zelf, vastgesteld en op basis van de relocatie-informatie in het ROM Class File ingevuld.

5

Vervolgens worden, stap 75, op basis van de in de ROM Class Files en HASH tabellen bijeengehouden informatie alle Classes, methode tabellen en array classes opnieuw gebouwd. Voor de classes wordt daarbij uitgegaan van iteraties over alle classes die dienen te worden samengesteld, waarbij een class pas daadwerkelijk wordt gebouwd 10 indien alle in hiërarchisch opzicht daaraan superieure classes werden gebouwd. Deze iteraties worden herhaald totdat alle classes aldus uiteindelijk aan de beurt zijn geweest, dan wel een exceptie wordt opgeworpen bijvoorbeeld omdat een superieure class niet aanwezig blijkt te zijn. Deze werkwijze blijkt het minst belastend voor de aanwezige hoeveelheid geheugenruimte.

15

De methode-tabel van een class omvat een rechtstreekse verwijzing naar aan de class gekoppelde methoden en wordt als zodanig gedurende executie aangewend bij een reguliere methode-aanroep van de class. De Java Virtuele Machine omvat standaard een algoritme om een dergelijke methode-tabel samen te stellen. Dit algoritme wordt ook 20 hier gebruikt om vanuit de classes de bijbehorende methode-tabellen vast te stellen.

Indien in een class Java arrays worden toegepast, zal het ROM Class file zogenaamde constant-pool entries omvatten die naar de betreffende array class verwijzen. Ook deze verwijzingen worden opnieuw vastgesteld. Voor een overzicht van de noodzakelijke 25 array classes per ROM Class File wordt de daarin opgenomen relocatie-informatie geraadpleegd en op basis van de HASH-tabel de bijbehorende naam van de class bepaald. Zo nodig, dat wil zeggen indien de bewuste array-class rechtstreeks vanuit het ROM Class file wordt aangeroepen en de structuur niet reeds eerder, bij voorbeeld ten behoeve van een ander ROM Class file, werd samengesteld, wordt de juiste class-30 structuur voor de bewuste array-class gebouwd in het format van een ROM Class file, zij het dat daarin geen relocatie-informatie is opgenomen, daar deze hier overbodig is.

101037b -28-

Nu alle class-structuren zo nodig opnieuw werden gebouwd en de verwijzingen daarin herberekend worden de classes opnieuw gelinkt tot een samenhangend geheel dat zich volledig in het leesgeheugen van de doelinrichting bevindt en op basis van de daarin actueel ingevulde verwijzingswaarden rechtstreeks uitvoerbaar is. In deze herlinkstap 76 5 wordt de relocatie-informatie in de ROM Class files gelezen en de symbolische informatie gebruikt om pointers opnieuw vast te stellen. De aldus opnieuw berekende pointers worden te bestemder en als zodanig in de verwijzingsinformatie bekende plaatse in het ROM Class file ingevuld.

10 Nadat de voorgaande stappen allen succesvol zijn afgerond kunnen eventueel aangemaakte back-up bestanden en overige hulpbestanden worden verwijderd om de daardoor ingenomen geheugenruimte in de doelinrichting vrij te maken. Dit wordt in de laatste stap 77 van het laadproces uitgevoerd, waarmee het gehele proces wordt voltooid. Aldus is op basis van het nieuwe ROM Class File en het daarbij horende Link 15 Info File weer een volledig vanuit ROM leesgeheugen werkende configuratie verkregen. Dankzij de plaatsing in het ROM-geheugen is deze configuratie bestand tegen onderbrekingen in de voedingsspanning en behoeft geen daarvoor geen, althans minimaal, beroep te worden gedaan op het vaak schaarse willekeurig toegankelijke RAM geheugen van de inrichting.

20

Hoewel de uitvinding hiervoor aan de hand van louter dit ene uitvoeringsvoorbeeld nader werd toegelicht moge het duidelijk zijn dat de uitvinding daartoe geenszins is beperkt. Integendeel zijn voor een gemiddelde vakman binnen het kader van de uitvinding nog vele variaties en verschijningsvormen mogelijk.

25 1019876

Claims (11)

1. Systeem voor het laden van ten minste een deel programmacode vanuit een broninrichting in een doelinrichting die elektronische verwerkingsmiddelen en 5 geheugenmiddelen omvat, waarbij de broninrichting is ingericht om op basis van het deel programmacode een althans in hoofdzaak volledige interne representatie voor de doelinrichting te vormen, en waarbij overdrachtsmiddelen zijn voorzien om de in hoofdzaak volledige interne representatie van het deel programmacode naar de doelinrichting over te brengen en in het geheugen daarvan te plaatsen, met het kenmerk 10 dat de broninrichting is ingericht om een nog onvolledige interne representatie van het deel programmacode tezamen met verwijzingsinformatie te genereren, welke verwijzingsinformatie de doelinrichting in staat stelt om verwijzingen in de programmacode vast te stellen en achteraf in te vullen, dat de overdrachtsmiddelen in staat en ingericht zijn om de nog onvolledige interne representatie van de 15 programmacode en de verwijzingsinformatie naar de doelinrichting over te brengen, en dat de doelinrichting in staat is en is ingericht om op basis van de daarin overgebrachte verwijzingsinformatie vanuit de onvolledige interne representatie een volledige interne representatie van de programmacode te vormen.

2. Systeem volgens conclusie 1 met het kenmerk dat de broninrichting is ingericht 20 om de string-verwijzingen in het deel programmacode in een eerste bestand onder te brengen en de interne representatie van de programmacode tezamen met overige verwijzingsinformatie in een afzonderlijk tweede bestand en dat de overdrachtsmiddelen in staat zijn beide bestanden naar de doelinrichting over te brengen.

3. Systeem volgens conclusie 2 met het kenmerk dat de doelinrichting is ingericht 25 om het aangeboden bestand met string-verwijzingen te verweven met een interne administratie van overige string-verwijzingen.

4. Systeem volgens conclusie 3 met het kenmerk dat de string-verwijzingen in versleutelde vorm in de doelinrichting liggen opgeslagen, in het bijzonder gecodeerd volgens een HASH-algoritme.

5. Systeem volgens conclusie 4 met het kenmerk dat de string-verwijzingen volgens een door de doelinrichting gehanteerd HASH-algoritme zijn versleuteld en als f ü 1 8 ö '7 6 -30- zodanig in een of meer door de doelinrichting bij gehouden HASH-tabellen of andere datastructuren zijn verwerkt.

6. Systeem volgens een of meer der voorafgaande conclusies met het kenmerk dat de geheugenmiddelen van de doelinrichting een willekeurig toegankelijk, vluchtig 5 geheugen omvatten alsmede een elektronisch schrijfbaar, niet-vluchtig leesgeheugen en dat de programmacode althans grotendeels in het leesgeheugen is geladen.

7. Systeem volgens conclusie 6 met het kenmerk dat de doelinrichting is voorzien van initialisatiemiddelen die zijn ingericht om op basis van in de doelinrichting aanwezige en als zodanig gehandhaafde verwijzingsinformatie te bestemder plaatse in 10 het leesgeheugen delen in de programmacode te initialiseren opdat aldaar informatie vrij schrijfbaar is.

8. Systeem volgens conclusies 7 met het kenmerk dat de doelinrichting is voorzien van defragmentatiemiddelen die zijn ingericht om programmacode in de doelinrichting zoveel mogelijk aansluitend in het leesgeheugen van de doelinrichting te plaatsen.

9. Systeem volgens conclusie 8 met het kenmerk dat de defragmentatiemiddelen de initialisatiemiddelen omvatten.

10. Systeem volgens een der voorgaande conclusies 1 met het kenmerk dat de broninrichting en doelinrichting althans tijdelijk, al of niet gelijktijdig, door ten minste één communicatieverbinding aan elkaar zijn gekoppeld en dat de overdrachtsmiddelen 20 gegevensuitwisseling over de communicatieverbinding mogelijk maken.

11. Systeem volgens conclusie 10 met het kenmerk dat de overdrachtsmiddelen in staat zijn tot gegevensuitwisseling via een al of niet draadgebonden telecommunicatienetwerk. 1019876