On Wed, Jul 2, 2014 at 11:31 AM, Nikolay Dimitrov <picmaster-***@public.gmane.org> wrote:
>
> .
>>
> I would rather avoid disturbing the OS constantly for each and every
> memory access. Would be better if the MMU contains a primitive policy to
> control memory accesses.
>
> You disturb it only when you switch banks - which shouldn't be often.
>
> Page faulting recovery is also very very hard on the Z80 because you've
>> not got restartable instructions. If you fault in the middle of LDI exactly
>> what state are you in ?
>>
> Hmm, you're right. Haven't thought about restarting instructions... But
> from another perspective, we can do it "almost the right way":
> 1. Allow partial address space mappings for the userspace.
>
Easy enough but you could also just map the same block repeatedly in all
the "banks" that are empty so a program only wees on itself.
3. Inform the OS that a non-mapped access occurred, with detailed info
> about the misbehaving task. It's totally possible to just kill or restart
> the task in such circumstance, what do you think?
Will's MMU can already generate an error on a forbidden access and you can
wire it to NMI although it isn't connected in the current SocZ80.
> What will you achieve when splitting the instruction and data? Usually (in
> Von-Neumann) I & D paths are split only because the 2 streams have
64K code + 64K data without having to bank switch.
> A fully protected UZI or similar environment just needs the I/O
>> protection, IRQ via NMI and a way to get back into supervisor mode as far
>> as I can tell. Things like VM are just surplus to requirements.
>>
> But if you add memory address space protection between supervisor and user
> modes, it will gain the same complexity, imho.
I don't think so, nothing of the same order.
>
>
> Yep. But this is a classic choice between "who has to handle the job" -
> the kernel or the MMU. The cheapest approach is to have just 2 contexts,
> kernel and user, which fully maps the logical address space to the physical
> one. Then each time when the kernel decides to switch to another task, it
> will have to load the new mapping in the MMU-user-part. If the MMU supports
> enough SRAM for multiple mappings, the switching between mappings can be
> only a write to a "task id" register, which is connected to the MSB address
> lines to the MMU SRAM. But in general I'm OK with either approach, as long
> as it works :).
>
>
> I'm sort of torn there between something clever and simply trying to
>> software work around a "classic" 4 x 16K bank model.
>>
> Can you guys explain me why noone likes the idea of having smaller pages
> for Z80, like 4KiB or 1KiB?
>
These two are closely related. On SocZ80 the CPU executes a lot of
instructions to do a bank switch. At 128MHz nobody notices. On a "classic"
4MHz CP/M Z80 board you execute something like 10 instructions with 4 16K
banks.
Four banks means four I/O writes to switch completely (3 for CP/M where the
top 16K is fixed). It requires a 2 input mux and four registers holding the
bank numbers, plus the relevant CPU glue to update them.
4K pages means you need a four input mux, 16 bank registers and it's a lot
more glue logic, especially before PAL, CPLD and ULA type devices were
available.
In some cases having a small number of banks also saved a lot of logic
because you could do dirty tricks with spare I/O device pins. For example
Grant Searle's Z80 'DIY' system has a pair of free lines on the Z80 SIO
which with a tiny bit more logic would be sufficient to implement bank
switching and using more of the RAM without having to implement all the
register setting but instead (ab)using the SIO to do the hard work. In fact
there were real systems that did exactly that. Something as simple as
A16 <= (A14 and A15 and SIOsparepin1) or SIOsparepin2 ought to do the trick.
"cost" is relative. With an FPGA gates are cheap (although as I keep
finding out the hard way - not in long chains at high speed), on a real
board, especially a historic one gates were expensive.
Alan
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to n8vem-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.