| |||||||||||||
16bit versus 32bit?16bit versus 32bit?Posted Sep 12, 2002 3:34 UTC (Thu) by smoogen (subscriber, #97)Parent article: Multics security, thirty years later I was wondering about one line quoted above: ...the ring 0 supervisor of Multics of 1973 occupied about 628K bytes of executable code and read-only data. This was considered to be a very large system. By comparison, the size of the SELinux module with the example policy code and read-only data has been estimated to be 1767K bytes. I am not sure if this is an apples and oranges comparison. One the two architectures used different instruction widths. Second, the number of instructions are comparable. If they were able to code the Multics code for an Intel processor/hardware and get the same size then I think the comparison would be valid.
(Log in to post comments)
No, that's *36* bits young man. Posted Sep 12, 2002 8:07 UTC (Thu) by oldtoss (guest, #3648) [Link] Not that bitness should have a great deal of influence on code size, but FYI Multics used 36 bit hardware (4 9-bit bytes). It isn't clear whether the authors allowed for the difference in byte width, so let's make that 706.5K to err on the safe side. Multics still comes out vastly less bloated. Remember also the Multics hardcore needed much *more* memory management code (relative to i386) to work with a much more primitive MMU. So, now you all know the facts, please don't perpetuate the old FUD about bloat.
No, that's *36* bits young man. Posted Sep 12, 2002 9:37 UTC (Thu) by beejaybee (guest, #1581) [Link] Yeah, well, when I started programming seriously (about 1975) I was told in no uncertain terms that if it wouldn't run in 16K (24-bit words - NOT on multics h/w), it wasn't worth writing.Things have moved on a bit since then, but "small is beautiful" is obviously still a worthwhile concept. Plain straightforward common sense suggests than the bigger a chunk of code is, the more likely it is to contain bugs - and security holes.
|
|||||||||||||