Tue Jan 18 13:26:14 EST 2022

JMP to a label: JMP _fthterminate
2011b8 4883c428 (644) ADDQ $40,SP
2011bc e9d0fcffff (493) JMP ,200e91
2011c1 4883c428 (656) ADDQ $40,SP

JMP to symbol: JMP terminate(SB)
2011b8 4883c428 (645) ADDQ $40,SP
2011bc ff2425910e2000 (670) JMP ,terminate+0(SB)
2011c3 4883c428 (672) ADDQ $40,SP

CALL to symbol: CALL terminate(SB)
2011b8 4883c428 (645) ADDQ $40,SP
2011bc e8d0fcffff (655) CALL ,200e91+terminate
2011c1 4883c428 (657) ADDQ $40,SP

JMP to a label: JMP _fthterminate
2011b8 4883c428 (644) ADDQ $40,SP
2011bc e9d0fcffff (493) JMP ,200e91
2011c1 4883c428 (656) ADDQ $40,SP

JMP to symbol: JMP terminate(SB)
2011b8 4883c428 (645) ADDQ $40,SP
2011bc ff2425910e2000 (654) JMP ,terminate+0(SB)
2011c3 4883c428 (657) ADDQ $40,SP

CALL to symbol: CALL terminate(SB)
2011b8 4883c428 (645) ADDQ $40,SP
2011bc e8d0fcffff (655) CALL ,200e91+terminate
2011c1 4883c428 (657) ADDQ $40,SP

#include <u.h>
#include <libc.h>
#include <libsec.h>

enum {
	KiB = 1024,
	MiB = 1024*KiB,
	GiB = 1024*MiB,
};

int nproc = 1;
int iosize = 8*1024;
char *order = "seq";
vlong fsize = 0;

int fd;
char *buf;
vlong nbytes = 0;
long (*iofn)(int, void*, long, vlong);

void
usage(void)
{
	fprint(2, "usage: %s [-p procs] [-s iosize] [-o order] path\n", argv0);
	exits("usage");
}

void
inc64(vlong *v, vlong dv)
{
	vlong ov, nv;

	while(1){
		ov = *v;
		nv = ov + dv;
		extern int cas64(u64int*, u64int, u64int);
		if(cas64((u64int*)v, ov, nv))
			break;
	}
}

vlong
seq(vlong off)
{
	return off + iosize;
}

vlong
skip(vlong off)
{
	return off + 2*iosize;
}

vlong
randoff(vlong off)
{
	return (fastrand()<<32)|fastrand();
}

void
io(vlong (*next)(vlong))
{
	vlong off = 0;

	while(1){
		pwrite(fd, buf, iosize, off);
		inc64(&nbytes, iosize);
		off = next(off);
		if(off > fsize + iosize)
			off -= fsize;
		off -= off % iosize;
	}
}

void
showstats(void)
{
	double speed;
	int sec;

	sec = 0;
	while(1){
		sleep(1000);
		sec++;
		speed = (double)nbytes/(double)sec;
		print("%lld/%d\n", nbytes, sec);
		if(speed > GiB)
			print("%f GiB/s\n", speed/GiB);
		else if(speed > MiB)
			print("%f MiB/s\n", speed/MiB);
		else if(speed > KiB)
			print("%f KiB/s\n", speed/KiB);
	}
}

void
main(int argc, char **argv)
{
	Dir *d;
	int i, pid;

	iofn = pwrite;
	ARGBEGIN{
	case 'p':
		nproc = atoi(EARGF(usage()));
		break;
	case 's':
		iosize = atoi(EARGF(usage()));
		break;
	case 'o':
		order = EARGF(usage());
		break;
	case 'r':
		iofn = pread;
		break;
	default:
		usage();
		break;
	}ARGEND;

	if(argc != 1)
		usage();
	if((fd = open(argv[0], OWRITE)) == -1)
		sysfatal("open %s: %r", argv[0]);
	if((d = dirfstat(fd)) == nil)
		sysfatal("stat %s: %r", argv[0]);
	if((buf = malloc(iosize)) == nil)
		sysfatal("alloc buf: %r");
	fsize = d->length;

	for(i = 0; i < nproc; i++){
		if((pid = rfork(RFPROC|RFMEM)) == -1)
			sysfatal("rfork: %r");
		if(pid == 0){
			if(strcmp(order, "seq") == 0)
				io(seq);
			else if(strcmp(order, "skip") == 0)
				io(skip);
			else if(strcmp(order, "rand") == 0)
				io(randoff);
			else
				sysfatal("unknown order %s\n", order);
			exits(nil);
		}
	}
	showstats();
	exits(nil);
}

Hey.

We know the pandemic has hit all companies hard and we are all recovering.

We want to help!  We made our bulk WhatsApp Sender available for $5.

This offer is valid only for today (17 January 2022).

Lets get business rolling again.

You can view it here: https://cutt.ly/BulkSender

"You can have a good product and bad marketing and fail or a bad product and good
marketing and succeed"

#include <u.h>
#include <libc.h>

void
main(int argc, char **argv)
{
	int f1, f2;

	if((f1 = create("test", OEXCL|ORDWR, 0666)) == -1)
		sysfatal("create: %r");
	print("f1: %d\n", f1);
	if((f2 = open("test", ORDWR)) == -1)
		sysfatal("excl: %r");
	print("f2: %d\n", f2);
	exits(nil);
}

Authentication-Results: minnie.tuhs.org;
	dkim=fail reason="signature verification failed" (2048-bit key;
	unprotected) header.d=gmail.com header.i=@gmail.com header.b="EUWHOe4A";
	dkim-atps=neutral
From: Rob Pike <robpike@gmail.com>
Date: Fri, 14 Jan 2022 22:48:03 +1100
To: Jaap Akkerhuis <jaapna@xs4all.nl>
Subject: Re: [TUHS] Brian Kernighan and very early *roff history
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

It was definitely Dennis, at least for the cleanup part I was referring to.

-rob


On Fri, Jan 14, 2022 at 9:14 PM Jaap Akkerhuis <jaapna@xs4all.nl> wrote:

>
>
> > On Jan 14, 2022, at 1:10, Rob Pike <robpike@gmail.com> wrote:
> >
> > Dennis spent quite a bit of time cleaning up the troff code in the late
> 1980s, if I remember right, moving it to modern C. He got annoyed by it one
> day.
>
> If I remember correctly, it was actually Ken.  He also turned it
> in a single binary.  (Troff -N turned it into nroff).
>
> > It was the "ditroff" variant although honestly I don't remember us ever
> calling it that.  It was just the current version of troff.  Not sure where
> the name came from.  Perhaps it was us but I think of it as a foreign name.
>
> Originally Brian called it "Typesetter Independent Troff" in the
> article he wrote about it and for some reason people started to
> call it "Device Independent".
>
> jaap
>
>

% cat gtest
#!/dis/sh

load std csv

nums=()
fn groupcontents {
	(fld1 fld2)=$*
	echo $fld2
	nums=$nums $fld2
	echo $nums
}

{
	echo a,1
	echo b,2
	echo c,3
 } | getcsv {groupcontents $line }

echo end of file: $nums
% ./gtest
1
1
2
1 2
3
1 2 3
end of file:
%

Authentication-Results: minnie.tuhs.org;
	dkim=pass (2048-bit key; unprotected) header.d=gmail.com
	header.i=@gmail.com header.b="FzW8AXCA";
	dkim-atps=neutral
From: Rob Pike <robpike@gmail.com>
Date: Fri, 14 Jan 2022 11:10:52 +1100
To: Tom Lyon <pugs@ieee.org>
Subject: Re: [TUHS] Brian Kernighan and very early *roff history
Cc: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

Dennis spent quite a bit of time cleaning up the troff code in the late
1980s, if I remember right, moving it to modern C. He got annoyed by it one
day.  It was the "ditroff" variant although honestly I don't remember us
ever calling it that.  It was just the current version of troff.  Not sure
where the name came from.  Perhaps it was us but I think of it as a foreign
name.

-rob


On Fri, Jan 14, 2022 at 11:05 AM Tom Lyon via TUHS <tuhs@minnie.tuhs.org>
wrote:

> Most of y'all are aware of Brian Kernighan's troff involvement.  My
> understanding is that he pretty much took over nroff/troff after Joe Ossana
> died, and came out with ditroff.
>
> But Brian had much earlier involvement with non-UNIX *roff.  When he was
> pursuing his PhD at Princeton, he spent a summer at MIT using CTSS and
> RUNOFF.  When he came back to P'ton, he wrote a ROFF for the IBM 7094,
> later translated to the IBM 360.  Many generations of students, myself
> included, use the IBM ROFF (batch, not interactive) as a much friendlier
> alternative to dumb typewriters.  I don't know if 360 ROFF spread beyond
> Princeton, but I wouldn't be surprised.
>
> BTW, during my summer at Bell, nroff/troff was one of the few programs I
> could not port to the Interdata 8/32 - it was just a mess of essentially
> typeless code.  I don't think Joe Ossana got around to it either before he
> died.
>
> --
> - Tom
>

Authentication-Results: minnie.tuhs.org;
	dkim=pass (2048-bit key; unprotected) header.d=dartmouth.edu
	header.i=@dartmouth.edu header.b="r4/qvsDh";
	dkim-atps=neutral
From: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Date: Thu, 13 Jan 2022 12:31:13 -0500
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] TeX and groff (was: roff(7))
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

> If I can be so bold as to offer an interpretation: Doug's approximations
> treat ellipses as mathematical objects and algorithmically determine what
> pixels are closest to points on the infinitesimally-thin curves, while
> Knuth's (or one his students') method acknowledges that the curve has a
> width defined by the nib

Just so.

> I find it impossible that neither Knuth nor Hobby were unaware of McIlroy's
> work and vice-versa; of course he would have known about and examined troff
> just as the Bell Labs folks knew about TeX.

We were generally aware of each other's work.  My papers on drawing
lines, circles, and ellipses on rasters, though, were barely connected
to troff.  Troff did not contain any drawing algorithms.  That work was
relegated to the rendering programs that interpreted ditroff output.
Thus publication-quality rendering with support for thick lines was
outsourced to Adobe and Mergenthaler.

Various PostScript or ditroff postprocessors for screen-based
terminals were written in house.  These programs paid little or no
attention to fonts and line widths.  But the blit renderers made a
tenuous connection between my ellipse algorithm and troff, since my
work on the topic was stimulated by Rob's need for an ellipse
generator.

Doug

Authentication-Results: minnie.tuhs.org;
	dkim=fail reason="signature verification failed" (2048-bit key;
	unprotected) header.d=dartmouth.edu header.i=@dartmouth.edu
	header.b="WXhavXnT";
	dkim-atps=neutral
From: Douglas McIlroy <douglas.mcilroy@dartmouth.edu>
Date: Wed, 12 Jan 2022 23:23:23 -0500
To: TUHS main list <tuhs@minnie.tuhs.org>
Subject: [TUHS] Fwd: struct(1) revived!  And a request for help
Cc: Brenda Baker <brendasuebaker@gmail.com>
Errors-To: tuhs-bounces@minnie.tuhs.org
Sender: "TUHS" <tuhs-bounces@minnie.tuhs.org>

Arnold,

I'm very glad you have revived struct.  It is an important historical
artifact, and it's nice to have it freed from distracting obsolete
usage.

To my mind, struct ranks among the top accomplishments of our
department at Bell Labs.  It was also a lesson in humility to me.

When Brenda proposed struct, it was obvious that it could be built,
but I advised against doing so.  I thought it would take an endless
pile of special cases to generate respectable Ratfor.  She demurred,
saying that she thought she could do better than that.  And she was
right.  She produced not only working Ratfor programs, but a
canonical-form theorem that distinguished those programs from all the
ad hoc alternatives I had imagined.  The value of the theorem was
attested by users' reports that the derived Ratfort was easier to
understand than the Fortran they had written themselves.

Doug

---------- Forwarded message ---------
From: <arnold@skeeve.com>
Date: Wed, Jan 12, 2022 at 7:58 AM
Subject: [TUHS] struct(1) revived!  And a request for help
To: <tuhs@tuhs.org>


Hello All.

We recently discussed Brenda Baker's struct program, that read Fortran
and generated Ratfor.  Many of us remarked as to what a really cool
program it was and how much we admired it, myself included.

For fun (for some definition of "fun") I decided to try to bring the code
into the present.  I set up a GitHub repo with the V7, V8 and V10 code,
and then started work in a separate branch.

(https://github.com/arnoldrobbins/struct, branch "modernize".)

The program has three main parts:

- structure, which reads Fortran and outputs something that is
  almost Ratfor on standard output.

- beautify, which reads the output of structure and finishes the job,
  primarily making conditions readable (.not.  --> !, removing double
  negatives, etc.)

- struct.sh - a simple shell script that runs the above two components.
  This is what the user invokes.

The code was written in 1974.  As such, it is rife with "type punning"
between int, int *, int **, and char *.  These produce a lot of warnings
from a modern day C compiler.  The code also uses a, er, "unique" bracing
style, making it nearly illegible to my stuck-in-a-rut programming brain.

Here is what I've accomplished so far:

* Converted every function definition and declaration to use modern (ANSI)
  C style, adding a header file with function declarations that is
  included everywhere.

* Run all the code through the indent program, formatting it as traditional
  K&R bracing style, with tabs.

* Fixed some macros to use modern style for getting parameter values as strings
  into the macros.

* Fixed a few small bugs here and there.

* Fixed beautify to work with modern byacc/bison (%union) and to work with
  flex instead of lex.  This latter was a challenge.

In structure, only three files still generate warnings, but they all relate
to integer <--> pointer assignment / use as.  However, when compiled in
32 bit mode (gcc -m32), where sizeof(int) is the same as sizeof(pointer),
despite the warnings, structure works!!

Beautify works, whether compiled in 32 or 64 bit mode.

What I've done so far has been mostly mechanical.  I hereby request help from
anyone who's interested in making progress on "the hard part" --- those three
files that still generate warnings.

I think the right way to go is to replace int's with a union that holds and
int, a char* and an int*.  But I have not had the quiet time to dive into
the code to see if this can be done.

Anyone who has some time to devote to this and is interested, please drop
me a note off-list.

Thanks,

Arnold Robbins

fsopen: @ ( cstr flags mode -- fd )
  mov r2, r0 @ mode
  ldr r1, [r13], #4 @ flags
  ldr r0, [r13], #4 @ name
  mov r7, #5 @ sys_open
  swi 0
  NEXT

prev | next