[Pearpc-devel] moving from nasm to gas

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I have rewritten all assembler files to gnu assembler. This means pearpc
no longer depends on nasm.
Please check out CVS and test.
Sebastian

I'd try it if anon cvs access wasn't that slow to recognize updates :)

by the way, I've noticed you included my ppc_mmu changes, I gather
you did not need
a patchfile to cut / copy then ? :)

Jens

Sebastian Biallas

2006-03-01 16:49:11 UTC

Post by Jens von der Heydt
I'd try it if anon cvs access wasn't that slow to recognize updates :)

BTW: sf.net has subversion support now, and I'd really like to convert
the pearpc repository.. Does anyone know of some caveats?

Post by Jens von der Heydt
by the way, I've noticed you included my ppc_mmu changes, I gather you
did not need
a patchfile to cut / copy then ? :)

Yes :)

Jens von der Heydt

2006-03-01 16:57:58 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jens von der Heydt
I'd try it if anon cvs access wasn't that slow to recognize
updates :)

BTW: sf.net has subversion support now, and I'd really like to convert
the pearpc repository.. Does anyone know of some caveats?

Yes, I've noticed that too. I don't think there are actual caveats
for a project like PearPC.

A nice page for information is http://www.pushok.com/
soft_svn_vscvs_1.php

I think we could convert to svn so we could lose some of the old
directory
structures still existant in the cvs repository (cpu vs cpu_jit...).
Question is,
does the conversion on sourceforge also copy our update history and
branches?
I wouldn't like to lose the diff between PearPC versions of the source.

Jens

Sebastian Biallas

2006-03-01 17:11:32 UTC

I think we could convert to svn so we could lose some of the old directory
structures still existant in the cvs repository (cpu vs cpu_jit...).
Question is,
does the conversion on sourceforge also copy our update history and
branches?
I wouldn't like to lose the diff between PearPC versions of the source.

This looks promising:
http://sourceforge.net/docs/E09/#import

Sebastian

Bill Fraser

2006-03-01 20:29:38 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://sourceforge.net/docs/E09/#import

Don't know if SF will convert it themselves, but if they don't, I've
used cvs2svn (http://cvs2svn.tigris.org/) before, and it works
perfectly for this.

Either way, importing svn repositories into SF.net is still rather
sketchy. I did it for one of my projects last week and it took several
submissions (and waiting ~10 minutes for each) before it finally
worked.

Probably still worth it though. CVS is a pain sometimes. ;)

Sebastian

-Bill

Daniel Foesch

2006-03-01 17:17:35 UTC

Post by Sebastian Biallas
Hello,
I have rewritten all assembler files to gnu assembler. This means pearpc
no longer depends on nasm.
Please check out CVS and test.

I get a HUGE dump of errors.

----One set----
jitc_mmu.S:790: Error: too many memory references for 'mov'
jitc_mmu.S:1163: Error: too many memory references for 'mov'
jitc_mmu.S:1181: Error: too many memory references for 'mov'
jitc_mmu.S:1526: Error: too many memory references for 'movaps'
jitc_mmu.S:1549: Error: too many memory references for 'movaps'

----Another set----
jitc_mmu.S:701: Error: Unrecognized token `<<14)'

jitc_mmu.S:701: Error: Unexpected token `'

jitc_mmu.S:701: Error: Unrecognized token `<<29)'

jitc_mmu.S:701: Error: Unexpected token `'

jitc_mmu.S:701: Error: Unrecognized token `<<8)|(1<<7)'

jitc_mmu.S:701: Error: Unexpected token `'

jitc_mmu.S:702: Error: Unrecognized token `<<6)|(1<<31)'

jitc_mmu.S:702: Error: Unexpected token `'

jitc_mmu.S:702: Error: Unrecognized token `<<6)|(1<<31)'

jitc_mmu.S:702: Error: Unexpected token `'

----

I looked on the GAS documentation, and it does support <<, and >>

I don't understand what it would be having a problem with.

--
Daniel Foesch

Sebastian Biallas

2006-03-01 17:27:40 UTC

Post by Daniel Foesch
I get a HUGE dump of errors.
----One set----
jitc_mmu.S:790: Error: too many memory references for 'mov'
jitc_mmu.S:1163: Error: too many memory references for 'mov'
jitc_mmu.S:1181: Error: too many memory references for 'mov'
jitc_mmu.S:1526: Error: too many memory references for 'movaps'
jitc_mmu.S:1549: Error: too many memory references for 'movaps'

These were real errors, fixed. (Which gas is this? I don't get these
errors. I'm using GNU assembler 2.16.91 20050610)

Post by Daniel Foesch
----Another set----
jitc_mmu.S:701: Error: Unrecognized token `<<14)'

I don't understand this.

pg_table_lookup(1<<6, 8, data)
pg_table_lookup(1<<6, 8, data)
pg_table_lookup(1<<6, 8, data) <------ line 701
pg_table_lookup(1<<6, 8, data)

Why should line 701 fail but not 700? This could be some preprocessor
error...

Sebastian

Daniel Foesch

2006-03-01 17:46:58 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

These were real errors, fixed. (Which gas is this? I don't get these
errors. I'm using GNU assembler 2.16.91 20050610)

That's cleaned up.

GNU assembler 2.15.90.0.1.1 20040303 (SuSE Linux)

Post by Daniel Foesch
----Another set----
jitc_mmu.S:701: Error: Unrecognized token `<<14)'

I don't understand this.
pg_table_lookup(1<<6, 8, data)
pg_table_lookup(1<<6, 8, data)
pg_table_lookup(1<<6, 8, data) <------ line 701
pg_table_lookup(1<<6, 8, data)
Why should line 701 fail but not 700? This could be some preprocessor
error...

jitc_mmu.S:700: Error: Unrecognized token `<<6)|(1<<31)'

jitc_mmu.S:700: Error: Unexpected token `'

jitc_mmu.S:700: Error: Unrecognized token `<<6)|(1<<31)'

jitc_mmu.S:700: Error: Unexpected token `'

jitc_mmu.S:700: Error: Unrecognized token `<<14)'

jitc_mmu.S:700: Error: Unexpected token `'

jitc_mmu.S:700: Error: Unrecognized token `<<29)'

jitc_mmu.S:700: Error: Unexpected token `'

jitc_mmu.S:700: Error: Unrecognized token `<<8)|(1<<7)'

jitc_mmu.S:700: Error: Unexpected token `'

It does, in fact, EVERY << operator hits this same error, I was just
printing a subset, sorry if that wasn't clear.

Also, in the comment header:

* This program is free software; you can r%edistribute it and/or modify

I think there's some stuff around that went wacko when you
search/replaced. (kind of like when suddenly strings that just
happend to contain "ppc" changed to "cos" when a certain company was
distributing a certain project ;) )

--
Daniel Foesch

Sebastian Biallas

2006-03-01 17:55:21 UTC

Post by Sebastian Biallas
These were real errors, fixed. (Which gas is this? I don't get these
errors. I'm using GNU assembler 2.16.91 20050610)

That's cleaned up.
GNU assembler 2.15.90.0.1.1 20040303 (SuSE Linux)

Well, actually your version is more correct.

Post by Daniel Foesch
It does, in fact, EVERY << operator hits this same error, I was just
printing a subset, sorry if that wasn't clear.

Urgs. Does this also happens if you put spaces around the <<?

Post by Daniel Foesch
* This program is free software; you can r%edistribute it and/or modify
I think there's some stuff around that went wacko when you
search/replaced. (kind of like when suddenly strings that just
happend to contain "ppc" changed to "cos" when a certain company was
distributing a certain project ;) )

LOL. But I could swear I used the "whole words only" option.

Sebastian

Daniel Foesch

2006-03-01 19:57:06 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sebastian Biallas
These were real errors, fixed. (Which gas is this? I don't get these
errors. I'm using GNU assembler 2.16.91 20050610)

That's cleaned up.
GNU assembler 2.15.90.0.1.1 20040303 (SuSE Linux)

Well, actually your version is more correct.

Post by Daniel Foesch
It does, in fact, EVERY << operator hits this same error, I was just
printing a subset, sorry if that wasn't clear.

Urgs. Does this also happens if you put spaces around the <<?

Yep :(

Have you actually run the produced executable after switching to GAS? or did
it just compile for you? It could be that it expects constants to be
prefixed with $ even in intel syntax. Although, I tried that, and it just
complained more, so I doubt it.

Post by Daniel Foesch
* This program is free software; you can r%edistribute it and/or

modify

Post by Daniel Foesch
I think there's some stuff around that went wacko when you
search/replaced. (kind of like when suddenly strings that just
happend to contain "ppc" changed to "cos" when a certain company was
distributing a certain project ;) )

LOL. But I could swear I used the "whole words only" option.

Yeah, I never trust search and replace much anymore heh.

--
Daniel Foesch

Sebastian Biallas

2006-03-01 20:10:28 UTC

Post by Daniel Foesch
Yep :(
Have you actually run the produced executable after switching to GAS? or
did it just compile for you?

I'm running the new version for some time now.

Sebastian

Sebastian Biallas

2006-03-01 20:31:14 UTC

Post by Daniel Foesch
It could be that it expects constants to
be prefixed with $ even in intel syntax.

Does this work for you?
- ------------------------------
.text
mov 1<<1, %eax
- ------------------------------

Maybe we should just replace all those "<<" constants with real constants.

Daniel Foesch

2006-03-01 20:43:17 UTC

Well, once I change it to:

movl $(1<<1), %eax

it works. The $ is needed in AT&T syntax to indicate a constant.

Although the code:

.intel_syntax
mov %eax, (1<<1)

begins generating the same errors. Without the ()'s the "unrecognized"
empty token error goes away.

It could be that between 2.15, (my version) and 2.16 (your version) they
added support for the << and >> operators in intel syntax?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Daniel Foesch
It could be that it expects constants to
be prefixed with $ even in intel syntax.

Does this work for you?
- ------------------------------
.text
mov 1<<1, %eax
- ------------------------------
Maybe we should just replace all those "<<" constants with real constants.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRAYEkv81M8QtvOSJAQJhSwgAsjgtnkYgkKFoczVx7wNc0QRhplwg/BGZ
CLvWU/eAyADot/lz6bPURFL7i+Cj3+23uO+YPiKgNt4Z/TsmLT/Ay/EY5U7pWRr8
tgNCfYeWrUObVnSTEknKgGYHW0tWWaqmPDyrpMa6rBKrPAFDtk9YWi9vE401ilCS
3I+DBkHGh4bct2f0fUOczeU1fmHXJ9hMSGwdnEEAoogSDKHjMFisO1UiJM/ceHHl
rspIc1e7wmE2CMybPoRgGO28ybiyrT5A4V3OkJsjezbYfYnOP+L8ZLF3/dmfrbV3
xRYvbJlLLIR9l+2iCgkaBj6isnjCUMR70aFERQXzIcWZFLCXsDbV4g==
=7FFu
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel

--
Daniel Foesch

Sebastian Biallas

2006-03-01 20:50:59 UTC

Post by Daniel Foesch
movl $(1<<1), %eax
it works. The $ is needed in AT&T syntax to indicate a constant.

Without the $ it's a load, but this shouldn't matter for the test.

Post by Daniel Foesch
.intel_syntax
mov %eax, (1<<1)
begins generating the same errors. Without the ()'s the "unrecognized"
empty token error goes away.
It could be that between 2.15, (my version) and 2.16 (your version) they
added support for the << and >> operators in intel syntax?

Maybe... I have no idea.

Sebastian

Daniel Foesch

2006-03-01 21:21:04 UTC

Post by Daniel Foesch
movl $(1<<1), %eax
it works. The $ is needed in AT&T syntax to indicate a constant.

Without the $ it's a load, but this shouldn't matter for the test.

Post by Daniel Foesch
.intel_syntax
mov %eax, (1<<1)
begins generating the same errors. Without the ()'s the

"unrecognized"

Post by Daniel Foesch
empty token error goes away.
It could be that between 2.15, (my version) and 2.16 (your version)

they

Post by Daniel Foesch
added support for the << and >> operators in intel syntax?

Maybe... I have no idea.
I've resolved my issue, by downloading binutils-2.16.1 and installing

movzx %edx, dx
movzx %edx, %dx

I also found some problems in vaccel with similarly unprefixed registers.

I've checked in those changes.

--
Daniel Foesch

Daniel Foesch

2006-03-01 21:17:24 UTC

Post by Daniel Foesch
movl $(1<<1), %eax
it works. The $ is needed in AT&T syntax to indicate a constant.

Without the $ it's a load, but this shouldn't matter for the test.

Maybe... I have no idea.
I've resolved my issue, by downloading binutils-2.16.1 and installing it.

Now, my gas doesn't complain, except for one line on 771:

movzx %edx, dx

I think this is supposed to be:

movzx %edx, %dx

--
Daniel Foesch

Sebastian Biallas

2006-03-01 21:58:54 UTC

Post by Sebastian Biallas
I've resolved my issue, by downloading binutils-2.16.1 and installing it.

So now we have a binutils dependency...

Post by Sebastian Biallas
movzx %edx, dx

I wonder why my gas doesn't catch these.

Sebastian

Daniel Foesch

2006-03-01 22:26:08 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Sebastian Biallas
I've resolved my issue, by downloading binutils-2.16.1 and installing it.

So now we have a binutils dependency...

Well, we were going to have that all along. Just now it's moved from
2.10to something later.

It might be a good idea to just change them all to constants rather than
shifts to avoid having such a high-level dependency. I'll try downgrading
my binutils and see if it is a 2.16 requirement or if 2.15 works fine, and
my SUSE linux just had a weird version.

Post by Sebastian Biallas
movzx %edx, dx

I wonder why my gas doesn't catch these.

I'd rather know why my AltiVec bug is happening rather than why your gas
didn't catch them ;)

What could cause this though... it's possible that there was an assumed
operand size on it, and it automatically chose either:
movzx %edx, word ptr dx
or
movzx %edx, byte ptr dx
It could also be that it just issues a warning and chose one of the above,
while mine errored. It's hard to say for sure, especially since I've had
all my experience with GAS using AT&T syntax.

--
Daniel Foesch

Sebastian Biallas

2006-03-01 22:40:05 UTC

Post by Daniel Foesch
It might be a good idea to just change them all to constants rather than
shifts to avoid having such a high-level dependency. I'll try
downgrading my binutils and see if it is a 2.16 requirement or if 2.15
works fine, and my SUSE linux just had a weird version.

Ok, I'll replace the constants (should have done this long before).

movzx %edx, dx

I wonder why my gas doesn't catch these.
I'd rather know why my AltiVec bug is happening rather than why your gas
didn't catch them ;)

Does your altivec bug only happen with SSE processors?

Post by Daniel Foesch
What could cause this though... it's possible that there was an assumed
movzx %edx, word ptr dx
or
movzx %edx, byte ptr dx

No, this would result in a linker error.

Sebastian

Daniel Foesch

2006-03-01 23:19:10 UTC

Ok, I'll replace the constants (should have done this long before).

movzx %edx, dx

I wonder why my gas doesn't catch these.
I'd rather know why my AltiVec bug is happening rather than why your gas
didn't catch them ;)

Does your altivec bug only happen with SSE processors?

Yes, actually the AltiVec bug still happens with all of my AltiVec
instructions interpreted (generic code). So, with my AltiVec code being
entirely interpreted, and not jitc'ed the bug still repros.

I need to check the generic core to see if it causes the same problem also,
but the generic core was out of commission for a while there, and I've not
check up on it recently.

Post by Daniel Foesch
What could cause this though... it's possible that there was an assumed
movzx %edx, word ptr dx
or
movzx %edx, byte ptr dx

No, this would result in a linker error.

Everything is just going to have different errors from something else. What
bothers me is how inconsistent the .intel_syntax form of GAS is.

If we were to use the AT&T syntax, I know that this is pretty stable, and
has changed little, and is highly tested (since every GCC program compiles
to assembly which GAS then turns to machine code.)

--
Daniel Foesch

Sebastian Biallas

2006-03-01 23:40:36 UTC

Post by Daniel Foesch
Yes, actually the AltiVec bug still happens with all of my AltiVec
instructions interpreted (generic code). So, with my AltiVec code being
entirely interpreted, and not jitc'ed the bug still repros.

Ok, maybe you have to repeat yourself, but how exactly can I reproduce
this bug?

Post by Daniel Foesch
Everything is just going to have different errors from something else.
What bothers me is how inconsistent the .intel_syntax form of GAS is.

Is it?

Post by Daniel Foesch
If we were to use the AT&T syntax, I know that this is pretty stable,
and has changed little, and is highly tested (since every GCC program
compiles to assembly which GAS then turns to machine code.)

So you are the second one today, volunteering to rewrite ~2500 lines of
code :)

Sebastian

Daniel Foesch

2006-03-02 00:23:49 UTC

Ok, maybe you have to repeat yourself, but how exactly can I reproduce
this bug?

Get a Tiger installation DVD, boot up with it using AltiVec mode. When the
language select screen pops up, you should immediately notice that it's
missing the Apple logo, and the "Next" button. OSX still responds to the
"Next" button, but it's not drawn.

It looks like some sort of conditional, I do know that the Apple logo gets
slightly composed into the background pattern, although I don't know about
the next button. Basically, if you boot to it as G3, and you boot to it as
G4 and take screen shots of both, the differences should be readily
apparent.

Post by Sebastian Biallas
Everything is just going to have different errors from something else.

Post by Daniel Foesch
What bothers me is how inconsistent the .intel_syntax form of GAS is.

Is it?

Well, how inconsistent it seems to be. First my gas didn't like using <<
and >> in intel syntax expressions, then your gas is fine with unprefixed
registers in intel syntax...

It just seems odd that the behaviour would change so drastically.

So you are the second one today, volunteering to rewrite ~2500 lines of
code :)
Oh, I've been saying this needs to be rewritten for a long time ;) Don't

take this as a new development.

--
Daniel Foesch

Sebastian Biallas

2006-03-02 00:54:24 UTC

Post by Daniel Foesch
Yes, actually the AltiVec bug still happens with all of my AltiVec
instructions interpreted (generic code). So, with my AltiVec code

being

Post by Daniel Foesch
entirely interpreted, and not jitc'ed the bug still repros.

Ok, maybe you have to repeat yourself, but how exactly can I reproduce
this bug?
Get a Tiger installation DVD,

Don't have one..

Post by Sebastian Biallas
boot up with it using AltiVec mode. When
the language select screen pops up, you should immediately notice that
it's missing the Apple logo, and the "Next" button. OSX still responds
to the "Next" button, but it's not drawn.

Hmm... It's very unlikely that we'll find this bug by reviewing the
code, since we both have already reviewed it a thousand times :)

Please try to engage the generic cpu.

Post by Sebastian Biallas
Well, how inconsistent it seems to be. First my gas didn't like using
<< and >> in intel syntax expressions, then your gas is fine with
unprefixed registers in intel syntax...
It just seems odd that the behaviour would change so drastically.

These are gas bugs, I guess because .intel_syntax doesn't seem to be
well tested. In fact gas seems to be only tested as a gcc backend and
nothing more.

Sebastian

Daniel Foesch

2006-03-02 01:12:47 UTC

Post by Daniel Foesch
Yes, actually the AltiVec bug still happens with all of my AltiVec
instructions interpreted (generic code). So, with my AltiVec code

being

Post by Daniel Foesch
entirely interpreted, and not jitc'ed the bug still repros.

Ok, maybe you have to repeat yourself, but how exactly can I

reproduce

Post by Sebastian Biallas
this bug?
Get a Tiger installation DVD,

Don't have one..

Hmm... It's very unlikely that we'll find this bug by reviewing the
code, since we both have already reviewed it a thousand times :)
Please try to engage the generic cpu.

Yeah, I really do doubt that it's going to be found by code review. I've
crawled over every part of the AltiVec code, and found one "undocument"
behavior of the AltiVec vcmp* instructions that I was hoping was the
problem, but to no avail.

I'll be working on getting the generic core working tonight.

These are gas bugs, I guess because .intel_syntax doesn't seem to be
well tested. In fact gas seems to be only tested as a gcc backend and
nothing more.

Most likely. You're quite correct that gas is poorly tested in the
.intel_syntax. The AT&T syntax is pretty heavily tested, there are quite a
few projects that still use raw assembly, but always in AT&T syntax.

Quite frustrating for a project like ours.

--
Daniel Foesch

Sebastian Biallas

2006-03-02 01:18:12 UTC

Post by Daniel Foesch
Most likely. You're quite correct that gas is poorly tested in the
.intel_syntax. The AT&T syntax is pretty heavily tested, there are
quite a few projects that still use raw assembly, but always in AT&T
syntax.

That's not the only problem. ".struct" and ".macro" aren't well-tested
either.

Post by Daniel Foesch
Quite frustrating for a project like ours.

Indeed.

Sebastian

Alex Smith

2006-03-02 07:19:06 UTC

I'm getting this while building:

g++ -Wundef -Wall -Woverloaded-virtual -fsigned-char -O2
-fomit-frame-pointer -g -fno-inline -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -pipe -o ppc -L/usr/X11R6/lib main.o ppc_img.o
ppc_font.o ppc_button_changecd.o configparser.o cpu/cpu_jitc_x86/libcpu.a
io/graphic/libgraphic.a io/ide/libide.a system/ui/x11/libui.a
debug/libdebug.a io/libio.a io/prom/libprom.a io/prom/fs/libfs.a
io/prom/fs/hfs/libhfs.a io/prom/fs/hfsplus/libhfsplus.a io/pic/libpic.a
io/pci/libpci.a io/macio/libmacio.a io/nvram/libnvram.a io/cuda/libcuda.a
io/3c90x/lib3c90x.a io/rtl8139/librtl8139.a io/usb/libusb.a tools/libtools.a
system/libsystem.a system/arch/x86/libsarch.a
system/osapi/posix/libsosapi.a -lpthread -lrt -lrt -lX11
cpu/cpu_jitc_x86/libcpu.a(jitc_mmu.o): In function
`ppc_effective_to_physical_data_write':jitc_mmu.S:(.text+0x2554): undefined
reference to `esp'
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[3]: Leaving directory `/home/alex/PearPC/pearpc/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/alex/PearPC/pearpc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alex/PearPC/pearpc'
make: *** [all] Error 2

Any ideas? I'm using binutils 2.16.91.0.6 and GCC 4.0.2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That's not the only problem. ".struct" and ".macro" aren't well-tested
either.

Post by Daniel Foesch
Quite frustrating for a project like ours.

Indeed.
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRAZH0/81M8QtvOSJAQLkNQf+JYMEi+XLmvCKL9Ft+AfXdEL8J/XHF35E
ReNxIskXysGDrjWkmm3sCPaoykETMWcivMtsvxoa+PCkhtxPy9Lfbclbs7pb8wNA
14VUO7F7VW3eM/UwQ/TVdq5kQEAbW9N+dE2zJjObzNhSXpvplmPd4+KLfQrjy7zc
tbF3OwbAYE8ETRmrenGRxqWxNEu8QER8upDMj2TNiuD7VtMGraS7jXzFPaQwD9A0
f1BPvTCBURvfIJReuoswKKYZY6CD0i3QpWGbirnpqF6JCAWa0JwCZ3nI9WmW5b6L
G0XT5HugFx4tQgsdcOpAx+TpYKEcRQT2jM1eMGGSdkY0D1ftpgZJLQ==
=1Yk3
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel

Daniel Foesch

2006-03-02 16:42:39 UTC

Post by Alex Smith
g++ -Wundef -Wall -Woverloaded-virtual -fsigned-char -O2
-fomit-frame-pointer -g -fno-inline -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -pipe -o ppc -L/usr/X11R6/lib main.o ppc_img.o
ppc_font.o ppc_button_changecd.o configparser.o cpu/cpu_jitc_x86/libcpu.a
io/graphic/libgraphic.a io/ide/libide.a system/ui/x11/libui.a
debug/libdebug.a io/libio.a io/prom/libprom.a io/prom/fs/libfs.a
io/prom/fs/hfs/libhfs.a io/prom/fs/hfsplus/libhfsplus.a io/pic/libpic.a
io/pci/libpci.a io/macio/libmacio.a io/nvram/libnvram.a io/cuda/libcuda.a
io/3c90x/lib3c90x.a io/rtl8139/librtl8139.a io/usb/libusb.a tools/libtools.a
system/libsystem.a system/arch/x86/libsarch.a
system/osapi/posix/libsosapi.a -lpthread -lrt -lrt -lX11
cpu/cpu_jitc_x86/libcpu.a(jitc_mmu.o): In function
undefined reference to `esp'
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[3]: Leaving directory `/home/alex/PearPC/pearpc/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/alex/PearPC/pearpc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alex/PearPC/pearpc'
make: *** [all] Error 2
Any ideas? I'm using binutils 2.16.91.0.6 and GCC 4.0.2

I just wanted to respond to this to let people know that Sebastian
fixed this problem.

--
Daniel Foesch

Alex Smith

2006-03-02 17:20:42 UTC

Cool, it's compiled. Let me try booting OS X

Post by Alex Smith

io/cuda/libcuda.a

Post by Alex Smith
io/3c90x/lib3c90x.a io/rtl8139/librtl8139.a io/usb/libusb.a

tools/libtools.a

Post by Alex Smith
system/libsystem.a system/arch/x86/libsarch.a
system/osapi/posix/libsosapi.a -lpthread -lrt -lrt -lX11
cpu/cpu_jitc_x86/libcpu.a(jitc_mmu.o): In function
undefined reference to `esp'
collect2: ld returned 1 exit status
make[3]: *** [ppc] Error 1
make[3]: Leaving directory `/home/alex/PearPC/pearpc/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/alex/PearPC/pearpc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/alex/PearPC/pearpc'
make: *** [all] Error 2
Any ideas? I'm using binutils 2.16.91.0.6 and GCC 4.0.2

I just wanted to respond to this to let people know that Sebastian
fixed this problem.
--
Daniel Foesch
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
that extends applications into web and mobile media. Attend the live
webcast
and join the prime developer group breaking into this new coding
territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel

Jens von der Heydt

2006-03-02 11:21:18 UTC

Post by Sebastian Biallas
So you are the second one today, volunteering to rewrite ~2500
lines of
code :)
Oh, I've been saying this needs to be rewritten for a long time ;)
Don't take this as a new development.

Maybe intel2gas at http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/
can help with this.
One can easily extend it's syntax, maybe it can help to prevent us to
change all .S by hand
when we really wanted at&t syntax.

Jens

Sebastian Biallas

2006-03-01 22:45:36 UTC

movzx %edx, dx

I wonder why my gas doesn't catch these.

I tested it. My gas doesn't need the % prefix for registers.

This is so ridiculous: I moved to gas because I wanted a more stable
platform. And now it looks like gas just has different problems than
nasm/yasm.

Sebastian

Jens von der Heydt

2006-03-02 09:33:26 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

movzx %edx, dx

I wonder why my gas doesn't catch these.

I tested it. My gas doesn't need the % prefix for registers.
This is so ridiculous: I moved to gas because I wanted a more stable
platform. And now it looks like gas just has different problems than
nasm/yasm.
Sebastian

Anyone tried this with a cygwin install ?

Jens

Sebastian Biallas

2006-03-02 10:21:10 UTC

Post by Jens von der Heydt
Anyone tried this with a cygwin install ?

Look in my headers.

Sebastian

Jens von der Heydt

2006-03-02 10:36:48 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jens von der Heydt
Anyone tried this with a cygwin install ?

Look in my headers.
Sebastian

Yes, I just saw it while doing changes to compile .S on x64-64
systems. Sorry!

Bruce Allen

2006-03-02 00:25:04 UTC

If it ain't broke - don't fix it?

--
Bruce Allen

-------------- Original message --------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, maybe you have to repeat yourself, but how exactly can I reproduce
this bug?

Post by Daniel Foesch
Everything is just going to have different errors from something else.
What bothers me is how inconsistent the .intel_syntax form of GAS is.

Is it?

So you are the second one today, volunteering to rewrite ~2500 lines of
code :)
Sebastian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEVAwUBRAYw9P81M8QtvOSJAQL5zwf+JMWlFYxK90h/Zk4Mm38GvFj/PqdnSIo/
4rEr/e3SKniW+RX3rZxHzxqstZ9DqpQs14Dm2sTskrYs0I+ZE327eeyV2eh0DICx
vWn5eiLiP8pek2cOc88GWs3Skm2ttSj5f1GdkqC1KBk+j8yTeAjoX0K5z/6lPOVH
45zqJErsqEN5WcBm0vCF2BcXNSOqwMS/BjaFWRx62SvVUiaElnv5pKR7rFuF68zy
jy+j2pUpatJ5HlmpYjceBO2EPep2WlyFSTyawamqxac/NOMRzOcTPJIjTtxvfVn/
zerXAuxGzoQDZStcoIeBqJCvnDKVfLP9G3SZpmpYgtOXKc8+6Xufsw==
=0VQs
-----END PGP SIGNATURE-----
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Pearpc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/pearpc-devel

Ryan Hennessee

2006-03-02 00:38:16 UTC

Bruce Allen <***@comcast.net> wrote:
If it ain't broke - don't fix it?

--

Ryan Hennessee

2006-03-02 14:25:07 UTC

I may be out of date, but I beleive the new Intel Macs do not have a Classic Environment. If someone werer to get Pearpc to ccompile and run on an Intel Mac AND get Mac OS9 bootable we could have a classic environment for Intel Macs. What do you guys think about it? Is it doable?

Ryan

---------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail makes sharing a breeze.

C. Rayden

2006-03-02 18:15:08 UTC

Would there be much purpose for it? I imagine that with a hypothetical
greater availability of Mac hardware, and the possibility of a dual boot,
most worthwhile applications would be available in one form or another and
eliminate the need for classic. Either that or the lack of a Classic x86
environment would force distributors to have the code ported...

Or would this be a just-because-we-can-do-it project?

Chris

Post by Ryan Hennessee
I may be out of date, but I beleive the new Intel Macs do not have a
Classic Environment. If someone werer to get Pearpc to ccompile and run on
an Intel Mac AND get Mac OS9 bootable we could have a classic environment
for Intel Macs. What do you guys think about it? Is it doable?
Ryan
------------------------------
Yahoo! Mail
Bring photos to life! New PhotoMail
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=39174/*http://photomail.mail.yahoo.com>makes sharing a breeze.

Ryan Hennessee

2006-03-02 18:18:57 UTC

This post might be inappropriate. Click to display it.

Daniel Foesch

2006-03-02 19:53:01 UTC

Post by Ryan Hennessee
Probably more of a "we-can-do-it" project, and also for those want "top of
the line" hardware, but still have a few favorite programs running under
Classic that either aren't updated anymore, or the updates for them suck.
Ryan

Also, there are a number of people who have classic versions of their
favorite game (Such as, say, Sam & Max) which don't require a stellar
computer to play, and it's infrequent enough to justify most other options.

In any case, if we got OS9 booting, it would be a good thing, and we are
working towards trying to get something for OS9, but as of lately there have
been a number of obstacles in the way of poor documentation, or a
misunderstanding of the documentation for OpenFirmware as published that
causes problems with booting MacOS9.

It's something that I looked into fairly recently, but realized that there's
a lot of work involved, and would require rewriting a significant part of
the OpenFirmware structures, and functions. That's why we were just going
to wait on OpenBIOS, but they've had just as many problems as us getting
things to work, just in different places.

--
Daniel Foesch

Ryan Hennessee

2006-03-02 20:05:47 UTC

I've used Sheepshaver to boot Mac OS 9.0.4. Granted it won't boot 9.1-9.2.2.which I thought was a MMU issue Is there something that Sheepshaver is doing that can't be implemented in PearPC? I haven't looked at Sheepshaver's code, and even if I did it would take me weeks to understand it all. I barely understand what's going on in Pearpc's 'subsystems', and nothing at all about the CPU core.

Ryan

Daniel Foesch <***@gmail.com> wrote:
2006/3/2, Ryan Hennessee <***@yahoo.com>: Probably more of a "we-can-do-it" project, and also for those want "top of the line" hardware, but still have a few favorite programs running under Classic that either aren't updated anymore, or the updates for them suck.

Ryan

Also, there are a number of people who have classic versions of their favorite game (Such as, say, Sam & Max) which don't require a stellar computer to play, and it's infrequent enough to justify most other options.

In any case, if we got OS9 booting, it would be a good thing, and we are working towards trying to get something for OS9, but as of lately there have been a number of obstacles in the way of poor documentation, or a misunderstanding of the documentation for OpenFirmware as published that causes problems with booting MacOS9.

It's something that I looked into fairly recently, but realized that there's a lot of work involved, and would require rewriting a significant part of the OpenFirmware structures, and functions. That's why we were just going to wait on OpenBIOS, but they've had just as many problems as us getting things to work, just in different places.

--
Daniel Foesch

---------------------------------
Brings words and photos together (easily) with
PhotoMail - it's free and works with Yahoo! Mail.

Daniel Foesch

2006-03-02 20:27:00 UTC