And what would do that “read data off disk, then write other data back”, if not a program? Even if you use a monitor (https://en.wikipedia.org/wiki/Machine_code_monitor) to write a program, that’s still a program.
The only way to avoid that is to hand-punch a tape or something like that (with lots of practice and patience, it may be possible to program a small PROM or write an early floppy by hand)
I've compiled some simple C (microcontroller blinky) by hand. Then assembled and linked the output, and written the machine code into a HEX (Intel format) file. Then tested it on the micro. It's a rather fun exercise (Type 2 fun).
Fun with extra twists and turns you weren't expecting. Usually quite an adventure, some unintended learning and growth. Hopefully a story worth telling.
As opposed to the obvious doing an activity for fun.
On a Commodore 64, the kernal [sic] was similar to the BIOS on a PC, with display and keyboard handlers, IO routines, etc. When you first turned on the machine, something had to say "** COMMODORE 64 BASIC V2 **", and that something was the kernal.
I always kind of thought the kernel was, at its core, the thing that handles processes and hardware io. Even if you use one of those tiny micro kernels it has to handle processes and present an api through which to communicate with devices (even if it doesn’t handle the devices itself.) I think it’s true you need a kernel to compile a kernel in this sense.
You don't need to host another program to compile something. All you need to do is to read data off disk, then write other data back.