在上述的映射文件中，我們了解到庫占用了 1K 的寶貴存儲器空間。深入查看映射文件，通過 Excel 進行分析后得到了如圖 2 所示的結果。我們從圖中移出較小的庫函數部分。盡管這些函數名稱比較晦澀，不過我們可以對照庫參考資料逐一了解其含義。首先，ULDIV 是指無符號數的長除法 (long division)，而圖中第二個則是指長乘法 (long multiplication)。

.map 文件的交叉參考表明我們很幸運：上述函數只用于一個文件中。.lst 文件顯示了長除法函數的兩種使用情況以及長乘法函數的一種使用情況

glNandDevCapacity = CYAN_NAND_DEV_NUMPAGES_BLOCK * CYAN_NAND_UBLKS_PER_ZONE * (uint32_t)glNandNumZones;

在該特定案例中，我們知道 zone 的數量是一個二進制數，而另兩個值為常量。因此，我們可用重復 8 次的左移位 (left shift) 操作替代長乘法：

{

char zoneCtr = glNandNumZones;

glNandDevCapacity = CYAN_NAND_DEV_NUMPAGES_BLOCK * CYAN_NAND_UBLKS_PER_ZONE;

while (zoneCtr)

{

glNandDevCapacity = 1;

zoneCtr >>= 1;

}

}

盡管這個例程相當大，但它仍能減少庫的使用并減小代碼的整體大小。

掌握比編輯器更多的信息

成熟的 8 位編譯器包括代碼編寫良好、經過優化的庫函數。不過，這些函數須考慮到通過對數據的了解可自行處理的一些不常見情況。映射文件中顯示的最大庫函數就是這樣一個很好的例子。調用兩次 ULDIV 例程，以獲得輸入值除以常量后得到的除數和余數：

zn = (adj_lba / CYAN_NAND_UBLKS_PER_ZONE);

glNandRelativeBlkAddr = (adj_lba % CYAN_NAND_UBLKS_PER_ZONE);

由于我們在預期值方面比編譯器了解的更多，因此我們可以讓編譯器不使用龐大的長除法函數，而采用較小的 16 位版本來替代。

{

xdata unsigned char lastNibble = adj_lba 0xf;

adj_lba >>= 4;

zn = ((uint16_t)adj_lba / (uint8_t)CYAN_NAND_UBLKS_PER_ZONE/16));

glNandRelativeBlkAddr = ((uint16_t)adj_lba % (uint8_t) (CYAN_NAND_UBLKS_PER_ZONE/16));

glNandRelativeBlkAddr = (glNandRelativeBlkAddr 4) + lastNibble;

}

激進的的程序優化者甚至可能實現他們自己的二進制長除法例程。