Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Newsgroups | comp.arch |
| Subject | Re: System calls |
| Date | 2025-08-15 18:33 +0000 |
| Organization | PANIX Public Access Internet and UNIX, NYC |
| Message-ID | <107nuh3$4q1$1@reader1.panix.com> (permalink) |
| References | <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <107l5ju$k78a$1@dont-email.me> <107llca$c9c$1@reader1.panix.com> <107nkv2$1753a$1@dont-email.me> |
In article <107nkv2$1753a$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
>On 14.08.2025 23:44, Dan Cross wrote:
>> In article <107l5ju$k78a$1@dont-email.me>,
>> David Brown <david.brown@hesbynett.no> wrote:
>>> [snip]
>>> UB on signed integer
>>> arithmetic overflow is a different matter altogether.
>>
>> I disagree.
>
>You have overflow when the mathematical result of an operation cannot be
>expressed accurately in the type - regardless of the representation
>format for the numbers. Your options, as a language designer or
>implementer, of handling the overflow are the same regardless of the
>representation. You can pick a fixed value to return, or saturate, or
>invoke some kind of error handler mechanism, or return a "don't care"
>unspecified value of the type, or perform a specified algorithm to get a
>representable value (such as reduction modulo 2^n), or you can simply
>say the program is broken if this happens (it is UB).
>
>I don't see where the representation comes into it - overflow is a
>matter of values and the ranges that can be stored in a type, not how
>those values are stored in the bits of the data.
I understood your point. But we are talking about the history of
the language here, not the presently defined behavior.
We do, in fact, have historical source materials we can draw
from when discussing this; there's little need to guess. Here,
we know that the earliest C implementations simply ignored the
posibility of overflow. In K&R1, chap 2, sec 2.5 ("Arithmetic
Operators") on page 38, the authors write, "the action taken on
overflow or underflow depends on the machine at hand." In
Appendix A, sec 7 ("Expressions"), page 185, the authors write:
"The handling of overflow and divide check in expression
evaluation is machine-dependent. All existing implements of C
ignore integer overflows; treatment of division by 0, and all
floating point exceptions, varies between machines, and is
usually adjustable by a library function."
In other words, different machines give different results; some
will trap, others will differ due to representation issues. No
where here does it suggest that the language designers were
worried about getting the "wrong" result, as you have asserted.
>>>> Regardless, signed integer overflow remains UB in the current C
>>>> standard, nevermind definitionally following 2s complement
>>>> semantics. Usually this is done on the basis of performance
>>>> arguments: some seemingly-important loop optimizations can be
>>>> made if the compiler can assert that overflow Cannot Happen.
>>>
>>> The justification for "signed integer arithmetic overflow is UB" is in
>>> the C standards 6.5p5 under "Expressions" :
>>
>> Not in ANSI/ISO 9899-1990. In that revision of the standard,
>> sec 6.5 covers declarations.
>>
>>> """
>>> If an exceptional condition occurs during the evaluation of an
>>> expression (that is, if the result is not mathematically defined or not
>>> in the range of representable values for its type), the behavior is
>>> undefined.
>>> """
>>
>> In C90, this language appears in sec 6.3 para 5. Note, however,
>> that they do not define what an exception _is_, only a few
>> things that _may_ cause one. See below.
>
>It's basically the same in C90 onwards, with just small changes to the
>wording.
Did I suggest otherwise?
>And it /does/ define what is meant by an "exceptional
>condition" (or just "exception" in C90) - that is done by the part in
>parentheses.
That is an interpretation.
>>> It actually has absolutely nothing to do with signed integer
>>> representation, or machine hardware.
>>
>> Consider this language from the (non-normative) example 4 in sec
>> 5.1.2.3:
>>
>> |On a machine in which overflows produce an exception and in
>> |which the range of values representable by an *int* is
>> |[-32768,+32767], the implementation cannot rewrite this
>> |expression as [continues with the specifics of the example]....
>>
>> That seems pretty clear that they're thinking about machines
>> that actually generate a hardware trap of some kind on overflow.
>
>They are thinking about that possibility, yes. In C90, the term
>"exception" here was not clearly defined - and it is definitely not the
>same as the term "exception" in 6.3p5. The wording was improved in C99
>without changing the intended meaning - there the term in the paragraph
>under "Expressions" is "exceptional condition" (defined in that
>paragraph), while in the example in "Execution environments", it says
>"On a machine in which overflows produce an explicit trap". (C11
>further clarifies what "performs a trap" means.)
>
>But this is about re-arrangements the compiler is allowed to make, or
>barred from making - it can't make re-arrangements that would mean
>execution failed when the direct execution of the code according to the
>C abstract machine would have worked correctly (without ever having
>encountered an "exceptional condition" or other UB). Representation is
>not relevant here - there is nothing about two's complement, ones'
>complement, sign-magnitude, or anything else. Even the machine hardware
>is not actually particularly important, given that most processors
>support non-trapping integer arithmetic instructions and for those that
>don't have explicit trap instructions, a compiler could generate "jump
>if overflow flag set" or similar instructions to emulate traps
>reasonably efficiently. (Many compilers support that kind of thing as
>an option to aid debugging.)
>
>>> It doesn't even have much to do
>>> with integers at all. It is simply that if the calculation can't give a
>>> correct answer, then then the C standards don't say anything about the
>>> results or effects.
>>>
>>> The point is that there when the results of an integer computation are
>>> too big, there is no way to get the correct answer in the types used.
>>> Two's complement wrapping is /not/ correct. If you add two real-world
>>> positive integers, you don't get a negative integer.
>>
>> Sorry, but I don't buy this argument as anything other than a
>> justification after the fact. We're talking about history and
>> motivation here, not the behavior described in the standard.
>
>It is a fair point that I am describing a rational and sensible reason
>for UB on arithmetic overflow - and I do not know the motivation of the
>early C language designers, compiler implementers, and authors of the
>first C standard.
Then there's really nothing more to discuss. The intent here is
to understand the motivation of those folks.
Early C didn't even have unsigned; Dennis Ritchie's paper for
the History of Programming Languages conference said that it
came around 1977
(https://www.nokia.com/bell-labs/about/dennis-m-ritchie/chist.html;
see the section on "portability"), and in pre-ANSI C, struct
fields of `int` type were effectively unsigned (K&R1,
pp.138,197). I mentioned the quote from K&R1 about overflow
above, but we see some other hints about signed overflow
becoming negative in other documents. For instance, K&R2, p 118
gives the example of a hash function followed by the sentence,
"unsigned arithmetic ensures that the hash value is
non-negative." This does not suggest to me that the authors
thought that the wrapping behavior of twos-complement arithemtic
was "incorrect".
>I do know, however, that the principle of "garbage in, garbage out" was
>well established long before C was conceived. And programmers of that
>time were familiar with the concept of functions and operations being
>defined for appropriate inputs, and having no defined behaviour for
>invalid inputs. C is full of other things where behaviour is left
>undefined when no sensible correct answer can be specified, and that is
>not just because the behaviour of different hardware could vary. It
>seems perfectly reasonable to me to suppose that signed integer
>arithmetic overflow is just another case, no different from
>dereferencing an invalid pointer, dividing by zero, or any one of the
>other UB's in the standards.
Indeed; this is effectively what I've been saying: signed
integer overflow is UB because the behavior of overflow varied
between the machines of the day, so C could not make assumptions
about what value would result, in part because of representation
issues: at the hardware level, signed overflow of the largest
representable positive integer yields different _values_ between
1s comp and 2s comp machines. Who is to say which is correct?
>> In particular, C is a programming language for actual machines,
>> not a mathematical notation; the language is free to define the
>> behavior of arithmetic expressions in any way it chooses, though
>> one presumes it would do so in a way that makes sense for the
>> machines that it targets.
>
>Yes, that is true. It is, however, also important to remember that it
>was based on a general abstract machine, not any particular hardware,
>and that the operations were intended to follow standard mathematics as
>well as practically possible - operations and expressions in C were not
>designed for any particular hardware. (Though some design choices were
>biased by particular hardware.)
This is historically inaccurate.
C was developed by and for the PDP-11 initially, targeting Unix,
building from Martin Richards's BCPL (which Ritchie and Thompson
had used under Multics on the GE-645 machine, and GCOS on the
635) and Ken Thompson's B language, which he had implemented as
a chopped-down BCPL to be a systems programming language for
_very_ early Unix on the PDP-7. B was typeless, as the PDP-7
was word-oriented, and we see vestages of this ancestral DNA in
C today. See Ritchie's C history paper for details.
Concerns for protability, leading to the development of the
abstract machine informally described by the C standard, came
much, much later in its evolutionary development.
>> Thus, it could have formalized the
>> result of signed integer overflow to follow 2's complement
>> semantics had the committee so chosen, in which case the result
>> would not be "incorrect", it would be well-defined with respect
>> to the semantics of the language. Java, for example, does this,
>> as does C11 (and later) atomic integer operations. Indeed, the
>> C99 rationale document makes frequent reference to twos
>> complement, where overflow and modular behavior are frequently
>> equivalent, being the common case. But aside from the more
>> recent atomics support, C _chose_ not to do this.
>
>It could have made signed integer overflow defined behaviour, but it did
>not. The C standards committee have explicitly chosen not to do that,
>even after deciding that two's complement is the only supported
>representation for signed integers in C23 onwards. It is fine to have
>two's complement representation, and fine to have modulo arithmetic in
>some circumstances, while leaving other arithmetic overflow undefined.
>Unsigned integer operations in C have always been defined as modulo
>arithmetic - addition of unsigned values is a different operation from
>addition of signed values. Having some modulo behaviour does not in any
>way imply that signed arithmetic should be modulo.
>
>In Java, the language designers decided that integer arithmetic
>operations would be modulo operations. Wrapping therefore gives the
>correct answer for those operations - it does not give the correct
>answer for mathematical integer operations. And Java loses common
>mathematical identities which C retains - such as the identity that
>adding a positive integer to another integer will increase its value.
>Something always has to be lost when approximating unbounded
>mathematical integers in a bounded implementation - I think C made the
>right choices here about what to keep and what to lose, and Java made
>the wrong choices. (Others may of course have different opinions.)
>
>In Zig, unsigned integer arithmetic overflow is also UB as these
>operations are not defined as modulo. I think that is a good natural
>choice too - but it is useful for a language to have a way to do
>wrapping arithmetic on the occasions you need it.
None of this seems relevant to understanding the motivations of
the members of the committee that produced the 1990 C standard,
other than agreeing that the decision could have been different.
I would add that very early C treated signed and unsigned
arithmetic as more or less equivalent. It wasn't until they
started porting C to machines other than the PDP-11 that it
started to matter.
>> Also, consider that _unsigned_ arithmetic is defined as having
>> wrap-around semantics similar to modular arithmetic, and thus
>> incapable of overflow.
>
>Yes. Unsigned arithmetic operations are different operations from
>signed arithmetic operations in C.
This is the second time you have mentioned this. Did I say
something that led you believe that I suggested otherwise, or
am somehow unaware of this fact?
>> But that's simply a fiction invented for
>> the abstract machine described informally in the standard: it
>> requires special handling one machines like the 1100 series,
>> because those machines might trap on overflow. The C committee
>> could just as well have said that the unsigned arithmetic
>> _could_ overflow and that the result was UB.
>
>They could have done that (as the Zig folk did).
Or the SML folks before the Zig folks.
>> So why did C chose this way? The only logical reason is that
>> there were machines at the time that where a) integer overflow
>> caused machine exceptions, and b) the representation of signed
>> integers was not well-defined, so that the actual value
>> resulting from overflow could not be rigorously defined. Given
>> that C90 mandated a binary representation for integers and so
>> the representation of of unsigned integers is basically common,
>> there was no need to do that for unsigned arithmetic.
>
>Not at all. Usually when someone says "the only logical reason is...",
>they really mean "the only logical reason /I/ can think of is...", or
>"the only reason that /I/ can think of that /I/ think is logical is...".
I probably should have said that I'm also drawing from direct
references, as well as hints and inferences from other
historical documents; both editions of K&R as well as early Unix
source code and the "C Reference Manual" from 6th and 7th
Edition Unix (the language described in 7th Ed is quite
different from the language in 6th Ed; most of this was driven
by the a) portability, and b) the need to support
phototypesetters, hence why the C implemented in 7th Ed and PCC
is sometimes called "Typesetter C"). This is complemented with
direct conversations with some of the original players, though
admittedly those were quite a while ago.
>For a language that can be used as a low-level systems language, it is
>important to be able to do modulo arithmetic efficiently. It is needed
>for a number of low-level tasks, including the implementation of large
>arithmetic operations, handling timers, counters, and other bits and
>pieces. So it was definitely a useful thing to have in C.
>
>For a language that can be used as a fast and efficient application
>language, it must have a reasonable approximation to mathematical
>integer arithmetic. Implementations should not be forced to have
>behaviours beyond the mathematically sensible answers - if a calculation
>can't be done correctly, there's no point in doing it. Giving nonsense
>results does not help anyone - C programmers or toolchain implementers,
>so the language should not specify any particular result. More sensible
>defined overflow behaviour - saturation, error values, language
>exceptions or traps, etc., would be very inefficient on most hardware.
>So UB is the best choice - and implementations can do something
>different if they like.
This is where we differ: you keep asserting notions of
"correctness", without acknowledging that a) correctness differs
in this context, and b) the notion of what is "correct" has
itself differed over time as C has evolved.
Moreover, when you say, "if a calculation can't be done
correctly, there's no point in doing it" that's seems highly
specific and reliant on your definition of correctness. My
Here's an example:
char foo = 128;
int x = foo + 1;
printf("%d\n", x);
What is printed? (Note: that's rhetorical)
On the systems I just tested, x86_64, ARM64 and RISCV64, I get
-127 for the first two, and 129 for the last.
Of course, we all know that this relies on implementation
defined behavior around whether `char` is treated as signed or
unsigned (and resultingly conversion from an unsigned constant
to signed), but if what you say were true about GIGO, why is
this not _undefined_ behavior?
>Too many options make a language bigger - harder to implement, harder to
>learn, harder to use. So it makes sense to have modulo arithmetic for
>unsigned types, and normal arithmetic for signed types.
>
>I am not claiming to know that this is the reasoning made by the C
>language pioneers. But it is definitely an alternative logical reason
>for C being the way it is.
But we _can_ see what those pioneers were thinking by reading
the artifacts they left behind, which we know, again based on
primary sources, had an impact on the standards committee.
>>>> And of course, even today, C still targets oddball platforms
>>>> like DSPs and custom chips, where assumptions about the ubiquity
>>>> of 2's comp may not hold.
>>>
>>> Modern C and C++ standards have dropped support for signed integer
>>> representation other than two's complement, because they are not in use
>>> in any modern hardware (including any DSP's) - at least, not for
>>> general-purpose integers. Both committees have consistently voted to
>>> keep overflow as UB.
>>
>> Yes. As I said, performance is often the justification.
>>
>> I'm not convinced that there are no custom chips and/or DSPs
>> that are not manufactured today. They may not be common, their
>> mere existence is certainly dumb and offensive, but that does
>> not mean that they don't exist. Note that the survey in, e.g.,
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm
>> only mentions _popular_ DSPs, not _all_ DSPs.
>
>I think you might have missed a few words in that paragraph, but I
>believe I know what you intended. There are certainly DSPs and other
>cores that have strong support for alternative overflow behaviour -
>saturation is very common in DSPs, and it is also common to have a
>"sticky overflow" flag so that you can do lots of calculations in a
>tight loop, and check for problems once you are finished. I think it is
>highly unlikely that you'll find a core with something other than two's
>complement as the representation for signed integer types, though I
>can't claim that I know /all/ devices! (I do know a bit about more
>cores than would be considered popular or common.)
I was referring specifically to integer representation here, not
saturating (or other) operations, but sure.
>> Of course, if such machines exist, I will certainly concede that
>> I doubt very much that anyone is targeting them with C code
>> written to a modern standard.
>
>Modern C is definitely used on DSPs with strong saturation support.
>(Even ARM cores have saturated arithmetic instructions.) But they can
>also handle two's complement wrapped signed integer arithmetic if the
>programmer wants that - after all, it's exactly the same in the hardware
>as modulo unsigned arithmetic (except for division). That doesn't mean
>that wrapping signed integer overflow is useful or desired behaviour.
So again, the context here is understanding the initial
motivation. I've mentioned reasons why they don't change it now
(there _are_ arguments about correctness, but compiler writers
also argue strongly that making signed integer overflow well
defined would prohibit them from implementing what they consider
to be important optimizations).
- Dan C.
Back to comp.arch | Previous | Next — Previous in thread | Next in thread | Find similar
Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-05-19 19:15 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-05-19 21:26 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-05-21 15:07 +0000
Re: Why I've Dropped In David Chmelik <dchmelik@gmail.com> - 2025-05-22 06:51 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-05-22 17:42 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-05-22 18:03 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 12:37 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 13:24 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-26 05:57 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-26 06:14 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-10 21:45 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-10 22:45 -0500
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-08-01 04:42 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-08-01 05:03 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-08-01 18:07 -0500
Re: Why I've Dropped In MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-27 01:01 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 17:19 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 12:16 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 02:11 +0000
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-12 11:48 -0700
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-15 17:26 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 08:00 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-10 22:53 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 05:56 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-11 04:42 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 16:37 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-11 14:47 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 19:13 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-12 16:30 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 00:00 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-15 13:21 -0500
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-15 18:42 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-15 16:42 -0500
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-11 16:51 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 19:08 +0000
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-11 18:00 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 23:01 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-12 08:38 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-12 18:44 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-20 05:56 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-12 19:55 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-11 16:28 -0500
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-12 07:05 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-12 15:27 -0500
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 15:30 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 15:59 +0000
Re: Why I've Dropped In moi <findlaybill@blueyonder.co.uk> - 2025-06-20 17:12 +0100
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 19:46 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-23 16:03 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 14:12 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 16:49 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-11 17:34 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-11 19:16 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-14 14:22 -0500
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-16 12:17 -0400
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-17 01:07 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 18:26 -0700
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 17:45 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-17 11:09 -0700
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-17 16:43 -0400
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-17 21:18 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-17 18:14 -0400
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-18 07:31 +0000
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-18 11:50 -0400
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-19 08:56 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-06-18 15:37 -0500
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-18 00:47 -0700
Re: Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-18 11:22 -0400
Re: Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-19 21:45 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-11 17:05 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-12 15:00 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-12 08:44 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 03:09 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-12 20:36 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 06:03 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 11:14 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 08:23 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 17:40 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 10:57 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-13 18:11 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 18:18 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 18:42 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 20:31 -0700
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-15 15:55 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 11:55 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:15 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 12:17 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 19:44 +0000
Re: base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-15 20:09 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 21:02 -0700
Re: base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 14:37 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 07:55 -0700
Re: base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-16 17:42 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 10:56 -0700
Re: base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 21:52 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-16 15:04 -0700
Re: base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 18:11 +0000
Re: base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 14:25 +0000
Re: base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-16 14:45 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 14:39 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-16 02:33 +0000
Re: base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 14:22 +0000
Re: big pages, base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-16 16:42 +0000
Re: big pages, base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 16:52 +0000
Re: Why I've Dropped In Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-06-13 19:49 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 18:37 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 21:09 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 20:27 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 10:48 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 09:45 -0700
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-14 13:56 -0400
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 12:23 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 21:26 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 14:37 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 21:49 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 20:34 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 03:52 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 04:04 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 04:09 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 04:38 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-15 07:37 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 07:00 -0700
Re: swapping pain, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:39 +0000
Re: swapping pain, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 12:23 -0700
Re: base hackery, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:22 +0000
Re: Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-15 09:48 -0400
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 18:51 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 12:33 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 20:06 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-15 19:29 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 09:55 -0700
Re: more addressing, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-18 18:19 +0000
Re: more addressing, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 12:07 -0700
Re: more addressing, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 06:13 +0000
Re: more addressing, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 23:39 -0700
Re: more addressing, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 07:46 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-13 13:14 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 11:52 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 08:15 -0700
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-13 19:50 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 13:50 -0700
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-13 22:01 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-13 23:10 -0700
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 09:26 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 10:44 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 15:40 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 09:24 -0700
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 16:49 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 16:39 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-15 01:07 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-15 07:10 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-15 16:01 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-15 16:53 +0000
Re: static linked libraries, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:54 +0000
Re: Why I've Dropped In Robert Swindells <rjs@fdy2.co.uk> - 2025-06-15 19:24 +0000
Re: Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-16 14:15 +0000
Re: static libraries, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 17:00 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-24 10:47 +0000
Re: Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-14 16:56 +0000
Re: Why I've Dropped In Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-06-14 12:42 +0000
Re: Why I've Dropped In anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-14 15:53 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 17:02 +0000
Re: Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-14 21:19 +0000
Re: fitting programs in Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-14 22:12 +0000
Re: Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-14 20:51 -0700
Re: base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 18:08 +0000
Re: base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-15 12:38 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-15 20:20 +0000
Re: old and slow base and bounds, Why I've Dropped In Al Kossow <aek@bitsavers.org> - 2025-06-15 18:48 -0700
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 10:35 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-18 19:51 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 15:30 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 01:23 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 19:41 -0700
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-19 05:36 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-18 23:10 -0700
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-19 09:35 -0400
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 15:11 +0000
Re: Fortran, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 18:03 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-19 18:53 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 23:18 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-20 15:13 -0400
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 20:35 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:27 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:09 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:48 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-21 14:57 -0400
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 23:36 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 01:32 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 13:45 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 17:19 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 18:06 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 18:31 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-20 12:27 -0700
Re: emulation, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 20:16 +0000
Re: emulation, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 20:47 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 21:26 +0000
Re: old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-21 14:33 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 21:34 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 23:57 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 00:06 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 00:13 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-20 23:20 -0700
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 07:40 +0000
Killer Micros (was: old and slow base and bounds) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-06-21 09:56 +0000
Re: old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-21 14:25 +0000
Re: old and slow base and bounds, Why I've Dropped In Stefan Monnier <monnier@iro.umontreal.ca> - 2025-06-21 11:39 -0400
Re: old and slow base and bounds, Why I've Dropped In Vir Campestris <vir.campestris@invalid.invalid> - 2025-06-21 16:50 +0100
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-21 17:59 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-21 18:26 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-21 19:37 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-06-21 20:27 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-21 20:31 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-21 20:36 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-21 14:27 -0700
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-24 09:45 +0200
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-22 06:34 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Andreas Eder <a_eder_muc@web.de> - 2025-06-22 11:52 +0200
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-22 00:55 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Vir Campestris <vir.campestris@invalid.invalid> - 2025-07-01 14:22 +0100
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-07-01 17:39 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-07-01 18:00 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-22 20:23 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Lynn Wheeler <lynn@garlic.com> - 2025-06-22 12:15 -1000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-22 22:44 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-23 09:23 -0400
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-23 20:04 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-23 23:16 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Al Kossow <aek@bitsavers.org> - 2025-06-23 17:02 -0700
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-24 00:25 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-24 00:53 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-24 02:49 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-24 06:21 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Terje Mathisen <terje.mathisen@tmsw.no> - 2025-06-24 09:59 +0200
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-24 06:16 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-24 14:12 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Al Kossow <aek@bitsavers.org> - 2025-06-24 07:43 -0700
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-24 14:53 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-24 14:48 +0000
Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-24 13:01 -0400
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-21 17:49 +0000
Re: old and slow base and bounds, Why I've Dropped In scott@slp53.sl.home (Scott Lurndal) - 2025-06-21 14:36 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 13:37 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 17:52 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-19 19:00 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-20 07:42 -0700
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds John Levine <johnl@taugh.com> - 2025-06-20 18:40 +0000
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-20 17:15 -0400
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds Thomas Koenig <tkoenig@netcologne.de> - 2025-06-20 21:30 +0000
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds John Levine <johnl@taugh.com> - 2025-06-21 17:21 +0000
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-21 15:46 -0400
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-21 22:42 -0700
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-24 10:58 -0700
Re: cramming 24 bits of address into 16 bits, was old and slow base and bounds John Levine <johnl@taugh.com> - 2025-06-24 19:31 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-19 12:36 -0700
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-19 21:45 +0000
Re: old and slow base and bounds, Why I've Dropped In Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-06-19 16:05 -0700
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-19 23:45 +0000
Re: old and slow base and bounds, Why I've Dropped In quadibloc <quadibloc@gmail.com> - 2025-06-20 14:51 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 15:55 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 20:25 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 12:12 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-19 10:32 -0400
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-19 14:54 +0000
Re: old and slow base and bounds, Why I've Dropped In EricP <ThatWouldBeTelling@thevillage.com> - 2025-06-19 20:36 -0400
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-20 01:10 +0000
Re: old and slow base and bounds, Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-20 01:15 +0000
Re: old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-21 12:04 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-21 20:32 +0000
Re: old and slow base and bounds, Why I've Dropped In antispam@fricas.org (Waldek Hebisch) - 2025-06-22 01:26 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-22 01:36 +0000
Re: old and slow base and bounds, Why I've Dropped In Thomas Koenig <tkoenig@netcologne.de> - 2025-06-22 08:57 +0000
Re: linking and sortiing, old and slow base and bounds, John Levine <johnl@taugh.com> - 2025-06-22 17:52 +0000
Re: linking and sortiing, old and slow base and bounds, mitchalsup@aol.com (MitchAlsup1) - 2025-06-22 18:25 +0000
Re: linking and sortiing, old and slow base and bounds, scott@slp53.sl.home (Scott Lurndal) - 2025-06-22 20:29 +0000
Re: tape hacks, linking and sortiing John Levine <johnl@taugh.com> - 2025-06-22 22:44 +0000
Re: linking and sortiing, old and slow base and bounds, Thomas Koenig <tkoenig@netcologne.de> - 2025-06-23 06:07 +0000
Re: linking and sortiing, old and slow base and bounds, quadibloc <quadibloc@gmail.com> - 2025-06-23 09:56 +0000
Re: linking and sortiing, old and slow base and bounds, quadibloc <quadibloc@gmail.com> - 2025-06-23 10:01 +0000
Re: linking and sortiing, old and slow base and bounds, Thomas Koenig <tkoenig@netcologne.de> - 2025-06-23 17:13 +0000
Re: old and slow base and bounds, Why I've Dropped In John Levine <johnl@taugh.com> - 2025-06-22 01:31 +0000
Re: Why I've Dropped In mitchalsup@aol.com (MitchAlsup1) - 2025-06-14 17:00 +0000
Re: Why I've Dropped In John Savard <quadibloc@invalid.invalid> - 2025-07-28 23:18 +0000
Re: Why I've Dropped In BGB <cr88192@gmail.com> - 2025-07-28 22:56 -0500
Re: Why I've Dropped In MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-26 21:46 +0000
VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-29 08:45 +0000
Re: VAX (was: Why I've Dropped In) John Levine <johnl@taugh.com> - 2025-07-29 16:44 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-07-30 05:59 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-07-30 04:02 -0500
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-07-30 16:24 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-07-30 13:24 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-01 17:02 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-01 15:24 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-02 15:33 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-02 15:15 -0500
Re: VAX BGB <cr88192@gmail.com> - 2025-08-02 18:55 -0500
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 16:33 +0000
Re: VAX MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-25 00:56 +0000
Re: VAX MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-08-31 18:04 +0000
What is more important MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-09-04 15:23 +0000
Re: What is more important Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-09-04 10:25 -0700
Re: What is more important MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-09-04 21:00 +0000
Re: What is more important BGB <cr88192@gmail.com> - 2025-09-04 16:54 -0500
Re: What is more important anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-05 15:03 +0000
Re: What is more important BGB <cr88192@gmail.com> - 2025-09-05 14:26 -0500
Re: What is more important BGB <cr88192@gmail.com> - 2025-09-05 14:38 -0500
Re: What is more important Robert Finch <robfi680@gmail.com> - 2025-09-05 21:56 -0400
Re: What is more important Thomas Koenig <tkoenig@netcologne.de> - 2025-09-10 13:31 +0000
Re: VAX (was: Why I've Dropped In) Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-07-30 17:17 +0000
Re: VAX (was: Why I've Dropped In) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-01 17:16 +0000
Re: VAX (was: Why I've Dropped In) scott@slp53.sl.home (Scott Lurndal) - 2025-08-01 18:11 +0000
Re: VAX (was: Why I've Dropped In) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-01 20:41 +0000
Re: VAX (was: Why I've Dropped In) Thomas Koenig <tkoenig@netcologne.de> - 2025-08-02 09:07 +0000
Re: VAX (was: Why I've Dropped In) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:21 +0000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-02 23:10 -0400
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-03 09:14 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-03 07:41 -0700
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 10:24 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:40 +0000
Re: VAX John Ames <commodorejohn@gmail.com> - 2025-08-04 08:32 -0700
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 11:47 -0500
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 17:20 +0000
Re: 32 vs 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-04 18:17 +0000
Re: 32 vs 64 bits, was VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:17 +0300
Re: 32 vs 64 bits, was VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:36 +0000
Re: 32 vs 64 bits, was VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 20:00 +0000
Re: IBM's 32 vs 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-04 21:04 +0000
Re: IBM's 32 vs 64 bits, was VAX Lynn Wheeler <lynn@garlic.com> - 2025-08-07 07:32 -1000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-04 15:40 -0400
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 16:34 +0000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-31 16:43 -0400
Re: VAX Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:26 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-01 06:07 +0000
Re: VAX Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-01 06:57 +0000
Debian on AMD64 (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-01 07:40 +0000
Re: Debian on AMD64 Stefan Monnier <monnier@iro.umontreal.ca> - 2025-09-01 12:15 -0400
Re: Debian on AMD64 BGB <cr88192@gmail.com> - 2025-09-01 11:33 -0500
Re: Debian on AMD64 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-01 20:34 +0000
Re: VAX Marco Moock <mm@dorfdsl.de> - 2025-09-21 16:20 +0200
Re: VAX Nuno Silva <nunojsilva@invalid.invalid> - 2025-09-21 15:45 +0100
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-09-21 17:54 +0300
Re: VAX Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-04 14:06 -0700
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 00:21 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 21:51 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:38 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:39 +0000
Re: VAX "Kerr-Mudd, John" <admin@127.0.0.1> - 2025-08-05 09:25 +0100
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-05 17:24 +0200
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-05 15:41 +0000
System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 07:32 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 15:03 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 16:10 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 18:15 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 19:40 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 19:25 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-13 21:23 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-14 07:58 +0000
Re: System calls (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-14 13:28 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 15:14 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 15:25 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-14 15:32 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 15:44 +0000
Re: System calls David Brown <david.brown@hesbynett.no> - 2025-08-14 19:15 +0200
Re: System calls Thomas Koenig <tkoenig@netcologne.de> - 2025-08-14 17:43 +0000
Re: System calls David Brown <david.brown@hesbynett.no> - 2025-08-15 17:49 +0200
Re: System calls cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-14 21:44 +0000
Re: System calls David Brown <david.brown@hesbynett.no> - 2025-08-15 17:49 +0200
Re: System calls cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-15 18:33 +0000
Re: System calls (was: VAX) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-13 18:51 +0000
Re: System calls (was: VAX) scott@slp53.sl.home (Scott Lurndal) - 2025-08-13 20:28 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-13 19:35 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 00:49 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 13:48 +0000
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:24 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:41 +0000
Re: VAX vallor <vallor@cultnix.org> - 2025-08-05 05:56 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 01:34 +0000
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-01 20:06 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 03:37 +0000
Re: VAX ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2025-08-02 04:14 +0000
Re: VAX "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-01 21:35 -0700
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-02 08:07 +0000
Re: VAX Al Kossow <aek@bitsavers.org> - 2025-08-02 01:48 -0700
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:45 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-02 23:08 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-03 16:51 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-04 00:04 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-03 21:07 -0500
Re: VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-03 20:39 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-04 04:50 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 12:35 +0300
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 11:59 -0500
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 12:19 +0300
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 12:09 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 14:51 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 18:28 +0300
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-04 09:53 -0700
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-04 16:58 +0000
Re: VAX "Brian G. Lucas" <bagel99@gmail.com> - 2025-08-05 13:03 -0500
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:03 +0300
Re: VAX James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-04 15:25 -0400
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:40 +0300
Re: VAX "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-08-04 12:44 -0700
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-04 22:21 -0700
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-05 21:25 +0000
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-05 19:14 -0700
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-06 04:31 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-06 11:48 +0300
Re: VAX James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-06 11:56 -0400
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-05 21:13 +0000
Re: VAX James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-06 11:54 -0400
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-06 13:58 -0700
Re: VAX Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-05 21:08 +0000
Re: VAX Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 20:18 +0200
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-17 22:18 -0700
Re: VAX Richard Heathfield <rjh@cpax.org.uk> - 2025-08-18 08:02 +0100
Re: VAX David Brown <david.brown@hesbynett.no> - 2025-08-18 11:34 +0200
Re: VAX Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-08-18 21:57 -0700
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 15:11 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 19:00 +0300
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 19:04 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-04 22:49 +0200
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 00:14 +0300
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 01:43 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-05 17:31 +0200
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 19:49 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-05 22:17 +0200
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-06 00:21 +0300
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-06 16:19 +0200
3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-06 20:43 +0300
Re: 3-way long addition Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-07 15:15 +0200
3-way long addition (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-19 05:47 +0000
Re: 3-way long addition (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-19 07:09 +0000
Re: 3-way long addition Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-19 12:11 +0200
Re: 3-way long addition anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-19 17:43 +0000
Re: 3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-19 17:20 +0300
Re: 3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-19 17:24 +0300
Re: 3-way long addition (was: VAX) Michael S <already5chosen@yahoo.com> - 2025-08-19 23:03 +0300
Re: 3-way long addition Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-20 10:50 +0200
Re: 3-way long addition Michael S <already5chosen@yahoo.com> - 2025-08-20 14:16 +0300
Intel ADX (was: 3-way long addition) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-20 14:08 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 18:25 +0300
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 12:56 -0500
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 14:22 +0000
Re: VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-04 16:46 +0200
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 15:05 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 18:07 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 15:32 +0000
Re: VAX Stefan Monnier <monnier@iro.umontreal.ca> - 2025-08-04 15:09 -0400
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 22:31 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 20:29 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-05 00:08 +0300
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-04 21:23 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 06:46 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-05 03:14 -0500
Re: VAX Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-05 11:52 -0700
Re: VAX Thomas Koenig <tkoenig@netcologne.de> - 2025-08-06 05:37 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 06:20 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-04 12:12 -0500
I32LP64 vs. ILP64 (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 11:28 +0000
Re: I32LP64 vs. ILP64 antispam@fricas.org (Waldek Hebisch) - 2025-08-06 15:55 +0000
Re: I32LP64 vs. ILP64 BGB <cr88192@gmail.com> - 2025-08-06 12:47 -0500
Re: I32LP64 vs. ILP64 BGB <cr88192@gmail.com> - 2025-08-06 12:00 -0500
Re: I32LP64 vs. ILP64 (was: VAX) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:34 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 05:38 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 11:05 +0000
Re: VAX BGB <cr88192@gmail.com> - 2025-08-06 12:12 -0500
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 18:22 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-06 10:32 +0000
Re: 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-06 17:25 +0000
Re: 64 bits, was VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-06 12:11 -0700
Re: individual 64 bits, was VAX John Levine <johnl@taugh.com> - 2025-08-06 19:50 +0000
Re: individual 64 bits, was VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-06 20:30 +0000
Re: 64 bits, was VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:36 +0000
Re: 64 bits, was VAX Terje Mathisen <terje.mathisen@tmsw.no> - 2025-08-07 15:44 +0200
Re: 64 bits, was VAX Peter Flass <Peter@Iron-Spring.com> - 2025-08-07 07:34 -0700
Re: 64 bits, S/360 was VAX John Levine <johnl@taugh.com> - 2025-08-07 20:54 +0000
Re: 64 bits, was VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-08 03:51 +0000
Bit addressing (was: 64 bits) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 14:57 +0000
Re: Bit addressing drb@ihatespam.msu.edu (Dennis Boone) - 2025-08-07 15:54 +0000
Re: Bit addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-08-07 13:01 -0700
Re: Bit addressing (was: 64 bits) Al Kossow <aek@bitsavers.org> - 2025-08-07 13:34 -0700
Re: VAX Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-08-06 23:12 +0000
Re: VAX John Levine <johnl@taugh.com> - 2025-08-06 23:15 +0000
Re: VAX Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-08-06 23:32 +0000
Re: word lengths in C, was VAX John Levine <johnl@taugh.com> - 2025-08-07 02:56 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-07 11:21 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-07 13:34 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-06 23:38 +0000
Re: VAX Michael S <already5chosen@yahoo.com> - 2025-08-04 12:42 +0300
Re: VAX Al Kossow <aek@bitsavers.org> - 2025-08-04 03:32 -0700
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 05:37 +0000
Re: VAX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-04 13:42 +0000
Re: VAX Andy Burns <usenet@andyburns.uk> - 2025-08-04 16:50 +0100
Re: VAX antispam@fricas.org (Waldek Hebisch) - 2025-08-04 23:52 +0000
Re: VAX Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-08-05 05:35 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-05 01:31 +0000
Re: VAX scott@slp53.sl.home (Scott Lurndal) - 2025-08-05 13:46 +0000
Re: VAX cross@spitfire.i.gajendra.net (Dan Cross) - 2025-08-05 17:21 +0000
ILP32 code on 64-bit substrate (was: VAX) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-08-12 15:28 +0000
(Thread has 1028 articles, showing 500 — browse group in flat view)
csiph-web