Jonas Maebe c91a23c27d * new constant handling: from now on, hex constants >$7fffffff are ... parsed as unsigned constants (otherwise, $80000000 got sign extended and became $ffffffff80000000), all constants in the longint range become longints, all constants >$7fffffff and <=cardinal($ffffffff) are cardinals and the rest are int64's. * added lots of longint typecast to prevent range check errors in the compiler and rtl * type casts of symbolic ordinal constants are now preserved * fixed bug where the original resulttype wasn't restored correctly after doing a 64bit rangecheck		2000-12-07 17:19:42 +00:00
..
ag386att.pas	* moved to i386	2000-11-30 22:16:49 +00:00
ag386bin.pas	* moved to i386	2000-11-30 22:16:49 +00:00
ag386int.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
ag386nsm.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
aopt386.pas	+ register renaming ("fixes" bug1088)	2000-10-24 10:40:52 +00:00
cgai386.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00
cpuasm.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
cpubase.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
cpuinfo.pas	* moved cpu*.pas to i386/	2000-10-15 09:39:36 +00:00
cpunode.pas	* moved cpu*.pas to i386/	2000-10-15 09:39:36 +00:00
cpuswtch.pas	* renamed	2000-11-30 22:41:55 +00:00
csopt386.pas	* when searching for constants in registers, the returned register	2000-12-05 09:33:42 +00:00
daopt386.pas	* invalidate regs that depend on a modified register	2000-12-04 17:00:09 +00:00
i386att.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
i386atts.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
i386ins.dat	* moved to i386/	2000-10-15 09:43:29 +00:00
i386int.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
i386nop.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
i386op.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
i386prop.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
i386tab.inc	* move also the i386*.inc to i386/	2000-10-15 09:41:37 +00:00
n386add.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00
n386bas.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
n386cal.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
n386cnv.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
n386con.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
n386flw.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00
n386ic.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
n386inl.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
n386ld.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00
n386mat.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
n386mem.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00
n386set.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00
n386util.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
popt386.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
ra386.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
ra386att.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
ra386dir.pas	* unused units removed from uses clause	2000-11-29 00:30:30 +00:00
ra386int.pas	* new constant handling: from now on, hex constants >$7fffffff are	2000-12-07 17:19:42 +00:00
rropt386.pas	* fixed bug where "shl $1,%reg" was changed to "leal (%reg),%reg2"	2000-12-05 09:32:47 +00:00
tgcpu.pas	+ new integer regvar handling, should be much more efficient	2000-12-05 11:44:32 +00:00