Josh Triplett以一個“笑點”開始了他在PyCon 2015上的演講：移植Python使其無需操作系統運行：他和他的英特爾同事讓解釋器能夠在GRUB引導程序、BIOS或EFI系統上運行。連演講的休息時間也沒放過，他有很多有趣的要說的事情，還有許多讓人大開眼界的演示。
Python在Boot Loader上運行的最初想法是能夠測試硬件，像BIOS，可擴展固件接口(EFI)以及高級配置和電源接口(ACPI)，而無需去寫一些“一次性測試項目“程序集。傳統來說，英特爾已經寫了很多針對DOS(BIOS系統)或EFI系統的測試程序。無論是DOS還是EFI都不提供環境保護，這樣程序就能夠駐入在內存和硬件中去做他們所需的任何事情。
他不過是想用腳本來寫測試代碼而已，“因為這樣比較有趣”。他既不想寫太多的 C 語言代碼，也不想像以前那樣用那個能計算 C-類 表達式的 GRUB shell。 其實, 他說，“C 代碼寫的越少， 我就越輕松"。
隨著時間的推移, 移植到 GRUB 中的 Python 已經變成操控硬件的利器。它又把我們帶回到使用 PEEK 和 POKE 在 Commodore 64(or DOS) 上面操控硬件的美好時光。“那些事是現在的硬件設備無法完成的”他說。
GRUB中的PYTHON
BIOS Implementation Test Suite(BITS)，正如其名，將會運行在多種固件上的GRUB中：32位BIOS或32/64位EFI。他使用原始的GRUB或GRUB 2。基於標准的PYTHON解釋器(如CPython)，但是他道歉道：它使用PYTHON2.7。這個工具的目標受眾對這個版本的語言相當熟悉。如果不是這樣，他更喜歡在以後遷移到Python 3.
有一個“讀取-求值-輸出 循環” 交互環境[read-eval-print loop (REPL)]讓你完全訪問Python語言。它包括Tab完成，歷史記錄，和行編輯。一個標准庫的“大量碎片”已經被一直BITS上運行。最重要的是，這個項目已經添加了一些對平台支持的模塊：CPU,SMP(symmetric multi-processing),ACPI,EFI以及其他。INTEL已經創建了一個測試集以及 使用Python寫了使用以上模塊的一些試探性的工具。
Triplett然後從幻燈片切換到了虛擬機的GRUB中運行一個Python解釋器的提示界面。他輸入了兩句語句到解釋器來展示它支持列表解析和任意大的整數(如：bignums)。
要獲得一個python交互環境，GRUB需要調用一個單獨的函數：
PyRun_InteractiveLoop(stdin, "");
它會處理所有REPL[讀取-執行-輸出 循環]，包括對輸入的解析和執行、行編輯等等。
這兩個參數簡單的表明了在哪裡獲取輸入 和 當發生異常時在traceback裡要輸出什麼來當做源文件。但是想要能在GRUB裡調用那個函數還有一些工作要做。
因為不能使用來自於 Linux 主機的工具鏈和特性，這個項目不能像平常那樣安裝和配置 Python。對於 GRUB 來說，沒有 GNU 目標聲明(例如：用於交叉編譯的 cpu-vendor-od-triple)和目標頭文件可以使用。因此，BITS 將所有的 Python 源文件添加到了 GRUB 的構件系統中。本質上說那僅僅是一些GRUB 添加 Python 所必需的 C 語言文件。通常，autoconf 將創建 Python 構件程序中的apyconfig.h 文件來說明哪些功能在平台上存在。相反的，這個項目手動的創建 apyconfig.h 文件大量“不，我沒有這個功能”的配置參數和一小撮“是”的條目。
許多在 pyconfig.h 文件中被列出的功能是被(或不被)操作系統所提供的，但是在這種情況下是沒有操作系統的。Python 的確需要最低限度的一些支持功能，以及一些額外被配置的特性。這個項目需要去做的是提供任何被渴望而又不存在功能。
CPython 需要什麼
那麼，什麼情況下你真的需要運行 CPython?Triplett 提供的大量實例來證明什麼時候需要運行 CPython。有一些平常的文件操作就需要了，比如說：使用 stat () 來確定一個路徑是否包含 __init__或是文件中是否包含 __init__。增加 simpleisatty()(以位為單位，文件描述符是少於三則返回 true)好比經歷一個 seek() 執行一樣。為了支持那些功能，不得不添加一個簡單的文件描述符表，因為 GRUB 的文件功能使用結構體指針，而不是描述符。
解析器把一個字符放回在輸入流的時候，Python 也需要使用 ungetc() 。而不是在添加一個字符緩沖區的時候使用，即添加"快速 hack"來尋找後一個字符。添加開放式編碼的 qsort() 時也一樣一樣要使用 ungetc();GRUB 不任何支持排序。
GRUB還沒有支持的另一個方面是浮點運算。項目組發現了一個許可的浮點運算庫FDLIBM。它沒有使用任何浮點硬件加速，這在GRUB環境是非常有用的。這意味啊即使在固件沒完全初始化浮點運算硬件時也能使用浮點運算。
在使用Python時，我們大量使用printf()和sprintf()。大部分情況，GRUB版本工作很好，但對“%%”(輸出一個”%“)這種特殊格式還不支持。事實證明，Python頻繁使用格式化的字符串輸出。
在被發現和修復之前，怪異的BUG仍然存在。
這個工程還有一些性能問題需要解決。首先，啟動時間出乎意料的長。對硬件來說，這是十分痛苦的事情，但是在 CPU 的模擬電路上也很糟糕(“我們不想花三天時間做引導”)。部分問題來自於 Python 的解釋器，每次它讀取一個數據的時候都要調用 usesungetc()。GRUB 沒有太多高速緩存的磁盤，所以所有 I/O 端口直接訪問磁盤。
通過加入對 .pyc (Python 字節代碼)文件格式的支持，這個工程能夠提前減少許多語法分析工作。主機的版本和 GRUB 的版本在同一時刻編譯，用於 Python 文件在啟動時的編譯工作。
這做出了實質性的提升，但是由於stat()的原因，啟動時間仍然有些慢。他說在Linux系統上，stat()僅花費幾微秒的時間，但是BITS版本會花費幾毫秒。增加對zipimport的支持能讓工程把所有的.py文件打包放入一個單一的ZIP文件中來避免對stat()的調用。
這個工程希望做有歷史和tab自動補全的REPL(讀取﹣求值﹣輸出循環)，但是一般獲得支持的方式是使用GUN的Readline library。這個庫由有終端設備的POSIX(可移植操作系統接口)提供環境支持。開發者不想寫一個“C代碼文件”來支持它，所以他們用Python寫了一個讀取線支持來替代。CPython的PyOS_ReadlineFunctionPointer被稱為一個使用C語言API的新Python函數的C函數集合。
為了能夠使用其他的操作和多種的測試套件，仍迫切需要構建 GRUB 的動態菜單。GRUB 已經為設備提供了磁盤和文件系統像磁盤分區和 CD 驅動器(例如：“(hd0)”,"(cd)")因此 BITS 增加了一個的“(python)”設備和一個工作起來像在 Linux 用戶空間的文件系統(譯者注：打不開請加梯子)。因此 Python 代碼能訪問任意的內存文件，例如在 (python)/menu.cfg 下的菜單配置文件，“即使我們沒有寫更多的C代碼”，Triplett 說道。
訪問硬件
既然目標是提供一個友好的測試硬件環境，Python 需要能夠訪問它。一個叫做“bits”的模塊被添加進來提供訪問各種硬件的功能，例如：CPUID，特殊模塊寄存器 (MSRs)，I/O 端口，和內存映射 I/O。他用幾行代碼展示了這些能力。
>>> import bits >>> from ctypes import * >>> c = bits.cpuid(0, 0) >>> c cpuid_result(eax=0x..., ebx=..., ecx=..., edx=...)
他引入ctypes模塊，以便在下一部分演示中“操作原始內存片”。對於那些想要深挖一些的人來說，幾乎所有演示都可以在這個YouTube視頻的演講中看到。cpuid()調用返回了CPU0的CPUID，他之後將其打印出來。他問：“這是不是很有趣?我們正從Python中得到處理器的寄存器信息。” 接著，他使用Python來解釋這個結果：
>>> buf = (c_uint32*3)(c.ebx, c.edx, c.ecx) >>> (c_char*12).from_buffer(buf).value 'GenuineIntel'
三個寄存器包含描述處理器類型的標識符。他使用ctypes模塊中的類型，以字符串的形式重新解釋這三個寄存器(按照之前的順序)的信息，結果顯示為處理器類型。
Intel希望能夠測試高度並行化的系統，但GRUB只了解啟動了的CPU的信息。所以BITS在系統中喚醒每個CPU，並把它們放入一個睡眠循環中，使用MWAIT(x86監視器等待指令)等待工作的到來。特定CPU有專門的喚醒函數和執行函數。
這個項目還准備用Python獲取ACPI的信息和方法。這參考了ACPI組件架構 (ACPICA)的實現並把它加入BITS中。由於全部是C代碼，所以增加了Python綁定。這一做法使得Python可以調用任意ACPI方法——只要先將參數轉換成ACPI類型並將結果轉成Python類型。他用了一個簡單的Python程序演示了如何將虛擬機中所有設備的硬件ID顯示出來:
>>> import acpi >>> print acpi.dump('_HID')
Triplett聲稱他不會繼續深入講解BITS硬件探索的細節。他已經在其它演講中更加詳盡地解釋過了。
英特爾也希望系統能使用這個固件而不是BIOS訪問EFI。這種擴展名義上是指一切在EFI中都是”協議“，每一個都包含了原生c語言函數調用。要做到這樣，通過libffi提供的外部函數接口被移植到GRUB並且添加了支持EFI調用轉換的功能。使用這種方式和Python c類型的模塊(Python提供的c語言類型的接口和函數)允許解釋器訪問EFI。他僅使用Python演示了訪問EFI的方法：
>>> import efi >>> out = efi.system_table.ConOut.contents >>> out.ClearScreen(out) [ which clears the screen ] >>> out.OutputString(out, 'Hello world!rn') Hello world!
訪問EFI後，允許Python使用EFI文件協議去創建目錄和寫文件到EFI文件系統中。這是非常有幫助的，因為GRUB僅僅能夠讀文件。不僅僅如此，存在著圖像輸出協議(GOP)能夠讀寫屏幕內容。正如他所解釋的，幻燈片就是簡單的圖像，事實上是通過在筆記本上BITS和EFI顯示出來的。在BITS的環境下，做出了這個幻燈片和demo，因此，事實來說，整個演示就是一個demo，他說這些話時周圍響起了掌聲。這樣做是不需要任何一行新的C語言代碼的。
最後他保存了認為最好的demo，並從EFI(可擴展固件接口)GOP(畫面組)的幀緩沖區中作為Python啟動，當他敲完最後的幾行代碼，很明顯機器開始識別了，計算並顯示了一個400x400大小的 Mandelbrot set(曼德布洛特集合)的灰度圖片。他對周圍鼓掌的人說：“在EFI圖形協議中僅用八行Python代碼顯示了不規則圖形(Fractal)”。大約要15秒來繪出圖像，有點慢，他說，那不是Python的問題，而是因為使用純軟件進行浮點運算了。
在談話最後，Triplett指出在BITS(後台智能傳輸服務)裡沒有中斷處理的鉤子函數(hook)，但是這很容易就添加上的。他說，在像Mirage OS(和其它的“類似操作系統”)也能在BITS上添加Python代碼，並且和這沒有多大區別。“待辦事件清單上的下一個有趣的項目”是添加Python綁定的EFI TCP網絡協議和鉤子到Python的socket模塊，看看能否在那樣的環境(BITS)下運行一個簡單的HTTP服務(SimpleHTTPServer)。這樣就能添加一個“網絡REPL(web REPL)”到BITS環境了。
