[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: apple2-v003-linux.tar.gz
In article <331C68E4.4D83@baldmountain.bbn.com>,
Aaron Culliney <chernabog@baldmountain.bbn.com> wrote:
>Christian Koechli wrote:
>>
>> I got the new file from ftp.apple.asimov.net unpacked it
>> and tried to compile it on my RedHat 4.1 (kernel 2.0.27) linux box:
>>
>> # make
>> gcc -I/usr/include -Wall -c apple2.S
>> /tmp/cca01775.s: Assembler messages:
>> /tmp/cca01775.s:2163: Error: register does not match opcode suffix
>> /tmp/cca01775.s:2171: Error: register does not match opcode suffix
>> make: *** [apple2.o] Error 1
>>
>
>Someone else reported this problem with RH4.1 and gcc v.2.7.2.1. (I
>currently use RH3.0.3, kernel2.0.23, on an i586 with gcc v2.7.2 and
>everything works just fine)
>
Well, I get the problem with gcc 2.7.2.1 on an i586. It's a simple
thing to fix, though. Here's the patch:
===== BEGIN PATCH =====
*** apple2.S Tue Mar 4 12:52:38 1997
--- apple2.S~ Sat Mar 1 15:15:25 1997
***************
*** 1572,1590 ****
/* ----------------------------------
HANG instruction
---------------------------------- */
op_HANG:
! decw PC_Reg
Continue
/* ----------------------------------
NOP_2 instruction
---------------------------------- */
op_NOP_2:
! incw PC_Reg
Continue
/* ----------------------------------
NOP_3 instruction
---------------------------------- */
--- 1572,1590 ----
/* ----------------------------------
HANG instruction
---------------------------------- */
op_HANG:
! decb PC_Reg
Continue
/* ----------------------------------
NOP_2 instruction
---------------------------------- */
op_NOP_2:
! incb PC_Reg
Continue
/* ----------------------------------
NOP_3 instruction
---------------------------------- */
===== END PATCH =====
As you see, the patch looks like it fixes a couple of bugs. The
program counter being treated as a byte value when it should be a word.
I don't suspect that the HANG and NOP_2 operations are often invoked in
real code, so it shouldn't be a big problem. I suspect that it only
causes problems on page boundaries in the virtual machine, if the
byte-ordering is low-high for the PC. (reminiscent of the 6502 indirect
jump bug).
Oh, this problem was also in v002, I patched it and kept going.
--
Christopher Neufeld - Not a graduate student neufeld@physics.utoronto.ca
Home page: http://caliban.physics.utoronto.ca/neufeld/Intro.html
"Don't edit reality for the sake of simplicity"