Issue with as86/ld86 and ORG

[myk]

Are the changes on sourceforge? The files on there I see are pretty out of date.

Edit: NM, I see you sub'd them to the SVN

[myk]

When I do a make release when I check out revision 65 I'm getting a bunch of errors

Code: Select all

g++ -O2 -I./include -DX86LIB_BUILD -c x86Lib.cpp -o objs/x86Lib.o
In file included from ./include/x86Lib.h:430,
                 from x86Lib.cpp:31:
./include/opcode_def.h:478: error: extra qualification ‘x86Lib::x86CPU::’ on member ‘ReadByte’
./include/opcode_def.h:486: error: extra qualification ‘x86Lib::x86CPU::’ on member ‘ReadWord’
./include/opcode_def.h:504: error: extra qualification ‘x86Lib::x86CPU::’ on member ‘ReadDword’
./include/opcode_def.h:522: error: extra qualification ‘x86Lib::x86CPU::’ on member ‘WriteByte’
./include/opcode_def.h:530: error: extra qualification ‘x86Lib::x86CPU::’ on member ‘WriteWord’
./include/opcode_def.h:544: error: extra qualification ‘x86Lib::x86CPU::’ on member ‘WriteDword’
In file included from ./include/x86Lib.h:438,
                 from x86Lib.cpp:31:
./include/x86Lib_internal.h:293: error: definition of ‘uint16_t x86Lib::ModRM16::GetRegD()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:324: error: definition of ‘uint16_t x86Lib::ModRM16::GetDisp()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:359: error: definition of ‘void x86Lib::ModRM16::ModRM16(x86Lib::x86CPU*)’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:369: error: definition of ‘void x86Lib::ModRM16::ModRM16()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:375: error: definition of ‘uint8_t x86Lib::ModRM16::ReadByter()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:390: error: definition of ‘uint16_t x86Lib::ModRM16::ReadWordr()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:406: error: definition of ‘uint32_t x86Lib::ModRM16::ReadDword()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:425: error: definition of ‘void x86Lib::ModRM16::WriteByter(uint8_t)’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:440: error: definition of ‘void x86Lib::ModRM16::WriteWordr(uint16_t)’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:455: error: definition of ‘void x86Lib::ModRM16::WriteDword(uint32_t)’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:472: error: definition of ‘uint8_t x86Lib::ModRM16::GetLength()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:492: error: definition of ‘uint8_t x86Lib::ModRM16::GetExtra()’ is not in namespace enclosing ‘x86Lib::ModRM16’
./include/x86Lib_internal.h:496: error: definition of ‘uint16_t x86Lib::ModRM16::ReadOffset()’ is not in namespace enclosing ‘x86Lib::ModRM16’
make: *** [release] Error 1 

[earlz]

yea. I'm in bad need of making a new release.. If you haven't been using the SVN version(and instead the release version) then you'll have to convert some of your code. You can look in tester.cpp for the changes between the two API versions. You can email me at earlz -AT- earlz.biz.tm if you want to take this off the forum lol or if you have XMPP I'm on at hackr9483 -AT gmail.com

[myk]

Yea, I see I'll need to update my code, but the make release was just for building the library, that doesn't seem to be working for me. Any ideas?

[myk]

Got another one for ya,

Code: Select all

NOT DX

isn't handled and gives a CpuInt_excp at the group_F7 handing. The GetExtra value is 2 but is unhandled.

[myk]

I just removed all of the NOT's from my code (1 place, inverting the DX register to write to the hardware LEDs) and ran it and dayum! it boots to the main menu without crashing! Now I just have to implement a way of sending keys to it and need to parse the LCD output better and we've (so far) got a working emulator!

[earlz]

ok. I've updated it up to revision 70 so try updating your code. It should build. I use an old version of gcc usually, so thats why some little bugs were in there but compiled for me.. I tested it with the latest gcc and it works now though

as for NOT DX I'll add that..

edit:
Ok, NOT rm/8 and rm/16 opcodes are added..

man I wasn't aware I was missing so many lol

[myk]

Yea I was following your progress last night

I think this is working out well, looks like this old program of mine is doing some good testing of x86Lib.

I'm currently creating an LCDDisplay class that creates a display buffer and updates it on the console. When I'm done it will handle all of the LCD commands.

[earlz]

I edited my post.. lol

Is this LCD class and such going to be open source? I think it would be neat to have a /example_devices directory or something in my SVN..

[myk]

Yea I've got no problem with that.

Is there a good way of managing devices? Currently I kinda hacked it into PhysMemory but I don't really like having that class depending on a LCDDisplay class that may or may not be used. Is there anything like your InstallOp function that could install a device at a certain address?

I need to switch over to the SVN version of your code lol. Currently I'm not even using it as a library since xcode is was giving me trouble when I compiled it and then tried using it in my project... blah... I'm not too familiar with these dev tools.

[myk]

By the way, I'm getting a build error with the library at SVN V. 71

Code: Select all

g++ -O2 -I./include -DX86LIB_BUILD -c x86Lib.cpp -o objs/x86Lib.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/ect.cpp -o objs/ops/ect.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/maths.cpp -o objs/ops/maths.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/flow.cpp -o objs/ops/flow.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/strings.cpp -o objs/ops/strings.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/flags.cpp -o objs/ops/flags.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/store.cpp -o objs/ops/store.o
g++ -O2 -I./include -DX86LIB_BUILD -c ops/groups.cpp -o objs/ops/groups.o
ar crs libx86Lib.a objs/x86Lib.o objs/ops/ect.o objs/ops/groups.o objs/ops/store.o objs/ops/flags.o objs/ops/strings.o objs/ops/flow.o objs/ops/maths.o
g++ -O2 -I./include -DX86LIB_BUILD -c tester.cpp -o objs/tester.o
g++ -O2 -I./include -DX86LIB_BUILD -static -o x86Lib_test objs/tester.o -lx86Lib -L.
ld: library not found for -lcrt0.o
collect2: ld returned 1 exit status
make: *** [release] Error 1

Any idea what that means?

Edit: Looks this has something to do with OSX and static libraries...

[myk]

Ok got it, user programs are not allowed to link statically to libraries...

removing -static from building the tester app fixed it

[earlz]

Yea I've got no problem with that.

Is there a good way of managing devices? Currently I kinda hacked it into PhysMemory but I don't really like having that class depending on a LCDDisplay class that may or may not be used. Is there anything like your InstallOp function that could install a device at a certain address?

I need to switch over to the SVN version of your code lol. Currently I'm not even using it as a library since xcode is was giving me trouble when I compiled it and then tried using it in my project... blah... I'm not too familiar with these dev tools.

I don't compile it often with windows.. so I don't know much about that...

and for Managing devices.. I don't have any functionality built in at the moment for that.

I do suppose I could rewrite the interface so that you install address ranges. That would be pretty simple since the PhysMemory class could just have some built in functions for handling that.. but it would completely change that part of the API..

I think your right though. A better way of handling devices should be used... I'll try to come up with something after I implement like 5 more missing opcodes(group FE)

[myk]

Ok, got everything ported over to using a library built from SVN. I had some trouble linking in the DumpState code so I just hacked it out for the time being. It was giving me some very long error doing with standard output or something.

I'm going to get this current code to where I was before and then start up on coding up some LCD command parsing.

[earlz]

Ok, got everything ported over to using a library built from SVN. I had some trouble linking in the DumpState code so I just hacked it out for the time being. It was giving me some very long error doing with standard output or something.

I'm going to get this current code to where I was before and then start up on coding up some LCD command parsing.

what problems were there with the DumpState?

and it should actually have every opcode in it now.

and for device management I tried seeing if maybe you could use inheritance and I don't think it'll work without virtual functions which I prefer to avoid since they are slow.

So I think I'm going to have to have an InstallDevice function or something which can maybe contain both ports and memory access. I'll have to think of how to do this though so its lightweight, simple, and fast though.