Alonzo Church löste problemet 1936 – svaret är nej. 1937 kom Alan Turing självständigt fram till samma svar med en annorlunda metod, och den lösningen är mest känd. För att formalisera algoritmbegreppet introducerade han en teoretisk “maskin”, Turing­maskinen, som kan manipulera symboler på en remsa enligt en uppsättning regler.

Praktiska datorer är inspirerade av Turing­maskinen, och har stora likheter med den. Bland annat kan de beräkna samma saker, och de har också samma komplexitets­begränsningar: förhållandet mellan storleken på ett problem och den mängd tid och minne det tar att lösa följer samma mönster. (Principiellt gäller samma begränsningar också för människor under optimala förhållanden, det vill säga att de räknar rätt och i fast takt.)

Ett problem anses vara “hanterligt” om det kan lösas inom en tid som beskrivs av ett polynom i problems storlek, eller mindre (t.ex. n² mikrosekunder för att lösa ett beräkning med n poster). Dessa problem sägs tillhöra komplexitets­klassen P (”polynomial time”).

Turing­maskinen anses kunna beräkna alla funktioner som kan beräknas “effektivt”, vilket dock inte är bevisbart. Ett sätt att försöka motbevisa det är att luckra upp begränsningar i Turing­maskinens definition, där den mest uppenbara är att den är deterministisk, alltså alltid gör samma sak i varje givet tillstånd. Frågan är: om man låter den välja slump­mässigt mellan olika regler, kan den då lösa problem som en deterministisk Turing­maskin (DTM) inte kan? Med andra ord, kan den få fram ett korrekt svar på ändlig tid som en deterministisk aldrig kan nå, om man antar att den vid varje tillfälle väljer “rätt”?

(Gammalt datavetar­skämt – man kan sortera en lista i linjär tid enligt följande: välj en ordning slumpmässigt efter en kvant-slumpkälla. Om listan är oordnad, förstör universum. Om flervärlds­tolkningen stämmer har du rätt ordning i de världar som är kvar, annars finns det ingen kvar som kan klaga.)

Svaret på detta är nej; en ickedeterministisk Turing­maskin (NTM) är inte mer generell än en deterministisk, eftersom en NTM kan simuleras av en DTM. Däremot förefaller den vara snabbare: det finns problem som har polynomtids­lösningar på en NTM men ingen känd för DTM. Problem som kan lösas i polynomtid på en NTM tillhör komplexitets­klassen NP (”nondeterministic polynomial time”).

Alla problem i P tillhör också NP, men man vet inte om motsatsen gäller. Man skulle kunna bevisa att de är lika genom att lösa ett så kallat NP-fullständigt problem i polynomtid. Ett problem K är NP-fullständigt om man kan bevisa att alla problem i NP kan omformuleras till K.

Exempel på NP-fullständiga problem:

• Handelsresandeproblemet: givet en uppsättning städer och vägar, hitta den kortaste rutten som besöker varje stad och slutar vid startpunkten. Uppenbara tillämpningar på logistik, men också mycket annat som programmering av industrirobotar.
• Kappsäcksproblemet (med varianter): givet en uppsättning saker med olika volym och värde, välj ut den värdefullaste kombinationen som kan packas i en viss behållare. Viktigt för handelsresande, men också för schemaläggning och andra typer av planering.
• Primtalsfaktorisering: givet ett stort tal x, hitta två primtal vars produkt är x. Grunden för de flesta kryptografiska system, eftersom det är väldigt lätt att bekräfta en korrekt lösning.
• Diverse problem inom molkylärbiologi, till exempel multipel linjering/inpassning.

Den som löser ett NP-fullständigt problem har således en lysande karriär framför sig i speditionsbranschen. Dessutom väntar ett startkapital på en miljon dollar i form av Millenniepriset.

Due to changes in the Minecraft forum you can now only read the original thread if you’re logged in, and the formatting is messed up, so I’m reposting it here.

By functionally identical, I mean that my ALU has the same instruction set as theinternetftw’s – the Hack instruction set developed for the book The Elements of Computing Systems. I haven’t read the book, but there’s enough information available online to implement the ALU and most other components.

I didn’t copy any part of theinternetftw’s implementation, but I did use pre-existing XNOR gates and adders as noted in the text.

Minecraft is a moving target, but the ALU still works perfectly (and performs much better). If I built it today, I’d consider using repeaters for the data and control busses, but probably stick with torches because repeaters still aren’t implemented in Redstone Simulator. (Repeaters are simpler, and also give you a signal speed of 18 blocks per cycle if you use them well. Torches can do 17, but only 16 in tightly packed parallel busses.)

Some references:

• The preface to the book
• Slides on the Hack architecture (which I found after the initial implementation, but they helped clear some things up).

Original posts follow. They’re largely unedited, so they reflect the evolution of the ALU.

Imitating Greateness: 16-bit Hack ALU Design
29 October 2010 – 16:06 (UTC+1)

Like one or two other people, I saw theinternetftw’s ALU video (and the sequel). I also wondered how it worked, or rather, how one might go around designing such a thing.

A few days later I bought Minecraft and started playing.

Today, I implemented what I believe is a functionally identical ALU in MCRedstoneSim. I shall now proceed to describe it in agonizing detail. Schematic files will be provided.

Some caveats:

• I haven’t built any part of it in-game.
• I haven’t attempted to analyze theinternetftw’s design, and I haven’t read The Elements of Computing Systems. My design is based on the control bits shown in the first video and an understanding of how they’d be used in programming.
• I don’t claim to be a redstone wizard. Most of the components are based on designs from the forum and wiki. The original parts can probably be improved.
• I haven’t included the data busses, which account for a lot of bulk in theinternetftw’s design.
• The “output is zero” flag is not implemented. This is just a NOR of all the output bits, though.

The design took about six and a half hours. The result takes up 32 × 119 × 9 blocks (sixteen 6 + 1 × 27 × 5 logic elements, control busses and some interface), and uses 2237 wires and 687 torches.

Specification

The ALU takes two sixteen-bit inputs (X and Y) and six control bits, and produces a sixteen-bit output (OUT) plus an overflow flag. The control bits are:

• ZX: if 1, treat X as all-zeros.
• NX: if 1, invert X (that is, flip all bits). Applied after ZX, so if both are set X is treated as all ones. The result of applying ZX and NX to X is referred to as X'.
• ZY: like ZX, but for the Y input.
• NY: guess.
• F (function): if 0, the preliminary output O' is the bitwise AND of X' and Y'. If 1, O' is the low sixteen bits of the sum of X' and Y'. The seventeenth bit is the overflow flag, FO.
• NO: if 0, the output OUT is equal to O'. If 1, OUT is the bitwise inverse of O'.

Currently, FO is not affected by NO, and is meaningless of F is 0.

High-level design

The design consists of sixteen identical logic elements, which each takes two input bits X_n and Y_n, an input carry bit CI_n for ripple-carry adding, and the six control bits on perpendicular buses. Each element produces an output bit O_n and an output carry bit CO_n. Getting the bits in and out of the ALU is beyond the scope of this project; I’m just using levers and trailing wires.

Input filters

The first thing the logic element needs to do is apply the ZX, NX, ZY and NY flags to the input. This requires two functionally identical circuits I call input filters.

The obvious way to implement this would be (X ∧ ¬ZX) ⊻ NX. However, an equivalent option with lower latency is (¬X ∨ ZX) = NX.

The wiki has several XNOR gates. I chose variant C for its compact design, low latency and narrow profile. By running the output across the top of the gate and the X input into an inverter attached to the side, the input filter including its three inputs is three wide and has a three-tick latency.

Here’s a model input filter. X is on the left, and the top two levers are ZX and NX in order.

Schematic file

I initially placed the two filters directly opposite each other, but I ended up staggering them by two blocks to be able to fit the four control bit inputs between them in a two-block space. The ZX and NX busses will run on bridges and connect to the north filter, while ZY and NY run in tunnels and connect to the south filter. ZY is provided by a torch immediately under the protruding wired block, while the others run on stairs. The buses and their controls are included in the schematic file but left out of the image for clarity.

Full schematic file (Control bits in order: ZX, NX, ZY, NY)

Operations

The input filters produce the values X' and Y'. The next step is to add these and AND them. We’ll select the appropriate value based on the F flag later.

The adder is vandrien’s 5 × 7 × 3 design with no modifications. (This is the niftiest part of the entire design – if I had to design my own adder the ALU would be twice as big and significantly slower. Thanks, vandrien!) The Y' line is rerouted slightly. The switch at the top is CI, and the dangling wire at the bottom is CO.

I originally had a separate NAND gate on top of the adder. While decomposing the design from this writeup, I noticed that the X' wire wasn’t connected, but it was working anyway. Turns out I was accidentally extracting an AND from the adder and then NANDing that with Y'. The revised design just uses the AND from the adder directly. The source is either of the two opposing torches on the input side of layer 2 of the adder.

Full schematic file

Output muxer

The next step is to select the appropriate preliminary output, O'. This requires a selector (muxer) circuit which takes three inputs, A, B and S, and outputs A if S is 1 and B if S is 0 – that is, (A ∧ S) ∨ (B ∧ ¬S). Here, S is in the middle to avoid crossing anything. (It will be routed through a tunnel.)

Schematic file

Plugged in:

Full schematic file (Control bits: ZX, NX, ZY, NY, F)

Output filter

The output filter is much like the input filter, but without a zero flag. It consists of an XNOR gate (wiki type C again) which takes O' from the muxer and ¬NO from a tunnelled bus.

Full schematic file (Control bits: ZX, NX, ZY, NY, F, NO)

And there you have it: a one-bit ALU. Here’s a block diagram:

The complete sixteen-bit version consists of sixteen of these side by side, with their carry flags chained together (low-order bit at the top, high-order bit at the bottom). I’ll spare you the details of working out the control bus wiring and stuff. The final design consists of eight identical two-element modules, with one set of bus repeaters per module, so the bus latency averages one tick per bit. Here it is, calculating its own redstone cost (2237 + 687 = 2924, or 1000 1011 1101 + 0010 1010 1111 = 1011 0110 1100):

Full schematic file

Future directions

• The output muxer could probably be made smaller. It’s pretty much the first design that came to mind.
• It looks like I could shave off two columns of length, one on each side of the op logic block. The output muxer would need to be flipped over, and the control bit bus negated.
• The input filter section is seven wide (including insulation), while the other blocks are six. I think it’s possible to make the input filter section one block narrower by flipping the filters so the control inputs are on the outside, and sharing the inputs between adjacent elements. The input order would then alternate (the first element would have X₀ on top and Y₀ on the bottom, and the second would have Y₁ on top and X₁ on the bottom).
• Performance profiling. An add should take about 40 ticks, but I haven’t timed it.
• Carry look-ahead adder for moar faster. By which I mean “slightly less slow.”
• Other computer components: program counter, I/O controller, RAM, ROM. I probably won’t bother with all of them.

FAQ

• What’s the point?
  I don’t understand the question.
  Seriously, if you’re going to ask what the point is of doing something for fun in a game, why are you even on this forum?

Improved input filter
30 October 2010 – 20:26

Improved input filter (and control bus) design, as outlined in first post.

The input filters now have the control inputs outwards, with one space between them, allowing the entire element to be one block narrower. The staggering is also removed, saving two blocks of length, with the control bus zig-zagging instead. Control inputs are torches (for isolation) on top of one torch in the appropriate bus repeater. The busses are negated.

This arrangement increases control bit latency. Wiring the low-order bit’s input differently could eliminate this delay for the add operation.

Since control bits are shared between adjacent input filters in different cells, the input bit order alternates: X₀, Y₀, Y₁, X₁, X₂, Y₂, Y₃, X₃. This will be rather inconvenient to use directly, but can be hidden by appropriate input bus wiring. The control bit order has also changed, to ZX, ZY, NX, NY.

The outputs adder stage will be moved up and back three steps, eliminating the staircase.

I’m not sure what I’m going to do about the output side yet.

Schematic file

Improved output muxer
30 October 2010 – 20:11

Flipping the output muxer over and smashing it into the side of the adder worked out nicely, saving two columns. The select input (circled) is again fed by the NO bus repeater. The bus itself runs at ground level.

Schematic file (four bits wide)

The output negator XNOR can then be stuck right on the end of that, one step below, with no wiring gap. The control input is tunnelled, and connected to the circled block using two vertical torches. (The extra latency is not a problem, since the data has to go through all the previous blocks first.)

In-game prototype
31 October 2010 – 01:56

While waiting for the update server to come back to life, I built a one-bit element in-game.

Totally legit! Many sheep were seriously annoyed in the making of this device. (Wooden parts are control lines, wool is the structure of the logic element, stone is support structure, access ladders and so forth.)

Here’s the full sixteen-bit schematic, again set to calculate its own component cost (including control interface): 1858 wires (0111 0100 0010) + 748 torches (0010 1110 1100) = 2606 redstone (1010 0010 1110). The 61 extra torches are the vertical-stack control line connections and input inverters, and the 379 fewer wires are space savings and simpler control busses.

The schematic is 26 × 104 × 12; 7 columns and 7 rows are interface, and 4 layers are control busses. The logic is 19 × (5 × 16 + 17 = 97) × 8.

Load immediate and control & output busses
31 October 2010 – 04:42

In addition to the ALU instructions, the Hack architecture has only one more instruction, the @ instruction (or, more traditionally, “load immediate”). This loads a fifteen-bit value into register A. This can be integrated into the ALU by simply whacking another muxer on the end. This muxer takes the ALU output and the corresponding instruction bit (always zero for the high-order bit) as inputs, and the relevant control bit as the selector input.

Rather than add another switch to each element, I added a complete instruction bus. This can take either an @ instruction or an ALU instruction. Both use very simple encodings, so the decoder just has to run wires to the right control inputs. The instruction codings are as follows:

@ instruction:
0DDD DDDD DDDD DDDD

• ALU: Copy the instruction word to the output bus.
• Output controller: write ALU output to register A.
• Program counter: increment unconditionally.

Logic instruction:
111A CCCC CCDD DJJJ
The bits in each field are numbered from left (high-order) to right, so C₁ is adjacent to A and C₆ is adjacent to D₁.

• ALU: Set ZX to C₁, NX to C₂, ZY to C₃, NY to C₄, F to C₅, and NO to C₆.
• Input controller: if A is 0, set Y to register A. Otherwise, set Y to the contents of memory at the address specified by register A (referred to as RAM[A] or M). (X is always set to register D).
• Output controller: if D₁, write to register A. If D₂, write to register D. If D₃, write to RAM[A] (presumably the value of A before updating it). Any combination is valid.
• Program counter: given condition bits NG (the high bit of the ALU output) and ZR (the NOR of all the output bits), jump to ROM[A] if (J₁ ∧ NG) ∨ (J₂ ∧ ZR) ∨ (J₃ ∧ (NG ⊽ ZR)), otherwise to the next instruction (dur). All combinations of J bits are valid.

(Note: RAM and ROM addresses are word addresses, or to put it differently, both the word size and the byte size is 16 bits.)

Here’s the instruction “DM=D+A” entered into the input bus (top right, levels 6–7):

The bits are in reverse order for routing reasons. (If you were standing in front of it facing south, it would be the right way around.) The three bits on the right are the logic instruction prefix (currently only the top bit matters, but the other two could be used for new instructions). The colour-coded ones are the control bits for logic ops; from right to left, ZX, NX, ZY, NY, F and NO. Destination bits D₂ and D₃ are set, but of course do nothing since there’s no output controller, and the condition bits are clear for no jump.

The logic element outputs are now in the middle of the schematic, so I added an output bus too (ending top right, layers 13-14). Here it is showing the value 5285 (0001 0100 1010 0101), once again backwards.

Schematic, set to calculate its own component cost in accordance with ancient tradition: 4232 wires (0001 0000 1000 1000) + 1053 torches (0000 0100 0001 1101) = 5285 redstone (0001 0100 1010 0101).

Design note: seven of the input bits are essentially duplicated in the control bit busses. This could be avoided, but the @ instruction would be slower, and it’s not clear that the recovered space could be used for anything since it’s underneath the output bus. I’ll revisit this if/when the other components are designed.

Input busses
31 October 2010 – 08:54

…and the logical next step is wiring the input busses. Nothing very interesting about them.

Schematic, set up to calculate 6357 (0001 1000 1101 0101) + 1177 (0000 0100 1001 1001) = 7534 (0001 1101 0110 1110).

ROM idea
7 November 2010 – 19:53

I haven’t done anything interesting (of relevance) this weekend, so here’s something boring instead: ROM. This will store the program, so the more you can fit in the available space the more the computer can do.

This is the cleverest ROM design I’ve been able to come up with, but it might not be the smartest – I suspect a less compressed design may end up taking less space when you consider stacking and control interfaces. I need to build several layers of each type, with output busses, to test this.

Schematic file

Each 1 bit is represented by a torch, and each zero bit (none in the schematic) by the absence of a torch. When the select line is off, the torches are powered and thus zero.

Half the bits feed into a bus above the module, and the other half a bus below the module. Feeding both into a compact bus above the module is possible, but requires more space and introduces delays.

I tried to come up with a way to avoid the parallel select line and space, but failed.

This module can be tiled in two dimensions without any space between copies. Repeater banks are required every three modules in the east/west direction. In the north/south direction, the two output busses are uninterrupted between words, so it’s easy to interpret the ROM as 8-bit or 32-bit elements just by putting a different output bus muxer on the end.

Here’s an eight-word matrix with output bus:

Schematic file

The rows are selected by putting a torch under a negated section of each row bus to force it to zero when not selected. The rows are then fed into the (positive) bus using the same technique. Note that there are currently two levers for each row, one for the low half-bus and one for the high, and these levers are negated while the column select levers are positive.

ALU download and exploded diagram
31 October 2010 – 21:31

I present, for your supremely geeky enjoyment, the ALU saved game.

Download

(The ALU is not well lit. I strongly recommend setting the game to peaceful before loading.)

In the middle is the ALU, essentially per the schematic above. However, I’ve aded some lights, walkways and signs, and improved the interfaces (except the instruction input, because I got bored). The low-order ALU channel is colour-coded and signposted.

To the right in the picture is a prototype input interface with feedback lights. It’s too bulky to integrate easily, but lifting all the lines off the top of a minimum-width bus was fun.

To the left is an “exploded” ALU channel. It implements the same logic as the ones in the full ALU, but is divided into distinct gates. The individual gates are mostly different from the ones in the real ALU, but they interact in the same way. It’s also colour-coded in the same way as the low-order “real” channel.

Section 1: input filters

The first section consists of the two input filters, the X input filter (right in diagram, diamond on map) and the Y input filter (gold). The main gate in each input filter is an XNOR gate (here wiki type A). The X input filter compares the NX control bit – lower right side input in diagram – with (NOT X OR ZX). If both NX and ZX are zero, the output on the X side will be X. If NX is set, it will be ¬X. If ZX is set, it will be 0, and if both ZX and NX are set, it will be 1.

For simplicity, I’ll refer to the filtered outputs as X and Y below, but this is misleading if any of the NX/NY/ZX/ZY control bits are set.

Logic:
X′ = (¬X ⋁ ZX) ↔ NX
Y′ = (¬Y ⋁ ZY) ↔ NY

Section 2: core functions

The second section is a full adder (made out of clay on the map). It consists of two almost identical modules, which are called half-adders. A half-adder takes two input bits, and produces a two-bit output ranging from 0 to 2. The possible combinations are:

Note that the low bit of the output is equal to X XOR Y, and the high bit is X AND Y. The half-adder used here, which is identical to the second one in the “real” ALU, is similar to wiki XOR gate A, but rearranged so an internal NAND value can be pulled out (and inverted) on either side.

A half-adder is sufficient for a one-bit computer, but to add multiple bits we need to be able to take a carry input and add it to the sum. This is done with a second half-adder which takes the low bit of the first one as one input, and the incoming carry bit from the previous ALU channel as the other input. (This is called ripple-carry adding. There are faster approaches, but they take more space.)

The carry output is the OR of the two half-adders’ carry outputs. This value and the output of the second adder form a two-bit number which is the sum of the three inputs X, Y and CI:

The ALU has two core functions, ADD and AND. The AND (denoted A below) is acquired by a bridge (brick) from the second AND output of the first half-adder, along the right hand side of the diagram. The ADD value is denoted S, for “sum”.

Logic:
S = X′ ⊻ Y′ ⊻ Ci
CO = (X′ ⋀ Y′) ⋁ ((X′ ⊻ Y′) ⋀ CI)
A = X′ ⋀ Y′

Section 3: function muxer

The third section (obsidian) selects one of the two functions, based on the F control bit. If F is set, the ADD function is selected. Otherwise, the AND function is selected. In logic terms, that’s (F AND S) OR ((NOT F) AND A), here implemented as two basic ANDs, a NOT and a bridge.

Logic:
O′ = (F ⋀ S) ⋁ (¬F ⋀ A)

Section 4: output filter

The output filter (iron) inverts the output if the NO control bit is set. It’s a single XNOR gate like the ones in the input filter. Since the input isn’t inverted in this case, the NO bit is instead. This is equivalent to using an XOR gate, but is a bit more compact in redstone.

Logic:
O = O′ ↔ ¬NO = O′ ⊻ NO

Section 5: load immediate muxer

This isn’t included in the exploded channel. On the real ALU, it’s identical to the F mux, but one step down and made out of cossy mobblestone.

Using the full ALU

The instruction format is exactly the same as for theinternetftw’s CPU. However, mine doesn’t have any registers yet, so you’ll need to copy data from the output to the inputs. Since there’s no I/O, no clock is needed (beyond Minecraft’s update ticks); when the output bank stops changing, it’s finished calculating.

An optimization question
11 December 2010 – 16:27

CX gamer said:
Is it possible to apply pipelining to this, so the performance of multiple consecutive calculations can greatly be improved?

Probably not within the ALU itself. In a full CPU, you could use instruction prefetching (possibly with prediction of unconditional branches) and start issuing the next instruction slightly before the IO parts of the current one are processed, at least if there’s no memory read in the next instruction. Other obvious optimizations would be a one-word RAM cache, possibly with a second word of write buffer, and tight timing of the various dispatch stages. But in terms of actually being able to do anything, the main focus has to be keeping it small, so you can fit as much RAM as possible.

All high-level CPU optimizations, like pipelining, better algorithms and more powerful high-level instructions (like multiplication) are based on using more CPU die area to do stuff in smarter ways. Since Minecraft space isn’t subject to Moore’s law, we can’t really expect to see much of that sort of improvement in Minecraft computing, although if Notch adds SSI components (like one-block logic gates and latches) things could get interesting.

(Actually, there is one major space saving that can be done now: stacking the ALU and bus channels vertically. Avus, above, had the right idea, although the size of each channel eats up most of the optimization.)

My position on convenience is this:

• Good user experience is the convenience of not having to use a difficult and dangerous hand crank to start your car.
• The Mac App Store is the convenience of having McDonald’s open in your apartment building.

Of course, everyone is free not to eat at McDonald’s exclusively, or even at all. But this is beside the point. The vast majority will appreciate the convenience, and grow accustomed to it. Soon, the idea of looking elsewhere for food will seem odd. The more adventurous will consider, perhaps, an occasional excursion to the nearby Burger King of Steam or other big brands, but the existence of more obscure alternatives will be little more than a strange piece of trivia. The McDonald’s in your apartment building will have a de facto captive audience.

The captive audience will have little grasp of what the limitations on their diet are, or whether the new baconburger of the week represents the true leading edge of hamburger innovation. They will have no idea whether the prices they are paying are fair, since there will be no market to compare with. If they want organic wholemeal buns with walnuts in, they’re out of luck, because their McDonald’s is doing fine selling the normal kind.

In short, with an effective monopoly on distribution, innovations that reach outside the box of the App Store agreement will not reach users, and there will be no incentive for Apple to cooperate in expanding the box.

I’m not a free market fundamentalist, but I will only approve of a monopoly if there is good reason to believe it will benefit consumers or the population at large in the long term. The App Store doesn’t come close. (Apple’s policy of rejecting apps that are “too similar” to ones already in the store ensure a true free market cannot develop within the store either.)

In the case of the iPad, my requirement as a potential customer has been a side-loading option of some sort, despite the knowledge that it would be very hard to be competitive outside the App Store. It is fundamental that I, as the owner of my hardware, can decide whether I want to install whatever software exists.

But for the Mac, coming at this distasteful compromise situation from the other direction is unacceptable. If the App Store succeeds – and it will, once the stupidity of the distribution agreement is reduced by the smallest possible amount – my next computer will not be a Mac. I will abide inferior, noisy hardware running inferior, noisome software before I abide a cage, be it ever so shiny.

For the record: no, I’ve never owned a game console.

However, it’s limited to a fixed set of types. As Vincent points out, this could be avoided by parsing the @encode() string rather than recognising specific strings. As it happens, I had a partially working parser. It is now wholly working and added a convenience macro similar to Vicent’s, and you can find it here. It handles most structs, unions and arrays automatically. It’s still not entirely general, though, in part because of compiler limitations:

• Bitfields aren’t supported. This is basically because I haven’t bothered. I’m not clear on whether the encoding actually provides enough information to handle these properly, though.
• Altivec and SSE vector types aren’t handled, because @encode() completely ignores them – if you have a struct { int a; __m128 v; int b; }, the encoding is {?=ii}, as if the vector wasn’t even there.
• Aggregate types with non-standard alignment (#pragma pack) are not supported. Again, the compiler doesn’t encode the necessary information.

The latter two cases could easily lead to crashes if left to their own devices. My solution is to first parse the entire type without reading any data, to ensure that the amount of data the parser will consume matches the size according to sizeof(), then reparse if the size matches.

There are probably cases it doesn’t handle. Bug reports would be welcome. Also, it doesn’t handle PPC-64 and ARM, because I don’t have suitable machines to extract alignment information on and I can’t be bothered to read actual documentation.

Update (2010-08-22): Added support for _Complex types (encoded as 'j'; a complex double is encoded as jd and stored the obvious way, as two doubles in a row).

Update (2010-08-23): Fixed alignment calculations for nested structs when alignment is not determined by first member.

███ ██ ███ ████ ██, ██████ ███████ ███. ██ █ ███ ███. ████ ███ ███, █ █████ ███. ████ █ ██ █ ███ ███ ██ ██ ██. ██ ███ ██ ███ █ █████. ███ ████ ███ ██, ██ ████ ███ ███ FRA ████. ███ ████ █████ ██, █ ███ ██ ███ █. █████ ███ ██ ██ ███ ███ █ ████ ██ ███. ███ █ ██ ███, █ ███ ██. ██ ███ ████ ███. ███ ██████ ███ ██, ██ ███ █ ███ ██.

████ █████ ███ ███. ██ █ █, ███ █ ██ ███ █, ███ █ ██. ████ ██████ ██ █ ███ ███ ███████. ███ █ ██ ██ ██ ████ ███ █ █ ██. ████ ██████, ██ █████ ███ ████, █ ██ ████ ██, █ ██████ ██ ███ █ ██. ██ ████ █████ ██ █ █████. ███ ███ ██ █ ██, ██████ █████ █. ███ ██ ████ ██. ██ ████ ███ ███. ████ █ ████ ██. █ ███ ████ ███, █ ██ ██████ █ ███ ████. ███ █ ██ ██ ██ ███ ████ █ ██ ███. ███ ████ ██ ███ ███ ████ ████. ██ ██ ██ █ ███ ████ ███.

███ █ ███ █. ████ ██ ███ █ ███ ███ ███ █ █ ██. ██ ████ █████ ████. ██ ███ ██ ██ ██ ████ ██ █████ ███ ███. ███ ██ ██, ███ █ ██ █, █████ ██ ███. ██ ███ ██ ████ ███ ████ █ ███ ██ █████. ██ █ ██ █ ██ ███ ████. ███ ██ ██████ ██, █ ████ ███ ███ ██. █████ ████, ██ █ ████ ████, ███ ██ █████ ██, █ █████ ███ ███ █ ██. ███ ██ ██, ███ ████ ████ █, ███ ██ ███. █ █ █████ ███. ████ ████ █████ ███ ██ ████. █████ ██ ███ ███ █ ████ ██ ███ █ ███ ████ ███ ███; █████ █████, ██ ██ ████ █████, ███ ██ █████ █ FRA █ ██ ████ ███ ██ ██ ███. ██ █ ██ ██. ██ █ ████ ███. ██ ██ █, █████ █ █████ █ ██, ████ ██ ███. ██ ███. ███ █ ██ ███, █ ████ ██.

█████ █ ██ ██ ██ ███ █████. ██ ████ ███████ ███ █ ████. ███ ███ ██ █ ██ █████ ██ ████ ██ ████. ██████ ████ ███ ██ ██ ██. ██ █ █████ ██. ██ █████ ████ ███. ███ ████ █████ ██, █ ████ ███ ███ █. ██ █████ ████ ██ ██ █████. ██ ██████, █ █ █████ ███, ██ ██ █████ ██, ██ ████ ███ █ █ ██ █. ██ ██ ██, ████ ██ ███ █ ██, █████ █ ███. ██ ████, ██ █ ██████ ███, █ ██ ████ ███, █████ ███ ███ ██ █████ ██. ██ █ ███ █ ██ ███ ████. ██ ███ ███, ████ █ FRA ███ ██, █████ █ ██. ███ ████ ████ ██ █ ████. ████ ██ ███ ██, ██ ████ ██. ██████ ████ ███ ██ ██ ████. ██ █████ ███ ████.

I don’t think my random musings have much influence on the design of the language, but if I don’t write it down nobody’s going to know how nuts I am, so here’s a semi-concrete proposal for contextual types and generics for Objective-C. Since anyone even mentioning generics in the vicinity of Objective-C will inevitably be flamed for trying to turn it into C++, this is followed by an aside entitled Why This is Not the Baby-eating Spawn of Bjarne Stroustrup. (Nothing personal, Bjarne.)

Types in Objective-C

A fundamental characteristic of Objective-C is that it has two separate type systems: the dynamic type system, which applies to objects, and the static type system, which applies to variables (which may or may not refer to objects).

As far as objects are concerned, the static type system is optional — you can refer to any object with the type id, except when calling a method whose type may be ambiguous. The static type system is also advisory — it suggests to programmers, the compiler and other tools such as the IDE and analyzer what the class of an object may be at runtime, but doesn’t constrain the object. A variable of type NSString * may actually refer to an NSArray at runtime, and method calls will dynamically go to NSArray’s implementation.

My proposal deals only with the static type system. The idea is to provide information that helps the compiler and analyzer check your logic, and the IDE to provide better suggestions. This is done by replacing id with more specific static types in most of the situations it’s used in. The generated code is not affected in any way. The proposal does not introduce bondage and discipline on the language; the new types can always be cast away.

Contextual Types

By far the most common use of id is as the return type for methods that may return an instance of “this” class, or of the subclass it’s called on. The obvious examples are +alloc and -init.

The IDE and, I believe, the analyzer already use heuristics to determine the return type of +alloc and -init, but I propose formalizing this in code. It would look something like this:

@interface NSObject <NSObject>
{
    Class   isa;
}

+ (void)load;

+ (void) initialize;
- ([:Self]) init;

+ ([:Self]) new;
+ ([:Self]) allocWithZone:(NSZone *)zone;
+ ([:Self]) alloc;

// ...

+ ([:Superclass]) superclass;
+ ([:Class]) class;
- ([:Superclass]) superclass;
- ([:Class]) class;

@end

When calling a class method, [:Class] resolves to the receiver (or, type-equivalently, a pointer to an instance the receiver’s metaclass), and [:Self] resolves to a pointer to an instance of the receiver. [:Superclass] resolves to the superclass of the receiver. For instances, they resolve as for class methods on the class of the instance.

I’m sure some people will object to the conceptual purity of this design, and possibly the names and syntax. The colon is a bit odd — it’s there to avoid ambiguity with generics (see below). All of these are minor quibbles; the syntax would need to be reviewed if actually implementing it.

So what’s the point? Consider the following code:

NSString *s = [[NSArray alloc] init];

As it stands, this is perfectly valid and doesn’t generate a compiler diagnostic. With the addition of contextual types it would, because:

• The type of +[NSArray alloc] (inherited from NSObject) is [:Self], which resolves to NSArray *.
• The receiver of the -init is thus known to be an NSArray.
• The type of -[NSArray init] (inherited from NSObject) is [:Self], which again resolves to NSArray *.
• Therefore, the right hand side of the assignment is of type NSArray *, and the assignment is invalid.

If, for some reason, you really wanted to do that, you could use an explicit cast to get rid of the diagnostic.

Generics

The other major use of id is for polymorphic collections. True polymorphic collections are great! But some of the time, you only want to put one kind of object in your collection, and would appreciate the computer doing the drudge work of checking that you didn’t put the wrong stuff in the wrong place.

From the perspective of the previous section, generics are a simple extension to contextual types. Instead of restricting you to [:Self] and the highly specialized [:Class] and [:Superclass], you can provide one or more class names as a parameter to a type declaration. Example time again:

@interface MyThingHolder[ThingType = id] : NSObject
{
    [ThingType]     thing;
}

- ([:Self]) initWithThing:([ThingType])thing;

- (void) setThing:([ThingType])thing;
- ([ThingType]) thing;

// Or, for modernists:
@property (readonly, nonatomic) [ThingType] thing;

@end

// ...
MyThingHolder[NSString] *holder = [[MyThingHolder[NSString] alloc] initWithThing:@"foo"];
holder.thing = [NSNumber numberWithBool:MAYBE];      // Warning: type mismatch
holder.thing = (id)[NSNumber numberWithBool:MAYBE];  // OK. (an issue here would be inconsistent with general Objective-C behaviour.)

// Or, equivalently:
typedef MyThingHolder[NSString] MyStringHolder;
MyStringHolder *holder = [[MyStringHolder alloc] initWithThing:@"foo"];

Some notes: the type parameter can only be a class, since specialized code is not generated for each type. (See Why This is Not the Baby-eating Spawn of Bjarne Stroustrup below.) Since the type parameter is always a class, I have made the * implicit. This is cleaner, but could well lead to confusion and is quite likely a bad idea. (If only I had a time machine…)

The type parameter has a default value, previously unheard of in Objective-C, so that you can ignore generics and create a “vanilla” MyThingHolder that works just like in traditional Objective-C. This provides an upgrade path for existing classes:

@interface NSArray[Item <NSObject> = id <NSObject>] : NSObject <NSCopying, NSMutableCopying, NSCoding, NSFastEnumeration>

- (NSUInteger) count;
- ([Item]) objectAtIndex:(NSUInteger)index;

@end

@interface NSArray[Item] (NSExtendedArray)

- (NSArray[Item] *) arrayByAddingObject:([Item])anObject;
- (NSArray[Item] *) arrayByAddingObjectsFromArray:(NSArray[Item] *)otherArray;
// ...
- (BOOL)containsObject:([Item])anObject;
// ...
+ ([:Self[Item]]) arrayWithObject:([Item])anObject;
// ...


@interface NSDictionary[Key <NSCopying, NSObject> = id <NSCopying, NSObject>, Value <NSObject> = id <NSObject>] : NSObject <NSCopying, NSMutableCopying, NSCoding, NSFastEnumeration>

- (NSUInteger) count;
- ([Value]) objectForKey:([Key])aKey;
- (NSEnumerator[Key] *)keyEnumerator;

@end

@interface NSDictionary[Key, Value] (NSExtendedDictionary)

- (NSArray[Key] *) allKeys;
- (NSArray[Key] *) allKeysForObject:([Value])anObject;
- (NSArray[Value] *) allValues;
// ...
- (BOOL) isEqualToDictionary:(NSDictionary[Key, Value] *)otherDictionary;
- (NSEnumerator[Value] *) objectEnumerator;
- (NSArray[Value] *) objectsForKeys:(NSArray[Key] *)keys notFoundMarker:([Value])marker;
// ...
- (void) getObjects:([Value] *)objects andKeys:([Key] *)keys;
// ...

These examples introduce an additional concept: restrictions on type parameters, in this case protocol requirements. The other obvious type of restriction would be a superclass requirement, such as [Type: NSString = NSString].

Using these genericized versions in the same manner as the existing versions would require no code changes – as long as you’re using them with objects that fulfil the protocol requirements, which already exist but aren’t explicit in code.

Type Conformance

A fundamental question for static type systems with inheritance is when implicit casts are allowed. There are subtleties here, some of which I probably haven’t considered, and I have a feeling I’ve considered some and then forgotten about them. The most obvious case is when the base type and each type parameter could be validly cast:

NSMutableArray[NSMutableString] *a = whatever;
NSMutableArray *b = a;            // OK, b is NSMutableArray[id <NSObject>]
NSMutableArray[NSString] *c = a;  // OK
a = b;                            // Not OK, implicit cast from NSMutableArray[NSString] to NSMutableArray[NSMutableString]
NSArray[NSMutableString] *d = a;  // OK
NSArray[NSString] *e = a;         // OK
id f = a;                         // OK

As indicated above, passing an id when a parameter type is expected is necessary for consistency with Objective-C in general:

NSMutableArray[NSString] *a = whatever;
[a addObject:[NSNumber numberWithInt:42]];      // Type mismatch, assuming +numberWithInt: is declared to return [:Self]
[a addObject:(id)[NSNumber numberWithInt:42]];  // OK

How about the case where a method returns an unadorned type?

@interface LegacyThing: NSObject
- (NSArray *) legacyListOfStrings;
@end

LegacyThing *l = whatever;
NSArray[NSString] *list = [l legacyListOfStrings];

In order to minimize the burden of adopting generic syntax, I’d suggest explicitly permitting this, with an optional warning. (The non-generic equivalent, assigning an id <NSObject> to an NSString *, generates the somewhat unexpected warning “type ‘id <NSObject>’ does not conform to the ‘NSCopying’ protocol” in GCC and nothing in Clang. Assigning an NSObject * to an NSString * generates warnings in both. My proposal is that assigning a T to a T[P] should work without warning by default, even if the default type parameter is a class rather than id with or without protocols.)

Why This is Not the Baby-eating Spawn of Bjarne Stroustrup

Many Objective-C programmers are refugees from the blasted wasteland of C++, and will reflexively cringe at the similarity with templates:

std::vector<Duck> ducks;
Chicken chicken;
ducks.push_back(chicken);             // Error
ducks.push_back(*(Duck *)chicken);    // Horrible crash here or some time in the future, maybe.

NSArray[Duck] *ducks = [NSArray new];
Chicken *chicken = [Chicken new];
[ducks addObject:chicken];            // Warning: type mismatch
[ducks addObject:(Duck *)chicken];    // No problem, unless you call -quack on it.

While the difference should hopefully be clear by now, I’ll spell it out: in C++, std::vector<Duck> creates an entirely new class (with bits of Duck inlined into it). The Objective-C-with-generics version only provides hints to the compiler, so it can catch mistakes. It doesn’t stop you from putting chickens among your ducks, or make the duck array reject chickens at runtime, or generate a new array-of-chickens class.

In earlier discussions of generics, it has been stated that this type of mistake is rare in practice and should be caught with unit tests. If you feel that way, you’re welcome to stick to your current approach, and the introduction of generics, as described, will not affect you.

To avoid ballooning side effects of generics, I’ve deliberately avoided suggesting generic functions and methods (i.e., ones whose return type is dependent on one or more argument types, independent of their class in the case of methods).

One Last Thing

An effect of the above is that I want the language to contain types like NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] *. That doesn’t mean I want to spend my time typing NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] *, even with autocomplete. Fortunately, there exists a well-known solution to this problem: type inference.

If I access a member of an array of the aforementioned sesquipedalian type, I get an NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]] *. What’s more, the compiler knows this. The benefit of static typing lies primarily in checking what I do with my dictionary, rather than checking that the item I retrieved is what I thought it was, so I should be able to ask it to type a variable appropriately.

I quite like C++1x’s solution of recycling the auto keyword for this use, but that would conflict with Objective-C’s goal of being a strict superset of C. There are various other choices, such as var or any — or maybe ego. In any case, type inference would lead to code like:

typedef NSArray[NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]] MyHorribleNestedType;  // TODO: replace with sensible model classes.

MyHorribleNestedType *array = whatever;
var element = [array objectAtIndex:0];              // Type is inferred as NSMutableDictionary[NSString, NSSet[NSMutableArray[NSNumber]]]*
var subEntry = [NSArray arrayWithObject:@"bloop"];  // Type is inferred as NSArray[NSString]
[element setObject:subEntry forKey:@"moop"];        // Type mismatch: expected NSSet[NSMutableArray[NSNumber]], got NSArray[NSString]

A subtlety here: the return type of [NSArray arrayWithObject:@"bloop"] (declared previously) is [:Self[Item]], which is inferred from the receiver (the NSArray class object) and argument to resolve to NSArray[NSString]. Instead of typedefing MyHorribleNestedType, we could have constructed the type implicitly in the same way. like everything else in the proposal, this is optional; if you used id or explicit, unparameterized types in this example, the type mismatch would not be detected, but the generated code would be identical.

Summary

• The id type is very powerful and flexible. However, most of the time you don’t need this flexibility, and type checking is helpful — this is why Objective-C has optional static type checking in the first place, and almost all Objective-C code opts in to it.
• The proposal would not impose any new restrictions, or any new guarantees. It would only extend (optional) static type checking to cases which are currently not covered.
• It would not involve any implicit code generation, and no runtime overhead.
• Combined with type inference, it could catch errors without additional code.
• There would be no new collections, and no implementation changes to existing ones other than updated type declarations. (Updated headers would work with the existing implementations.)
• If you really don’t want static type checking, you can continue using id everywhere.
• I mean it about the “optional”. The proposed change would have no effect unless adopted both by a class and its clients. A parameterized collection pointer can be cast to plain one at any time with no cost.

JAMultiTypeSavePanelController is a class (abstracted from ImageIO Export for Acorn) to handle the case where you want to offer the user a choice of formats to save in.

It wraps an NSSavePanel and handles all the UTI and extension details. You can provide a customised NSSavePanel or let the controller create one. The only restriction is that the controller appropriates the accessory view. Usage is similar to NSSavePanel itself:

NSArray *types =
    [NSArray arrayWithObjects:@"com.apple.rtfd", @"public.rtf", @"public.plain-text", nil];
JAMultiTypeSavePanelController *controller =
    [JAMultiTypeSavePanelController controllerWithSupportedUTIs:types];
controller.autoSaveSelectedUTIKey = @"document format"; // Optional: preferences key for selected type.
controller.sortTypesByName = NO; // Optional: show in specified order instead of alphabetically by display name.
[controller beginSheetForDirectory:nil
                              file:@"untitled 42"
                    modalForWindow:docWindow
                     modalDelegate:self
                    didEndSelector:@selector(savePanelDidEnd:returnCode:contextInfo:)
                       contextInfo:nil];

-runModalForDirectory:file: is also supported.

Code (MIT/X11 license)

(Well, roughly. It actually looks like this, but I couldn’t find a decent-resolution Swedish one.)

This was a sensible design for the right-handed majority when it was introduced, some time in the stone age. However, since then, something quite important has happened: the keyboard has been joined by another input device, which I suspect is used more than the keypad by most people who are not cursed with an Excel-dominated career.

The ergonomics of the extended keyboard + mouse combination is quite, quite horrible. The human arm is not optimized for sitting turned out 30 degrees for hours at a time.

Apple has tried at least twice to solve this in one obvious way: remove all or part of the junk on the right. This has been widely, or at least loudly, decried, leading to the Extended ADB Keyboard for high-end Macs in the deep past and to extended keyboards for all in the USB era. There is another solution, though:

Unfortunately, day-to-day conservatism means that people, in the aggregate, will loudly complain about having to adopt a superior solution if it involves half an hour of retraining. I’m sure many would point out that this is why we still have rectangular QWERTY keyboards in the first place. Still, if anyone can force change down our throats and make us like it, it’s Apple.

I urge all EU citizens to contact an MEP, via e-mail or (preferably) phone, and encourage them to support the Citizens’ Rights Amendments, which reaffirm net neutrality and anti-censorship positions adopted by the European Parliament in the first reading but subsequently removed by the Council of Ministers in their “common position”.

The primary purpose of these amendments is to make it explicit that the European Convention on Human Rights applies to internet and telecoms legislation. This should be obvious, but it is clear from the actions of politicians that it is not; it is all too clear that many see the internet as a frivolous toy, and civil rights obviously do not apply to toys. (It occurs to me that politicians are probably among those in the western world least affected by the digital communications revolution; if they need to communicate, they talk to their secretaries.)

Draft texts of the amendments (not yet numbered) can be found here: part I, part II, part III. There’s a (rather bad) campaign site here, and a less bad editorial – for all that it’s in a pointy-haired e-mag – in Computer World UK here.

As an early Christmas present to fellow lovers of twisted, evil code that should never have seen the light of day under any circumstances whatsoever, I hereby present an implementation of the first half of that wish.

Caveat lector

Now, when I say it’s evil, I really, really mean it. We’re talking about building objects in the data section of your code by packing structs, thus depending on data layout (and as such, depending on the old 32-bit runtime). We’re talking about nested macros with lots of ?:s in them. We’re talking about gcc’s built-in parser pseudo-functions. Hearken to the words of Greg Parker, official Objective-C Runtime Wrangler at Apple:

@gparker: @ahruman JANumberLiteral would break in several exciting ways in 64-bit. Might almost be safe enough in 32-bit, though.
@ahruman: @gparker Yeah, I know. I’ll be pasting “If you do this in real life, I’ll have to track you down and shoot you” warnings all over it. :-)
@gparker: @ahruman Don't shoot 'em, just maim 'em a bit. I want my turn after you're done.
@ahruman: @gparker That’s what kneecaps were invented for.

Be told.

Overview

So, all that aside… what we’re looking at here is a macro $N(n) which takes a number and returns an NSNumber. (The convention of using dollar signs for macros implementing desired language features was introduced by the other Jens A.) If passed a compile-time constant, it will produce a constant object, i.e. a single, immortal instance based in the data section with no instantiation overhead, just like a string object constant. If passed a non-constant, it will give you a normal autoreleased NSNumber instead.

Constant NSStrings work by creating a struct with the following layout: { &__CFConstantStringClassReference, 1992, "foo", 3 }, where 1992 is a flag field and 3 is the length of the string. (Note that this is not the NSConstantString from the bottom of NSString.h. I believe this change was made in the OS X 10.2 SDK.) __CFConstantStringClassReference is a symbol exported from CoreFoundation.framework and implicitly declared in all Objective-C or Objective-C++ files by the compiler.¹ My task, once I chose to accept it, was to do something similar for NSNumber.

Trying to build actual NSCFNumbers would be an unnecessary extra evil. Instead, I subclassed the abstract NSNumber twice, once for long longs and once for doubles, giving me a known layout to target. The subclasses also override -retain, -release and -autorelease to do nothing, in the manner of a singleton. Then, building an instance is conceptually simple:

const static struct { Class isa; double value; } fakeObj =
{ [JAFloatNumber class], 42.0 };
NSNumber *number = (NSNumber *)&fakeObj;

The structure needs to be declared static so that it doesn’t evaporate at the end of the containing scope. This presents a dilemma, however: static initializers must be constant expressions, and a method call doesn’t qualify. Besides, we want the object to be constant data.

Luckily for us, classes are represented by global symbols like any other. Well, almost like any other. Unlike symbols based on C identifiers, their linker symbols don’t start with an underscore but with a dot, meaning you can’t reference them the usual way. Fortunately, gcc provides us with a solution in the form of asm labels:

extern const struct objc_class JAFloatLiteralClassObject
        __asm__(".objc_class_name_JAFloatNumber");

The basic implementation then becomes:

#define JANUMBERLITERAL_CONSTANT_FLOAT(n) \
        ({ static const struct { const struct objc_class *isa; double value; } \
        object = { &JAFloatLiteralClassObject, (n) }; \
        (NSNumber *)&object; })

A problem here is that, despite all those consts, a non-const value can be used in Objective-C++. (In plain Objective-C, you get a moderately helpful warning about non-const initializers.) If you write a function that returns JANUMBERLITERAL_CONSTANT_FLOAT(random());, each instance will return the same object but its value will change, which is rather bad. The fix is to wrap this up in a macro that uses __builtin_constant_p() to ensure constant objects are only created with constant values. For non-constant values, normal autoreleased NSNumbers are created instead.

Results

The above pieces, along with a bunch of extra preprocessor stuff to handle the distinctions between Objective-C and Objective-C++ and between integer and floating point values gives us a $N(n) macro which works as advertised: if given an integer constant it returns a JAIntegerNumber, for a floating point constant it returns a JAFloatNumber, and for a non-constant it returns an autoreleased NSCFNumber. But is it really working as intended? The following code:

static NSNumber *GetNumber(void)
{
    return $N(42.0);
}

disassembles to:

    .const_data
    .align 2
_object.67163:
    .long   .objc_class_name_JAFloatNumber  // isa
    .long   0           // low bytes of 42.0
    .long   1078263808  // high bytes of 42.0

…with the actual use of the object inlined (in an optimized build) to movl $_object.67163, (%esp). The values 0 and 1078263808 correspond to the little-endian hex value of 42.0: 00000000 00004540. In other words, this really is an object as constant data. For comparison, the NSString literal used in the sample code disassembles to:

    .cstring
LC0:
    .ascii "Hello, World! %@ = %li (%@)\0"
    .section __DATA, __cfstring
    .align 2
LC1:
    .long   ___CFConstantStringClassReference // isa
    .long   1992  // flags
    .long   LC0   // bytes pointer
    .long   27    // length

Conclusion

So there you have it: fully-functional, constant NSNumber objects, as long as you don’t use the 64-bit runtime. Now don’t go actually using it, or I’ll have to shoot your kneecaps off and leave you to Greg.

Oh yeah, the code is on Google Code. For a much simpler macro that just gives you an NSNumber, automatically choosing between integer and floating-point representations, try natevw’s.

^{^1} Its value, on my system, is 0xa00034a0. Traditionally (pre Leopard), a value above 0xFFF would mean it’s a real Objective-C class rather than a CF type tag, but that test is no longer in the CFLite source in Leopard, so it may have changed.

If you declare extern const Class __CFConstantStringClassReference; in an Objective-C++ file, you’ll get the error “'__CFConstantStringClassReference' has a previous declaration as 'int __CFConstantStringClassReference []'”. In Objective-C, you won’t be told a type, just that it was “previously declared here”, referring to the location “<built-in>:0”.