A highly inventive individual, going by the online moniker "b33f", has undertaken a fascinating project: the meticulous conversion of the entirety of the groundbreaking 1993 first-person shooter video game, Doom, into the portable document format (PDF). This is not simply a document about Doom, but rather a functional, albeit unconventional, rendition of the game itself. The PDF file, hosted online for public access, leverages the surprising capabilities of the PDF specification to emulate a rudimentary form of interactive gameplay within the confines of a document typically associated with static text and images.
The project utilizes a series of intricately designed pages, each representing a distinct game state or a minor incremental change within the game world. Rather than employing traditional animation or code execution, the "gameplay" progresses by manually navigating through these numerous pages, simulating movement, actions, and even the passage of time within the Doom environment. Each page is a static snapshot, depicting the game's visuals at a specific moment, including elements such as the player's perspective, enemy positions, and the state of the environment. Progression is achieved by clicking hyperlinks embedded within the PDF, each link corresponding to a potential player action, like moving forward, turning, or firing a weapon. Clicking a link transports the user to the page representing the outcome of that action, effectively creating a painstakingly constructed illusion of interactive experience.
While this approach drastically deviates from the original game's real-time dynamics and smooth animation, it serves as a remarkable demonstration of the often-overlooked flexibility inherent in the PDF format. The project is not meant to be a practical replacement for playing the original Doom, but rather an intriguing experiment and a testament to creative problem-solving. It showcases how a seemingly inflexible format can be manipulated to achieve unexpected results, blurring the lines between document and application, and offering a unique, albeit cumbersome, way to experience a classic piece of gaming history within the familiar confines of a PDF reader. The sheer volume of pages required to represent even a small portion of the game highlights the dedication and effort invested in this curious undertaking.
This comprehensive guide, titled "BCPL Programming on the Raspberry Pi," serves as an introduction to the BCPL programming language specifically tailored for use on the Raspberry Pi platform. It aims to provide novice programmers, particularly young individuals, with a foundational understanding of BCPL and equip them with the necessary skills to develop functional programs on their Raspberry Pi.
The document begins with a brief historical overview of BCPL, highlighting its influence as a precursor to the widely-used C programming language. This historical context establishes BCPL's significance in the evolution of programming languages. The guide then proceeds to detail the installation process of the Cintcode BCPL interpreter on a Raspberry Pi system, offering clear, step-by-step instructions to ensure a smooth setup.
Following the installation, the core concepts of BCPL programming are systematically introduced. This includes a detailed explanation of fundamental data types like integers and vectors (arrays), along with guidance on using operators for arithmetic and logical operations. Control flow mechanisms, crucial for directing program execution, are also covered comprehensively, encompassing conditional statements (IF, TEST), loops (WHILE, FOR), and switch statements (SWITCHON). The guide emphasizes the importance of structured programming techniques to promote clarity and maintainability in BCPL code.
The guide further delves into more advanced topics such as procedures (functions) and the concept of separate compilation. It elucidates how to define and call procedures, enabling modular program design and code reuse. The separate compilation feature allows developers to break down larger programs into smaller, manageable modules that can be compiled independently and then linked together. This promotes efficient development and simplifies debugging.
Input and output operations are also addressed, demonstrating how to interact with the user via the console and how to manipulate files. The guide provides examples of reading and writing data to files, enabling persistent storage of information.
Throughout the guide, numerous examples of BCPL code snippets are interspersed to illustrate the practical application of the concepts being discussed. These practical demonstrations reinforce the theoretical explanations and facilitate a deeper understanding of BCPL syntax and functionality. The document concludes with a series of suggested programming exercises designed to challenge the reader and encourage further exploration of BCPL's capabilities on the Raspberry Pi. These exercises provide hands-on experience and promote the development of practical programming skills. In essence, the document serves as a self-contained, accessible resource for anyone interested in learning BCPL programming in the context of the Raspberry Pi.
The Hacker News post titled "Young Persons Guide to BCPL Programming on the Raspberry Pi [pdf]" has several comments discussing the linked PDF and BCPL in general. A recurring theme is nostalgia and appreciation for the simplicity and elegance of BCPL.
One commenter recalls using BCPL on a Xerox Data Systems Sigma 9 in the early 1980s, highlighting its influence on C and emphasizing its small size and speed. They appreciate the document for its historical context and clear explanation of bootstrapping.
Another commenter focuses on the educational value of the document, suggesting that working through it provides valuable insight into how software works at a fundamental level, from bare metal up. They praise the clear writing style and the practical approach of using a Raspberry Pi.
A few comments delve into the history of BCPL, mentioning its relationship to CPL and C, and how it was a dominant language for systems programming before C took over. One user explains that BCPL was instrumental in the development of the original boot ROM for the Amiga. They also mention its continued use in some specialized areas due to its compact runtime.
Some comments express interest in trying BCPL on a modern platform like the Raspberry Pi. They discuss the potential benefits of learning such a foundational language and the practical experience it offers in understanding system architecture and bootstrapping.
Several commenters share personal anecdotes about their experiences with BCPL or related languages, giving the discussion a sense of historical perspective. One person talks about using BCPL in the 1970s and remembers the challenges of using paper tape. Another recounts learning C before BCPL and finding the differences fascinating.
The overall sentiment in the comments is positive, with many expressing admiration for BCPL's simplicity and power. The document is praised for being well-written, informative, and historically relevant. The discussion provides a glimpse into the enduring interest in older programming languages and the desire to understand the foundations of modern computing.
Hans-J. Boehm's paper, "How to miscompile programs with 'benign' data races," presented at HotPar 2011, explores the potential for seemingly harmless data races in multithreaded C or C++ programs to lead to unexpected and incorrect compiled code. The core issue stems from the compiler's aggressive optimizations, which are valid under the strict aliasing rules of the language standards but become problematic in the presence of data races. These optimizations, intended to improve performance, can rearrange or eliminate memory accesses based on the assumption that no other thread is concurrently modifying the same memory location.
The paper meticulously details how these "benign" data races, races that might not cause noticeable data corruption at runtime due to the specific values involved or the timing of operations, can interact with compiler optimizations to produce drastically different program behavior than intended. This occurs because the compiler, unaware of the potential for concurrent modification, may transform the code in ways that are invalid when a race is actually present.
Boehm illustrates this phenomenon through several compelling examples. These examples demonstrate how common compiler optimizations, such as code motion (reordering instructions), dead code elimination (removing seemingly unused code), and common subexpression elimination (replacing multiple identical calculations with a single instance), can interact with benign races to produce incorrect results. One illustrative scenario involves a loop counter being incorrectly optimized away due to a race condition, resulting in premature loop termination. Another example highlights how a compiler might incorrectly infer that a variable's value remains constant within a loop, leading to unexpected behavior when another thread concurrently modifies that variable.
The paper emphasizes that these issues arise not from compiler bugs, but from the inherent conflict between the standard's definition of undefined behavior in the presence of data races and the reality of multithreaded programming. While the standards permit compilers to make sweeping assumptions about the absence of data races, these assumptions are frequently violated in practice, even in code that appears to function correctly.
Boehm argues that the current approach of relying on programmers to avoid all data races is unrealistic and proposes alternative approaches. One suggestion is to restrict the scope of compiler optimizations in the presence of potentially shared variables, effectively limiting the compiler's ability to make assumptions about the absence of races. Another proposed approach involves modifying the memory model to explicitly define the behavior of data races in a more predictable manner. This would require a more relaxed memory model, potentially affecting performance, but offering greater robustness in the face of unintentional races.
The paper concludes by highlighting the seriousness of this problem, emphasizing the difficulty in diagnosing and debugging such issues, and advocating for a reassessment of the current approach to data races in C and C++ to ensure the reliability and predictability of multithreaded code. The overarching message is that even seemingly innocuous data races can have severe consequences on the correctness of compiled code due to the interaction with compiler optimizations, and that addressing this issue requires a fundamental rethinking of how data races are handled within the language standards and compiler implementations.
The Hacker News post titled "How to miscompile programs with "benign" data races [pdf]" (linking to a PDF of Hans Boehm's presentation at HotPar '11) has several comments discussing the implications of the paper and its relevance to modern programming.
One commenter points out the significance of Boehm's work, particularly given his deep involvement in garbage collection. They note that even seemingly harmless data races, the kind often dismissed as benign, can lead to surprising and difficult-to-debug compiler optimizations gone awry. This highlights the importance of understanding the subtle ways data races can interact with compiler behavior.
Another commenter expresses concern about the implications for C++, a language where data races are undefined behavior. They suggest that, according to the paper, C++ compilers are allowed to make optimizations that could break code even with seemingly harmless data races. This reinforces the danger of undefined behavior and the importance of avoiding data races altogether, even those that appear benign at first glance.
A further comment emphasizes the importance of formal specifications for memory models, especially given the complexity introduced by multithreading and compiler optimizations. They highlight that without rigorous definitions of how memory operations behave in a concurrent environment, compiler writers are left with considerable leeway, which can lead to unexpected results. This ties back to the core issue of the paper, where seemingly benign data races expose this ambiguity.
Several commenters discuss the difficulty of reasoning about concurrency and the challenges of writing correct concurrent code. They note that the paper serves as a good reminder of these complexities and reinforces the need for careful consideration of memory ordering and synchronization primitives.
One commenter even speculates whether it is possible to write truly correct, high-performance concurrent C++ without relying on library abstractions like those found in Java's java.util.concurrent. They suggest that the complexities highlighted in the paper make it exceptionally difficult to manage concurrency manually in C++.
The overall sentiment in the comments reflects an appreciation for Boehm's work and its implications for concurrent programming. The commenters acknowledge the difficulty of writing correct concurrent code and the subtle ways in which seemingly innocuous data races can lead to unexpected and difficult-to-debug problems. They emphasize the importance of understanding memory models, compiler optimizations, and the need for robust synchronization mechanisms.
Summary of Comments ( 57 )
https://news.ycombinator.com/item?id=42678754
Hacker News users generally expressed amusement and appreciation for the novelty of rendering Doom as a PDF. Several commenters questioned the practicality, but acknowledged the technical achievement. Some discussed the technical aspects, wondering how it was accomplished and speculating about the use of vector graphics and custom fonts. Others shared similar projects, like rendering Quake in HTML. A few users pointed out potential issues, such as the large file size and the lack of interactivity, while others jokingly suggested printing it out. Overall, the sentiment was positive, with commenters finding the project a fun and interesting hack.
The Hacker News post titled "Show HN: Doom (1993) in a PDF" generated a fair amount of discussion, with several commenters intrigued by the concept and its execution.
One of the most compelling threads started with a user questioning the practical use of having Doom rendered within a PDF. This sparked a discussion about potential applications, with some suggesting it could be used for archival purposes, preserving the game in a format less susceptible to software and hardware obsolescence. Others saw it as a novelty or a technical curiosity, appreciating the ingenuity involved in rendering a dynamic game within a static document format. The creator of the PDF chimed in, explaining that it was mainly a technical experiment, driven by curiosity about the possibilities of the PDF format.
Several users expressed admiration for the technical feat, particularly the implementation of sound within the PDF, which some found surprising. They inquired about the methods used to achieve this, prompting the creator to explain that they utilized the PDF's multimedia capabilities and embedded a MIDI soundtrack.
There was also discussion about the limitations of the PDF version, such as performance issues and the lack of interactivity beyond basic menu navigation. Some users pondered whether it would be possible to incorporate more complex game logic within a PDF, leading to a brief exchange about the potential and limitations of PDF as a platform for interactive applications.
A few commenters also drew parallels to other projects that had explored unconventional ways of running Doom, referencing instances like Doom running on calculators or other limited hardware. This reinforced the theme of technical curiosity and the desire to push the boundaries of what's possible with existing technology.
Finally, there were some lighthearted comments appreciating the quirkiness of the project and its nostalgic connection to the original Doom game.