OSDev.org

iansjack wrote:The real answer real is to use a proper assembler/linker so that you can make all calls relative and save even more memory.

I will use whatever assembler I want to use.

onlyonemac wrote:

iansjack wrote:The real answer real is to use a proper assembler/linker so that you can make all calls relative and save even more memory.

I will use whatever assembler I want to use.

Of course you will. So it's a good thing that you are using one that works in the required way.

And you are, of course, free to use inefficient far calls and returns if you wish (although it seems to have caused you a deal of trouble); just don't make up fallacious rationalizations for your choice.

iansjack wrote:[...] just don't make up fallacious rationalizations for your choice.

I wasn't.

onlyonemac wrote:

iansjack wrote:[...] just don't make up fallacious rationalizations for your choice.

I wasn't.

I don't want to waste memory/registers with having to specify an address.

iansjack wrote:

I don't want to waste memory/registers with having to specify an address.

I meant as in, having to find another memory location somewhere to put an address, or having to trash a register over it.

Anyway I realised that for a near call you don't need to add the base address of the code being executed, as the destination is relative to the current location and does not depend on the base address (position-independent code, duh). Somehow I forgot about that for a moment, as of course I have always been aware that the use of relative (near) jumps/calls is the simplest form of position-independent code, so I should have known that the base address does not matter.

onlyonemac wrote:as86

Please use an assembler that has been updated in the past 22 years.

onlyonemac wrote:No it's not position-independent code. It's a few low-level utility routines (such as "beep") which need to be located at known addresses such that they can be called from anywhere wihtout having to calculate an offset. Thus I can call them simply by calling their address - except that that's proving more complicated than it should be.

A proper assembler (and linker) will calculate the correct offsets for you. I like yasm, but nasm and gas are also sensible choices.

Octocontrabass wrote:

onlyonemac wrote:as86

Please use an assembler that has been updated in the past 22 years.

My main reason for that choice is that I find GAS syntax confusing, and prefer Intel syntax. Until I can find (i.e. someone writes) another FOSS assembler that uses Intel syntax, I will stay with as86.

Octocontrabass wrote:A proper assembler (and linker) will calculate the correct offsets for you. I like yasm, but nasm and gas are also sensible choices.

The linker issue actually has nothing to do with my choice of assembler. as86 can work with ld86 to link object files. Now if only I understood the more complicated aspects of labels, load addresses, etc. and knew how to use all of that stuff to produce code that will actually execute correctly at the address that I intend on executing it at, then I would try using them. But until then, I manage pretty well with my toolchain and I'm too busy to put the project on halt while I try to figure out how a linker works. I might read a tutorial if I had the time. Same goes for writing part of my code in C (which, as that is especially something that I would like to do here and there, I might well research).

onlyonemac wrote:Until I can find (i.e. someone writes) another FOSS assembler that uses Intel syntax, I will stay with as86.

As far as I know, yasm, nasm, and gas all fit in this category. (Yes, gas supports Intel syntax.)

onlyonemac wrote:Now if only I understood the more complicated aspects of labels, load addresses, etc. and knew how to use all of that stuff to produce code that will actually execute correctly at the address that I intend on executing it at, then I would try using them.

Um, okay.

Octocontrabass wrote:As far as I know, yasm, nasm, and gas all fit in this category. (Yes, gas supports Intel syntax.)

Perhaps if somebody bothered to mention that in a way that it isn't easily missed (i.e. without having to, I assume, actually install GAS and read the manual to find one obscure command-line option to switch to Intel syntax), then I might have reconsidered. I may look into this some time in the future.

Octocontrabass wrote:Um, okay.

Yeah I've read that page before.

onlyonemac wrote:Perhaps if somebody bothered to mention that in a way that it isn't easily missed

If you say so.

Octocontrabass wrote:

onlyonemac wrote:Perhaps if somebody bothered to mention that in a way that it isn't easily missed

If you say so.

Well it's not like I'm going to think of Googling the use of one assembler with a non-matching syntax, as I can't expect that there's going to be any results.

iansjack wrote:http://wiki.osdev.org/GAS

Yeah well I missed that. Searched my system's package repositories for "intel syntax" and got directed to as86.

onlyonemac wrote:

iansjack wrote:http://wiki.osdev.org/GAS

Yeah well I missed that. Searched my system's package repositories for "intel syntax" and got directed to as86.

I'd respectfully suggest that you need to use a different package system. (Yeah - I know - no-one's going to tell you what package system to use).

I understand that you might have had trouble discovering that GAS supports both syntaxes (even though I thought that was a pretty universal truth) but that you didn't get nasm or yasm as suggestions is unforgivable.

iansjack wrote:I'd respectfully suggest that you need to use a different package system. (Yeah - I know - no-one's going to tell you what package system to use).

Actually I use apt with my Ubuntu system.