The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lehmann@ans-netz.de (Oliver Lehmann)
Subject: [TUHS] Introduction
Date: Thu, 5 Jun 2008 19:59:47 +0200	[thread overview]
Message-ID: <20080605195947.27193afe.lehmann@ans-netz.de> (raw)
In-Reply-To: <20080605170730.35320095@veda.cnb.uam.es>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

Jose R. Valverde wrote:

> > so i created the following C code out of it:
> > 
> > u.u_count = (-u.u_segmts[NUSEGS-1].sg_limit+0x100)<<8;
> > ...
> > 
> > done by having 256² - 256*x. This was great. With that information I wrote
> > in C:
> > 
> > u.u_count = (256-u.u_segmts[NUSEGS-1].sg_limit)<<8;
> 
> 
> What happens if you use instead
> 
> 	u.u_count = (~(-u.u_segmts[NUSEGS-1].sg_limit))<<8;
> 
> That should mean the same, would avoid using a hard coded value and the
> compiler may optimize it to the same assembly.

This gets compiled+optimized to:

        ldb     rl2,_u+1060
        neg     r2
        com     r2
        ldb     rh2,rl2
        clrb    rl2
        ld      _u+48,r2

I think 256 is ok for me as it a) works, and b) I'm using a defined
variable (CPAS - clicks per address space) instead of the hardcoded 256
and instead of <<8 I'm using "ctob()" which is defined as 

/* clicks to bytes */
# define ctob(x)        ((x)<<8)

so I guess this is OK.



The other (unsolved) problem is quite more complicated for me. I tried
several different things:

u.u_dirp.l = (long)((saddr_t *)uap->linkname)->l & 0x7f00ffffL;
u.u_dirp.l = ((long)uap->linkname&0x7F00FFFFL);
u.u_dirp.l = (long)((int)uap->linkname&0x7F00);

(the types are all defined in param.h I linked to at the webpage) I've
tried to figure out what happens there.

Any value which is in the long-word-register will be ANDed with

    7F       00      FF       FF
01111111 00000000 11111111 11111111

This means, that the higher register will be taken from the long-word-
register unmodified. For the lower register the first bit will be
removed, and the highbyte will be removed as well. The colleague of
mine meant this could have to do something with memory adressing - maybe
to get an address from a memory segment. I didn't understood it that
much. But we didn't found a way how it could be written "differently" and
the optimizer creates the ANDing - again with a temporary register.
I also tried to put the 0x7f00ffff in front of the variable just to be
sure this is not what's triggering the copy. But without success. Maybe
I'm to focused on the ANDing with 7f00 of the first 16bit register-word
from the 32bit-longword - who knows?

-- 
 Oliver Lehmann
  http://www.pofo.de/
  http://wishlist.ans-netz.de/



  reply	other threads:[~2008-06-05 17:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-04 11:57 Jose R. Valverde
2008-06-04 15:11 ` Oliver Lehmann
2008-06-04 15:16   ` Oliver Lehmann
2008-06-05 15:07 ` Jose R. Valverde
2008-06-05 17:59   ` Oliver Lehmann [this message]
2008-06-05 15:17 ` Jose R. Valverde
2008-06-05 17:45   ` Oliver Lehmann
2008-06-23 14:18   ` Jose R. Valverde
2008-06-23 16:11     ` Oliver Lehmann
2008-06-25  9:40       ` Jose R. Valverde
2008-06-25 10:25       ` Jose R. Valverde
2008-06-26 14:52         ` Oliver Lehmann
2008-06-27 12:24           ` Jose R. Valverde
2008-06-29  8:25             ` Oliver Lehmann
2008-06-30  9:30               ` Jose R. Valverde
2008-06-30 17:34                 ` Oliver Lehmann
2008-07-01 14:21                   ` Jose R. Valverde
2008-07-01 18:35                     ` Oliver Lehmann
2008-07-03 10:12                       ` Jose R. Valverde
2008-07-06 16:14                         ` Oliver Lehmann
2008-07-07  9:25                           ` [TUHS] SysIII/PDP-11 on SIMH (was Re: Introduction) Jose R. Valverde
2008-07-07  9:32                           ` [TUHS] Introduction Jose R. Valverde
2008-07-07 14:45                             ` Oliver Lehmann
2008-06-06  9:58 ` Jose R. Valverde
  -- strict thread matches above, loose matches on Subject: below --
2008-06-03  4:18 Oliver Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080605195947.27193afe.lehmann@ans-netz.de \
    --to=lehmann@ans-netz.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).