Brainfuck bitwidth conversions

This is a set of translations to make normal 8-bit Brainfuck use 2 or 4 cells. Basically, by applying one of these conversions, you can make a normal BF program run as its 16-bit or 32-bit version on an 8-bit BF interpreter.

For both conversions, the output code must be prefixed with a single '>'.

Multiple conversions
It is also possible to combine these, and detect the bitwidth of the interpreter at runtime like so: // This generates 65536 to check for larger than 16bit cells >[-]<[-]++[>++++++++<-]>[<++++++++>-]<[>++++++++<-]>[<++++++++>-]<[>++++++++<-]+>[> // This code is the original source for 32bit cells ... <[-]]<

// This section is cell doubling for 16bit cells >[-]<[-]++++++++[>++++++++<-]>[<++++>-]<-]>[-]++[<++++++++>-]<[>++++++ ++<-]>[<++++++++>-]<[>++++++++<-]>[<++++++++>-]+<[>-<[->[> >...< <[-]]<[-]]

// This section is cell quadrupling for 8bit cells >[-]<[-]++++++++[>++++++++<-]>[<++++>-]+<[>-<[-]]>[> >...< <[-]]<

Note: The three sections are independent and can be reordered. If you omit any section the program will do nothing for that cell size. Obviously it'd be better to include an error message. The code used isn't the smallest possible, but it's very easy to see how it works; easy enough that several BF compilers (and C compilers) can work it out too and so eliminate the code that will never run.

Problems with I/O
The input command  is not easy to correctly convert. The difficulty is that there are three normal conventions for marking end of file: cell unchanged, cell zero and cell -1/255. With EOF there are 257 different results that the interpreter needs to pass to the running program. As this program believes it's running on a 16/32 bit interpreter it can represent these 257 codes but the eight bit interpreter cannot. So the input command needs to be mapped to match the expectations and limitations of BOTH the interpreter and the code it's running.

Generally the output command  is not a problem; except some interpreters will convert codes over 127 into UTF-8 Unicode strings (usually for input as well). Emulating this in BF while obviously possible is definitely non-trivial.

Other Conversions
The above conversions are not the only possible cell expanders, the alternative routines below are all shorter. Depending on the optimisations that an interpreter does they may be faster or slower. In addition they can be applied repeatedly to, in theory, expand the cells to any size required.

For example, the 'No Copy' routine will be the fastest on an interpreter that does not optimise, even if it's applied twice to create a 1→4 conversion.