1065 Commits

Author SHA1 Message Date
gbeauche
449c6496ff Link with AppKit framework on MacOS X. This should enable X11 builds when
there is no SDL available (suggested by Dara Hazeghi)
2006-03-14 22:14:13 +00:00
gbeauche
7ee9cb43dc Relocate MacOS X executable to 0x78048000 akin to linker scripts on Linux
arches. This probably already worked in the past but I have just verified
that Basilisk II works with up to 1 GB of Mac RAM in DIRECT_ADDRESSING or
REAL_ADDRESSING mode.

BTW, a quick Speedometer 4 CPU performance test showed a +15% speed increase
in real addressing mode vs. direct addressing. x86 arches don't benefit much
from that mode since they support complex address modes already (beyond plain
load/store).

TODO: check on MacOS X for Intel so that to reduce the test to darwin*:*)
2006-03-14 21:18:44 +00:00
nigel
fa84cf9a51 1. Happy New Year. 2. Minor syntax error 2006-03-14 09:38:24 +00:00
nigel
cce2d58228 Incorporate recent changes from Unix equivalent files 2006-03-11 11:45:25 +00:00
nigel
0fc35d5a91 Ensure event processing works in fullscreen mode 2006-03-10 08:16:56 +00:00
gbeauche
b80e9651f5 fix cross-block initializer 2006-02-27 13:39:29 +00:00
gbeauche
cafa8c8c89 add some barriers to make sure L_e_region* really come after the test insns 2006-02-27 13:38:52 +00:00
gbeauche
c19cc7a81b Updates 2006-02-27 07:25:43 +00:00
gbeauche
74c62b9095 - Try to allocate Mac memory only once on 32-bit systems
- Cap Mac memory to 1023 MB, Apple Personal Diagnostics crashes at 1 GB
- Scratch memory is meant to be addressed from Mac programs too
2006-02-27 07:24:58 +00:00
gbeauche
f446d610f8 Start allocating memory from 0x10000000 with linker scripts since the system
sometimes has a problem to make a decision when next_address == 0.

NOTE: this makes it possible to allocate up to 1 GB with DIRECT_ADDRESSING
2006-02-27 07:16:40 +00:00
gbeauche
9aab8c7d85 Move up _start base 2006-02-27 07:14:39 +00:00
gbeauche
93d918097b Fix vm_acquire_mac() fallback to non 33-bit addressing mode. Support 33-bit
addressing in REAL_ADDRESSING mode. Only support platforms with proper
linker scripts to map the whole Mac memory from address 0. Warning fix.

NOTE: when compiled with --enable-addressing=real on Linux {x86,x86_64},
you can not address up to 1.5 GB in Basilisk II.
2006-02-27 00:15:39 +00:00
gbeauche
2ef9d6e708 Add linker scripts for correct REAL_ADDRESSING support 2006-02-27 00:11:49 +00:00
gbeauche
077a232acc Memory allocated through win32 VirtualAlloc() is zero-filled. Likewise for
memory mmap()'ed with MAP_ANONYMOUS (equivalent to /dev/zero mapping but
faster)
2006-02-27 00:04:12 +00:00
gbeauche
735c332ab7 add 33-bit addressing support to vm_acquire_fixed() 2006-02-26 23:45:07 +00:00
gbeauche
dbc467e316 prefer lower indexes in register allocation, this avoids REX prefixes on
x86_64 when %r8 - %r15 are used (very light speedup expected)
2006-02-26 18:58:18 +00:00
gbeauche
91babf4bb5 fix FETOX & FTWOTOX translations for x86_64 2006-02-26 18:49:55 +00:00
gbeauche
c374d519a3 fix ROM85 bug fix for AppleShare extension 2006-02-19 14:18:29 +00:00
gbeauche
294664b726 Fix SAHF_SETO_PROFITABLE code for x86-64 platforms.
This was only an experiment. Improvement was marginal: only +3% on AMD64
(an Athlon 64 3200+). However, it may be interesting to test it on EM64T
(e.g. newer P4s) since an older P3/800, hence in 32-bit mode, got a +15%
improvement in Speedometer 4 benchmarks.

Rationale: lahf/seto sequences avoid load/stores to the stack (push/pop)
and it was thus hoped to be faster.

Anyhow, SAHF_SETO_PROFITABLE can only be enabled manually at this time.
Edit your generated Makefile for testing, but first make sure your CPU
supports lahf in 64-bit mode (lahf_lm flag in /proc/cpuinfo).
2006-02-06 23:06:54 +00:00
gbeauche
3b94dfb1a9 Cosmetics, fix %rh cases in !X86_FLAT_REGISTERS mode, lahf/sahf are now
valid instructions in long mode (recent enough CPU revisions: lahf_lm).
2006-02-06 22:57:18 +00:00
gbeauche
9ccf62f7b0 Manually emit LAHF instructions so that 64-bit assemblers can grok it 2006-02-06 22:55:44 +00:00
gbeauche
360a9457c6 fix logic 2006-01-27 23:49:01 +00:00
gbeauche
9d984b3b34 Check whether compiler supports byte bit-fields. If so, we can enable slirp
emulation code since it pure C+sockets code.
2006-01-27 23:41:43 +00:00
gbeauche
e9e3ad9a4b Further unaligned access fixes on IRIX (Brian J. Johnson). Configury needed
to ensure compiler supports bit-field members of unsigned char type.
2006-01-27 23:31:38 +00:00
gbeauche
a615a4ac24 Use the most portable POSIX-style non-blocking I/O (O_NONBLOCK) instead of
BSD-style through FIONBIO. It turns out Tru64 and probably IRIX don't support
the latter when fd is a pipe (slirp case).
2006-01-24 23:46:19 +00:00
gbeauche
064973dbc7 ugly cast games 2006-01-24 21:33:26 +00:00
gbeauche
e0a966ee15 Code I wrote yesterday was totally broken. It's enough to make sure nPC is
correctly updated too... Instruction skipper now works on Solaris/SPARC.
2006-01-23 23:57:41 +00:00
gbeauche
99f5dcf66f - Fix SPARC Store Doubleword transfer_size in decoder.
- In the instruction skipper code, add a huge kludge (trampoline) to forcibly
  zero out %global registers when requested. Otherwise, Solaris/SPARC turned
  out to use %g1 during signal handling, and the zero we could have written
  to there vanished. This assumes [%sp-8] is valid to use (ABI states data
  below %sp is undefined though)
2006-01-22 23:14:48 +00:00
gbeauche
100a3e1abd Adapt for MacOS X for Intel, also fix thread_state type in forward_exception() 2006-01-22 00:05:05 +00:00
gbeauche
f0f76cd7ad Remove nigel's hack, I am confident the problem was MacOS X implementation of
poll() that was not a cancellation point, which I fixed (OSX/Intel 10.4.4)
2006-01-21 20:48:17 +00:00
gbeauche
ceb7488a77 poll() and select() are still not cancellation points in MacOS X 10.4.4... 2006-01-21 16:19:47 +00:00
gbeauche
a6156a17b7 streamline for standalone VOSF performance testing 2006-01-21 16:00:17 +00:00
gbeauche
335a9dd7f3 MacOS X bundle 2006-01-21 13:06:32 +00:00
gbeauche
5ee0a6741b Packet headers can be examined through unaligned addresses. This patch
fixes this, especially for MIPS & SPARC platforms. [Initial patch from
Brian J. Johnson]
2006-01-17 21:19:12 +00:00
nigel
998e1f7f7b A few more clashes with OS X headers (10.3 only?), update year 2006-01-16 23:10:33 +00:00
nigel
078efac834 Added the cosmetic feature that I forgot was in v17 2006-01-16 23:09:53 +00:00
nigel
ff7665cb2e Add a Networking section, update formatting in other parts of the text 2006-01-16 23:07:22 +00:00
gbeauche
e534b07a70 more precise callee-saved register set 2006-01-16 21:31:41 +00:00
gbeauche
12f103a83a JIT generated code is not guaranteed to be leaf, e.g. there could be a call
to a generic instruction handler (untranslated code). This caused problems
on MacOS X for Intel where the unaligned stack conditions turned out to be
more visible. Performance loss is really neglectable and this is the right
fix now anyway.
2006-01-16 21:31:08 +00:00
gbeauche
1b99c9501f fix stack alignment (theoritically but it was OK in practise) in generated
functions, move m68k_compile_execute() to compiler/ dir since it's JIT
generic and it now depends on USE_PUSH_POP (as it should)
2006-01-15 22:42:51 +00:00
gbeauche
2bc7887bc1 fix framework detection on OSX/intel (thanks toshi for the remote access ;-) 2006-01-15 11:38:41 +00:00
nigel
a398b4a32a 10.4 builds are fine, but not when using Xcode 2006-01-05 03:37:56 +00:00
nigel
fc83144337 Update in what OSs this compiles under 2006-01-05 00:36:20 +00:00
nigel
9dbc9e276d Another year, OS X port networking now works, seperate OS X slirp
and udp tunneling descriptions by an extra blank line
2006-01-04 06:28:55 +00:00
nigel
681187bfc2 Another two years! 2006-01-04 06:23:57 +00:00
nigel
bdf1e05605 Version 17 test was a bit messy 2006-01-04 06:20:38 +00:00
nigel
ca2dba38fe Another year, another version 2006-01-04 06:14:55 +00:00
nigel
e47c1c50cd There is now a fix (er, hack) for the ethernet thread exit problem,
so move it from bugs to "wouldn't it be nice if ..."
2006-01-04 06:14:26 +00:00
nigel
4b000e4dad Clean up after configure 2006-01-04 06:11:04 +00:00
gbeauche
a2840298b0 - factor out native_byte_order determination
- fix ExpandMap[] when client X image byte order is different than host's
  e.g. { mips, ppc } -> x86 in 8 bpp mode
2006-01-03 22:03:27 +00:00