Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*dump

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*dump_header\s+changes\s+for\s+Alpha\s*$/: 10 ]

Total 10 documents matching your query.

1. dump_header changes for Alpha (score: 1): Author: Brian Hall <brianw.hall@xxxxxxxxxx>; Date: Mon, 03 Jan 2000 14:53:43 -0700 (MST); Since Intel & Alpha will be sharing the dump_header_t strucure, I thought there might be a problem with using 64 bit values on the Intel side, so I just added fields for Alpha matching Alpha's dh_reg; /archives/lkcd/2000-01/msg00000.html (10,717 bytes)
2. Re: dump_header changes for Alpha (score: 1): Author: Matt Robinson <yakker@xxxxxxxxxxxx>; Date: Mon, 3 Jan 2000 15:07:53 -0800 (PST); Well, what _really_ needs to happen, and I'll do this for 1.0.4, is to do the following (and I intended to do this from the beginning, but we were desperate to get something out the door): +--+ +--+; /archives/lkcd/2000-01/msg00001.html (12,924 bytes)
3. Re: dump_header changes for Alpha (score: 1): Author: Brian Hall <brianw.hall@xxxxxxxxxx>; Date: Mon, 03 Jan 2000 16:42:20 -0700 (MST); Sounds good. I think it might be convienent to have a pointer in the specific header to point back to the generic header, and vice versa. Also, maybe an register size, i.e. uint32_t for Intel, uint64; /archives/lkcd/2000-01/msg00002.html (15,252 bytes)
4. Re: dump_header changes for Alpha (score: 1): Author: Matt Robinson <yakker@xxxxxxxxxxxx>; Date: Mon, 3 Jan 2000 15:48:44 -0800 (PST); I'm not sure the best way to accomplish that. If we are using the right uint32_t and uint64_t, then it wouldn't matter in the long run, as the right "size" type would be used. The nice thing about th; /archives/lkcd/2000-01/msg00003.html (10,417 bytes)
5. Re: dump_header changes for Alpha (score: 1): Author: Keith Owens <kaos@xxxxxxxxxx>; Date: Tue, 04 Jan 2000 10:50:45 +1100; If you ever plan to allow cross platform dump analysis then you should use explicit sizes i.e. uint32_t or uint64_t. "reg_size_t" is meaningless if the dump came from a 64 bit machine but you are deb; /archives/lkcd/2000-01/msg00004.html (8,059 bytes)
6. dump_header changes for Alpha (score: 1): Author: Brian Hall <brianw.hall@xxxxxxxxxx>; Date: Mon, 03 Jan 2000 14:53:43 -0700 (MST); Since Intel & Alpha will be sharing the dump_header_t strucure, I thought there might be a problem with using 64 bit values on the Intel side, so I just added fields for Alpha matching Alpha's dh_reg; /archives/lkcd/2000-01/msg00015.html (10,809 bytes)
7. Re: dump_header changes for Alpha (score: 1): Author: Matt Robinson <yakker@xxxxxxxxxxxx>; Date: Mon, 3 Jan 2000 15:07:53 -0800 (PST); Well, what _really_ needs to happen, and I'll do this for 1.0.4, is to do the following (and I intended to do this from the beginning, but we were desperate to get something out the door): +--+ +--+; /archives/lkcd/2000-01/msg00016.html (12,980 bytes)
8. Re: dump_header changes for Alpha (score: 1): Author: Brian Hall <brianw.hall@xxxxxxxxxx>; Date: Mon, 03 Jan 2000 16:42:20 -0700 (MST); Sounds good. I think it might be convienent to have a pointer in the specific header to point back to the generic header, and vice versa. Also, maybe an register size, i.e. uint32_t for Intel, uint64; /archives/lkcd/2000-01/msg00017.html (15,332 bytes)
9. Re: dump_header changes for Alpha (score: 1): Author: Matt Robinson <yakker@xxxxxxxxxxxx>; Date: Mon, 3 Jan 2000 15:48:44 -0800 (PST); I'm not sure the best way to accomplish that. If we are using the right uint32_t and uint64_t, then it wouldn't matter in the long run, as the right "size" type would be used. The nice thing about th; /archives/lkcd/2000-01/msg00018.html (10,458 bytes)
10. Re: dump_header changes for Alpha (score: 1): Author: Keith Owens <kaos@xxxxxxxxxx>; Date: Tue, 04 Jan 2000 10:50:45 +1100; If you ever plan to allow cross platform dump analysis then you should use explicit sizes i.e. uint32_t or uint64_t. "reg_size_t" is meaningless if the dump came from a 64 bit machine but you are deb; /archives/lkcd/2000-01/msg00019.html (8,099 bytes)

Current List: 1 - 10
Page: [1]