It’s been nearly two months since my April Fools’ project this year (not a prank!) where I managed to get a Swift program to run on Mac OS 9. I’m still proud of both the technical achievement and the blog post there. But when I finished it…I didn’t want to stop.

1. Yellow Rose Mecosta Mi
2. Yellow Roses Mac Os X
3. Yellow Roses Mac Os X

Macbook 13', Mac OS X (10.6), 320 gig HD, 4gig ram, OS X, Backtrack3, WinXP Posted on Aug 29, 2009 4:22 AM Reply I have this question too (3) I have this question too Me too (3) Me too. (Redirected from Yellow Rose (2019 film)) Yellow Rose is a 2019 American-Fillipino musical drama film co-written and directed by Diane Paragas. It is produced by Cecilia R. Mejia, Diane Paragas, Rey Cuerdo, Orian Williams, and Jeremiah Abraham. The film stars Eva Noblezada, Dale Watson, Princess Punzalan, and Lea Salonga.

There were a few things I wanted to do. First of all, there’s the small bit of all this that’s useful work: to get to my minimum viable C-interoperating product, I chopped down the Swift standard library quite a bit. That’s something that’s still useful to people who want to write Swift in constrained environments, like embedded code, and I’ve been encouraged to write about my findings there. (And plan to.) But moreover, while BitPaint was a great proof-of-concept, it didn’t really use that much Swift. It really was just C interop. So, what could I do that would actually feel like a Swift project?

Well, how about my other useless project from this year, ROSE-8 and the Game ’by Color? A fictional game system I designed, running on the OS I learned to program on? Perfect.

This turned out to be, um, quite a bit of work.

Runtime requirements

ROSE-8 doesn’t actually use too many complicated Swift features…but of course, it depends on the standard library, and specifically Swift’s plain old resizable, copy-on-write Array. Handling Array means properly handling

• class allocation and retain counting
• generic types
• generic implementations that aren’t fully optimized away

All of this needs actual runtime support.¹ With normal Swift, the runtime is written in C++ and linked in to the standard library. While I had gotten Clang to emit code for Mac OS 9, C++ has its own standard library, and I didn’t want to try to get that working on Mac OS 9. (And of course, the C++ standard library provided on Mac OS 9 is too old to support many of the features the Swift runtime needs.) So one way or another I was going to have to do some implementing from scratch, not just copying from the real version like I’d done for the standard library.

But wait, why is the Swift runtime implemented in C++ anyway? Why not write it in Swift?

1. The runtime was needed pretty early on in the bring-up of Swift, so the oldest bits of it couldn’t have been written in Swift. That’s not going to apply here.

2. The runtime usually needs to be able to access platform functionality, but Swift has “overlay” libraries that augment the usual platform functionality when you do something like import Darwin (or in this case, import MacTypes). So you’d have a circular dependency between the runtime (usually linked in with the stdlib) and the platform overlays. However, if I’m always going to use static linking, the linker can handle these circular dependencies.²

3. There are still some things C++ can do that Swift can’t do, the most important being declaring globals with particular names and declaring complex globals with compile-time constant values. The Swift compiler expects to be able to reference certain things directly, such as the type metadata for basic integer types. This one’s still a problem for me, but maybe I can limit my C++ use to that.

I had avoided taking any dependencies on the runtime before, but maybe it’d be a good learning experience for me. Even when I worked on Swift at Apple, I mostly worked on the user-facing parts of the compiler, with only a few short jaunts into the runtime and standard library. So I decided to forge ahead with a runtime written in Swift (mostly). It may not be the fastest or prettiest, and it certainly wasn’t going to support everything the real runtime does, but I could make it work. Right?

Breaking it down

Like last time, I decided to start with an easier goal: getting enough of the runtime working to support an ‑Onone build of BitPaint. As I said above, BitPaint really isn’t so complicated from a Swift perspective, in that it’s mostly just pushing integers and pointers around. With optimizations on, it inlines everything it needs, and doesn’t even need to link against the built stdlib. However, quite a few of the integer and pointer operations in Swift are implemented generically, relying on the compiler to optimize them down to machine-provided operations! So right off the bat I had to handle a bunch of the generics model.

Aside: This post isn’t going to be a discussion of the Swift runtime—the real one or the tiny one I made. I’ve been encouraged to write a post on that too in the future, but for now I’m going to stick to a narrative about how I got the Mac OS 9 Game ’by Color app running.

My approach was basically “compile BitPaint at ‑Onone, try to link, and see what runtime functionality is missing”. There was a fair bit of it at the beginning!³

You can mostly group these into four categories:

1. Those global objects I mentioned earlier (the ones that start with $s)
2. Metadata, layout, and associated type utilities
3. Object allocation and reference counting
4. Some low-level numeric operations that weren’t implemented in the PowerPC of the day

And I ended up having to deal with each of these in a different way:

1. This is the one piece I borrowed most of from the real runtime. It is implemented in C++ but for any complicated code I called back into Swift.

2. This was the bulk of the work. A lot of what the runtime does is manage generic metadata, which has to be allocated and filled out for every set of generic arguments if the use can’t be optimized away. It’s also easy to get it wrong.

3. Object allocation is actually pretty simple if you don’t support unowned and weak references! But wait, why do I need it at all for BitPaint, which only does numbers and pointers? Turns out Swift uses objects behind the scenes to implement both existentials and the captures stored for a closure, and besides, I’m going to need them anyway for Array’s storage. (Also, this way my Swift can use ARC to manage CF objects.)

4. Most of these numeric operations, the ones with underscores, come from LLVM itself. LLVM knows that not every platform implements all these operations, so it provides the compiler‑rt project to implement them in software. With not too much trouble I was able to get the compiler‑rt “builtins” I needed to build for PPC32.

   truncf was the one exception, since it’s normally part of the C standard library, but Mac OS 9 didn’t actually provide it. Why? Probably because C converts between floats and doubles anyway, and the operation is going to have the same result if you round-trip through double. But LLVM wanted it to be there, and trying to trick it into calling the double-precision trunc wasn’t working, so in the end I just took a detour and implemented it myself, as a refresher on the IEEE 754 format.

Debugging

Yellow Rose Mecosta Mi

…was a challenge. Without real string formatting, I made good use of a little dump utility that I tweeted:

withUnsafePointer(to: v) {
let p = UnsafeRawPointer($0)
var i = 0
while i < MemoryLayout.size(ofValue: v) {
let nextByte = (p + i).load(as: UInt8.self)
putchar(hexToASCII(nextByte >> 4))
putchar(hexToASCII(nextByte & 0xF))
putchar(0x20)
i += 1
}
}

— Jordan Rose (@UINT_MIN) May 13, 2020

But this only goes so far. It’s not so helpful when a pointer points to the wrong thing, or when some memory is left uninitialized, or when everything is offset by 4 from its correct address. My debugging techniques ranged from placemarker calls to puts (“did we get this far?”), to trying to compile minimal programs that would still crash in the same way (what I called a “playground” app), to early-exiting or even intentionally breaking things to see if they still crashed. These are all fairly standard debugging techniques, but the most powerful ones are missing: directly inspecting memory and stepping through instructions until you find a crash or misbehavior. No backtraces and no live debugging on Mac OS 9, at least not without more specialized tools I didn’t have!⁴

The most mysterious problem was one where BitPaint would appear to work, but crash after several seconds of user interaction. What was going on? Want to guess?

.

.

.

.

.

.

Yellow Roses Mac Os X

It took me days to think of running out of memory; worse, this was after it had already been suggested to me in bouncing ideas off a friend. (Did you know that in Mac OS 9, an application had to specify the maximum amount of memory it would ever use up front?) To be fair, the code that was causing the problem shouldn’t have been allocating any memory, and the only metadata being allocated in the runtime was when a new generic type was instantiated. Why wasn’t the cache working?

It turned out to be a compiler bug, though fortunately not one that’s gone out in any shipping version of Swift.⁵ The symptom was that global variables with constant initializers were considered to never change, and therefore the cache for generic metadata was getting allocated from scratch, empty, with every call. The fix ended up being pulling the latest updates for the compiler and merging in my changes once more. That’s it.

The second most mysterious bug was another one I tweeted:

Last few days' debugging:
`a != a`
→ for two Optionals uses a tuple https://bugs.swift.org/browse/SR-12829
→ Runtime thinks tuple is half the size it should be
→ All tuples using the same metadata
→ Cache key is a CFData
→ All cache keys are 0-length
→ Forgot https://developer.apple.com/documentation/corefoundation/1542375-cfdatasetlength

— Jordan Rose (@UINT_MIN) May 19, 2020

Anyway, with a lot of trial and error, “psychic debugging”, and re-reading whatever code I guessed was causing the problem, I eventually got a runtime that would work with an unoptimized BitPaint. And not too long after, with Array as well, and then the Game ’by Color.

Yellow Roses Mac Os X

Rewards and Plans

Overall, it took me a month or so to do the original project, and maybe a month and a half to do this part. In retrospect, I should have expected that: the original project was mostly hooking up pieces that worked and chopping out things that didn’t, while this one was porting a good chunk of a moderately complicated project (the Swift runtime) without being able to use tests or a debugger. But I got some things out of it:

• A version of the Game ’by Color that runs on Mac OS 9. (Here’s the game I’ve been testing with.)

• An implementation of (some of) the Swift runtime, and more of the standard library, that runs on Mac OS 9. You can check this out in the ppc-swift-project repository. (The Game ’by Color sources are also available there.)

• A feature-flag-guarded version of the Swift standard library, which I plan to discuss on the actual Swift forums in case embedded developers are interested.

• A better understanding of the Swift runtime, which I hope to put in future blog posts.

I’ll finish off with a photo of the Game ’by Color running on an actual PowerPC Mac, once again courtesy of my friend Nadine:

1. The word “runtime” is a funny one these days. Originally it would have just meant “at the time when the program is run”, but these days it can also mean “a library that provides support for features that aren’t just compiled to plain machine code”. The simplest example of this is the automatic reference counting used by Swift classes; rather than directly manipulate reference count data in each object, the compiler emits calls to the swift_retain and swift_release functions. To keep these meanings clear, I tend to use “run-time” for the general “when the program is run” adjective, and “runtime” for the support library or things relating to it. ↩︎

2. Circular dependencies are normally not just a linking problem, but a conceptual problem: if something changes, what gets rebuilt? Does everything get rebuilt? Does everything cause everything to get rebuilt, resulting in building everything in a cycle forever?

   *cough*

   Anyway, in this case, there’s not really a circular dependency, even if we were using dynamic linking for everything, if you separate the interface and the implementation:

   1. Build Swift.swiftmodule (no dependencies)
   2. Build MacTypes.swiftmodule (depends on Swift.swiftmodule)
   3. Build _Runtime.dylib (depends on Swift.swiftmodule and MacTypes.swiftmodule)
   4. Build Swift.dylib (depends on Runtime.dylib)
   5. Build MacTypes.dylib (depends on Swift.dylib and Runtime.dylib)

   This logic only works because the runtime is optimized and doesn’t have any link-time dependencies on the standard library or overlays itself. Without that, this would still work, but it wouldn’t be completely clean. In practice, the runtime is always statically linked into the stdlib, even when the stdlib is a dylib, so the only thing that strictly has to be optimized out is the overlay usage.

   Does this mean it’s worth doing this for the real runtime? Probably not, at least not immediately. The real runtime is a lot more complicated and makes use of a number of C++ features, and a bunch of its logic is shared with the debugger. Trying to share logic across C++ and Swift would be pain, so it’d be hard to just write new code in Swift too. And detangling the build dependencies would be a pain. But maybe it’d be worth it to convert everything over, someday. ↩︎

3. This isn’t even all of it, because I #if‘d out a number of things in the standard library that I didn’t need once I saw they had runtime dependencies. ↩︎

4. There was a standard debugger distributed by Apple called MacsBug, but I could not get it to work in my emulator. ↩︎

5. I’m working from the master-next branch because I need IBM’s latest work on AIX; after the next LLVM rebranch, I’ll pin this project to Swift 5.3 or 5.4 or whatever and leave it there. ↩︎

If you are new to Mac, then the uses for the red, yellow and green window buttons at the top left corner of every Mac window may not be obvious. The red button closes the window. The yellow button minimizes the window, placing it in the Dock. The green button can either take the window into full screen mode, or maximize the window to its logical size.

Check out A Beginner’s Guide to the Red, Yellow and Green Window Buttons at YouTube for closed captioning and more options.

Video Transcript: If you're new to Mac you may be wondering about the exact functionality of the three colored buttons that appear at the top left corner of just about every window you'll ever see on the Mac. These are the red, yellow, and green buttons, sometimes referred to as the traffic light buttons. Sometimes the middle button is referred to as orange rather than yellow although official Apple documentation always calls it yellow. So, what do these do?Well, the first one is pretty obvious. It closes the window. Now modern applications automatically save the document when you close the window. So you can close a window at any time and it will just close. If you're working on an older document and you've made some changes since the last time you saved you may be prompted to save the document before it closes. Some apps, where there's just one big window and it's all the app has, if you close it the entire app actually quits. Now let's skip over to the green button. The green button does two different things. One thing it does is to take the app full screen. As a matter of fact take that particular window full screen. So I will click on it and you will see now it's full screen. Everything else is gone except this one window in this app. If I want to get the menu bar back, or even those colored buttons, just move the cursor to the top of the screen. You can see the menu bar comes back, the tool bar comes back, and there are those buttons with a green button there that changes a little bit to indicate that I can click to go back to the way it was before. Now when you go full screen you can actually use Control up arrow to see what you've got in terms of things full screen. I've got the desktop, which is what I was working before, and a screen called Pages and I can jump to either one. So I can go back to the desktop there. I can also use Control right arrow and left arrow to go back and forth between them. So, of course, to get out of this and exit full screen, I press the green button again. You can also use the green button with the Option key held down. What that does is it will change to a plus + symbol and I click on it and enlarges the window. Now it doesn't enlarge it to fill the screen. It enlarges it to fill the screen as much as it needs so everything fits in place. So here in this Pages document if I expand the window a bit you can see I've got these margins here on the left and right side of the page. There's nothing in those margins. So it won't expand the window to the point where I need that space. You'll see I'll do it again. Option and click the green button and it collapses it instead of expands it. So now if I were to go and zoom in where the document is 300%, now if I click plus you can see it expands it to fill all the space because the document itself, the margins, are off to the left or right. I can zoom out and you can see now, now I've got that extra space there. So basically it's a logical kind of function. It will expand the window as much as it needs but not more than it needs. Now Option and clicking a second time will return the window to the size you had it before. So if you had it this size, Option, click green enlarges it. Option click green returns it to the size you had. So you can toggle back and forth.Now what about the yellow button. Well, the yellow button minimizes the window or puts it in the Dock is what it really does. So you can see a list of windows here in the Dock and I can click to bring it back. Get rid of it. It's just a handy way to get a window out of the way and then be able to bring it back pretty easily.Now what happens if you have more than one window. Let's have two windows open here in Pages. I can use the Option key and it will affect all windows. So you can see both windows went there into the Dock when I held down the Option key and clicked the yellow button. If I didn't hold down the Option key only one goes in. It's the same thing for, say, close. If I were to hold down the Option key both windows close instead of just the one window.