abi
If we can select the ABi for our program (using gcc), why is there a
need for ABI stability?!
why not put it on a define
#define abi v3
int main() {
}
Each user would just have to compile the code, to follow the abi...no
need to worry changing it
thanks
andre
Re: abi
Because implementing an ABI, or dealing with an incompatibnle change, is hard
work. Also, ABI stability means that old binaries work. So ABI stability
isn't so much a requirement for the compiler as it is a requirement for any
sane operating system. An OS that changes ABI without an extremely good reason
is an OS that doesn't care about compatibility, which means it doesn't care
about its customers.
The MIPS examples I pointed to are a good illustration of this. The original
("O32") ABI is for MIPS with 32 bit registers and 32 bit addressing. N32 and
N64 were introduced by SGI to support 64 bit registers, and (for N64) 64 bit
pointers. That's a very compelling benefit. 64 bbit addressing is obvious,
and the performance benefit from using 64 bit registers on machines that have
them is very large. So there, the quite large cost of doing this was totally
justified.
paul
> On Jul 9, 2023, at 4:55 PM, André Albergaria Coelho via Gcc
> wrote:
>
> If we can select the ABi for our program (using gcc), why is there a need for
> ABI stability?!
>
> why not put it on a define
>
>
> #define abi v3
>
> int main() {
>
> }
>
>
> Each user would just have to compile the code, to follow the abi...no need to
> worry changing it
>
>
> thanks
>
>
> andre
>
gcc-14-20230709 is now available
Snapshot gcc-14-20230709 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20230709/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision d6c1d7c4009bfe759719675ce3bc03ca503b9bf4 You'll find: gcc-14-20230709.tar.xz Complete GCC SHA256=c988390f6ae1855b581e44744f6035c11b6e194a5b53a08edd108bc9f4461c2f SHA1=8086ff9b41dc4e8641b11d3f01231342145aa42a Diffs from 14-20230702 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: abi
Can we debate in this mailing list? thanks
On 7/9/23 22:04, Paul Koning wrote:
Because implementing an ABI, or dealing with an incompatibnle change, is hard
work.
you could just use one ABI..(that's what you have)..you can use other
, only at a cost of specifying an ABI version
the abi is text though..so you only have to write a text file
Also, ABI stability means that old binaries work
when you mean binaries, do you mean ELF files? executable files?
. So ABI stability isn't so much a requirement for the compiler as it is a
requirement for any sane operating system.
what does a calling convention, has to do with syscalls?! and syscalls,
and calling conventions, have to do with size and layouts?
used wikipedia definition
..https://en.wikipedia.org/wiki/Application_binary_interface
how can the OS, have a binary interface?!!
for example:
prtinf("abc"),
asm (say mov $123,%eax)
binary instruction is 010110101 (for example)...how can the operating
system know what interface to use?!
say i have 101010110101 1010101010101 , how does the O.S works on
binary files?! say how is the syscall used (at binary level)..it had to
be compiled / assembled
int main() {
write(123,&test_ptr,,count);
}
say write syscall is "101010101001" in binary ,so how does the O.S
interfaces this ? does the O.S. separate binary numbers?!?
unless you meant ELF as "binary program"
An OS that changes ABI without an extremely good reason is an OS that
doesn't care about compatibility, which means it doesn't care about its
customers.
The MIPS examples I pointed to are a good illustration of this. The original
("O32") ABI is for MIPS with 32 bit registers and 32 bit addressing. N32 and
N64 were introduced by SGI to support 64 bit registers, and (for N64) 64 bit pointers.
That's a very compelling benefit. 64 bbit addressing is obvious, and the performance
benefit from using 64 bit registers on machines that have them is very large. So there,
the quite large cost of doing this was totally justified.
The benefit would be for the user...code like it wants (for example,
return value in %ecx)..which is the ultimate reason to use compilers
and also, the benefit would be to use every ABI possible (choosing the best)
paul
On Jul 9, 2023, at 4:55 PM, André Albergaria Coelho via Gcc
wrote:
If we can select the ABi for our program (using gcc), why is there a need for
ABI stability?!
why not put it on a define
#define abi v3
int main() {
}
Each user would just have to compile the code, to follow the abi...no need to
worry changing it
thanks
andre
andre
Tiny asm (continued)
Hi The assembler checks at each instruction if the instruction is within the selected subset of risc-v extensions or not. I do not quite understand why this check is done here. I suppose that gcc, before emitting any instruction does this check too, somewhere. Because if an instruction is emitted to the assembler and the assembler rejects it, there is no way to pass that information back to the compiler, and emitting an obscure error message about some instruction not being legal will not help the user at all that probably doesn’t know any assembler language. I would like to drop this test in tiny-asm, but I am not 100% sure that it is really redundant. The checks are expensive to do, and they are done at EACH instruction... In the other hand, if the assembler doesn’t catch a faulty instruction, the user will know that at runtime (maybe) with an illegal instruction exception or similar… That would make bugs very difficult to find. Question then: can the assembler assume that gcc emits correct instructions? Thanks in advance for your attention. Jacob
Re: Tiny asm (continued)
On Sun, Jul 9, 2023 at 11:24 PM jacob navia wrote: > > Hi > The assembler checks at each instruction if the instruction is within the > selected subset of risc-v extensions or not. I do not quite understand why > this check is done here. > > I suppose that gcc, before emitting any instruction does this check too, > somewhere. Because if an instruction is emitted to the assembler and the > assembler rejects it, there is no way to pass that information back to the > compiler, and emitting an obscure error message about some instruction not > being legal will not help the user at all that probably doesn’t know any > assembler language. > > I would like to drop this test in tiny-asm, but I am not 100% sure that it is > really redundant. The checks are expensive to do, and they are done at EACH > instruction... > > In the other hand, if the assembler doesn’t catch a faulty instruction, the > user will know that at runtime (maybe) with an illegal instruction exception > or similar… That would make bugs very difficult to find. > > Question then: can the assembler assume that gcc emits correct instructions? Two things, inline-asm and hand written assembly code. > > Thanks in advance for your attention. > > Jacob
