dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/08/87)
I've noticed that Lattice uses a BSS hunk for BSS data in its executables, where as Aztec places it in the DATA hunk by specifying a larger buffer for the DATA hunk in the table section of the HEADER hunk than the actual DATA hunk contains. (Just in case anybody is interested.... this isn't a bug or anything) I'm just wondering why Manx opted for putting it in the DATA hunk? -Matt
rokicki@rocky.UUCP (05/08/87)
dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I've noticed that Lattice uses a BSS hunk for BSS data in its > executables, where as Aztec places it in the DATA hunk by specifying a > larger buffer for the DATA hunk in the table section of the HEADER > hunk than the actual DATA hunk contains. > (Just in case anybody is interested.... this isn't a bug or anything) > I'm just wondering why Manx opted for putting it in the DATA hunk? > -Matt My guess is that this makes it easy to use 16-bit address-register relative addressing, rather than 32-bit absolute addressing. Does Lattice also use this trick when in it's small memory model mode? Is there an advantage to using the BSS hunk over the DATA hunk? -tom
scotty@l5comp.UUCP (Scott Turner) (05/10/87)
In article <8705080053.AA10033@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I've noticed that Lattice uses a BSS hunk for BSS data in its >executables, where as Aztec places it in the DATA hunk by specifying a >larger buffer for the DATA hunk in the table section of the HEADER >hunk than the actual DATA hunk contains. The reason for this lies with the fact that Manx wished to access their global data and variables via disp(A4) addressing. The AmigaDOG loader "scatter loads" hunks into memory. Thus you can't assume that DATA and BSS hunks will follow each other in memory. So they crammed their BSS in with their DATA. They also didn't want to give up the space savings from using the BSS concept. So, they make the table entry larger than the actual size so that when the loader loads the data hunk it will allocate enough space for the data & the BSS, WITHOUT taking up space for the BSS on the disk! Cute. The side-effect is that they must zero the BSS themselves which they do with a hard coded ram zeroing routine in their main startup code. They are also in effect exploiting a bug in the loader :-). It could be argued that the loader should check that the table size matched with the hunk size to make sure that the code file wasn't mangled. Scott Turner L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)