To be fair the F22 would have been closer to the F35 in price if the number produced were larger so that the R&D was spread over a larger number of airframes. Such a pretty plane.
I agree that the F-22 is gorgeous, but it is also extremely expensive to operate, couldn’t be exported, can’t do carrier launch or VTOL so the demand was inherently lower.
That said, we could have made more than 195 of the them, but even at 750 it would have still been significantly more expensive per aircraft than the F-35 and it wouldn’t have let us cancel the F-35 program.
I feel like we got locked into the aerodynamic & airframe structural limitations of a particular CVN format with the USS Enterprise and are doing some wacky things, like not navalizing the F-22 or the C-130 or the B-21, because we can't dream any larger without assuming that such a ship would cost infinity dollars. South Korea, Japan, and China build larger container, tanker, and bulk ships all the time for ~1% of the price of a supercarrier; It's not that adding tens of thousands of tons of steel is going to break the bank, it's that a carrier group encompasses most functions of the military. The larger a ship gets the easier it is to move quickly through the wind, and the slower effective landing approaches are. The longer the catapult, the lower the necessary acceleration. CATOBAR takeoff and landing that works a little more like normal runway takeoff and landing means more of the USAF R&D ends up being projectable power.
It would cost an insane amount of money.... but... It already does cost an insane amount of money, and then we have to run three separate military aviation programs for different regimes.
The US military doesn’t want to sacrifice the capacity to go through the Panama Canal without getting a large benefit.
As to cost, in many ways a cruise ship is a better comparison than a cargo ship. The giant crew needed to maintain and operate a large aircraft fleet themselves need support staff, supplies, housing, etc. Carriers are expensive because of the people and systems onboard not the size of the ship.
Even just moving aircraft up and down from the flight deck requires a massive and thus expensive system. Civilian nuclear reactor are hideously expensive to build and operate let alone a system designed to ramp up and down more quickly, operate on a moving ship etc. Close in weapon systems have limited field of fire when you want a clear flight deck etc.
So sure, in theory you could just say we want a larger flight deck and are going to just have a number of empty components to pad out the ship but it’s not so simple.
The US sacrificed that a long time ago, when it first introduced supercarriers in the 50's. Too tall for the bridges, too wide for anything but the Third Locks era, and then only with some minor alterations.
Now that we do have the Third Locks, I think it would be reasonable to replace the bridges and make the alterations, a rounding error in the CVN budget.
Repositioning is far from the only concern but it is something they care about. For example the USS Dwight D. Eisenhower crossed the Suez Canal in 2021.
Surprised that no one has corrected them that it's not RS232 anymore. It was eventually ratified and it's technically called EIA-232-F (at least for the most recent 1997 version).
There were a number of hacks to deal with this. RAIN was very popular back in the day, but AMNHLTM appears to have better compatibility with modern CPUs.
They can roll their sleeves up and do the small amount of work that they tried to persuade everyone else was not necessary. And I'm sure they will have done so.
It's not that hard to design a wide decoder that can decode mixed 2-byte and 4-byte instructions from a buffer of 32 or 64 bytes in a clock cycle. I've come up with the basic schema for it and written about it here and on Reddit a number of times. Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64.
Not that anyone is going that wide at the moment. SiFive's P870 fetched 36 bytes/cycle from L1 icache, but decodes a maximum of 6 instructions from it. Ventana's Veyron v2 decodes 16 bytes per clock cycle into 4-8 instructions (average about 6 on random code).
> Yeah, it's a little harder than for pure fixed-width Arm64, but it is massively massively easier than for amd64.
For those who haven't read the details of the RISC-V ISA: the first two bits of every instruction tell the decoder whether it's a 16-bit or a 32-bit instruction. It's always in that same fixed place, there's no need to look at any other bit in the instruction. Decoding the length of a x86-64 instruction is much more complicated.
So that there are 48k combinations available for 2-byte instructions and 1 billion for 4-byte (or longer) instructions. Using just 1 bit to choose would mean 32k 2-byte instructions and 2 billion 4-byte instructions.
Note that ARMv7 uses a similar scheme with two instruction lengths, but using The first 4 bits from each 2-byte parcel to determine the instruction length. It's quite complex, but the end result is 7/8 (56k) 2-byte instructions are possible and 1/8 (512 million) 4-byte instructions.
IBM 360 in 1964 thru Z-System today also uses a 2-bit scheme to choose between 2-byte instructions with 00 meaning 2-bytes (16k instructions available), 01 or 10 meaning 4-bytes (2 billion instructions available), and 11 meaning 6-bytes (64 terra instructions available).
To increase the number of 16-bit instructions. Of the four possible combinations of these two bits, one indicates a 32-bit or longer instruction, while the other three are used for 16-bit instructions.
> Do they plan to support other instruction lengths in the future?
They do. Of the eight possible combinations for the next three bits after these two, one of them indicates that the instruction is longer than 32 bits. But processors which do not know any instruction longer than 32 bits do not need to care about that; these longer instructions can be naturally treated as if they were an unknown 32-bit instruction.
