m68k: use generic_msi

Change-Id: Ifced80c25c08632ade10190658f2fc17b1de5309
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6909
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

kernel & addons: Build with the non-legacy GCC even on x86_gcc2h.

Only one code change: for some reason, GCC chokes on the cr3 functions
as macros (throwing errors about invalid registers.) The BSDs have them
as inline functions instead, so they are converted to that here.

Tested and working. There seems to be about a 10% decrease in CPU time
on some compilation benchmarks that I briefly tried.

Change-Id: I31666297394d7619f83fca6ff5f933ddd6f07420
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4515
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

M68K: Switch to new gcc options for specifying cpu

Latest gcc converts the old ones to the new ones anyway...
including when passing to gas, which of course is not new enough,
so we have to also force gcc to pass the old one around in one case.

Fix building the m68k kernel

* Restructured the vm support code to align with the changes done to other archs.
* Not completely finished, but the kernel loads and panics. I had this sitting on the disk anyway.
* Only support 040 for now, 030 will need to be added back.
* This commit is dedicated to Jack Tramiel who passed away away last sunday:
http://www.forbes.com/sites/davidthier/2012/04/09/computer-legend-and-gaming-pioneer-jack-tramiel-dies-at-age-83/

*.c -> *.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34417 a95241bf-73f2-0310-859d-f6bbb57e9c96

This should fix m68k build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33619 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prefixed memset_physical() and memcpy_to_physical() with "vm_",
added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and
added respective functions to the vm_translation_map operations. The
architecture specific implementation can now decide how to implement
them most efficiently. Added generic implementations that can be used,
though.
* Changed vm_{get,put}_physical_page(). The former no longer accepts
flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore).
Instead it returns an implementation-specific handle that has to be
passed to the latter. Added vm_{get,put}_physical_page_current_cpu()
and *_debug() variants, that work only for the current CPU,
respectively when in the kernel debugger. Also adjusted the
vm_translation_map operations accordingly.
* Made consequent use of the physical memory operations in the source
tree.
* Also adjusted the m68k and ppc implementations with respect to the
vm_translation_map operation changes, but they are probably broken,
nevertheless.
* For x86 the generic physical page mapper isn't used anymore. It is
suboptimal in any case. For systems with small memory it is too much
overhead, since one can just map the complete physical memory (that's
not done yet, though). For systems with large memory it counteracts
the VM strategy to reuse the least recently used pages. Since those
pages will most likely not be mapped by the page mapper anymore, it
will keep remapping chunks. This was also the reason why building
Haiku in Haiku was significantly faster with only 256 MB RAM (since
that much could be kept mapped all the time).
Now we're using a different strategy: We have small pools of virtual
page slots per CPU that are used for the physical page operations
(memset_physical(), memcpy_*_physical()) with CPU-pinned thread.
Furthermore we have four slots per translation map, which are used to
map page tables.

These changes speed up the Haiku image build in Haiku significantly. On
my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG
disabled, block cache debug disabled). Still more than factor 3 slower
than FreeBSD and Linux, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96

- use a physical page for natfeat debug output for now
- add 040 cpu and mmu stuff
- use leftover from the page root table to put interrupt vector table to set VBR to


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26627 a95241bf-73f2-0310-859d-f6bbb57e9c96

The file was changed to C++...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26169 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Add missing globals
- stubbed commpage stuff.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26094 a95241bf-73f2-0310-859d-f6bbb57e9c96

move cpu-specific objects out of source list to other objects list.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26090 a95241bf-73f2-0310-859d-f6bbb57e9c96

- move atari platform subclass to platform/atari_m68k/
- fix exception handling, at least it builds now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26089 a95241bf-73f2-0310-859d-f6bbb57e9c96

- add fpu states
- add needed asm_offsets
- start of exception handling


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26073 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Jan Klötzke:
* Current linking scheme does not always export arch specific symbols from the
kernel. Merging all compiled arch stuff into a single .o file (and linking
that to the kernel) fixes it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25679 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new header directory headers/private/system which is supposed
to contain headers shared by kernel and userland (mainly libroot).
* Moved quite a few private kernel headers to the new location. Split
several kernel headers into a shared part and one that is still kernel
private. Adjusted all affected Jamfiles and source in the standard x86
build accordingly. The build for other architectures and for test code
may be broken.
* Quite a bit of userland code still includes private kernel headers.
Mostly those are <util/*> headers. The ones that aren't strictly
kernel-only should be moved to some other place (maybe
headers/private/shared/util).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25486 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some reorg.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23759 a95241bf-73f2-0310-859d-f6bbb57e9c96

Ditto.
cleanup
Less ppc, more m68k :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22822 a95241bf-73f2-0310-859d-f6bbb57e9c96

Unfinished kernel support for m68k.
Based on ppc/x86 from r22648.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22650 a95241bf-73f2-0310-859d-f6bbb57e9c96

M68K: Switch to new gcc options for specifying cpu

Latest gcc converts the old ones to the new ones anyway...
including when passing to gas, which of course is not new enough,
so we have to also force gcc to pass the old one around in one case.

Fix building the m68k kernel

* Restructured the vm support code to align with the changes done to other archs.
* Not completely finished, but the kernel loads and panics. I had this sitting on the disk anyway.
* Only support 040 for now, 030 will need to be added back.
* This commit is dedicated to Jack Tramiel who passed away away last sunday:
http://www.forbes.com/sites/davidthier/2012/04/09/computer-legend-and-gaming-pioneer-jack-tramiel-dies-at-age-83/

*.c -> *.cpp


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34417 a95241bf-73f2-0310-859d-f6bbb57e9c96

This should fix m68k build.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33619 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Prefixed memset_physical() and memcpy_to_physical() with "vm_",
added vm_memcpy_from_physical() and vm_memcpy_physical_page(), and
added respective functions to the vm_translation_map operations. The
architecture specific implementation can now decide how to implement
them most efficiently. Added generic implementations that can be used,
though.
* Changed vm_{get,put}_physical_page(). The former no longer accepts
flags (the only flag PHYSICAL_PAGE_DONT_WAIT wasn't needed anymore).
Instead it returns an implementation-specific handle that has to be
passed to the latter. Added vm_{get,put}_physical_page_current_cpu()
and *_debug() variants, that work only for the current CPU,
respectively when in the kernel debugger. Also adjusted the
vm_translation_map operations accordingly.
* Made consequent use of the physical memory operations in the source
tree.
* Also adjusted the m68k and ppc implementations with respect to the
vm_translation_map operation changes, but they are probably broken,
nevertheless.
* For x86 the generic physical page mapper isn't used anymore. It is
suboptimal in any case. For systems with small memory it is too much
overhead, since one can just map the complete physical memory (that's
not done yet, though). For systems with large memory it counteracts
the VM strategy to reuse the least recently used pages. Since those
pages will most likely not be mapped by the page mapper anymore, it
will keep remapping chunks. This was also the reason why building
Haiku in Haiku was significantly faster with only 256 MB RAM (since
that much could be kept mapped all the time).
Now we're using a different strategy: We have small pools of virtual
page slots per CPU that are used for the physical page operations
(memset_physical(), memcpy_*_physical()) with CPU-pinned thread.
Furthermore we have four slots per translation map, which are used to
map page tables.

These changes speed up the Haiku image build in Haiku significantly. On
my Core2 Duo 2.2 GHz 2 GB machine about 40% to 20 min 40 s (KDEBUG
disabled, block cache debug disabled). Still more than factor 3 slower
than FreeBSD and Linux, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28244 a95241bf-73f2-0310-859d-f6bbb57e9c96

- use a physical page for natfeat debug output for now
- add 040 cpu and mmu stuff
- use leftover from the page root table to put interrupt vector table to set VBR to


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26627 a95241bf-73f2-0310-859d-f6bbb57e9c96

The file was changed to C++...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26169 a95241bf-73f2-0310-859d-f6bbb57e9c96

- Add missing globals
- stubbed commpage stuff.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26094 a95241bf-73f2-0310-859d-f6bbb57e9c96

move cpu-specific objects out of source list to other objects list.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26090 a95241bf-73f2-0310-859d-f6bbb57e9c96

- move atari platform subclass to platform/atari_m68k/
- fix exception handling, at least it builds now.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26089 a95241bf-73f2-0310-859d-f6bbb57e9c96

- add fpu states
- add needed asm_offsets
- start of exception handling


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26073 a95241bf-73f2-0310-859d-f6bbb57e9c96

Patch by Jan Klötzke:
* Current linking scheme does not always export arch specific symbols from the
kernel. Merging all compiled arch stuff into a single .o file (and linking
that to the kernel) fixes it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25679 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Introduced new header directory headers/private/system which is supposed
to contain headers shared by kernel and userland (mainly libroot).
* Moved quite a few private kernel headers to the new location. Split
several kernel headers into a shared part and one that is still kernel
private. Adjusted all affected Jamfiles and source in the standard x86
build accordingly. The build for other architectures and for test code
may be broken.
* Quite a bit of userland code still includes private kernel headers.
Mostly those are <util/*> headers. The ones that aren't strictly
kernel-only should be moved to some other place (maybe
headers/private/shared/util).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25486 a95241bf-73f2-0310-859d-f6bbb57e9c96

Some reorg.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23759 a95241bf-73f2-0310-859d-f6bbb57e9c96

Ditto.
cleanup
Less ppc, more m68k :)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22822 a95241bf-73f2-0310-859d-f6bbb57e9c96

Unfinished kernel support for m68k.
Based on ppc/x86 from r22648.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22650 a95241bf-73f2-0310-859d-f6bbb57e9c96