1Tweaking the PCC to provide 64-bit integers 2------------------------------------------- 3 4A 64-bit integer data type would be nice to have to implement data 5structures such as millisecond time values, multi-gigabyte disk 6addresses and so on. 7 8Since the number of bits in the type field of the compiler type word is 9only 16 and all 16 types are used, it makes sense to pick a type which 10is not useful and overload it for the 64-bit type. Thus we'll use LONG 11and ULONG types to represent signed and unsigned 64-bit integers 12internally. Externally we must provide some name other than 'long' for 13the type or else all hell will break loose with standard width 14definitions; it's been suggested that we use 'quad', following its use 15in VAX assembler. (I suppose a flag could be used to signal the 16compiler that 'long' really should be 64 bits, so we can eventually 17convert existing code to appropriately handle three integer sizes in 18legal C.) 19 20Data structures 21--------------- 22 23It's probably simplest to just punt on quad constants for the time 24being. This would eliminate the only situation in which the compiler's 25own data structures would need to be adjusted to handle 64-bit 26integers. Once the compiler has been bootstrapped for 64-bit 27variables, 64-bit constants should follow with reasonable ease. 28 29Parameters in header files 30-------------------------- 31 32The size and alignment of LONG and ULONG will need to change in 33macdefs.h. This shouldn't cause any problems (famous last words). 34 35Algorithm changes, file by file 36------------------------------- 37 38cgram.y 39 The production for switch statements may need to change if we 40 want to allow quad type switch expressions. Do PDP-11 41 compilers permit long switch expressions? I doubt it... 42pftn.c 43 dclstruct 44 We will probably have to permit quad size enums eventually. 45 Since the plan is to hold off on quad size constants, we can 46 punt for now. 47code.c 48 type_move 49 MOVL must become MOVQ. Since this code is intended for 50 handling register variables, and we likely won't allow register 51 quads, we don't need to worry too hard about this. 52local.c 53 clocal 54 PCONV and SCONV code may need be changed to know about quads. 55 The SCONV code is primarily concerned with constants (again). 56 cisreg 57 LONG and ULONG will no longer be permitted types for register 58 variables. 59 ctype 60 This routine converts 'unsupported' types into INT; now that 61 LONG and ULONG have a separate meaning from INT, the routine 62 becomes an identity function. 63 tlen 64 LONG and ULONG now have size 2. Cthulhu knows how much code 65 assumes int types will always fit in 1 register. 66local2.c 67 tlen 68 Same as the first pass tlen. 69 prtype 70 Prints the letter ([blwfd]) which is appended to VAX 71 instructions for operations of a particular type. We need to 72 add 'q' for LONG and ULONG, although we won't be using prtype 73 very much! 74 zzzcode 75 The tough code generation issues get tougher... The 'A' 76 conversion code gets considerably more complex. The 'C' stack 77 count code needs a little adjustment to work from SZINT instead 78 of SZLONG. 79 collapsible 80 Again, conversions are a lot tougher with quads. 81 shumul 82 Pointers and arrays of quads need to be handled right. 83order.c 84 setbin 85 setasop 86 It won't be quite so simple to rewrite quads into register to 87 make a stuck tree work. 88 sucomp 89 We need to take another look at the special case hacking for 90 various flavors of integers. 91stab.c 92 inittypes 93 Add the 'quad' type. Does dbx know what to do with 64-bit 94 integers? I sure doubt it. 95table.c 96 Oof. Here is where the real work is. We get to use EMUL to 97 calculate 64-bit products (the architecture handbook conveniently 98 provides the algorithm) and other kinds of fun. 99