aboutsummaryrefslogtreecommitdiff
path: root/x86_64-gen.c
Commit message (Collapse)AuthorAgeFilesLines
* x86-64: Fix call saved register restoreMichael Matz2012-06-101-2/+2
| | | | | | Loads of VT_LLOCAL values (which effectively represent saved addresses of lvalues) were done in VT_INT type, loosing the upper 32 bits. Needs to be done in VT_PTR type.
* x86_64: Fix compares with NaNs.Michael Matz2012-05-131-2/+31
| | | | | | Comparisons with unordered doubles was broken, NaNs always compare unequal (and unordered) to everything, including to itself.
* x86_64: Fix segfault for global dataMichael Matz2012-04-181-1/+1
| | | | | | | | | | | When offsetted addresses of global non-static data are computed multiple times in the same statement the x86_64 backend uses gen_gotpcrel with offset, which implements an add insn on the register given. load() uses the R member of the to-be-loaded value, which doesn't yet have a reg assigned in all cases. So use the register we're supposed to load the value into as that register.
* x86_64: Fix indirection in struct paramatersMichael Matz2012-04-181-16/+23
| | | | | | | | | | | | | The first loop setting up struct arguments must not remove elements from the vstack (via vtop--), as gen_reg needs them to potentially evict some argument still held in registers to stack. Swapping the arg in question to top (and back to its place) also simplifies the vstore call itself, as not funny save/restore or some "non-existing" stack elements need to be done. Generally for a stack a vop-- operation conceptually clobbers that element, so further references to it aren't allowed anymore.
* x86_64: fix loading of LLOCAL floatsgrischka2012-03-051-4/+8
| | | | | | | | See also commit 9527c4949fd94adb2567229413c70c19b663a118 On x86_64 we need to extend the reg_classes array because load() is called for (at least) R11 too, which was not part of reg_classes previously.
* win64: va_arg with structuresgrischka2011-07-141-34/+38
|
* tccrun: win64: add unwind function table for dynamic codegrischka2011-07-141-3/+4
| | | | | This works only when tcc.exe is compiled using MSC. MinGW does something in the startup code that defeats it.
* Make alignments for struct arguments 8 bytesShinichiro Hamaji2010-12-281-4/+4
| | | | | The ABI (http://www.x86-64.org/documentation/abi.pdf) says "The size of each argument gets rounded up to eightbytes"
* Probably wrong stack alignment for struct on Win64Shinichiro Hamaji2010-08-271-1/+1
|
* Fix alignment around struct for SSE.Shinichiro Hamaji2010-08-271-6/+18
| | | | | | | - Fix a wrong calculation for size of struct - Handle cases where struct size isn't multple of 8 - Recover vstack after memcpy for pushing struct - Add a float parameter for struct_assign_test1 to check SSE alignment
* tccpe: improve dllimport/export and use for tcc_add_symbolgrischka2010-01-141-4/+4
|
* build from multiple objects: fix other targetsgrischka2009-12-201-1/+1
|
* x86-64: fix gtst, back to only 5 regs for nowgrischka2009-12-201-17/+9
|
* x86-64: use r8/r9 as generic integer registersgrischka2009-12-201-151/+98
|
* x86-64: use r8,r9 as load/store registersgrischka2009-12-201-43/+74
|
* use vpushv in some placesgrischka2009-12-201-1/+1
|
* win64: add tiny unwind data for setjmp/longjmpgrischka2009-12-201-104/+232
| | | | | | | | | This enables native unwind semantics with longjmp on win64 by putting an entry into the .pdata section for each compiled fuction. Also, the function now use a fixed stack and store arguments into X(%rsp) rather than using push.
* allow tcc be build from separate objectsgrischka2009-12-201-14/+24
| | | | If you want that, run: make NOTALLINONE=1
* tccpe: improve dllimportgrischka2009-12-191-0/+10
|
* integrate x86_64-asm.c into i386-asm.cgrischka2009-12-191-2/+13
| | | | | Also, disable 16bit support for now as it causes bugs in 32bit mode. #define I386_ASM_16 if you want it.
* x86-64: fix udiv, add cqto instructiongrischka2009-12-191-1/+7
|
* x86-64: Fix stab debug information.Shinichiro Hamaji2009-08-241-1/+2
| | | | | We need 32bit relocations for code and 64bit for debug info. Introduce a new macro R_DATA_PTR to distinguish the two usages.
* cleanup: constify some global datagrischka2009-07-181-3/+3
|
* x86-64: fix load() for const pointers: (void*)-2grischka2009-07-181-21/+22
|
* x86-64: chkstk, allocagrischka2009-07-181-1/+2
|
* pe32+ target: adjust x86_64-gen.cgrischka2009-07-181-25/+115
| | | | | | | | - calling conventions are different: * only 4 registers * stack "scratch area" is always reserved * doubles are mirrored in normal registers - no GOT or PIC there
* Improve the test coverage: !val for float/double/long long f.Shinichiro Hamaji2009-04-181-1/+0
|
* x86-64: Combine buffers of sections before we call tcc_run().Shinichiro Hamaji2009-04-181-1/+1
| | | | | | | - Now we can run tcc -run tcc.c successfully, though there are some bugs. - Remove jmp_table and got_table and use text_section for got and plt entries. - Combine buffers in tcc_relocate(). - Use R_X86_64_64 instead of R_X86_64_32 for R_DATA_32 (now the name R_DATA_32 is inappropriate...).
* Generate PIC code so that we can create shared objects properly.Shinichiro Hamaji2009-04-181-29/+97
| | | | | | - Add got_table in TCCState. This approach is naive and the distance between executable code and GOT can be longer than 32bit. - Handle R_X86_64_GOTPCREL properly. We use got_table for TCC_OUTPUT_MEMORY case for now. - Fix load() and store() so that they access global variables via GOT.
* x86-64: Save RDX and RCX before we use them as function parameters.Shinichiro Hamaji2009-04-181-2/+2
| | | | When the function call is indirect, these registers may be broken to load a function pointer.
* Generate PIC for addresses of symbols.Shinichiro Hamaji2009-04-181-11/+8
|
* A uint64 bug fix on x86-64Shinichiro Hamaji2009-04-181-1/+1
| | | | | 64bit unsigned literal was handled as 32bit integer. Added a unittest to catch this.
* Add support of x86-64.Shinichiro Hamaji2008-12-021-0/+1355
Most change was done in #ifdef TCC_TARGET_X86_64. So, nothing should be broken by this change. Summary of current status of x86-64 support: - produces x86-64 object files and executables. - the x86-64 code generator is based on x86's. -- for long long integers, we use 64bit registers instead of tcc's generic implementation. -- for float or double, we use SSE. SSE registers are not utilized well (we only use xmm0 and xmm1). -- for long double, we use x87 FPU. - passes make test. - passes ./libtcc_test. - can compile tcc.c. The compiled tcc can compile tcc.c, too. (there should be some bugs since the binary size of tcc2 and tcc3 is differ where tcc tcc.c -o tcc2 and tcc2 tcc.c -o tcc3) - can compile links browser. It seems working. - not tested well. I tested this work only on my linux box with few programs. - calling convention of long-double-integer or struct is not exactly the same as GCC's x86-64 ABI. - implementation of tcc -run is naive (tcc -run tcctest.c works, but tcc -run tcc.c doesn't work). Relocating 64bit addresses seems to be not as simple as 32bit environments. - shared object support isn't unimplemented - no bounds checker support - some builtin functions such as __divdi3 aren't supported