> > It is not impossible. In fact, if the C-compiler is good (let's face > > it, most of the non-time critical code is already there so why not > > use it? - the main problem is to get the code re-entrant and perhas > > dynamically linked? :), a usable Linux-port could be done in > > 250-300K of kernel. However, the question is if it is possible to > > use the MMU of the z380? SI? > > Right... I'm with Geoff on coding it in Z80 by the way - C does lead to a > fair bit of bloat unfortunately... :( (Which is why I think Nev Young's > course of writing the HD dos in C is a pretty awful one).
The bloatednes of binaries compiled with a C-compiler depends on the C-compiler. I've seen very good C-compilers and I've seen awful ones - where is SAMC (those of you who have tried it)? The point was that it takes quite a while to code (and maintain) assembly code. Of course, it would be better to code it all in z80, but is it realistic? > The problem here is with the MMU... while the Z380 has facilities for > reducing the chip count needed to access memory modules, it doesn't have an > MMU per se - just a 4Gb address space. So, if processes go walkabout, we > could be talking serious problems... > > I'm going to have to ask Zilog nicely if they've got an MMU finished for it > yet I think... I'll get back to you on it... How about a Z480? :) > > (The alternative is to replace every memory access with an undefined opcode > followed by the address it is to go to, followed by the data to be > written... slow, but it'd do it, as the Z380 traps the undefined ones > now...) *grunt* -Frode
