Latin was the standard language of the Roman-Catholic Mass until the Second Vatican Council in the 1960s. The current form of the Mass in national languages was formalized in 1970.
In this document [1] dated 1967-68, on page 8, IBM mention 8-bit character sets only: their EBCDIC and the "8-bit extension of the 7-bit code" proposed by ISO.
Because eight rather than six bits are used
to represent a. character, up to 256 possible characters
could be represented in the Extended Binary Coded
Decimal Interchange Code (EBCDIC) shown in Figure 7. Except for certain teleprocessing equipment,
the code that makes use of characters is either
EBCDIC or an eight-bit extension of a seven-bit code
proposed by the International Standards Organization.
IBM System/360 normally used the IBM EBCDIC 8-bit character set, which was designed simultaneously with the decision to use 8-bit bytes, before the launch of System/360. All the IBM computers older than System/360 had used 6-bit character sets.
The 7-bit ASCII code, with a few small differences from the current version, had been standardized in 1967 in USA as USAS X3.4-1967 and internationally as ISO 646.
No computer has ever been designed with 7-bit bytes, so all computers with 8-bit bytes, starting with IBM System/360, store the ASCII characters using an "8-bit extension of the 7-bit code".
Your document refers to this. The fact that ASCII has only 7 bits mattered only when the characters were sent over communication lines, when there was no need to transmit more than 7 data bits.
While in IBM systems EBCDIC was the primary character set and ASCII was used only for interchange with computing equipment made by other companies, in all the computers made by others the usage was reversed, ASCII extended to 8 bits was the primary character set, but EBCDIC was also supported for data interchange with IBM computers.
In general, I agree with your conclusions. However, I found it interesting that this document made no mention of ASCII or other 7-bit character sets. Especially since the first version of the standard (X3.4-1963, no lowercase) was already several years old at that point.
That document referred very clearly to ASCII (the 1967 variant), by "seven-bit code proposed by the International Standards Organization". There was no other character set that could be referred to by these words. Probably at the time when the document had been written it was not known yet that the number of the standard would be ISO 646.
The 1963 ASCII version was very different from the 1967 and later versions, it did not even have lowercase letters.
ASCII-1963 must be considered as a different character set from the later ASCII versions. It had a very limited adoption as a method for storing text in computers, because in the beginning only IBM System/360 had 8-bit bytes, while most other computers still had 6-bit bytes, and System/360 used a much more complete character set, EBCDIC, for storing text.
Thus ASCII-1963 was used in the beginning only for communication on serial lines, e.g. in terminals like Teletype Model 33, where it had the advantage of having more control characters than 6-bit character sets, even if it had only about the same set of printable characters. For storage, an ASCII-1963 string would have been converted to some 6-bit character set, because there was no need to store control characters and the number of printable characters was less than 64.
In most contexts references to "ASCII" should be understood as referring only to the 1967 and later versions, which were complete 7-bit character sets and which were adopted as both US and international standards.
But does it really matter what the details were? The most important thing is that the standard published in 1963 was 7-bit. I mentioned that the 1963 version did not include lowercase letters. The (unpublished) 1965 version, mentioned on the first scan page, did.
As for the name, the acronym ASCII comes from the 1963 version (American Standard Code for Information Interchange). Later in 1966, ASA became USASI, and the official name was changed to USASCII, with ASCII as an acceptable alternative abbreviation. Later still, in 1969, USASI changed its name once again to ANSI, and an attempt was made to rename it ANSCII, but this did not catch on, and ASCII returned as the official name.
As for this 8-bit extension (not seven-bit code proposed by the ISO), perhaps they were referring to ECMA-35, the first version of which was published in December 1971? Or perhaps other proposals mentioned in the brief history. Of course, it seems that ASCII - regardless of the version - served as the basis for these extensions.
My point was that before the 1967 version, ASCII had no influence whatsoever on the design of computer architectures, because it was useful only for transmission on serial communication lines and it remained compatible with the use of 6-bit character sets for storing character strings in the computer memory.
Only after the number of printable characters had been greatly increased in 1967, making impossible the conversion to 6-bit character sets, and the new version was adopted not only in USA, but also internationally, by both ISO and CCITT, it became a necessity to have a byte size equal to or greater than 7 bits, in order to be able to store efficiently ASCII strings in computers.
From that moment on, the 8-bit byte size became a hard requirement for any new computer ISA, e.g. for DEC PDP-11, which was designed mostly during 1969 and it was launched in 1970.
Anyway, I do not see how this affects the design of C in a way that makes no sense anymore today (except that one could require CHAR_BIT to be eight, but there are still DSPs where this is not the case). I think people repeat the "the C design reflects the out-dated PDP-11 hardware" meme because it sounds smart while in reality it is just nonsense.
So when is WG14 standardising modern hardware into the C standard?
Basic stuff like SIMD, SIMT, without requiring users to go beyond language extensions, something that any programming language can offer in similar capacity?
Why does the language standard need to prescribe everything. It is a standardization of between existing compilers, they are allowed and intended to invent things. If anything the experience from C++ has shown, that writing too much behaviour into the standard accidentally has consequences on the possible performance. The C standard is descriptive, not prescriptive.
> something that any programming language can offer in similar capacity?
By your measure a lot of other languages don't offer anything to begin with, because they do not have a standard at all, only a reference implementation.
It isn't 1970 anymore. You can get 32-bit ARM MCUs with tens of kilobytes of flash and multiple kilobytes of RAM for less than 10 cents.
We've long since reached a point where chips are cheap enough to be disposable. They are included in paper transit tickets and price tags. There is basically no market left where your volume is small enough that custom application-specific ICs aren't an option, but your volume is large enough that the cost of a few additional kilobytes of memory isn't massively outweighed by the developer time saved.
Want several megabytes of RAM and flash to run Java? That's the price of a cup of coffee!
You always could find deep niche where any high-level technology is not suitable.
I don't think you will program such device in C, rather in assembly, right? When you have like memory for 500 commands, it is easier to go directly to assembler, anyway, with such hardware as a target you don't need portability, this code is 100% hardware-dependable, at it is perfectly Ok.
BTW, which uC your have in mind when you talk about single-digit nA draw (in running state? in deep sleep?), because old 8-bit architectures typically are designed for older node processes and not as energy effective as new one, and draw in sleep doesn't depend much on RAM or FLASH size or architecture, it is more design philosophy.
Anyway, PIC16LF (20nA in deep sleep) or 8051 clone (50nA in deep sleep) or STM8 (~0.30 uA in halt) or ATtinys (100nA in deep sleep), which are covered by "768 bytes of flash and 64 bytes of RAM" description are comparable with EFM32 ARM32-M0+ (20nA in deep sleep), same with uA/Mhz, but ARM32-M0+ will do much more work for each Mhz, so it will be more efficient in the end (faster does all work and go to sleep again).
I find this to be a bit strange question considering that I haven't mentioned the tablet model... but incidentally the answer is "yes" to both questions - it can boot from sd card also (beside eMMC), and there is a setup guide available: https://github.com/biolds/tibuta-w100/ (somewhat similar to the OP one)
If you won't form an argument illustrating how X is like Y, then try to resist simply stating that they are alike. It creates a wasteful, distracting fork in the conversation. Rhetorical analogies are lazy and almost always very shaky.
This is my pet project, a desktop app for working with xAI models & capabilities, so by "performance" I mostly mean "pleasant to use" (as it goes, simple & opinionated). Technically speaking, something like: stable FPS, no visible lags, and the ability to scroll smoothly while the model is streaming.
Regarding the parent comment: yes, memory is important, and I absolutely get the point. There should be a red line, for sure. But I will not sacrifice UX, productivity, and simple pleasure from using software just to save a few hundred megabytes of RAM (or even a few gigabytes) especially for an app I spend hours with behind the screen.
Memory consumption can & should be optimised with proper engineering for sure. As lags & inadequate performance in basic SDK-level primitives are much harder (impossible?) to fix from the outside.
reply