Re: [9fans] too good to pass up

Re: [9fans] too good to pass up

[erik quanstrom]

not even his allocator?

- erik

On Fri Apr 28 08:02:29 CDT 2006, brantley@coraid.com wrote:
> > Not that I'm defending writing C as
> > though it were Algol 68...
>
> I kind of liked it after the initial shock.
> Even inspired the Obfuscated C Contest.
> I don't think SRB's code was obfuscated, though.
>
>

Re: [9fans] too good to pass up (SRB Comments)

[Brantley Coile]

That was really John Mashy's fault, as I understand it.  He suggested
it to SRB.  I had to deal with it when I ported V7 to the 68K.  Too
bad every processor wasn't as clean in this reguard as the PDP-11.

For those who might not have heard of this, SRB caught segfault
signals, allocated more memory and just returned.  The instruction
that caused the segfault would restart.  It was an automatic memory
allocator.  Problem was that not all processors could pull off this
sort of stunt.

Geoff cleaned this up years ago.

> not even his allocator?
>
> - erik
>
> On Fri Apr 28 08:02:29 CDT 2006, brantley@coraid.com wrote:
>> > Not that I'm defending writing C as
>> > though it were Algol 68...
>>
>> I kind of liked it after the initial shock.
>> Even inspired the Obfuscated C Contest.
>> I don't think SRB's code was obfuscated, though.
>>
>>

OT: Re: [9fans] too good to pass up (SRB Comments)

[Dave Lukes]

The story from the horse's mouth was that the PWB shell already used the
sigsegv trick
because they were concerned about (groan) speed,
so before they'd use Bourne's shell they insisted that it use the same hack.

Of course, the PWB people didn't care:
after all it was "portable" in the Humpty-Dumpty sense: it worked on
Vaxes & PDP/11s.

I wonder how many different people had to rewrite that code for the M68K?:-)
(luckily someone had already done it before I got there:-)

    DaveL

Brantley Coile wrote:
> That was really John Mashy's fault, as I understand it.  He suggested
> it to SRB.  I had to deal with it when I ported V7 to the 68K.  Too
> bad every processor wasn't as clean in this reguard as the PDP-11.
>
> For those who might not have heard of this, SRB caught segfault
> signals, allocated more memory and just returned.  The instruction
> that caused the segfault would restart.  It was an automatic memory
> allocator.  Problem was that not all processors could pull off this
> sort of stunt.
>
> Geoff cleaned this up years ago.
>
>
>> not even his allocator?
>>
>> - erik
>>
>> On Fri Apr 28 08:02:29 CDT 2006, brantley@coraid.com wrote:
>>
>>>> Not that I'm defending writing C as
>>>> though it were Algol 68...
>>>>
>>> I kind of liked it after the initial shock.
>>> Even inspired the Obfuscated C Contest.
>>> I don't think SRB's code was obfuscated, though.
>>>
>>>
>>>
>
>

Re: OT: Re: [9fans] too good to pass up (SRB Comments)

[Brantley Coile]

> I wonder how many different people had to rewrite that code for the M68K?:-)
Lots.

Re: [9fans] too good to pass up (SRB Comments)

[Roman Shaposhnik]

On Fri, 2006-04-28 at 09:10 -0400, Brantley Coile wrote:
> That was really John Mashy's fault, as I understand it.  He suggested
> it to SRB.  I had to deal with it when I ported V7 to the 68K.  Too
> bad every processor wasn't as clean in this reguard as the PDP-11.
> 
> For those who might not have heard of this, SRB caught segfault
> signals, allocated more memory and just returned.  The instruction
> that caused the segfault would restart.  It was an automatic memory
> allocator.  Problem was that not all processors could pull off this
> sort of stunt.

  That's some tricky programming! Do you know of any place one can get
an access to the original code ?

Thanks,
Roman.

Re: [9fans] too good to pass up (SRB Comments)

[Taj Khattra]

>   That's some tricky programming! Do you know of any place one can get
> an access to the original code ?

you can browse it here:
http://minnie.tuhs.org/UnixTree/V7/usr/src/cmd/sh/fault.c.html

Re: [9fans] too good to pass up

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 221 bytes --]

i think both those mechanisms were much less shocking in `Unix: the early years',
and i found them quite interesting, even though i had no intention of emulating them.
(mind you, i subscribed to the algol68 bulletin.)

[-- Attachment #2: Type: message/rfc822, Size: 2603 bytes --]

From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] too good to pass up
Date: Fri, 28 Apr 2006 08:01:58 -0500
Message-ID: <d95f31573a6820f5d27d18130cc49c2e@quanstro.net>

not even his allocator?

- erik

On Fri Apr 28 08:02:29 CDT 2006, brantley@coraid.com wrote:
> > Not that I'm defending writing C as
> > though it were Algol 68...
>
> I kind of liked it after the initial shock.
> Even inspired the Obfuscated C Contest.
> I don't think SRB's code was obfuscated, though.
>
>

Re: [9fans] too good to pass up

[dmr]

 > Hmmm, I've always wondered if maybe DMR could sneak this [A68C compiler]
 > out to the TUHS
 > archives?  Is it at least on line?

It's not online here, so far as I can see.

	Dennis

[9fans] too good to pass up

[Ronald G Minnich]

next big thing appears to be USB over IP.

Almost as good as ATM over ethernet.

yee ha!

ron

Re: [9fans] too good to pass up

[Noah Evans]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Isn't that by Takahiro Hirofuchi? He's in the lab below me. He's a plan 9
and inferno fan.

Noah

On 5/2/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>
>
> next big thing appears to be USB over IP.
>
> Almost as good as ATM over ethernet.
>
> yee ha!
>
> ron
>

[-- Attachment #2: Type: text/html, Size: 557 bytes --]

Re: [9fans] too good to pass up

[Martin C. Atkins]

On Mon, 01 May 2006 21:29:39 -0600 Ronald G Minnich <rminnich@lanl.gov> wrote:
> next big thing appears to be USB over IP.

Makes a lot of sense.... if your devices don't talk 9P!

Martin

-- 
Martin C. Atkins			martin_ml@parvat.com
Parvat Infotech Private Limited		http://www.parvat.com{/,/martin}

Re: [9fans] too good to pass up

[David Leimbach]

That's "virtual media". :)

And there are already linux kernel drivers for VHCI interfaces
"virtual host control interface" that implement this.

There are also a handful of KVM vendors with implementations and it's
part of AMD's OPMA specification too.

Dave

On 5/1/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>
> next big thing appears to be USB over IP.
>
> Almost as good as ATM over ethernet.
>
> yee ha!
>
> ron
>

Re: [9fans] too good to pass up

[Skip Tavakkolian]

>> next big thing appears to be USB over IP.

i'm sure there's a spec for it in UPnP

Re: [9fans] too good to pass up

[erik quanstrom]

obviously, you haven't worked on CAD software.

- erik

On Thu Apr 27 17:54:39 CDT 2006, rminnich@lanl.gov wrote:
>
> 25 parameters?  If you tell me which drugs were involved in this code,
> I know what to stay away from.  Might be the current record for any
> code ever proposed for inclusion.

[9fans] too good to pass up

[Ronald G Minnich]

this is from the openib mailing list :-)

ron
===
On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:

 >> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
 >> adapter_handle,
 >> +			     struct ehca_pfqp *pfqp,
 >> +			     const u8 servicetype,
 >> +			     const u8 daqp_ctrl,
 >> +			     const u8 signalingtype,
 >> +			     const u8 ud_av_l_key_ctl,
 >> +			     const struct ipz_cq_handle send_cq_handle,
 >> +			     const struct ipz_cq_handle receive_cq_handle,
 >> +			     const struct ipz_eq_handle async_eq_handle,
 >> +			     const u32 qp_token,
 >> +			     const struct ipz_pd pd,
 >> +			     const u16 max_nr_send_wqes,
 >> +			     const u16 max_nr_receive_wqes,
 >> +			     const u8 max_nr_send_sges,
 >> +			     const u8 max_nr_receive_sges,
 >> +			     const u32 ud_av_l_key,
 >> +			     struct ipz_qp_handle *qp_handle,
 >> +			     u32 * qp_nr,
 >> +			     u16 * act_nr_send_wqes,
 >> +			     u16 * act_nr_receive_wqes,
 >> +			     u8 * act_nr_send_sges,
 >> +			     u8 * act_nr_receive_sges,
 >> +			     u32 * nr_sq_pages,
 >> +			     u32 * nr_rq_pages,
 >> +			     struct h_galpas *h_galpas);


25 parameters?  If you tell me which drugs were involved in this code,
I know what to stay away from.  Might be the current record for any
code ever proposed for inclusion.

Re: [9fans] too good to pass up

[Roman Shaposhnick]

On Thu, Apr 27, 2006 at 04:45:25PM -0600, Ronald G Minnich wrote:
>
> this is from the openib mailing list :-)

  Sigh! The fact that 'struct ehca_pfqp *pfqp' is there rules
  out the possibility that the guy have never heard of
  structs. Although, not entirely, after all a buddy of mine
  migrated from Pascal to C with:

  #define begin {
  #define end }
  ....

  you get the idea...

Thanks,
Roman.

>
> ron
> ===
> On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:
>
> >> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
> >> adapter_handle,
> >> +			     struct ehca_pfqp *pfqp,
> >> +			     const u8 servicetype,
> >> +			     const u8 daqp_ctrl,
> >> +			     const u8 signalingtype,
> >> +			     const u8 ud_av_l_key_ctl,
> >> +			     const struct ipz_cq_handle send_cq_handle,
> >> +			     const struct ipz_cq_handle receive_cq_handle,
> >> +			     const struct ipz_eq_handle async_eq_handle,
> >> +			     const u32 qp_token,
> >> +			     const struct ipz_pd pd,
> >> +			     const u16 max_nr_send_wqes,
> >> +			     const u16 max_nr_receive_wqes,
> >> +			     const u8 max_nr_send_sges,
> >> +			     const u8 max_nr_receive_sges,
> >> +			     const u32 ud_av_l_key,
> >> +			     struct ipz_qp_handle *qp_handle,
> >> +			     u32 * qp_nr,
> >> +			     u16 * act_nr_send_wqes,
> >> +			     u16 * act_nr_receive_wqes,
> >> +			     u8 * act_nr_send_sges,
> >> +			     u8 * act_nr_receive_sges,
> >> +			     u32 * nr_sq_pages,
> >> +			     u32 * nr_rq_pages,
> >> +			     struct h_galpas *h_galpas);
>
>
> 25 parameters?  If you tell me which drugs were involved in this code,
> I know what to stay away from.  Might be the current record for any
> code ever proposed for inclusion.
>
>
>
>

Re: [9fans] too good to pass up

[Brantley Coile]

>   #define begin {
>   #define end }
>   ....

Have you read the source code for adb or the borne shell?

Re: [9fans] too good to pass up

[Roman Shaposhnick]

On Thu, Apr 27, 2006 at 06:58:32PM -0400, Brantley Coile wrote:
> >   #define begin {
> >   #define end }
> >   ....
>
> Have you read the source code for adb or the borne shell?

  Nope. I'm pretty happy with rc ;-) although, I'm about
  to indulge myself in es.

  That said, I'm not surprised that borne turned out that way.
  All that love for do/done kinda hints at that.

Thanks,
Roman.

Re: [9fans] too good to pass up

[geoff]

Bourne had been immersed in the Algol 68C compiler at Cambridge and
did a port of it to PDP-11 Unix (thus the overlay a.out type(s) in
V7), as I recall, so it's somewhat understandable that he'd be
attached to Algol 68 (which uses do/od, actually, but od was already
the name of a Unix command).  Not that I'm defending writing C as
though it were Algol 68...

Re: [9fans] too good to pass up

[Brantley Coile]

> Not that I'm defending writing C as
> though it were Algol 68...

I kind of liked it after the initial shock.
Even inspired the Obfuscated C Contest.
I don't think SRB's code was obfuscated, though.

Re: [9fans] too good to pass up

[Aharon Robbins]

Hmmm, I've always wondered if maybe DMR could sneak this out to the TUHS
archives?  Is it at least on line?

In article <383a34aca230dbcd89d76b9929cfc8c5@collyer.net> you write:
>Bourne had been immersed in the Algol 68C compiler at Cambridge and
>did a port of it to PDP-11 Unix (thus the overlay a.out type(s) in
>V7), ...
-- 
Aharon (Arnold) Robbins --- Pioneer Consulting Ltd.	arnold AT skeeve DOT com
P.O. Box 354		Home Phone: +972  8 979-0381	Fax: +1 206 350 8765
Nof Ayalon		Cell Phone: +972 50  729-7545
D.N. Shimshon 99785	ISRAEL

Re: [9fans] too good to pass up

[geoff]

There's at least one free algol 68 implementation that translates to
C, called Ctrans.  There are pointers to it and other implementations
at www.algol68.org.

Re: [9fans] too good to pass up

[geoff]

u8, that's the new super-high-altitude spy plane, isn't it?  Or is it
the band named after the plane?

I especially like the const parameters that aren't const pointers.
Very important to make sure that the copy of the parameter on the
stack doesn't get modified by the called function.

Re: [9fans] too good to pass up

[David Leimbach]

I've actually seen worse :)  I saw a function in a certain library
with 36 parameters before.



On 4/27/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>
> this is from the openib mailing list :-)
>
> ron
> ===
> On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:
>
>  >> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
>  >> adapter_handle,
>  >> +                        struct ehca_pfqp *pfqp,
>  >> +                        const u8 servicetype,
>  >> +                        const u8 daqp_ctrl,
>  >> +                        const u8 signalingtype,
>  >> +                        const u8 ud_av_l_key_ctl,
>  >> +                        const struct ipz_cq_handle send_cq_handle,
>  >> +                        const struct ipz_cq_handle receive_cq_handle,
>  >> +                        const struct ipz_eq_handle async_eq_handle,
>  >> +                        const u32 qp_token,
>  >> +                        const struct ipz_pd pd,
>  >> +                        const u16 max_nr_send_wqes,
>  >> +                        const u16 max_nr_receive_wqes,
>  >> +                        const u8 max_nr_send_sges,
>  >> +                        const u8 max_nr_receive_sges,
>  >> +                        const u32 ud_av_l_key,
>  >> +                        struct ipz_qp_handle *qp_handle,
>  >> +                        u32 * qp_nr,
>  >> +                        u16 * act_nr_send_wqes,
>  >> +                        u16 * act_nr_receive_wqes,
>  >> +                        u8 * act_nr_send_sges,
>  >> +                        u8 * act_nr_receive_sges,
>  >> +                        u32 * nr_sq_pages,
>  >> +                        u32 * nr_rq_pages,
>  >> +                        struct h_galpas *h_galpas);
>
>
> 25 parameters?  If you tell me which drugs were involved in this code,
> I know what to stay away from.  Might be the current record for any
> code ever proposed for inclusion.
>
>
>
>
>

Re: [9fans] too good to pass up

[David Leimbach]

Ok maybe it was 31:

static void ADIOI_W_Exchange_data(ADIO_File fd, void *buf, char *write_buf,
                         ADIOI_Flatlist_node *flat_buf, ADIO_Offset
                         *offset_list, int *len_list, int *send_size,
                         int *recv_size, ADIO_Offset off, int size,
                         int *count, int *start_pos, int *partial_recv,
                         int *sent_to_proc, int nprocs,
                         int myrank, int
                         buftype_is_contig, int contig_access_count,
                         ADIO_Offset min_st_offset, ADIO_Offset fd_size,
                         ADIO_Offset *fd_start, ADIO_Offset *fd_end,
                         ADIOI_Access *others_req,
                         int *send_buf_idx, int *curr_to_proc,
                         int *done_to_proc, int *hole, int iter,
                         MPI_Aint buftype_extent, int *buf_idx, int *error_code)

>From the ROMIO implementation of MPI-IO :-).  When I first saw this
function a few years ago my jaw dropped....  I'm still looking for
parts of it.

Dave


On 4/27/06, David Leimbach <leimy2k@gmail.com> wrote:
> I've actually seen worse :)  I saw a function in a certain library
> with 36 parameters before.
>
>
>
> On 4/27/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> >
> > this is from the openib mailing list :-)
> >
> > ron
> > ===
> > On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:
> >
> >  >> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
> >  >> adapter_handle,
> >  >> +                        struct ehca_pfqp *pfqp,
> >  >> +                        const u8 servicetype,
> >  >> +                        const u8 daqp_ctrl,
> >  >> +                        const u8 signalingtype,
> >  >> +                        const u8 ud_av_l_key_ctl,
> >  >> +                        const struct ipz_cq_handle send_cq_handle,
> >  >> +                        const struct ipz_cq_handle receive_cq_handle,
> >  >> +                        const struct ipz_eq_handle async_eq_handle,
> >  >> +                        const u32 qp_token,
> >  >> +                        const struct ipz_pd pd,
> >  >> +                        const u16 max_nr_send_wqes,
> >  >> +                        const u16 max_nr_receive_wqes,
> >  >> +                        const u8 max_nr_send_sges,
> >  >> +                        const u8 max_nr_receive_sges,
> >  >> +                        const u32 ud_av_l_key,
> >  >> +                        struct ipz_qp_handle *qp_handle,
> >  >> +                        u32 * qp_nr,
> >  >> +                        u16 * act_nr_send_wqes,
> >  >> +                        u16 * act_nr_receive_wqes,
> >  >> +                        u8 * act_nr_send_sges,
> >  >> +                        u8 * act_nr_receive_sges,
> >  >> +                        u32 * nr_sq_pages,
> >  >> +                        u32 * nr_rq_pages,
> >  >> +                        struct h_galpas *h_galpas);
> >
> >
> > 25 parameters?  If you tell me which drugs were involved in this code,
> > I know what to stay away from.  Might be the current record for any
> > code ever proposed for inclusion.
> >
> >
> >
> >
> >
>

Re: [9fans] too good to pass up

[David Leimbach]

Ok I counted that several times and I'm still not sure if it's 30 or
31.... too tired to care.  It's a formidably scary function though...
:-)

On 4/27/06, David Leimbach <leimy2k@gmail.com> wrote:
> Ok maybe it was 31:
>
> static void ADIOI_W_Exchange_data(ADIO_File fd, void *buf, char *write_buf,
>                          ADIOI_Flatlist_node *flat_buf, ADIO_Offset
>                          *offset_list, int *len_list, int *send_size,
>                          int *recv_size, ADIO_Offset off, int size,
>                          int *count, int *start_pos, int *partial_recv,
>                          int *sent_to_proc, int nprocs,
>                          int myrank, int
>                          buftype_is_contig, int contig_access_count,
>                          ADIO_Offset min_st_offset, ADIO_Offset fd_size,
>                          ADIO_Offset *fd_start, ADIO_Offset *fd_end,
>                          ADIOI_Access *others_req,
>                          int *send_buf_idx, int *curr_to_proc,
>                          int *done_to_proc, int *hole, int iter,
>                          MPI_Aint buftype_extent, int *buf_idx, int *error_code)
>
> From the ROMIO implementation of MPI-IO :-).  When I first saw this
> function a few years ago my jaw dropped....  I'm still looking for
> parts of it.
>
> Dave
>
>
> On 4/27/06, David Leimbach <leimy2k@gmail.com> wrote:
> > I've actually seen worse :)  I saw a function in a certain library
> > with 36 parameters before.
> >
> >
> >
> > On 4/27/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
> > >
> > > this is from the openib mailing list :-)
> > >
> > > ron
> > > ===
> > > On Thu, 27 April 2006 12:49:36 +0200, Heiko J Schick wrote:
> > >
> > >  >> +u64 hipz_h_alloc_resource_qp(const struct ipz_adapter_handle
> > >  >> adapter_handle,
> > >  >> +                        struct ehca_pfqp *pfqp,
> > >  >> +                        const u8 servicetype,
> > >  >> +                        const u8 daqp_ctrl,
> > >  >> +                        const u8 signalingtype,
> > >  >> +                        const u8 ud_av_l_key_ctl,
> > >  >> +                        const struct ipz_cq_handle send_cq_handle,
> > >  >> +                        const struct ipz_cq_handle receive_cq_handle,
> > >  >> +                        const struct ipz_eq_handle async_eq_handle,
> > >  >> +                        const u32 qp_token,
> > >  >> +                        const struct ipz_pd pd,
> > >  >> +                        const u16 max_nr_send_wqes,
> > >  >> +                        const u16 max_nr_receive_wqes,
> > >  >> +                        const u8 max_nr_send_sges,
> > >  >> +                        const u8 max_nr_receive_sges,
> > >  >> +                        const u32 ud_av_l_key,
> > >  >> +                        struct ipz_qp_handle *qp_handle,
> > >  >> +                        u32 * qp_nr,
> > >  >> +                        u16 * act_nr_send_wqes,
> > >  >> +                        u16 * act_nr_receive_wqes,
> > >  >> +                        u8 * act_nr_send_sges,
> > >  >> +                        u8 * act_nr_receive_sges,
> > >  >> +                        u32 * nr_sq_pages,
> > >  >> +                        u32 * nr_rq_pages,
> > >  >> +                        struct h_galpas *h_galpas);
> > >
> > >
> > > 25 parameters?  If you tell me which drugs were involved in this code,
> > > I know what to stay away from.  Might be the current record for any
> > > code ever proposed for inclusion.
> > >
> > >
> > >
> > >
> > >
> >
>