> [A]lthough these days "byte" is synonymous with "8 bits", historically it
> meant "the number of bits needed to store a single character".
It depends upon what you mean by "historically". Originally "byte"
was coined to refer to 8 bit addressable units on the IBM 7030 "Stretch"
computer. The term was perpetuated for the 360 family of computers. Only
later did people begin to attribute the meaning to non-addressable
6- or 9-bit units on 36- and 18-bit machines.
Viewed over history, the latter usage was transient and colloquial.
Doug
I should have checked my 7030 manual before asserting
that the 8-bit byte came from there. The term did,
but it meant an addressable unit of 1 to 8 bits
depending on the instruction being executed.
[The machine was addressable to the bit. It also
had all 16 bitwise logical operators, and
maintained counts of the 1 bits and leading
0 bits in a register. And it was BIG. I saw
one with 17 memory boxes (each essentially
identical with the total memory of a 7090)
stretched across the immaculate hardwood
floor of IBM's Poughkeepsie plant.]
Doug
The surviving 8th edition source has code for Chaos networking included:
https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys <https://www.tuhs.org/cgi-bin/utree.pl?file=V8/usr/sys>
It does not appear to be included in the man pages.
Was Chaos networking in use at the labs, or is it just an artifact present on the surviving tape?
Related to that, I’m interested in the Chaosnet implementation for 7th edition. Dave Moon's Chaosnet memo includes this intriguing sentence when talking about the V7 implementation: “The NCP is entirely implemented in the kernel as a device driver”.
I could not find that source code in the TUHS archive, nor on Kirk McKusick’s DVD. Does anybody happen to have it?
Discussions today on the TUHS list about the signed/unsigned nature of
the C char type led me to reexamine logs of my feature test package at
http://www.math.utah.edu/pub/features/
I had 170 build logs for it from 2017.11.07, so I moved those aside
and ran another set of builds in our current enlarged test farm. That
generated another 361 fresh builds. Those tests are all with the C
compiler named "cc". I did not explore what other C compilers did,
but I strongly suspect that they all agree on any single platform.
On all but THREE systems, the tests report that "char" is signed, with
CHAR_MAX == +127.
The three outliers have char unsigned with CHAR_MAX == +255, and are
* ARM armv7l Linux 4.13.1 (2017) and 5.6.7 (2020)
* SGI O2 R10000-SC (150 MHz) IRIX 6.5 (2017 and 2020)
* IBM POWER8 CentOS Linux release 7.4.1708 (AltArch) (2017)
So, while the ISO C Standards, and historical practice, leave it
implementation dependent whether char is signed or unsigned, there is
a strong majority for a signed type.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
Hello All
In case this is of interest:
> Date: Sat, 16 May 2020 12:18:15 +0100
> Subject: qed-archive (Github)
> To: arnold(a)skeeve.com
>
> Hi Arnold
>
> Apologies for an un-solicited email.
>
> I have ported Rob's UofT QED from your qed-archive/unix-1992 to Linux
> (although I suspect anything with a Unix API will work), and have updated
> it to work completely in UTF8/Unicode. This includes correct handling of
> unicode codepoints in regexes, subs, etc.
>
> It's up on Github under phonologus/QED. I thought you might want to add it
> to your list of QED-s in your README, as it may be of interest to the other
> three connoisseurs out there...!
>
> I have also included typeset pdf-s of the tutorial and manpage. The
> tutorial is fascinating.
>
> Also, there is no clear statement about copyright, or license, of the
> unix-1992 tarball. I have attributed it to Rob, and I have noted that I
> scavenged it from your Github repo, but was wondering if there is any
> definitive statement on ownership/authorship that I could include in my
> repo?
>
> Best wishes
Brantley Coile <brantley(a)coraid.com> wrote on Sun, 17 May 2020 01:36:16 +0000:
>> It looks like only grap and pic have mkfiles that invoke lex.
Both of those are Brian Kernighan's work, and from the FIXES file
in his nawk, I can offer this quote:
>> ...
>> Aug 9, 1997:
>> somewhat regretfully, replaced the ancient lex-based lexical
>> analyzer with one written in C. it's longer, generates less code,
>> and more portable; the old one depended too much on mysterious
>> properties of lex that were not preserved in other environments.
>> in theory these recognize the same language.
>> ...
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> The function prototype for getchar() is: int getchar(void);
>
> It returns an int, not a char. In all likelihood this is specifically
> *because* EOF is defined as -1.
It would have probably returned int anyway, because of the automatic
promotion of char to int in expressions. It was natural to declare
functions returning char as int, if you bothered to declare them at
all. As K&R1 said:
Since char promotes to int in expressions, there is no need
to declare functions that return char.
Similarly functions that might return short or float would normally
return int or double; there aren't separate atof and atod functions
for example.
-- Richard
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
Hi Legends,
during corona times i “ported” Dave Cheney’s avr11 PDP11/40 emulator to a Teensy 4 MCU board,
fixed already some bugs in it and added multiple rk drives and a partially working tm emulation.
(space forward/reverse unimplemented)
It runs V6 at about 1 Mips and is completely fine usable with multiple rk and tm drives.
Playing around with V6 i noticed that Shoppa disk and tried to get ncc running, but after some
debugging it looked like it is stuck in some loop which i think is due to possible bugs in
the emulator code.
So the question is, are there programs V6 runnable or rk bootable available which test the CPU
functionality? I already hat a look at some xxdp disk, but the one i found (while they boot)
seem to lack basic cpu tests.
Best regards,
Michael
The properties of object oriented programming are better described as an la carte menu like a cafeteria buffet or smörgåsbord, than a point, line, or continuum.
http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html>
Paul Graham: Reese Re: OO
(Jonathan Rees had a really interesting response to Why Arc isn't Especially Object-Oriented, which he has allowed me to reproduce here.)
Here is an a la carte menu of features or properties that are related to these terms; I have heard OO defined to be many different subsets of this list.
• Encapsulation - the ability to syntactically hide the implementation of a type. E.g. in C or Pascal you always know whether something is a struct or an array, but in CLU and Java you can hide the difference.
• Protection - the inability of the client of a type to detect its implementation. This guarantees that a behavior-preserving change to an implementation will not break its clients, and also makes sure that things like passwords don't leak out.
• Ad hoc polymorphism - functions and data structures with parameters that can take on values of many different types.
• Parametric polymorphism - functions and data structures that parameterize over arbitrary values (e.g. list of anything). ML and Lisp both have this. Java doesn't quite because of its non-Object types.
• Everything is an object - all values are objects. True in Smalltalk (?) but not in Java (because of int and friends).
• All you can do is send a message (AYCDISAM) = Actors model - there is no direct manipulation of objects, only communication with (or invocation of) them. The presence of fields in Java violates this.
• Specification inheritance = subtyping - there are distinct types known to the language with the property that a value of one type is as good as a value of another for the purposes of type correctness. (E.g. Java interface inheritance.)
• Implementation inheritance/reuse - having written one pile of code, a similar pile (e.g. a superset) can be generated in a controlled manner, i.e. the code doesn't have to be copied and edited. A limited and peculiar kind of abstraction. (E.g. Java class inheritance.)
• Sum-of-product-of-function pattern - objects are (in effect) restricted to be functions that take as first argument a distinguished method key argument that is drawn from a finite set of simple names.
[…]
(See the web page and the original thread for a discussion of which languages implement which of the above features.)
http://www.paulgraham.com/reesoo.html <http://www.paulgraham.com/reesoo.html>
https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail… <https://web.archive.org/web/20160308032317/http://www.eros-os.org/pipermail…>
-Don
