Ludo Brands wrote:
The speed of emulated or low-resource systems is obviously a
problem- I
put some informal benchmarks on the wiki page I did a few
weeks ago when
I was putting Qemu on a development system with ARM, Mipsel and so on.
Do you have an Url for that page?
http://wiki.lazarus.freepascal.org/Qemu_and_other_emulators although I
suspect that there's not much in it that you're not doing already. I
hacked it together when I was setting up the system since it's probably
not every day that somebody does it from scratch. Benchmarks on the
discussion page.
On Qemu sparc I'm stuck with debian etch (gdb too old => dead lock with
lazarus) since lenny is compiled for v8+. Display is limited at 8-bit which
lazarus doesn't support. Only solution that is working for me is a reverse
ssh tunnel, tunneling X11 and no encryption (else ssh and sshd cpu usage
goes through the roof with lazarus).
Similar solution for Qemu arm where the low screen resolution of the
versatilePB platform makes running lazarus impossible. On arm lenny is
running and debugging in lazarus works fine.
But in the case of SPARC-on-Qemu you should be able to use VNC
(specifically, Debian's vnc4server package), in conjunction with FluxBox
as desktop/wm it's fairly lean and performs well. The machine in front
of me is a (real) SPARC running Etch, thanks to your patches
0.9.30+2.4.2 are now running fine on it so there's a fair chance the
same would apply to an emulated system; I'm in no great hurry to update
this system to a later OS but am overdue for going round everything and
getting onto 2.4.4.
ARM is more of a problem since vnc4server is not ported to it, I believe
that there are some ARM-specific problems in the VNC sources. There's a
different server that does run on it (from memory, tightvncserver) but
it appears to be hardcoded to expect the display manager to be xdm- I
prefer gdm since it's the only one with a reliable XDMCP implementation.
In either case you /should/ be able to connect to the system using
XDMCP, e.g. using Xnest on your local system and gdm+FluxBox on the
headless one, subject to your network setup since XDMCP is a UDP-based
protocol which implies that broadcasts don't route well. However at one
time (I don't know whether this is fixed) Lazarus and some other apps
performed very badly using networked X, my recollection is that the
consensus was that there was excessive input-device polling.
So if I understand that correctly, that define is telling the
compiler
that it should always arrange data structures so that fields are
aligned. It's obviously not in control of structures which
are forced in
some way, or of explicit pointer arithmetic.
The other way around. The compiler aligns data for all processors even when
it is not mandatory for the processor. This is for speed. The packed
directive tells the compiler to not align the data. The compiler sets
FPC_REQUIRES_PROPER_ALIGNMENT for the programmer. He should use this to
conditionally define packed structures or think twice when casting fe. pchar
to pword.
Thanks, noted.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
