On Thursday, 6 May 2021 at 13:32:39 UTC+1, muta...@gmail.com wrote:
> I believe the Amiga has a concept of "fast RAM".
>
> It occurs to me that huge pointers on 8086 are
> effectively "slow but large RAM".
>
> So how about adding:
>
> char slow_large *ptr;
>
> ptr = slow_large_malloc(slow_large_size_t);
>
> Obviously on most environments you would just
> #define slow_large to nothing
>
> On existing MSDOS compilers you could define
> it to "huge".
>
> Maybe on some implementations, slow_large could
> actually be disk.
>
> Does such a concept exist?
>
Yes. Many machines have different types of memory installed.
Sometimes they are all in the same "address space", so the
low half of memory might be flash for example whilst the high
half is DRAM. But sometimes they are in different address spaces
and then it's not sensible for a C compiler to use one type of
pointer to refer to them both. So there's an extension to mark the
either slow, large memory pointers or the small fast ones, to use
your example.

On Thursday, May 6, 2021 at 10:49:35 PM UTC+10, Malcolm McLean wrote:

> Yes. Many machines have different types of memory installed.
> Sometimes they are all in the same "address space", so the
> low half of memory might be flash for example whilst the high
> half is DRAM. But sometimes they are in different address spaces
> and then it's not sensible for a C compiler to use one type of
> pointer to refer to them both. So there's an extension to mark the
> either slow, large memory pointers or the small fast ones, to use
> your example.

Ok, great!

So I'd like to hook into this existing situation.

Can the extensions you mentioned above be standardized?

And would disk be a 3rd form of memory? Or is that an
entirely different concept?

Thanks. Paul.

On Thursday, 6 May 2021 at 13:59:31 UTC+1, muta...@gmail.com wrote:
> On Thursday, May 6, 2021 at 10:49:35 PM UTC+10, Malcolm McLean wrote:
>
> > Yes. Many machines have different types of memory installed.
> > Sometimes they are all in the same "address space", so the
> > low half of memory might be flash for example whilst the high
> > half is DRAM. But sometimes they are in different address spaces
> > and then it's not sensible for a C compiler to use one type of
> > pointer to refer to them both. So there's an extension to mark the
> > either slow, large memory pointers or the small fast ones, to use
> > your example.
> Ok, great!
>
> So I'd like to hook into this existing situation.
>
> Can the extensions you mentioned above be standardized?
>
Not really, because you'd have to standardise the way that devices are
engineered. The reason for using C is usually because you want a simple
mapping from source code to machine language instructions, so there's
a limit to how far you can abstract pointers.
>
> And would disk be a 3rd form of memory? Or is that an
> entirely different concept?
>
Traditionally disks have been treated as backing store because they
didn't support efficient random access. However that's no longer the
case for solid state drives. So you could implement an extension to C
which allowed for pointers to disks.

On Thursday, May 6, 2021 at 11:12:25 PM UTC+10, Malcolm McLean wrote:

> > And would disk be a 3rd form of memory? Or is that an
> > entirely different concept?
> >
> Traditionally disks have been treated as backing store because they
> didn't support efficient random access.

I see! Perhaps we need a "random_access" keyword
worked in somewhere, if that is the distinguishing
factor.

> However that's no longer the
> case for solid state drives. So you could implement an extension to C
> which allowed for pointers to disks.

Ok, it occurs to me that there are other potential
address spaces.

E.g. why do I/O ports need a special function to call?

Maybe video ram competes with normal ram, and needs
to be banked in, written to, then banked out again.

And video ram can have a video_size_t of 16-bits, while
non_random_hard_disk_size_t is 64-bits, and
ssd_size_t is 32-bits.

To obtain suitable pointers, maybe this should be combined
with fslurp().

> > Can the extensions you mentioned above be standardized?
> >
> Not really, because you'd have to standardise the way that devices are
> engineered. The reason for using C is usually because you want a simple
> mapping from source code to machine language instructions, so there's
> a limit to how far you can abstract pointers.

Ok, maybe the solution for me is to stop using C then?
Because maybe I want a complex mapping. What language
would you suggest does what I want? Perhaps start with
video RAM that gets banked in and out again, which
effectively makes it a different address space. And do
I/O ports at the same time.

Another possibility is this could be done with fwrite etc
instead of pointers. Would it be possible for a compiler
to handle fseek() and fwrite() to video RAM so efficiently
that it is the same as pointers? Let's say video RAM that
doesn't require banking in/out, but you want to allow for
the possibility that it may require banking in future.

Maybe it needs custom macros for this operation. Or
maybe I should just accept the "lowest common
denominator" which is to just have two simple forms
of storage - the slowest RAM available, and non-random
hard disks, and use the existing C facilities.

And if my C compiler supports a "-veryhuge" option to
make everything a huge pointer on an 8086, that's
fine, and that's the limit. Adding keywords is not
appropriate as it detracts from the simplicity of C.
I can live with that. :-) PDPCLIB is simple too.

BFN. Paul.

On 2021-05-06, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> And would disk be a 3rd form of memory? Or is that an
>> entirely different concept?
>>
> Traditionally disks have been treated as backing store because they
> didn't support efficient random access. However that's no longer the

This is badly stated. Hardly anything is used because of what it
*cannot* do.

(Tapes also don't have efficient random access; can we reasonably swap
to tapes?)

Disk have sufficiently usable random access (not having to read a
billion bytes in order to get to the billionth-first) that we can
install them as a level in the memory hierarchy.

> case for solid state drives. So you could implement an extension to C
> which allowed for pointers to disks.

I doubt it. Solid states are block devices which implement a flash
translation layer over a memory that doesn't behave like C memory. The
only way you're reasonably going to have pointers into them is if you
map the block device with a MMU, which you're already doing today.

A direct C pointer into the flash memory of a solid state drive would
have to deal with issues like having to erase a large block in order
to change anything on it. Even if that were solved and somehow hidden
from the program, the C program repeatedly erasing and updating the same
block, due to using the same pointer, would cause wear. You really need
some indirection over that to do wear-leveling. To reduce wear, you have
to buffer changes; you can't be erasing a block every time a small
change occurs, like one word being updated.

It seems that there is no getting away from buffering: storing blocks in
DRAM, and flushing dirty blocks out to the device via a block erase
cycle.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

"muta...@gmail.com" <mutazilah@gmail.com> writes:
>On Thursday, May 6, 2021 at 11:12:25 PM UTC+10, Malcolm McLean wrote:

>> >
>> Not really, because you'd have to standardise the way that devices are
>> engineered. The reason for using C is usually because you want a simple
>> mapping from source code to machine language instructions, so there's
>> a limit to how far you can abstract pointers.
>
>Ok, maybe the solution for me is to stop using C then?

Actually, the solution for you is to give up on the 8086
and use a modern CPU (e.g. x86_64 in long mode, or an
ARMv8-A core).

64-bit flat, paged address space is much easier to deal
with.

On Friday, May 7, 2021 at 10:38:07 AM UTC+10, Scott Lurndal wrote:

> >Ok, maybe the solution for me is to stop using C then?

> Actually, the solution for you is to give up on the 8086
> and use a modern CPU (e.g. x86_64 in long mode, or an
> ARMv8-A core).
>
> 64-bit flat, paged address space is much easier to deal
> with.

No, that's cheating.

You may as well have just standardized on that in 1990.
You can standardize on little-endian too. In fact, you
can standardize on the exact x86_64 instruction set
and just invalidate everything else. Why not? And drop
EBCDIC at the same time. May as well drop non-English
languages too, they are quite annoying.

BFN. Paul.

On 07/05/2021 01:10, Kaz Kylheku wrote:
> On 2021-05-06, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> And would disk be a 3rd form of memory? Or is that an
>>> entirely different concept?
>>>
>> Traditionally disks have been treated as backing store because they
>> didn't support efficient random access. However that's no longer the
>
> This is badly stated.

It's not just badly stated, it is wrong.

> Hardly anything is used because of what it
> *cannot* do.
>
> (Tapes also don't have efficient random access; can we reasonably swap
> to tapes?)
>
> Disk have sufficiently usable random access (not having to read a
> billion bytes in order to get to the billionth-first) that we can
> install them as a level in the memory hierarchy.
>
>
>> case for solid state drives. So you could implement an extension to C
>> which allowed for pointers to disks.
>
> I doubt it. Solid states are block devices which implement a flash
> translation layer over a memory that doesn't behave like C memory. The
> only way you're reasonably going to have pointers into them is if you
> map the block device with a MMU, which you're already doing today.
>

That is correct. In a sense, SSD's are even less random access than
spinning rust as the worst you can do with them would be random writes
scattered about (assuming you first have it mapped with mmap() or similar).

(Technically, a dedicated ram disk device with battery backup is also an
SSD, but those are rare.)

> A direct C pointer into the flash memory of a solid state drive would
> have to deal with issues like having to erase a large block in order
> to change anything on it. Even if that were solved and somehow hidden
> from the program, the C program repeatedly erasing and updating the same
> block, due to using the same pointer, would cause wear. You really need
> some indirection over that to do wear-leveling. To reduce wear, you have
> to buffer changes; you can't be erasing a block every time a small
> change occurs, like one word being updated.
>
> It seems that there is no getting away from buffering: storing blocks in
> DRAM, and flushing dirty blocks out to the device via a block erase
> cycle.
>

And then of course you have all sorts of other block devices - such as
an iSCSI or nbd map across the internet. How would these fit in a
"direct C pointer" ?

On 06/05/2021 14:59, muta...@gmail.com wrote:
> On Thursday, May 6, 2021 at 10:49:35 PM UTC+10, Malcolm McLean wrote:
>
>> Yes. Many machines have different types of memory installed.
>> Sometimes they are all in the same "address space", so the
>> low half of memory might be flash for example whilst the high
>> half is DRAM.

For that kind of thing, a single pointer type in a flat address space is
used.

>> But sometimes they are in different address spaces
>> and then it's not sensible for a C compiler to use one type of
>> pointer to refer to them both. So there's an extension to mark the
>> either slow, large memory pointers or the small fast ones, to use
>> your example.

Some C implementations for some microcontrollers have extensions like
this for different address spaces. Others handle things differently,
such as using intrinsics or even assembly functions.

>
> Ok, great!
>
> So I'd like to hook into this existing situation.
>
> Can the extensions you mentioned above be standardized?

In a word, no. Some implementations have special extensions precisely
because the details vary so much from device to device. There is no
need for standardisation because any code using such features of the
device will be tied very tightly to the device - people rarely write
code designed to work well on an 8-bit 8051 and an 8-bit AVR
microcontroller, never mind expecting it to be used on a PC or mainframe
as well.

There was an attempt at standardising named address spaces (and IO
access, and scaled integer types) for use in embedded C programming.
You can google for it as the N1275 draft of ISO document 18037. It was
an almost complete failure - it tried to solve problems no one had,
failed to solve problems that people did have, repeated old problems (no
embedded C programmer has use for a fixed point integer type whose size
is implementation dependent rather than explicit in the type name), and
generally had almost no support from either compiler writers or users.

However, a few ideas can be copied from it - gcc has done so for the AVR
microcontroller in regard to named address spaces. It's not really any
different than what compiler developers have been using for decades on
awkward architectures (like "far" pointers). And it can't really be
standardised except for the syntax and grammar.

<https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html>

>
> And would disk be a 3rd form of memory? Or is that an
> entirely different concept?
>
> Thanks. Paul.
>

On Friday, May 7, 2021 at 5:32:29 PM UTC+10, David Brown wrote:

> microcontroller in regard to named address spaces. It's not really any
> different than what compiler developers have been using for decades on
> awkward architectures (like "far" pointers). And it can't really be
> standardised except for the syntax and grammar.

Ok, thankyou. I'll give up on this then, and stick to
the "all or nothing" approach I have used for the
8086 ever since I got one. ie I just choose a
memory model and leave it at that. My current
desire is a memory model where all the pointers
are huge, which is what Smaller C gives, and
no-one else seems to have that ability. I might
try to make Watcom produce that too though,
using 8086 instructions instead of 80386
instructions.

BFN. Paul.

>>
>> Can the extensions you mentioned above be standardized?
>
> In a word, no. Some implementations have special extensions precisely
> because the details vary so much from device to device. There is no
> need for standardisation because any code using such features of the
> device will be tied very tightly to the device - people rarely write
> code designed to work well on an 8-bit 8051 and an 8-bit AVR
> microcontroller, never mind expecting it to be used on a PC or mainframe
> as well.
>
> There was an attempt at standardising named address spaces (and IO
> access, and scaled integer types) for use in embedded C programming.
> You can google for it as the N1275 draft of ISO document 18037. It was
> an almost complete failure - it tried to solve problems no one had,
> failed to solve problems that people did have, repeated old problems (no
> embedded C programmer has use for a fixed point integer type whose size
> is implementation dependent rather than explicit in the type name), and
> generally had almost no support from either compiler writers or users.

I guess youc an call it an "almost complete failure". But the one part
that is relevant for the topic here here, the named address spaces, is
the part that was not a failure.
E.g. SDCC has support for both intrinsic and user-defined named addres
spaces from the Embedded C standard. Section 3.5 "SDCC language
extensions" show how thoise are used on various µC architectures:
http://sdcc.sourceforge.net/doc/sdccman.pdf

Philipp

On 07/05/2021 02:18, muta...@gmail.com wrote:
> On Friday, May 7, 2021 at 10:38:07 AM UTC+10, Scott Lurndal wrote:
>
>>> Ok, maybe the solution for me is to stop using C then?
>
>> Actually, the solution for you is to give up on the 8086
>> and use a modern CPU (e.g. x86_64 in long mode, or an
>> ARMv8-A core).
>>
>> 64-bit flat, paged address space is much easier to deal
>> with.
>
> No, that's cheating.
>
> You may as well have just standardized on that in 1990.

There were a range of devices in 1990 that offered flat address spaces
beyond 1MB.

So why would that be cheating to use a more sensible processor than the
8086?

> You can standardize on little-endian too. In fact, you
> can standardize on the exact x86_64 instruction set
> and just invalidate everything else. Why not?

Well, that's what I've done. But then I don't get the inexplicable
reason to turn the clock back to 1990. Is that because of the '90' in C90?

Because limiting the target hardware for a C90 implementation to only
those machines available in 1990 is ridiculous. It's like only creating
Algol68 implementions for machines available in 1968.

Besides C90 was current until 1998. (If C99 and C11 hadn't happened, it
would still be current now.)

> And drop
> EBCDIC at the same time.

That's actually a good idea. AFAIK it's not part of Unicode.

> May as well drop non-English
> languages too, they are quite annoying.

This has got absolutely nothing to do with C90 or whether you choose an
8086 processor anything else. Other than a processor with a bigger,
easier-to-access address space would make it easier to support multiple
alphabets.

On Friday, May 7, 2021 at 8:33:08 PM UTC+10, Bart wrote:

> >>> Ok, maybe the solution for me is to stop using C then?
> >
> >> Actually, the solution for you is to give up on the 8086
> >> and use a modern CPU (e.g. x86_64 in long mode, or an
> >> ARMv8-A core).
> >>
> >> 64-bit flat, paged address space is much easier to deal
> >> with.
> >
> > No, that's cheating.
> >
> > You may as well have just standardized on that in 1990.

> There were a range of devices in 1990 that offered flat address spaces
> beyond 1MB.
>
> So why would that be cheating to use a more sensible processor than the
> 8086?

Because the 8086 existed, and couldn't be willed out
of existence.

It annoyed the hell out of me seeing people plastering
code with "near" and "far". It's actually still unclear to
me why people were doing that, instead of just choosing
a memory model and leaving it at that. What were they
trying to do? Be 1% faster, outside of human
detectability?

> > You can standardize on little-endian too. In fact, you
> > can standardize on the exact x86_64 instruction set
> > and just invalidate everything else. Why not?

> Well, that's what I've done. But then I don't get the inexplicable
> reason to turn the clock back to 1990. Is that because of the '90' in C90?

I'm not turning the clock back. I never left. I'm not
going to leave until I understand the situation in
1990.

We can start with this question. Why did MSDOS
print "Divide error" on a divide by zero situation
instead of:

got a divide by zero
AX 0005 BX 0000 CX 5C12 DX 0000
SI 6F70 DI 0000 DS 5C12 ES 5C12
BP 0FE8 CS 561B IP 00C1 FLAGS 0216
module loaded at 561B:0000, entry point 561B:551E
interrupt address is 561B:00C1
regptrs is 6315:0FA6
retaddr is 561B:5EC6
and that caller might have done a near call to 561B:0000
halting

What was the technical barrier? MVS does something
like that, and did so back in 1990.

How was a production environment using MSDOS
meant to report that problem to the vendor? It's
unclear who the vendor even is. I need to print
the name of the executable out too. And that will
all be written to a dump file anyway.

> Because limiting the target hardware for a C90 implementation to only
> those machines available in 1990 is ridiculous. It's like only creating
> Algol68 implementions for machines available in 1968.

No, that's not correct. When I was programming in C
in 1990 I programmed with the assumption that in
the future, char/short/int/long would all be 256 bits
one day.

> > And drop
> > EBCDIC at the same time.

> That's actually a good idea. AFAIK it's not part of Unicode.

I care far more about EBCDIC than Unicode, and you
can't will EBCDIC out of existence anyway. Not even
in 2021, never mind 1990.

> > May as well drop non-English
> > languages too, they are quite annoying.

> This has got absolutely nothing to do with C90 or whether you choose an
> 8086 processor anything else. Other than a processor with a bigger,
> easier-to-access address space would make it easier to support multiple
> alphabets.

You can't will things out of existence. CPUs and
human languages both. And nuclear bombs for
that matter. There are multiple people who have
the technical ability to nuke me out of existence
in a matter of minutes. There is a quote from
"Wargames" - "we may have to go through with
this thing anyway".

BFN. Paul.

On 07/05/2021 11:41, Philipp Klaus Krause wrote:
>
>>>
>>> Can the extensions you mentioned above be standardized?
>>
>> In a word, no. Some implementations have special extensions precisely
>> because the details vary so much from device to device. There is no
>> need for standardisation because any code using such features of the
>> device will be tied very tightly to the device - people rarely write
>> code designed to work well on an 8-bit 8051 and an 8-bit AVR
>> microcontroller, never mind expecting it to be used on a PC or mainframe
>> as well.
>>
>> There was an attempt at standardising named address spaces (and IO
>> access, and scaled integer types) for use in embedded C programming.
>> You can google for it as the N1275 draft of ISO document 18037. It was
>> an almost complete failure - it tried to solve problems no one had,
>> failed to solve problems that people did have, repeated old problems (no
>> embedded C programmer has use for a fixed point integer type whose size
>> is implementation dependent rather than explicit in the type name), and
>> generally had almost no support from either compiler writers or users.
>
> I guess youc an call it an "almost complete failure". But the one part
> that is relevant for the topic here here, the named address spaces, is
> the part that was not a failure.
> E.g. SDCC has support for both intrinsic and user-defined named addres
> spaces from the Embedded C standard. Section 3.5 "SDCC language
> extensions" show how thoise are used on various µC architectures:
> http://sdcc.sourceforge.net/doc/sdccman.pdf
>

Named address spaces can certainly be useful. But they were in heavy
use from before N1275, and nothing in N1275 has (IMHO) added anything
useful to them. About the only point you could make is that compilers
previously referred to them as "extensions", "qualifiers", "extra
keywords", or other terms - while these days the term "named address
space" is vaguely standardised.

At most, I'd say N1275 documented common existing practice, rather than
giving anything useful.

On Friday, 7 May 2021 at 08:06:30 UTC+1, David Brown wrote:
> On 07/05/2021 01:10, Kaz Kylheku wrote:
> > On 2021-05-06, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >>> And would disk be a 3rd form of memory? Or is that an
> >>> entirely different concept?
> >>>
> >> Traditionally disks have been treated as backing store because they
> >> didn't support efficient random access. However that's no longer the
> >
> > This is badly stated.
> It's not just badly stated, it is wrong.
i>
Efficient random access is crucial to storage being used as "memory".
Disks are better than tapes, but still not efficient enough.

Flash however can be treated as read-only memory. If you want to write
to it it's a bit more difficult. The actual writing can still be via memory-
mapped pointer dereferences, but you have to erase before writing,
and you have to ration your writes as it can only support a limited number
of cycles.

On 07/05/2021 14:56, Malcolm McLean wrote:
> On Friday, 7 May 2021 at 08:06:30 UTC+1, David Brown wrote:
>> On 07/05/2021 01:10, Kaz Kylheku wrote:
>>> On 2021-05-06, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
>>>>> And would disk be a 3rd form of memory? Or is that an
>>>>> entirely different concept?
>>>>>
>>>> Traditionally disks have been treated as backing store because they
>>>> didn't support efficient random access. However that's no longer the
>>>
>>> This is badly stated.
>> It's not just badly stated, it is wrong.
> i>
> Efficient random access is crucial to storage being used as "memory".
> Disks are better than tapes, but still not efficient enough.

Fair enough, as far as it goes. But since disks are not remotely close
enough in random access behaviour to ram, they are never used directly
as "memory". The closest you get is using them as backing store for
swap files.

You can certainly use normal memory pointers, combined with an MMU and
an OS handling reads and writes to block storage, as a way of accessing
data on disks in a convenient manner. This is what is done with mmap()
(and you can consider swap memory to be the same idea).

However, you do not have direct read or write random access to data on
the disk.

>
> Flash however can be treated as read-only memory.

Some flash can, yes - typically the small, fast and expensive "NOR"
flash used in microcontrollers for program memory. NAND flash, as used
in SSD's and larger flash, is read as blocks (with ECC, bad block
management, indirection/translation layers, etc.). It is a block
device, like a spinning rust disk but faster.

> If you want to write
> to it it's a bit more difficult. The actual writing can still be via memory-
> mapped pointer dereferences, but you have to erase before writing,
> and you have to ration your writes as it can only support a limited number
> of cycles.
>

You do not write to or erase flash using normal memory pointers (except
by use of an MMU and an OS for mmap'ed files and the like, as mentioned
above).

NOR flash (for embedded systems) can be read as memory. But flash is
written and erased as a device. (Of course, controlling the device is
generally done by volatile reads and writes to hardware device
registers, which is often done via pointers, but I don't think that is
what you mean.)

On Friday, 7 May 2021 at 14:21:00 UTC+1, David Brown wrote:
> On 07/05/2021 14:56, Malcolm McLean wrote:
> > On Friday, 7 May 2021 at 08:06:30 UTC+1, David Brown wrote:
> >> On 07/05/2021 01:10, Kaz Kylheku wrote:
> >>> On 2021-05-06, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> >>>>> And would disk be a 3rd form of memory? Or is that an
> >>>>> entirely different concept?
> >>>>>
> >>>> Traditionally disks have been treated as backing store because they
> >>>> didn't support efficient random access. However that's no longer the
> >>>
> >>> This is badly stated.
> >> It's not just badly stated, it is wrong.
> > i>
> > Efficient random access is crucial to storage being used as "memory".
> > Disks are better than tapes, but still not efficient enough.
> Fair enough, as far as it goes. But since disks are not remotely close
> enough in random access behaviour to ram, they are never used directly
> as "memory". The closest you get is using them as backing store for
> swap files.
>
> You can certainly use normal memory pointers, combined with an MMU and
> an OS handling reads and writes to block storage, as a way of accessing
> data on disks in a convenient manner. This is what is done with mmap()
> (and you can consider swap memory to be the same idea).
>
> However, you do not have direct read or write random access to data on
> the disk.
> >
> > Flash however can be treated as read-only memory.
> Some flash can, yes - typically the small, fast and expensive "NOR"
> flash used in microcontrollers for program memory. NAND flash, as used
> in SSD's and larger flash, is read as blocks (with ECC, bad block
> management, indirection/translation layers, etc.). It is a block
> device, like a spinning rust disk but faster.
> > If you want to write
> > to it it's a bit more difficult. The actual writing can still be via memory-
> > mapped pointer dereferences, but you have to erase before writing,
> > and you have to ration your writes as it can only support a limited number
> > of cycles.
> >
> You do not write to or erase flash using normal memory pointers (except
> by use of an MMU and an OS for mmap'ed files and the like, as mentioned
> above).
>
> NOR flash (for embedded systems) can be read as memory. But flash is
> written and erased as a device. (Of course, controlling the device is
> generally done by volatile reads and writes to hardware device
> registers, which is often done via pointers, but I don't think that is
> what you mean.)
>
That's not what i remember. Erasing a block, which had to be done via special
instructions, put it into a state of all bits set. It was then possible to clear
a set bit, but not set a clear bit.
So initially after erasure a byte would be 0xFF. If you then wrote 0x06 to it
you would clear all but bits 1 and 2. If you then wrote 0x05 to it, you would
clear bit one, but you would not set bit zero. So the result would be a byte of
0x04.
This was several years ago. Technology has moved on and modern systems
might not work that way.

David Brown <david.brown@hesbynett.no> writes:
>On 07/05/2021 01:10, Kaz Kylheku wrote:

>>
>> I doubt it. Solid states are block devices which implement a flash
>> translation layer over a memory that doesn't behave like C memory. The
>> only way you're reasonably going to have pointers into them is if you
>> map the block device with a MMU, which you're already doing today.
>>
>
>That is correct. In a sense, SSD's are even less random access than
>spinning rust as the worst you can do with them would be random writes
>scattered about (assuming you first have it mapped with mmap() or similar).

There are, today, hybrid DIMMs installed in systems that provide both
dynamic ram and non-volatile ram (e.g. Optane) as elements of the physical
address space. This trend will continue, giving the size of a 64-bit
physical address space, quite a large amount of it could be direct mapped
flash/PCM/MRM nonvolatile memory.

ARM added instructions to deal with this to the ARMv8 instruction
set (e.g. DC CVAP - Data Cache clear by VA to "point of persistence".

The cache subsystem will load/store 64 bytes (on intel/amd, 128 on other cpus)
at a time from the underlying storage devices into the LLC/L2/L1 as
required.

>
>
>(Technically, a dedicated ram disk device with battery backup is also an
>SSD, but those are rare.)

The were common, albeit expensive, back in the 1980's.

muta...@gmail.com <mutazilah@gmail.com> wrote:
> On Friday, May 7, 2021 at 8:33:08 PM UTC+10, Bart wrote:
>
> > >>> Ok, maybe the solution for me is to stop using C then?
> > >
> > >> Actually, the solution for you is to give up on the 8086
> > >> and use a modern CPU (e.g. x86_64 in long mode, or an
> > >> ARMv8-A core).
> > >>
> > >> 64-bit flat, paged address space is much easier to deal
> > >> with.
> > >
> > > No, that's cheating.
> > >
> > > You may as well have just standardized on that in 1990.
>
> > There were a range of devices in 1990 that offered flat address spaces
> > beyond 1MB.
> >
> > So why would that be cheating to use a more sensible processor than the
> > 8086?
>
> Because the 8086 existed, and couldn't be willed out
> of existence.

I successfuly managed that from 1992: machines that I bought
or advised other folks to buy where at least 386. And any
code I wrote required flat address space (some could run
on 86 because it would fit in 64k).
> It annoyed the hell out of me seeing people plastering
> code with "near" and "far". It's actually still unclear to
> me why people were doing that, instead of just choosing
> a memory model and leaving it at that. What were they
> trying to do? Be 1% faster, outside of human
> detectability?

I think you vastly underestimate perfomance effects. I quickly
left 86 behind, but heard reports of programs that after
recompilation in 32-bit flat mode run 20 times faster.
Part of this probably was due to better compiler optimization
(compiler had more resources and do not need to fight with
machine misfeatures, so could spent more effort on optimizing),
part due to better instruction set (86 had quite irregular
instruction set, 386 made it much more regular), but main
part was due to huge pointers. Simply looking

p++

where p is a pointer is single instruction in flat mode
or when using near pointers, but requires sequence of
several instructions for huge pointers.

> > > You can standardize on little-endian too. In fact, you
> > > can standardize on the exact x86_64 instruction set
> > > and just invalidate everything else. Why not?
>
> > Well, that's what I've done. But then I don't get the inexplicable
> > reason to turn the clock back to 1990. Is that because of the '90' in C90?
>
> I'm not turning the clock back. I never left. I'm not
> going to leave until I understand the situation in
> 1990.
>
> We can start with this question. Why did MSDOS
> print "Divide error" on a divide by zero situation
> instead of:
>
> got a divide by zero
> AX 0005 BX 0000 CX 5C12 DX 0000
> SI 6F70 DI 0000 DS 5C12 ES 5C12
> BP 0FE8 CS 561B IP 00C1 FLAGS 0216
> module loaded at 561B:0000, entry point 561B:551E
> interrupt address is 561B:00C1
> regptrs is 6315:0FA6
> retaddr is 561B:5EC6
> and that caller might have done a near call to 561B:0000
> halting
>
>
> What was the technical barrier? MVS does something
> like that, and did so back in 1990.

Do you understand is that engineering is largly art of
getting useful results from limited resources? MSDOS
was designed to be usable when started from floppy disc.
IIUC first version was supposed to run in 32k. That
was quite different class of systems compared to MVS.
First, relatively early in OS360 history IBM decided
that you need permanently attached disc to run OS360.
Second, MVS started to show resonable performance
only after machines got few megs of real storage
and several megs of virtual storage.

Another things is how flexible is your system. Your
message has 'module loaded at' but that implies that
OS must be in some way notified about modules. It
can be argued that program should have right to use
modules in any wat it wishes, in particular in ways
not understood by OS. Also, question is what users
want. Unix used to create core dumps by default.
From core dump you can get more detailed information
than message above. But "ordinary" folks did not
look at core dumps, treating them as trash that needs
to be deleted. So on Linux popular default is to
disable core dumps.

BTW: If program is compiled with debugging info you
can get much better information than message above,
namely you can see source line (say in C) responsible
for crash. Apparently most folks are not interested
in such info and insist on stripping executables to
save disc space (Linux distribution now ofer separate
package with debug info for folks that want it).

> I care far more about EBCDIC than Unicode, and you
> can't will EBCDIC out of existence anyway. Not even
> in 2021, never mind 1990.

Well, I can make it irrelevant. Most of my programs
will not run on EBCDIC machines, and if needed EBCDIC
can be handled by translation table on imput and output.
Nothing beyond tiny part of program must be aware of
inconvenience. Note that this is not much different
from what IBM was and is doing: peripherial used various
encodings but translation tables give appearence of EBCDIC.

--
Waldek Hebisch

On 07/05/2021 12:33, muta...@gmail.com wrote:
> On Friday, May 7, 2021 at 8:33:08 PM UTC+10, Bart wrote:

>> There were a range of devices in 1990 that offered flat address spaces
>> beyond 1MB.
>>
>> So why would that be cheating to use a more sensible processor than the
>> 8086?
>
> Because the 8086 existed, and couldn't be willed out
> of existence.

So did lots of microprocessors then. In that case, why choose, 30 years
on, one of the worst architectures?

> It annoyed the hell out of me seeing people plastering
> code with "near" and "far".

I found the half dozen memory models of C amusing (eg code fits within
64KB, but larger data; or large code and small data; et). But I never
used C then; my own systems language just had the one model.

>> Well, that's what I've done. But then I don't get the inexplicable
>> reason to turn the clock back to 1990. Is that because of the '90' in C90?
>
> I'm not turning the clock back. I never left. I'm not
> going to leave until I understand the situation in
> 1990.
>
> We can start with this question. Why did MSDOS
> print "Divide error" on a divide by zero situation
> instead of:
>
> got a divide by zero
> AX 0005 BX 0000 CX 5C12 DX 0000
> SI 6F70 DI 0000 DS 5C12 ES 5C12
> BP 0FE8 CS 561B IP 00C1 FLAGS 0216
> module loaded at 561B:0000, entry point 561B:551E
> interrupt address is 561B:00C1
> regptrs is 6315:0FA6
> retaddr is 561B:5EC6
> and that caller might have done a near call to 561B:0000
> halting

>
> What was the technical barrier? MVS does something
> like that, and did so back in 1990.

Did MVS run on a microprocessor?

In any case, what is the situation now? If I force a divide by zero in a
C program, Windows just reports: 'c.exe' has stopped working. If I click
on details, I get:

Problem Event Name: APPCRASH
Application Name: c.exe
Application Version: 0.0.0.0
Application Timestamp: 60956988
Fault Module Name: c.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 60956988
Exception Code: c0000094
Exception Offset: 000000000000157f
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 2057
Additional Information 1: 70a3
Additional Information 2: 70a30a9820a2087554b9fcb6d7f5ee06
Additional Information 3: 3d3c
Additional Information 4: 3d3c8ca5d7214eb0f6102d63ed858949

Really useful! If I run it on rextester.com, I get 'Floating point
exception (SIGFPE)' but nothing else. More useful is a line number in a
source file, but how is the OS supposed to know that? It only has a binary.

> How was a production environment using MSDOS
> meant to report that problem to the vendor? It's
> unclear who the vendor even is.

Maybe you've forgotten how basic MSDOS was, and how limited the
resources. (But they will usually know the vendor because in those days
you had to pay for software.)

However, the resources are no longer so limited. (I'd be surprised if
you could still buy DRAM chips from the 1980s; you might have trouble
these days buying anything smaller than a 1GB module. You'd have to look
at what's used with small embedded devices.)

>> Because limiting the target hardware for a C90 implementation to only
>> those machines available in 1990 is ridiculous. It's like only creating
>> Algol68 implementions for machines available in 1968.
>
> No, that's not correct. When I was programming in C
> in 1990 I programmed with the assumption that in
> the future, char/short/int/long would all be 256 bits
> one day.

Really? All my applications were written with exactly one target in
mind. (And my languages were the same.)

Assuming the lifetime of each platform at ten years, apps would need
rewriting towards the end anyway.

My 'int' (not in C, and AFAICR), was 16 bits from 1981 to 2001, then 32
bits, then 64 bits from perhaps 2012.

I'm not anticipating a /default/ int size of 128 bits anytime soon. If I
need that specically, I have a 128-bit version, or I will use a bignums.

Neither am I expecting a char size of 256 bits, which would rather a
massive character set. (I do use an internal 64-bit char, but only
because all operations are in 64 bits. Strings of ASCII/UTF8 use 8-bit
characters.)

But, good luck with 256-bit integers and characters on 8086.

(BTW your comment makes little sense. You want to write software as
though the 8086 was the only processor that ever existed, or ever will,
but at the same time, you like to assume that chars and ints could be
any size up to 256 bits each. Which I would bet are not accommodated in
your actual software.)

>>> And drop
>>> EBCDIC at the same time.
>
>> That's actually a good idea. AFAIK it's not part of Unicode.
>
> I care far more about EBCDIC than Unicode, and you
> can't will EBCDIC out of existence anyway.

Most people are doing it very successfully! I haven't used EBCDIC since
1977.

> Not even
> in 2021, never mind 1990.

Do you have a link to ANY online document coded in EBCDIC?

On Saturday, May 8, 2021 at 1:38:12 AM UTC+10, anti...@math.uni.wroc.pl wrote:

> > Because the 8086 existed, and couldn't be willed out
> > of existence.

> I successfuly managed that from 1992: machines that I bought
> or advised other folks to buy where at least 386. And any
> code I wrote required flat address space (some could run
> on 86 because it would fit in 64k).

I'm not sure there is a need to require a flat
address space. This is something that should
be transparent.

> > It annoyed the hell out of me seeing people plastering
> > code with "near" and "far". It's actually still unclear to
> > me why people were doing that, instead of just choosing
> > a memory model and leaving it at that. What were they
> > trying to do? Be 1% faster, outside of human
> > detectability?

> I think you vastly underestimate perfomance effects. I quickly
> left 86 behind, but heard reports of programs that after
> recompilation in 32-bit flat mode run 20 times faster.
> Part of this probably was due to better compiler optimization
> (compiler had more resources and do not need to fight with
> machine misfeatures, so could spent more effort on optimizing),
> part due to better instruction set (86 had quite irregular

I think you misunderstood me. The target was 8086.
Why did people code the keywords "near" and "far"?
Why not just choose a memory model, e.g. "compact",
and leave it at that?

> instruction set, 386 made it much more regular), but main
> part was due to huge pointers. Simply looking
>
> p++
>
> where p is a pointer is single instruction in flat mode
> or when using near pointers, but requires sequence of
> several instructions for huge pointers.

It was rare for people to use huge pointers, and no
memory model gives you complete huge pointers.
far pointers do not require several instructions to
increment.

> > What was the technical barrier? MVS does something
> > like that, and did so back in 1990.

> Do you understand is that engineering is largly art of
> getting useful results from limited resources? MSDOS
> was designed to be usable when started from floppy disc.
> IIUC first version was supposed to run in 32k. That

You can use that argument to say that MSDOS should
have stayed at 1.0 and no functionality should have
been added.

Is adding a coredump facility such a huge amount
of code?

> Another things is how flexible is your system. Your
> message has 'module loaded at' but that implies that
> OS must be in some way notified about modules. It
> can be argued that program should have right to use
> modules in any wat it wishes, in particular in ways
> not understood by OS.

I don't care if MSDOS doesn't diagnose faults where
the program has bypassed the OS.

I'm after diagnosis of conforming programs, that have
a bug, such as divide by zero.

> Also, question is what users
> want. Unix used to create core dumps by default.
> From core dump you can get more detailed information
> than message above. But "ordinary" folks did not
> look at core dumps, treating them as trash that needs
> to be deleted. So on Linux popular default is to
> disable core dumps.

Well it seems that every environment except IBM
mainframes is run by donkeys.

> BTW: If program is compiled with debugging info you
> can get much better information than message above,
> namely you can see source line (say in C) responsible
> for crash. Apparently most folks are not interested
> in such info and insist on stripping executables to
> save disc space

That is perfectly fine. The software vendor should be
able to regenerate the executable with debug any time
they want, to match up to the coredump.

> Well, I can make it irrelevant. Most of my programs
> will not run on EBCDIC machines,

Then you're not programming in C.

BFN. Paul.

On Saturday, May 8, 2021 at 2:52:58 AM UTC+10, Bart wrote:

> > Because the 8086 existed, and couldn't be willed out
> > of existence.

> So did lots of microprocessors then. In that case, why choose, 30 years
> on, one of the worst architectures?

I'm not "choosing" it, I'm "catering" for it.

> > What was the technical barrier? MVS does something
> > like that, and did so back in 1990.

> Did MVS run on a microprocessor?

No. But PDOS/86 runs on an 8086 and just printed out
that divide by zero diagnostics.

> Really useful! If I run it on rextester.com, I get 'Floating point
> exception (SIGFPE)' but nothing else. More useful is a line number in a
> source file, but how is the OS supposed to know that? It only has a binary.

That's an interesting comment to make.

MVS executables in the 1980s were all binary too.

That's what professionals do.

The user only needs to provide the dump to the vendor.
The vendor will match it up to source. The OS doesn't
need to know. The OS just needs to report full diagnostics,
as MVS does.

> > How was a production environment using MSDOS
> > meant to report that problem to the vendor? It's
> > unclear who the vendor even is.

> Maybe you've forgotten how basic MSDOS was, and how limited the
> resources. (But they will usually know the vendor because in those days
> you had to pay for software.)

PDOS/86 runs in 640k, which is what I had when I was
running MSDOS on a real 8086.

PDOS/86 was able to print out much more than
"Divide error".

> But, good luck with 256-bit integers and characters on 8086.

I didn't expect to see that on an 8086. My software
was designed to run on a future platform.

> (BTW your comment makes little sense. You want to write software as
> though the 8086 was the only processor that ever existed, or ever will,

No, that's far from correct. 8086 is one of many.

The operative word is "one". As opposed to "zero".

> but at the same time, you like to assume that chars and ints could be
> any size up to 256 bits each. Which I would bet are not accommodated in
> your actual software.)

Most of my software is written in portable C and should
work with 256 bits as above.

> > Not even
> > in 2021, never mind 1990.

> Do you have a link to ANY online document coded in EBCDIC?

ASCII is the standard for the web, not EBCDIC.

That doesn't mean EBCDIC doesn't exist.

BFN. Paul.

On 07/05/2021 18:10, muta...@gmail.com wrote:
> On Saturday, May 8, 2021 at 2:52:58 AM UTC+10, Bart wrote:

> The user only needs to provide the dump to the vendor.
> The vendor will match it up to source.

Now you're going back to the 1970s. Do machines still dump all of memory
after a crash? I for one would have no idea what to do with it. (A lot
of the addresses for allocated memory seem to vary from run to run anyway.)

Users now are not just computer centre professionals, they are anybody;
what are /they/ supposed to do with a dump?

> The OS doesn't
> need to know. The OS just needs to report full diagnostics,
> as MVS does.

But I said that the massive Windows OS doesn't, and none of its one
billion users seems to care. So why does it matter if MSDOS doesn't?

In any case, by the time a program error has caused enough mischief to
be detected by the OS, a billion instructions may have been executed
from the point of the actual bug. Half the time the execution address
will be inside an external library or the OS itself.

> PDOS/86 was able to print out much more than
> "Divide error".

Divide error is an easy one to trace in a program, as divide ops are not
that common.

>> But, good luck with 256-bit integers and characters on 8086.
>
> I didn't expect to see that on an 8086. My software
> was designed to run on a future platform.

But presumably not one of the current 64-bit ones?

>> (BTW your comment makes little sense. You want to write software as
>> though the 8086 was the only processor that ever existed, or ever will,
>
> No, that's far from correct. 8086 is one of many.
>
> The operative word is "one". As opposed to "zero".
>
>> but at the same time, you like to assume that chars and ints could be
>> any size up to 256 bits each. Which I would bet are not accommodated in
>> your actual software.)
>
> Most of my software is written in portable C and should
> work with 256 bits as above.

What about other peoples'? Most C code won't work when if int was 64
bits instead of 32.

>>> Not even
>>> in 2021, never mind 1990.
>
>> Do you have a link to ANY online document coded in EBCDIC?
>
> ASCII is the standard for the web, not EBCDIC.

That should tell you a lot. Why dump ASCII? It's like dumping English
and deciding you're only going to use Esperanto or Ido. It's crazy.

> That doesn't mean EBCDIC doesn't exist.

OK. But where, exactly? I've seen endless examples of text files for
Unix, for Windows, and containing UTF8. But I've never come across a
text file online which was EBCDIC.

On 2021-05-07, Bart <bc@freeuk.com> wrote:
> On 07/05/2021 18:10, muta...@gmail.com wrote:
>> On Saturday, May 8, 2021 at 2:52:58 AM UTC+10, Bart wrote:
>
>> The user only needs to provide the dump to the vendor.
>> The vendor will match it up to source.
>
> Now you're going back to the 1970s. Do machines still dump all of memory
> after a crash? I for one would have no idea what to do with it. (A lot
> of the addresses for allocated memory seem to vary from run to run anyway.)
>
> Users now are not just computer centre professionals, they are anybody;
> what are /they/ supposed to do with a dump?
>
>> The OS doesn't
>> need to know. The OS just needs to report full diagnostics,
>> as MVS does.
>
> But I said that the massive Windows OS doesn't, and none of its one
> billion users seems to care. So why does it matter if MSDOS doesn't?
>
> In any case, by the time a program error has caused enough mischief to
> be detected by the OS, a billion instructions may have been executed
> from the point of the actual bug. Half the time the execution address
> will be inside an external library or the OS itself.
>
>
>> PDOS/86 was able to print out much more than
>> "Divide error".
>
> Divide error is an easy one to trace in a program, as divide ops are not
> that common.
>
>>> But, good luck with 256-bit integers and characters on 8086.
>>
>> I didn't expect to see that on an 8086. My software
>> was designed to run on a future platform.
>
> But presumably not one of the current 64-bit ones?
>
>>> (BTW your comment makes little sense. You want to write software as
>>> though the 8086 was the only processor that ever existed, or ever will,
>>
>> No, that's far from correct. 8086 is one of many.
>>
>> The operative word is "one". As opposed to "zero".
>>
>>> but at the same time, you like to assume that chars and ints could be
>>> any size up to 256 bits each. Which I would bet are not accommodated in
>>> your actual software.)
>>
>> Most of my software is written in portable C and should
>> work with 256 bits as above.
>
> What about other peoples'? Most C code won't work when if int was 64
> bits instead of 32.
>
>>>> Not even
>>>> in 2021, never mind 1990.
>>
>>> Do you have a link to ANY online document coded in EBCDIC?
>>
>> ASCII is the standard for the web, not EBCDIC.
>
> That should tell you a lot. Why dump ASCII? It's like dumping English
> and deciding you're only going to use Esperanto or Ido. It's crazy.
>
>
>> That doesn't mean EBCDIC doesn't exist.
>
> OK. But where, exactly? I've seen endless examples of text files for
> Unix, for Windows, and containing UTF8. But I've never come across a
> text file online which was EBCDIC.

In 1992. I had to write support for EBCDIC in one program. Can't
remember what was it but I remember EBCDIC table how goes ;)

--
current job title: senior software engineer
skills: x86 aasembler,c++,c,rust,go,nim,haskell...

press any key to continue or any other to quit...

On Saturday, May 8, 2021 at 5:31:00 AM UTC+10, Bart wrote:

> > The user only needs to provide the dump to the vendor.
> > The vendor will match it up to source.

> Now you're going back to the 1970s.

No, I'm going back to when I was working in a professional
environment, MVS, in 1990. That professional environment
still exists in 2021, although it has been rebranded as z/OS.

> Do machines still dump all of memory
> after a crash?

Professional ones do, yes.

My desire is to make the x86-64 a professional
environment.

But part of that process starts with finding out
why the 8086 wasn't. What was the technical
barrier?

> I for one would have no idea what to do with it. (A lot
> of the addresses for allocated memory seem to vary from run to run anyway.)

Maybe it's time you learnt what to do with it?

If one of your customers is using your software in a
production environment, and once every 3 months
the software has a memory access violation, how
do you intend to solve it? Let's assume you can't
reproduce it in dev.

> Users now are not just computer centre professionals, they are anybody;
> what are /they/ supposed to do with a dump?

Ideally their computer would be configured to automatically
send the dump to the software vendor, and they have a
100 Mbps internet link, so the vendor has the dump open
on a window on their computer within 1 second of the
crash occurring.

Is there a technical barrier to this? Do we need 1 Gbps
before we can get sub-1-second response times?

Also, the user should be presented (within 1 second),
a confirmation id from the vendor that they have
received your bug report, a URL to the problem
report, and if they click on the link, the ETA should be
given as "how long is a piece of string?".

> > The OS doesn't
> > need to know. The OS just needs to report full diagnostics,
> > as MVS does.

> But I said that the massive Windows OS doesn't,

That's because Windows is for donkeys. Professionals
use MVS while waiting for PD-Windows.

> and none of its one billion users seems to care.

That's not true. I care.

I don't know where you are getting your statistics from,
but sometimes it is the minority who is right. Sometimes
it's not even a minority. At one point literally 100% of the
planet sincerely believed the Sun went around the Earth.
They even had what they sincerely believed was
irrefutable evidence that that was the case.

> So why does it matter if MSDOS doesn't?

Both matter.

> In any case, by the time a program error has caused enough mischief to
> be detected by the OS, a billion instructions may have been executed
> from the point of the actual bug.

The operative word is *may*. Normally it's close to
the point of failure.

Regardless, in the billion instructions situation, that's
where the challenge begins. You need to analyze the
state of your software at point of failure and find a
way of going back 1 billion instructions. It may not
be possible for you to do that. So the next step is to
ask for a hardware slip trap to be installed so that
you can monitor what happens earlier in the process,
for the next time it happens.

Actually, although I personally have constructed slip
traps, I've never been faced with the 1 billion instructions
situation, so I am not familiar with all the tracing options
(and concepts) that MVS provides.

Because it's a moot point. I want this to exist in
PD-Windows, not MVS. I only want to rely on OS
features I can actually produce myself.

> Half the time the execution address
> will be inside an external library

Yes, who do you expect to diagnose bugs that are inside
an external library used by the vendor?

> or the OS itself.

Ditto. Who do you expect to diagnose OS bugs?

> > PDOS/86 was able to print out much more than
> > "Divide error".

> Divide error is an easy one to trace in a program, as divide ops are not
> that common.

It's just an example. Normally it's a protection exception
that needs to be debugged.

> >> But, good luck with 256-bit integers and characters on 8086.
> >
> > I didn't expect to see that on an 8086. My software
> > was designed to run on a future platform.

> But presumably not one of the current 64-bit ones?

No, that's not correct. Most of my software will
run on 64-bit platforms. Little-endian, big-endian,
ASCII, EBCDIC. Everything that is C90-compliant.

> > Most of my software is written in portable C and should
> > work with 256 bits as above.

> What about other peoples'? Most C code won't work when if int was 64
> bits instead of 32.

The process of converting donkeys into professionals
needs to begin at some point.

> >>> Not even
> >>> in 2021, never mind 1990.
> >
> >> Do you have a link to ANY online document coded in EBCDIC?
> >
> > ASCII is the standard for the web, not EBCDIC.

> That should tell you a lot. Why dump ASCII? It's like dumping English
> and deciding you're only going to use Esperanto or Ido. It's crazy.

I'm not the one dumping ASCII. You're the one trying
to dump EBCDIC. That's more like dumping French.

> > That doesn't mean EBCDIC doesn't exist.

> OK. But where, exactly? I've seen endless examples of text files for
> Unix, for Windows, and containing UTF8. But I've never come across a
> text file online which was EBCDIC.

Would you like me to send you an archive containing
complete GCC 3.2.3 source code and generated
S/370 assembler in EBCDIC? All text. It's already
available online. It's stored in a RECFM=V (ie with
RDWs) PDS.

BFN. Paul.