On Mon, 12 Jun 2017 13:35:49 +0930 "David O'Shea" <dcoshea@xxxxxxxxx> wrote: > On Mon, Jun 12, 2017 at 12:24 AM, Alan Cox <alan@llwyncelyn.cymru> wrote: > > Moving to large code isn't a problem, but large data means far pointers > > and that means a huge slowdown in performance. > > Ah, that hadn't occurred to me, but it makes sense. Thanks! > > > For userspace large models also mean you can't do swapping until you have > > 286 protected mode. > > I assume the issues are that you can't page segments in on demand > because there's no MMU, so whenever you schedule the process you'd > have to page all of it in, and the process now has physical memory > addresses (rather than just addresses relative to some registers that > the kernel can change), so you always have to page it to the same > location in memory? Mostly the latter. If you want the full glorious horror story take a look at how windows16 does call stack frame fixup for 16bit apps. (Short version - each stack frame pushes bp. Windows 16 inc's bp before pushing and decs after if the function is far, thus allowing the windows OS code to walk the stack frames and modify each far return according to what is and isn't in memory and where it moved) We could modify the compiler to do that, but it's up there with coding while drunk on 'good idea' rating. > I presume that this is why the MS/PC-DOS DOSSHELL (and no doubt there > were various other tools that did the same) was a "task swapper" which > swapped your entire process to/from disk when you switched processes? That was more because a DOS program owns all of memory so you don't know how much to give it. > > To support larger programs, would it be worth sacrificing the ability > to swap those particular programs? No - those are the ones you need to swap the most. > And regardless of moving away from tiny model, I gather that moving to > OpenWatcom just for the optimisations and ANSI C would potentially be > worthwhile? 16bit gcc is probably better. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-8086" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
