專利名稱：：用于有條件地縮小可執(zhí)行模塊的系統(tǒng)和方法
技術(shù)領(lǐng)域：
：本發(fā)明的實施方案一般地涉及格式化代碼映像文件，并且更具體地，涉及在將映像儲存到閃存存儲器中之前，通過省略通用頭部中不必要的字段來縮短要被儲存到閃存存儲器中的代碼映像文件的長度(縮小代碼映像文件)。背景信息存在各種用于格式化和壓縮二進制代碼映像以儲存到儲存設(shè)備中的機制。在本文中，二進制代碼映像通常是可執(zhí)行映像，或者是例如在個人計算機(PC)上，或在固件等等中，或在其中計算機程序被用來完成某些任務的任何處理系統(tǒng)上執(zhí)行的任何映像。在處理器上被執(zhí)行的任何映像必須具有標準格式，從而目標處理器固件可以識別該映像可以從閃存存儲器被執(zhí)行，或被加載到存儲器中，或以另一種方式被執(zhí)行。在現(xiàn)有PC系統(tǒng)中使用的用于可執(zhí)行映像的通用標準是標題為“MicrosoftPortableExecutableandCommonObjectFileFormatSpecification(微軟可移植可執(zhí)行和通用對象文件格式規(guī)范)”(修訂版6.0，Microsoft公司，1999年2月)的可移植可執(zhí)行通用對象文件格式(PE/COFF)規(guī)范，并且可以在萬維網(wǎng)http://www.microsoft.com/whdc/hwdev/hardware/PECOFF.mspx上找到。該格式是可移植的，因為格式化的文件想要在不同目標上被執(zhí)行。例如，PE/COFF映像可能在WIN/CE環(huán)境以及WindowsXP環(huán)境兩者中被執(zhí)行。只要目標處理器識別PE/COFF格式，該處理器就可以執(zhí)行該PE/COFF格式化的映像。為了在不同平臺上執(zhí)行，PE/COFF映像必須包含與可能的目標平臺和操作系統(tǒng)相關(guān)的具體信息。因此，在PE/COFF映像中可以存在并不是與每個可能的目標平臺相關(guān)的信息。并非所有字段將被應用到所有平臺。例如，PE/COFF映像可以是設(shè)備驅(qū)動器(driver)。設(shè)備驅(qū)動器可以駐留在閃存存儲器中。期望縮減閃存存儲器中設(shè)備驅(qū)動器的大小以節(jié)省儲存設(shè)備上寶貴的空間。在現(xiàn)有系統(tǒng)中，空間節(jié)省技術(shù)常常限于映像內(nèi)容的壓縮。在一些情況下，包括頭部的整個映像文件被壓縮。設(shè)備驅(qū)動器映像通常被開發(fā)成在多個計算平臺上可用。具有一個可執(zhí)行體(executable)為廠家縮減配置和開發(fā)/維護成本?？赡芡ㄟ^包括指針或虛擬地址，映像的頭部可以指示不同的模塊或例程適用于不同的平臺。一些可執(zhí)行體必須從閃存存儲器中的實際地址被執(zhí)行。例如，這些可執(zhí)行體被稱為XIP(就地執(zhí)行(eXecuteInPlace))，并且不能被重定位。其他可執(zhí)行體可以被重定位到存儲器。該信息可以被包括在PE/COFF映像本身中。在現(xiàn)有系統(tǒng)中，PE/COFF映像被傳遞到多個平臺，并且被加載到目標平臺上的閃存存儲器中。如果映像具有XIP類型，則該映像不能在閃存存儲器上被壓縮，因為該映像必須從閃存存儲器被執(zhí)行。因此，駐留在閃存存儲器上的信息必須是直接可執(zhí)行的指令。其他映像可以在被加載到閃存存儲器之前被壓縮。存在著各種本領(lǐng)域已知的用于在寫閃存存儲器之前壓縮可執(zhí)行映像的方法。附圖簡要說明從本發(fā)明的以下詳細描述中本發(fā)明的特征和優(yōu)點將變得清楚，其中圖1是根據(jù)本發(fā)明的實施方案，表示PE/COFF映像并圖示用于縮小映像頭部的示例性方法的框圖；圖2是根據(jù)本發(fā)明的實施方案，表示被部分地減小或優(yōu)化的PE/COFF節(jié)(section)頭部的框圖；圖3示出指示圖2的節(jié)頭部是呈它們的默認形式還是被優(yōu)化的表；圖4和5圖示使用本發(fā)明的實施方案節(jié)省的空間；圖6是根據(jù)本發(fā)明的實施方案示出用于使用縮小或優(yōu)化的PE/COFF映像的示例性方法；以及圖7是根據(jù)本發(fā)明的實施方案示出用于重構(gòu)修剪的代碼映像文件的示例性系統(tǒng)。詳細說明本發(fā)明的實施方案包括涉及縮小或優(yōu)化可執(zhí)行映像的系統(tǒng)和方法，其結(jié)果是儲存空間的節(jié)省。在至少一個實施方案中，本發(fā)明想要在儲存到用于目標平臺的閃存存儲器中之前從可執(zhí)行映像頭部移除不必要的字段或信息。與目標平臺不相關(guān)的信息的移除允許可執(zhí)行體在閃存存儲器中占據(jù)較少的空間。當映像被加載時，基于優(yōu)化的頭部信息來解釋該映像。在實施方案中，映像可以進一步被已知的方法壓縮以節(jié)省額外的空間。在說明書中提及本發(fā)明的“一個實施方案”或“實施方案”意味著結(jié)合該實施方案描述的特定特征、結(jié)構(gòu)或特性被包括在本發(fā)明的至少一個實施方案中。因此，短語“在一個實施方案中”在整篇說明書中不同地方的出現(xiàn)不一定全是指同一實施方案。存在著各種用于縮減可執(zhí)行映像大小的方法。為了解釋說明和簡單起見，以下的實施方案在PE/COFF映像的背景下描述。本領(lǐng)域普通技術(shù)人員將清楚，這里描述的系統(tǒng)和方法可以用于其他映像格式，例如ELF映像或Mach-O格式化的映像。ELF(可執(zhí)行和鏈接格式(ExecutableandLinkingFormat))可以用于Linux操作系統(tǒng)，并且最初由Unix系統(tǒng)實驗室開發(fā)。關(guān)于ELF的更多信息可以在http://www.gsp.com/cgi-bin/man.cgi？section＝5&topic＝elf的Linux手冊參考頁中找到。Mach-O格式被蘋果計算機操作系統(tǒng)使用。關(guān)于該格式的更多信息可以被找到，如在蘋果計算機有限公司2003年8月7日的“Mach-ORuntimeArchitecture(Mach-O運行時體系結(jié)構(gòu))”(第三章Mach-O文件格式參考)中所描述的(參見http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachORuntime/)。本系統(tǒng)和方法的實施方案有效地修剪可執(zhí)行映像，由此使得映像大小能夠被縮減(或縮小)。本發(fā)明的實施方案不同于壓縮，因為壓縮的項目可以被重組成原始狀態(tài)?？s小的可執(zhí)行體以定制的方式被縮減，并且一些與目標平臺不相關(guān)的數(shù)據(jù)(或字段)可以被丟棄。經(jīng)修剪后，映像可以使用已知的方法被進一步壓縮。本發(fā)明的實施方案可以在將可執(zhí)行映像加載到閃存存儲器之前從所述可執(zhí)行映像移除內(nèi)容。不相關(guān)的數(shù)據(jù)可以被移除，并且所述映像的可應用子集被定義為針對目標平臺的標準。所定義的子集被用來壓縮和加載映像。這可以導致更小的映像，從而節(jié)省儲存設(shè)備上的空間。所公開的系統(tǒng)和方法的實施方案可以附加到現(xiàn)有壓縮技術(shù)。此外，所公開的系統(tǒng)和方法可以應用于已被壓縮的映像?，F(xiàn)在參照附圖，并且具體地參照圖1，圖1示出PE/COFF映像。PE/COFF映像包括COFF頭部110、PE頭部120、節(jié)頭部160和映像內(nèi)容180。在一個實施方案中，COFF頭部110可以包括七個字段(20個字節(jié))machine111、NumberofSections112、TimeDateStamp113、PtrToSymbol114、NumSymbols115、SizePEHdr116和Characteristics117。下面的表1根據(jù)PE/COFF規(guī)范圖示COFF頭部中每個字段的偏移(offset)和長度。在這20個字節(jié)中，目標平臺可能只需要訪問字段machine111、NumberofSections112、SizePEHdr116和Characteristics117，只使用八個字節(jié)。用于PE頭部120的末尾的地址偏移可以由COFF頭部110中指定PE頭部大小的值(即在偏移16處的SizePEHdr116)來確定。節(jié)頭部160的大小可以通過將節(jié)的數(shù)量乘以節(jié)的長度來確定，所述節(jié)的數(shù)量可以是在COFF頭部的偏移2處16位的值(即NumberOfSections112)。在本實施例中，默認節(jié)是40個字節(jié)長。表1COFF頭部字段偏移在本實施例中，PE頭部120包括字段Signature121、MajorVersion122、MinorVersion123、SizeOfCode124、SizeOfInitdData125、SizeOfUnInitdData126、EntryPoint127、BaseOfCode128、BaseOfData129、ImageBase130、SectionAlignment131、FileAlignment132、MajorOSVersion133、MinorOSVersion134、MajorImageVersion135、MinorImageVersion136、MajorSubVersion137、MinorSubVersion138、Win32Version139、ImageSize140、HeaderSize141、CheckSum142、Subsystem143、DllChar144、StackReserveSz145、StackCommitSz146、HeapReserveSz147、HeapCommitSz148、LoaderFlags149和NumberOfRVASz150。在本實施例中，PE頭部120包括108個字節(jié)。對于一些平臺，只需要PE頭部120的22個字節(jié)Signature121、SizeOfCode124、EntryPoint127、BaseOfCode128、ImageBase130和Subsystem143。因此，PE頭部可以被縮減86個字節(jié)，成為22個字節(jié)。在本實施例中，節(jié)頭部160包括以下字段的多個集合(針對每個節(jié)有一個集合)，所述字段為Name161、Virtsize162、VirAddr163、RawDataSz164、PointertoRawData165、PointertoRelocations166、PointertoLineNums167、NumofRelocs168、NumofLineNums169以及Characteristics170(總共40個字節(jié))。對于一些平臺，只有字段Name161、RawDataSz164、PointertoRawData165、PointertoRelocations166和NumofRelocs168，總共21個字節(jié)被使用。所述Name字段可以被預先分配成允許32個節(jié)，即一個開銷字節(jié)和32位數(shù)據(jù)。因此，消除不使用的字段每個節(jié)可以節(jié)省19個字節(jié)。在一個實施方案中，第一節(jié)頭部將總是具有Name字段。在許多情況下，第一節(jié)示出第一字節(jié)為0值(通常無效)，并且剩余四個字節(jié)是關(guān)于哪些節(jié)被優(yōu)化/縮小而哪些節(jié)未被優(yōu)化/縮小的32位掩碼。然而，可能第一節(jié)未優(yōu)化。在這種情況下，第一節(jié)將不具有為0的第一字節(jié)。換句話說，Name字段將與PE/COFF規(guī)范一致，并且是在其中具有某個實際名稱的八字節(jié)字段。在這種情形下，下一優(yōu)化的節(jié)頭部將是剩余節(jié)狀態(tài)的指示符，并且該下一節(jié)頭部將具有Name字段(五個字節(jié))。在前n個節(jié)頭部為未優(yōu)化的情況下，則第n+1個節(jié)頭部將在Name字段中具有位掩碼。一旦掩碼出現(xiàn)在一節(jié)頭部Name字段中，那么在后續(xù)的優(yōu)化節(jié)頭部中就不必要具有Name字段。一些實施方案可以在所有節(jié)頭部中使用Name字段，以保持一致。應該注意到在本討論中，所使用的字節(jié)和所要求的字段僅僅是用于圖示說明。其他系統(tǒng)可以使用針對頭部的不同格式，或要求不同的字段。圖2示出在具有四個節(jié)210、220、230和240的映像中被縮減為排除不需要的字段的PE/COFF節(jié)頭部的示意圖。在本實施例中，節(jié)頭部1、3和4(210、230和240)是優(yōu)化或縮小的。節(jié)頭部2使用如格式標準所定義的默認字段。如在圖2中看到的，節(jié)1(210)包括Name字段161，而節(jié)3和4(230，240)不包括Name字段。如圖1中所示，優(yōu)化的節(jié)頭部中的每個還包括四個字段164、165、166和168。如以下將更充分地描述的，Name字段161具有特殊的重要性。在一個實施方案中，在第一節(jié)頭部210中使用Name字段161來標識哪些節(jié)頭部是優(yōu)化的，以及哪些節(jié)頭部使用完整的默認格式。圖3示出定義接下來的節(jié)是優(yōu)化或修剪的，還是正使用默認格式的表300。例如，在一個實施例中，映像具有n個節(jié)，即1到n。第一節(jié)301是優(yōu)化的。第二節(jié)303使用默認格式。第三和第四節(jié)(305、307)是優(yōu)化的，諸如此類，直到第n節(jié)309是優(yōu)化的。在一些實施方案中，該表可以以掩碼字來實現(xiàn)，其中1-位(1b，1-bit)指示節(jié)是優(yōu)化的，并且0-位(0b，0-bit)指示節(jié)使用默認格式。該掩碼或頭部可以被預先設(shè)計(pre-pended)到映像文件中，或定位在映像中的另一個預先確定的偏移(已知)上，例如重載(overload)映像中未使用的字段，即Name字段161。在本實施例中，如圖3中所示，節(jié)1-4由1011b表示，其中最低有效位被用于第一節(jié)301。術(shù)語“優(yōu)化”具有與映像要被加載到的平臺相關(guān)的具體含義?？梢源嬖谔幚碛诚癫㈦S后將它們加載到存儲器中的代理(agent)或重構(gòu)器(reconstructor)。代理基于該位掩碼來解釋節(jié)。因此，如果節(jié)是優(yōu)化的，代理將了解在節(jié)中使用了多少字節(jié)和哪些字段。在實施方案中，節(jié)1(301)的Name字段161被用來將圖3的表儲存為位圖。這允許代理標識默認的節(jié)和優(yōu)化的節(jié)，而無需給映像文件增加額外的開銷。例如，以字節(jié)0開始的Name字段161可以被解釋為已被用來儲存優(yōu)化表的Name字段。如果第一字節(jié)非0，那么代理以默認/傳統(tǒng)格式讀入映像。在現(xiàn)有系統(tǒng)中，在PE/COFF映像中常常不超過16節(jié)。因此，在使用Name字段161來保存優(yōu)化表的實施方案中，只需要兩個字節(jié)來傳達掩碼信息。在PE/COFF規(guī)范中，Name字段被定義為8個字節(jié)。在實施方案中，為所述表而保留4個字節(jié)以允許多達32個節(jié)。因此，只使用五個字節(jié)來用于Name字段。在一個實現(xiàn)中，第一字節(jié)是指示該字段是否是作為表來使用的標志，四個字節(jié)被用于所述的表，并且Name字段的剩余三個字節(jié)可以用作其他用途，或被省略。現(xiàn)在參照圖4，示出了處理過的PE/COFF映像400的表示。在一個實施例中，PE/COFF頭部從129個字節(jié)(參見圖1)被縮減到30個字節(jié)(401)，并且節(jié)頭部區(qū)域403從40*n個字節(jié)被縮減到21*n個字節(jié)，其中n是節(jié)的數(shù)量。盡管所述節(jié)省表面上看可能是不顯著的，但閃存存儲器可以包括許多映像。如果對于許多被加載到閃存存儲器上的映像來講，空間節(jié)省是可獲得的，那么更多的空間可以用于額外的映像，或者閃存卡的大小可以被縮減?？臻g節(jié)省可以隨目標平臺而改變，因為每個平臺可能需要不同的字段集合。針對除PE/COFF之外的映像格式(例如ELF和Mach-O)的空間節(jié)省也將隨著格式和目標平臺而改變。圖5是示出使用所公開的系統(tǒng)和方法的實施方案的空間節(jié)省的閃存存儲器的表示。根據(jù)一個實施例，示出了處理前(510)和處理后(520)的整個閃存映像。未經(jīng)處理的閃存映像510可以包括專用于XIP代碼的65536個字節(jié)(511)和專用于非XIP代碼的458752個字節(jié)(513)。在閃存存儲器上的處理過的映像中，XIP映像是未壓縮的，但根據(jù)本發(fā)明的實施方案，XIP映像仍然可以是可修剪的。因此，傳統(tǒng)的方法將需要65536個字節(jié)以用于所述映像的該區(qū)域，而修剪的或優(yōu)化的XIP區(qū)域可以只需要個61180字節(jié)(521)。類似地，在本實施例中，使用傳統(tǒng)格式，非XIP代碼可能需要458752個字節(jié)(513)，但在修剪后只需要450403個字節(jié)(523)。應該注意到，XIP代碼可能不被壓縮，因此以傳統(tǒng)的方法，空間節(jié)省是不可能的?，F(xiàn)在參照圖6，根據(jù)本發(fā)明的實施方案示出了圖示示例性方法600的流程圖，所述方法600用于加載處理過的或修剪的映像。一旦引導或系統(tǒng)通電(框601)，可執(zhí)行映像可以從閃存存儲器被加載。在框603中做出關(guān)于固件模塊是否要從閃存存儲器被獲取的確定。如果沒有模塊要被獲取，處理在框605中以正常的操作繼續(xù)，直到在框603中必須確定固件模塊是否要從閃存存儲器被獲取。如果固件模塊要從閃存存儲器被獲取，那么在框607中分配具有足夠大小的存儲器緩沖區(qū)(buffer)用于儲存映像/模塊。映像大小被儲存在該映像中，并且如果未曾修剪，所述大小被儲存在PE頭部中。映像的大小對于非修剪映像來說從PE頭部確定，或者映像的大小從默認和優(yōu)化信息來計算。在框609中重構(gòu)主導的(leading)頭部文件。對于示例性的PE/COFF映像，用種子化信息(seededinformation)來重構(gòu)原始的PE和COFF頭部以填補被修剪的信息的空缺。換句話說，具有原始大小的頭部被重構(gòu)，從而當映像在存儲器中時，映像占據(jù)與如果數(shù)據(jù)未被修剪將占據(jù)的空間相同的空間。這樣的話傳統(tǒng)(legacy)軟件可以讀取所述映像。在一些實施方案中，PE/COFF(或其他格式)頭部被修剪，但節(jié)頭部數(shù)據(jù)僅僅被部分地修剪或根本不被修剪。在一個實施方案中，第一節(jié)頭部用優(yōu)化(修剪)掩碼來重載Name字段。在框611中確定映像是否已被修剪。在本實施例中，該確定查看第一節(jié)的Name字段。如果第一字節(jié)為0，那么映像已被修剪并且掩碼位于Name字段中。如果Name字段的第一字節(jié)非0，那么映像呈默認格式，并且可以以傳統(tǒng)方式被加載，即每次加載一個節(jié)。如果映像文件還未被修剪，那么在框613中第一節(jié)頭部被拷貝到分配的存儲器緩沖區(qū)。如果存在更多的節(jié)頭部要加載，如在框615確定的，那么處理以框611繼續(xù)，并且在框613中下一節(jié)頭部被拷貝到存儲器。本領(lǐng)域普通技術(shù)人員將清楚，在框611中做出的確定可能只需要被進行一次，并且隨后可以設(shè)置標志以遍歷多個節(jié)頭部。流程圖600中的循環(huán)(611，613，615)僅僅是例證性的，并且可以以各種方式來實現(xiàn)。如果如在框611指示的映像已被修剪，那么在一個實施方案中，在框619中使用接著的四個字節(jié)作為位掩碼來確定每一頭部是呈優(yōu)化還是默認格式。在框621，如在位掩碼中所標識的，確定當前節(jié)頭部是否被定義為優(yōu)化的頭部。如果不是，那么在框625中節(jié)頭部被拷貝到分配的存儲器，并且處理繼續(xù)下一節(jié)頭部。如果節(jié)頭部已被優(yōu)化或修剪，那么所述頭部必須被重構(gòu)。為了與期望完整映像格式的傳統(tǒng)程序相兼容，在框623中節(jié)頭部被重構(gòu)。剩余的字段被移動到對應于在映像格式(例如PE/COFF)中定義的偏移的位置。修剪的或刪除/省略的字段以種子數(shù)據(jù)(seeddata)來填充，或者被保持空白，并且被拷貝到原始文件格式中該字段的偏移位置。因此，重構(gòu)的節(jié)頭部將以與傳統(tǒng)軟件兼容的默認格式出現(xiàn)。按照定義，種子化字段(之前修剪的)對目標平臺是的確不必要的，并且這些字段中的任何數(shù)據(jù)被忽略。處理繼續(xù)進行，直到所有節(jié)頭部已被拷貝到分配的存儲器。一旦所有節(jié)頭部已被加載到存儲器，那么在框617中映像文件的剩余部分被加載到存儲器中。在框603處，處理繼續(xù)加載可能存在的任何額外的映像文件。如果映像是XIP，那么映像可以不被加載到主存儲器中，而必須直接從閃存存儲器被執(zhí)行。正常地，XIP文件將從閃存存儲器執(zhí)行，并且兼容性不是嚴格地需要的，因為這些文件通常很大程度上是不可移植的。通常，它們在系統(tǒng)初始化的非常早期被使用，并且一旦平臺已經(jīng)進展到資源更加豐富的狀態(tài)(即當存儲器被發(fā)現(xiàn)并使用時)就不被引用。XIP映像如何被處理是取決于具體實現(xiàn)的。現(xiàn)在參照圖7，示出用于重構(gòu)修剪的代碼映像文件的示例性系統(tǒng)700。在一個實施方案中，處理器701具有系統(tǒng)存儲器703，并且以可操作的方式耦合到閃存存儲器705。在預引導處理期間，基本輸入/輸出系統(tǒng)(BIOS)711在處理器701中執(zhí)行。在預引導期間的各個時刻，從閃存存儲器獲取代碼映像文件715可能是必要的。在實施方案中，一個或更多個代碼映像文件715可以駐留在閃存存儲器705中。代碼映像文件可以是修剪的映像文件715b，所述修剪的映像文件715b已經(jīng)根據(jù)上面描述的方法被修剪或縮減，或者代碼映像文件可以是原始代碼映像文件715a。無論代碼映像文件715是否也被修剪，它們可以被壓縮。在修剪的代碼映像715b的情況下，BIOS711將控制傳送給重構(gòu)器721以便重構(gòu)修剪的映像715b的頭部。重構(gòu)的代碼映像713以可以被傳統(tǒng)代碼處理的形式置入系統(tǒng)存儲器703中，其中傳統(tǒng)代碼不必要了解映像起初曾被修剪。傳統(tǒng)代碼處理重構(gòu)的映像是可能的，因為該目標平臺不需要曾從原始映像中被修剪的任何數(shù)據(jù)。本文中描述的技術(shù)不限于任何特定的硬件或軟件配置；它們可以在任何計算、消費電子或處理環(huán)境中找到適用性。所述技術(shù)可以以硬件、軟件或這兩者的組合來實現(xiàn)。所述技術(shù)可以以在可編程機器上執(zhí)行的程序來實現(xiàn)，所述可編程機器例如移動或固定計算機、個人數(shù)字助理、機頂盒、蜂窩電話和尋呼機、消費類電子設(shè)備(包括DVD播放器、個人錄像機、個人視頻播放器、衛(wèi)星接收器、立體聲接收器、有線電視接收器)，以及其他可以包括處理器、所述處理器可讀的儲存介質(zhì)(包括易失性和非易失性存儲器和/或儲存部件)、至少一個輸入設(shè)備和一個或更多個輸出設(shè)備的電子設(shè)備。程序代碼被應用到使用輸入設(shè)備錄入的數(shù)據(jù)，以執(zhí)行所描述的功能并產(chǎn)生輸出信息。輸出信息可以應用到一個或更多個輸出設(shè)備。本領(lǐng)域普通技術(shù)人員可以意識到，本發(fā)明可以以包括多處理器系統(tǒng)、微型計算機、大型計算機、獨立消費類電子設(shè)備等等的各種系統(tǒng)配置來實踐。本發(fā)明還可以以分布式計算環(huán)境來實踐，其中任務可以由通過通信網(wǎng)絡(luò)來鏈接的遠程處理設(shè)備進行。每個程序可以以高級的過程或面向?qū)ο缶幊陶Z言來實現(xiàn)，以與處理系統(tǒng)通信。然而，如果需要，程序可以以匯編或機器語言來實現(xiàn)。在任何情況下，所述語言可以被編譯或解釋。程序指令可以被用來導致以所述指令編程的通用或?qū)Ｓ锰幚硐到y(tǒng)進行這里描述的操作。可替換地，所述操作可以由包含用于進行所述操作的硬連線邏輯的具體硬件組件，或由編程的計算機組件和定制的硬件組件的任何組合來進行。這里描述的方法可以被提供為可以包括其上存有指令的機器可訪問介質(zhì)的計算機編程產(chǎn)品，所述指令可以用來編程處理系統(tǒng)或其他電子設(shè)備以進行所述方法。使用在這里，術(shù)語“機器可訪問介質(zhì)”包括能夠儲存或編碼指令序列的任何介質(zhì)，所述指令序列由機器執(zhí)行并且導致所述機器進行這里描述的方法中的任何一個。相應地，術(shù)語“機器可訪問介質(zhì)”包括但不限于，固態(tài)存儲器、光或磁盤、以及編碼數(shù)據(jù)信號的載波。此外，本領(lǐng)域中普遍地以提及呈一種形式或另一種形式的軟件(例如程序、過程、進程、應用、模塊、邏輯等)來表示發(fā)生動作或?qū)е陆Y(jié)果。這樣的表達僅僅是表述由處理系統(tǒng)執(zhí)行軟件而導致處理器進行產(chǎn)生結(jié)果的動作的簡便方式。盡管已經(jīng)參照示例性實施方案描述了本發(fā)明，但是該說明書不想要被解釋成限制性的。本發(fā)明所屬領(lǐng)域的技術(shù)人員將清楚，示例性實施方案的各種修改，以及本發(fā)明的其他實施方案被認為落在本發(fā)明的精神和范圍內(nèi)。權(quán)利要求1.一種用于加載映像的方法，包括分配具有足夠大小的存儲器緩沖區(qū)來保存可執(zhí)行映像文件；確定所述映像文件是否已被修剪；以及將所述映像文件加載到所述存儲器緩沖區(qū)中用于執(zhí)行。2.如權(quán)利要求1所述的方法，其中加載所述映像文件的操作還包括對于對應于所述映像文件的每個節(jié)頭部，如果所述映像文件已被修剪，那么確定當前節(jié)頭部是否已被修剪，并且如果是，那么從所述修剪的當前節(jié)頭部重構(gòu)當前標準格式的節(jié)頭部，并且將所述重構(gòu)的節(jié)頭部加載到所述存儲器緩沖區(qū)中，但如果所述當前節(jié)頭部還未被修剪，那么將所述當前節(jié)頭部加載到所述存儲器緩沖區(qū)中；以及如果所述映像文件還未被修剪，那么將每個節(jié)頭部加載到所述存儲器緩沖區(qū)中。3.如權(quán)利要求1所述的方法，其中確定所述映像文件是否已被修剪的操作包括獲取位掩碼；以及標識對應于所述映像文件的多個節(jié)頭部，并且使用所述位掩碼來確定每個標識的節(jié)頭部是否已被修剪。4.如權(quán)利要求3所述的方法，其中所述位掩碼位于對應于所述映像文件的所述多個節(jié)頭部的第一節(jié)頭部的Name字段中。5.如權(quán)利要求1所述的方法，其中加載所述映像文件的操作還包括將多個節(jié)頭部加載到所述存儲器緩沖區(qū)中；以及將映像內(nèi)容加載到所述存儲器緩沖區(qū)中。6.如權(quán)利要求5所述的方法，其中被加載到所述存儲器緩沖區(qū)中的所述多個節(jié)頭部中的每個包括默認格式的節(jié)頭部和重構(gòu)的節(jié)頭部中的一個。7.如權(quán)利要求5所述的方法，其中所述映像內(nèi)容被標識為就地執(zhí)行(XIP)代碼。8.如權(quán)利要求5所述的方法，其中所述映像內(nèi)容是壓縮的。9.如權(quán)利要求1所述的方法，其中所述映像文件以針對第一目標平臺的第一預先確定的格式被修剪，并且所述映像文件以針對第二目標平臺的第二預先確定的格式被修剪。10.一種包含用于加載映像文件的指令的機器可訪問介質(zhì)，當所述指令被執(zhí)行時，引起所述機器分配具有足夠大小的存儲器緩沖區(qū)來保存可執(zhí)行映像文件；確定所述映像文件是否已被修剪；以及將所述映像文件加載到所述存儲器緩沖區(qū)中用于執(zhí)行。11.如權(quán)利要求10所述的介質(zhì)，其中用于加載所述映像文件的所述指令還引起所述機器對于對應于所述映像文件的每個節(jié)頭部，如果所述映像文件已被修剪，那么確定當前節(jié)頭部是否已被修剪，并且如果是，那么從所述修剪的當前節(jié)頭部重構(gòu)當前標準格式的節(jié)頭部，并且將所述重構(gòu)的節(jié)頭部加載到所述存儲器緩沖區(qū)中，但如果所述當前節(jié)頭部還未被修剪，那么將所述當前節(jié)頭部加載到所述存儲器緩沖區(qū)中；以及如果所述映像文件還未被修剪，那么將每個節(jié)頭部加載到所述存儲器緩沖區(qū)中。12.如權(quán)利要求10所述的介質(zhì)，其中用于確定所述映像文件是否已被修剪的所述指令還引起所述機器獲取位掩碼；以及標識對應于所述映像文件的多個節(jié)頭部，并且使用所述位掩碼來確定每個標識的節(jié)頭部是否已被修剪。13.如權(quán)利要求12所述的介質(zhì)，其中所述位掩碼位于對應于所述映像文件的所述多個節(jié)頭部的第一節(jié)頭部的Name字段中。14.如權(quán)利要求10所述的介質(zhì)，其中用于加載所述映像文件的所述指令還引起所述機器將多個節(jié)頭部加載到所述存儲器緩沖區(qū)中；以及將所述映像內(nèi)容加載到所述存儲器緩沖區(qū)中。15.如權(quán)利要求14所述的介質(zhì)，其中被加載到所述存儲器緩沖區(qū)中的所述多個節(jié)頭部中的每個包括默認格式的節(jié)頭部和重構(gòu)的節(jié)頭部中的一個。16.如權(quán)利要求14所述的介質(zhì)，其中所述映像內(nèi)容被標識為就地執(zhí)行(XIP)代碼。17.如權(quán)利要求14所述的介質(zhì)，其中所述映像內(nèi)容是壓縮的。18.一種用于加載映像文件的系統(tǒng)，包括在目標平臺上的處理器，所述處理器具有系統(tǒng)存儲器并且以可操作的方式耦合到閃存存儲器設(shè)備；儲存在所述閃存存儲器設(shè)備中的至少一個可執(zhí)行映像文件；以及重構(gòu)器，所述重構(gòu)器重構(gòu)修剪的映像文件并且將所述修剪的映像文件加載到系統(tǒng)存儲器中。19.如權(quán)利要求18所述的系統(tǒng)，其中所述重構(gòu)器確定所述至少一個可執(zhí)行文件中的每個是否已被修剪，并且如果是，那么確定對應于所述修剪的可執(zhí)行文件的節(jié)頭部是否已被修剪，并且如果節(jié)頭部已被修剪，那么以與所述目標平臺一致的格式重構(gòu)所述修剪的節(jié)頭部。20.如權(quán)利要求18所述的系統(tǒng)，其中儲存在所述閃存存儲器設(shè)備中的所述可執(zhí)行映像文件中的至少一個已被修剪成與所述目標平臺一致的格式。21.如權(quán)利要求18所述的系統(tǒng)，其中一旦重構(gòu)的映像文件已被加載到系統(tǒng)存儲器中，那么所述映像文件以仿佛它未被從原始的映像文件修剪過的方式進行操作。全文摘要本發(fā)明的實施方案是涉及縮小或優(yōu)化可執(zhí)行映像的系統(tǒng)和方法，其結(jié)果是儲存空間的節(jié)省。在至少一個實施方案中，本發(fā)明在將映像儲存到用于目標平臺的閃存上之前從可執(zhí)行映像頭部移除不必要的字段或信息。與目標平臺無關(guān)的信息的移除允許可執(zhí)行體占據(jù)閃存存儲器上更少的空間。當映像被加載時，基于優(yōu)化的頭部信息來解釋所述映像。在實施方案中，所述映像可以進一步被已知的方法壓縮，以節(jié)省額外的空間。描述了其他實施方案并且主張了對它們的權(quán)利要求。文檔編號G06F15/16GK1947094SQ200580013217公開日2007年4月11日申請日期2005年4月8日優(yōu)先權(quán)日2004年4月26日發(fā)明者邁克爾·羅斯曼,文森特·齊默,格雷戈·麥格拉思申請人:英特爾公司