* Git-aware darcs: gettable repo
From: Juliusz Chroboczek @ 2005-04-25 20:09 UTC (permalink / raw)
To: darcs-devel, Git Mailing List
Hi,
Just to let you know that, thanks to some friendly tagging by Ian Lynagh,
I've been able to set up a gettable Darcs repository of the Git-aware
version of Darcs.
http://www.pps.jussieu.fr/~jch/software/repos/darcs-git/
If you're on a Linux system with darcs, ghc 6.2, libz, libcurl and libssl,
you should be able to do
$ darcs get --partial http://www.pps.jussieu.fr/~jch/software/repos/darcs-git
$ cd darcs-git
$ make darcs
$ make Context.hs
$ make darcs
$ mv darcs ~/bin/darcs-git
$ cd ..
$ mkdir linux
$ cd linux
$ darcs-git initialize
$ darcs-git pull /usr/local/src/linux-2.6
and see the OOM killer in action.
Juliusz
^ permalink raw reply
* Re: [FILE] GNU BIT
From: Andreas Gal @ 2005-04-25 20:03 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0504251134090.30848-100000@iabervon.org>
I fixed this bug and another nasty one in "bit pull". The new version is
up in its usual place:
bit clone http://nil.ics.uci.edu/~gal/public/bit
(You can't use pull because it was broken in the previous version.)
Another unrelated note: to add files to your repository, do "bit commit
filename". To remove a file, delete it and then do "bit commit
deleted-filename" (yes, I will add "bit add" and "bit rm" at some point).
Andreas
On Mon, 25 Apr 2005, Daniel Barkalow wrote:
> On Sun, 24 Apr 2005, Andreas Gal wrote:
>
> > http-pull -a `cat .git/HEAD` \
> > http://nil.ics.uci.edu/~gal/public/bit
>
> Don't forget the slash at the end... (one of us should probably fix that
> at some point; just stick a slash at the end of any URL without one)
>
> Also, it has become customary to have URLs like .../public/bit.git/, since
> the contents match a .git directory.
>
> -Daniel
> *This .sig left intentionally blank*
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: the REGISTER thread
From: Brian O'Mahoney @ 2005-04-25 19:43 UTC (permalink / raw)
Cc: Matthias-Christian Ott, git
In-Reply-To: <200504251855.j3PItHQs021408@turing-police.cc.vt.edu>
Enough already, school is out!
Brian
^ permalink raw reply
* git "tag" objects implemented - and a re-done commit
From: Linus Torvalds @ 2005-04-25 19:25 UTC (permalink / raw)
To: Git Mailing List
Ok, I just pushed out my "tag" object implementation, and due to some
local braindamage over here, I ended up re-doing one commit, so if you
happened to pull my 'git' tree at _just_ the right time, you will have a
commit object named 06a02346f6a2e9ff113c189629ff7148f5141bb0 in your git
repository, which is not exactly bogus, but which I ended up undoing.
So if you've been pulling my git stuff, check your "git log" for whether
you find that commit in your stuff. If you do, I guess it doesn't much
matter (ie should all merge in cleanly), but if you want to match my tree,
you should first undo it if it's your HEAD commit (by setting your HEAD to
the _parent_ of that commit, and then running the git-prune-script thing).
Anyway, I decided that my original model for tags was the right one, with
a trivial extension. Notably, if you want to tag a single file or a tree
object, go wild. The tag object format is:
object <sha1>
type <type>
tag <tag>
.. free-form commentary and signature of this all ..
and the "git-mktag" program verifies that the three first lines are valid
before it accepts it and writes it as a git object.
Right now the tags don't do anything, except fsck can verify them (not the
signature - git doesn't even specify any particular format, and you may
validly have unsigned tags in your tree), and will print out something
like
tagged commit e83c5163316f89bfbde7d9ab23ca2e25604af290 (v2.6.12-rc2)
if you were to have such a tag-object in your object database (you don't,
because I've not generated one, but hey..)
Linus
^ permalink raw reply
* git on solaris
From: Thomas Glanzmann @ 2005-04-25 19:07 UTC (permalink / raw)
To: GIT
[-- Attachment #1: Type: text/plain, Size: 109 bytes --]
Hello,
this patch makes git compile on Solaris, but it isn't considered for
upstream at the moment.
Thomas
[-- Attachment #2: git.patch.solaris --]
[-- Type: text/plain, Size: 2388 bytes --]
Index: Makefile
===================================================================
--- 648b1464afe31bf85116ca64734a8b8990f4e0da/Makefile (mode:100644 sha1:022af9b8c0a8ded65892c84bd419e46af6d2ae92)
+++ uncommitted/Makefile (mode:100644)
@@ -21,14 +21,14 @@
all: $(PROG)
install: $(PROG)
- install $(PROG) $(HOME)/bin/
+ ginstall $(PROG) $(HOME)/bin/
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o
LIB_FILE=libgit.a
LIB_H=cache.h object.h
LIBS = $(LIB_FILE)
-LIBS += -lz
+LIBS += -lz -L /opt/csw/lib -lsocket -lnsl
ifdef MOZILLA_SHA1
SHA1_HEADER="mozilla-sha1/sha1.h"
@@ -43,7 +43,7 @@
endif
endif
-CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
+CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)' -I/opt/csw/include -D_XOPEN_SOURCE_EXTENDED=1
$(LIB_FILE): $(LIB_OBJS)
$(AR) rcs $@ $(LIB_OBJS)
Index: rsh.c
===================================================================
--- 648b1464afe31bf85116ca64734a8b8990f4e0da/rsh.c (mode:100644 sha1:4d6a90bf6c1b290975fb2ac22f25979be56cb476)
+++ uncommitted/rsh.c (mode:100644)
@@ -1,6 +1,7 @@
#include "rsh.h"
#include <string.h>
+#include <sys/types.h>
#include <sys/socket.h>
#include "cache.h"
@@ -47,7 +48,7 @@
}
}
strcpy(posn, " -");
- if (socketpair(AF_LOCAL, SOCK_STREAM, 0, sv)) {
+ if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv)) {
return error("Couldn't create socket");
}
if (!fork()) {
Index: show-files.c
===================================================================
--- 648b1464afe31bf85116ca64734a8b8990f4e0da/show-files.c (mode:100644 sha1:b53ab1053e1acf7e2a1e9c97a4d87b76e8ee238e)
+++ uncommitted/show-files.c (mode:100644)
@@ -51,6 +51,7 @@
if (dir) {
struct dirent *de;
+ struct stat st;
char fullname[MAXPATHLEN + 1];
memcpy(fullname, base, baselen);
@@ -62,8 +63,8 @@
len = strlen(de->d_name);
memcpy(fullname + baselen, de->d_name, len+1);
+#if __LINUX__
switch (de->d_type) {
- struct stat st;
default:
continue;
case DT_UNKNOWN:
@@ -81,6 +82,17 @@
case DT_REG:
break;
}
+#else
+ if (lstat(fullname, &st))
+ continue;
+ if (S_ISDIR(st.st_mode)) {
+ memcpy(fullname + baselen + len, "/", 2);
+ read_directory(fullname, fullname, baselen + len + 1);
+ continue;
+ }
+ if (!S_ISREG(st.st_mode))
+ break;
+#endif
add_name(fullname, baselen + len);
}
closedir(dir);
^ permalink raw reply
* Re: git.git object database at kernel.org?
From: H. Peter Anvin @ 2005-04-25 19:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List, Junio C Hamano
In-Reply-To: <426D3B01.8060408@zytor.com>
H. Peter Anvin wrote:
> Linus Torvalds wrote:
>
>> NOTE! The fact that "mktime()" seems to depend on the timezone in
>> which it is made seems to make this questionable. I had always
>> assumed that mktime would take the timezone from the "struct tm",
>> and thus be reliable, but somebody seems to have shown that that is
>> not the case at all!
>
> No, mktime() always uses the local time zone. It's the inverse of
> localtime(). If you know the timezone offset (e.g. if you have a RFC
> 2822-style date) then you're probably better off rolling your own;
> otherwise setenv("TZ"); tzset(); mktime(); is of course also doable.
>
BTW, curl_getdate() from libcurl is a good multiformat date parser.
-hpa
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Valdis.Kletnieks @ 2005-04-25 18:55 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426D33BA.8040604@tiscali.de>
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
On Mon, 25 Apr 2005 20:15:22 +0200, Matthias-Christian Ott said:
> But this makes, like "register", direct use of processor registers (it stores int arguments in eax, ebx, etc.).
`-mregparm=NUM'
Control how many registers are used to pass integer arguments. By
default, no registers are used to pass arguments, and at most 3
registers can be used. You can control this behavior for a
specific function by using the function attribute `regparm'.
*Note Function Attributes::.
*Warning:* if you use this switch, and NUM is nonzero, then you
must build all modules with the same value, including any
libraries. This includes the system libraries and startup modules.
If it weren't for that *warning*, you could get away with making this another
auto-optimizable value (similar to register allocation inside a function).
Alas, the caller and called functions can be in different .o files, and as
a result, you need to be able to specify the NUM to use to each invocation
of gcc involved, as there's an ABI change involved....
> Stay serious. The book only teaches you ISO-C 99 like many other books. So
> where's your problem?
The problem is the supposition that the implied 3 week's experience in a
language makes anybody qualified to comment on how to use it truly effectively
(for that matter, I've been programming in C since SunOS 3.2, literally 2
decades ago, and I'm still finding little corners I didn't previously know...)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Linus Torvalds @ 2005-04-25 18:50 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <426D33BA.8040604@tiscali.de>
On Mon, 25 Apr 2005, Matthias-Christian Ott wrote:
>
> But this makes, like "register", direct use of processor registers (it
> stores int arguments in eax, ebx, etc.).
No. It make _unlike_ "register", direct use of processor registers.
The "register" keyword does _not_ use processor registers. It's just
syntactic fluff, and tells the compiler exactly one thing:
- that the compiler should warn if you take the address of such a thing.
In addition, the compiler may generate code that takes it into account,
which most likely means _worse_ code than if it didn't take it into
account.
In contrast regparm() actually says something very relevant: it says that
the function uses a totally different calling convention.
Linus
^ permalink raw reply
* Re: git.git object database at kernel.org?
From: H. Peter Anvin @ 2005-04-25 18:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.58.0504241553580.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> NOTE! The fact that "mktime()" seems to depend on the timezone in which
> it is made seems to make this questionable. I had always assumed that
> mktime would take the timezone from the "struct tm", and thus be
> reliable, but somebody seems to have shown that that is not the case at
> all!
>
No, mktime() always uses the local time zone. It's the inverse of
localtime(). If you know the timezone offset (e.g. if you have a RFC
2822-style date) then you're probably better off rolling your own;
otherwise setenv("TZ"); tzset(); mktime(); is of course also doable.
-hpa
^ permalink raw reply
* [PATCH COGITO] githelp.sh is not installed
From: Pavel Roskin @ 2005-04-25 18:44 UTC (permalink / raw)
To: git
Hello!
"make install" doesn't install githelp.sh
Signed-off-by: Pavel Roskin <proski@gnu.org>
Index: Makefile
===================================================================
--- 7de71a831508e51e0985cea173f3f7a7012c82b7/Makefile (mode:100644 sha1:0bbdbee6b6925b64af476de3cebde9b02f9b03ca)
+++ uncommitted/Makefile (mode:100644)
@@ -36,7 +36,7 @@
gitmerge.sh gitpull.sh gitrm.sh gittag.sh gittrack.sh gitexport.sh \
gitapply.sh gitcancel.sh gitXlntree.sh gitlsremote.sh \
gitfork.sh gitinit.sh gitseek.sh gitstatus.sh gitpatch.sh \
- gitmerge-file.sh
+ gitmerge-file.sh githelp.sh
COMMON= read-cache.o
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Matthias-Christian Ott @ 2005-04-25 18:23 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <20050425171821.GQ24187@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Mon, 2005-04-25 19:13:59 +0200, Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:
>
>
>>>Yeah, "register" is what you use after 21 days of programming
>>>pracitce...
>>
>>actually it is introduced on day 2.
>
>
> ...and excessive use of "goto" being on day one?
>
> MfG, JBG
>
Stay serious. The book only teaches you ISO-C 99 like many other books. So where's your problem?
A good old german adage says: "Das ist so schrecklich, dass heute jeder Idiot zu allem eine Meinung hat." (Dieter Nuhr (http://de.wikiquote.org/wiki/Dieter_Nuhr))
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Matthias-Christian Ott @ 2005-04-25 18:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0504251021280.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 25 Apr 2005, Matthias-Christian Ott wrote:
>
>>"register" and "auto" variables aren't relicts of the 60's, they're a
>>part of the ISO-C 99 standard, I'm following, "man".
>
>
> They _are_ relicts of the 60's. It's just that the C standard hasn't ever
> had the reason to remove them.
>
>
>>And if you think "register" variables are outdated, please remove the
>>CONFIG_REGPARM option from the Kernel source.
>
>
> That does something totally different. And doesn't use "register" at all.
>
> Pass the toke, you've been hogging the drugs for way too long.
>
> Linus
>
But this makes, like "register", direct use of processor registers (it stores int arguments in eax, ebx, etc.).
Matthias-Christian Ott
^ permalink raw reply
* Re: mod-times (was: keyword expansion)
From: Geert Bosch @ 2005-04-25 18:13 UTC (permalink / raw)
To: tony.luck; +Cc: Thomas Glanzmann, git
In-Reply-To: <200504251756.j3PHuSh01362@unix-os.sc.intel.com>
On Apr 25, 2005, at 13:56, tony.luck@intel.com wrote:
>> - Time stamp of the last modification of a file
>
> One way to do this would be to rip on some of the core fundamentals of
> GIT
> and store the time that an object was created inside the object. E.g.
>
> blob size secs-since-1970 ...
>
> Then "read-tree" could fill this into the cache, and checkout-cache
> could
> set the mod-time on the file when it creates it, which would mean that
> you
> could see the timestamp for a file simply by using "ls -l file".
Of course this negates the idea of content-based storage, since you
want two copies of the same content with different time-stamps to share
the same blob.
-Geert
^ permalink raw reply
* Re: mod-times (was: keyword expansion)
From: Thomas Glanzmann @ 2005-04-25 18:10 UTC (permalink / raw)
To: git
In-Reply-To: <200504251756.j3PHuSh01362@unix-os.sc.intel.com>
Hi,
> > - Time stamp of the last modification of a file
> One way to do this would be to rip on some of the core fundamentals of GIT
> and store the time that an object was created inside the object. E.g.
I think I have nearly something finished. Using rev-tree, cat-file and
ls-tree -r written in perl.
> blob size secs-since-1970 ...
I dislike the idea because of reasons Torvalds has already mentioned
when talking about file renames and cvs annotate. And it also would fit
only this special case.
Having a 'git export' with real timestamps would be fun, but when I
think it over I don't really need it. And if I need it it would be a
matter of 20 minutes. :-)
Thomas
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: David A. Wheeler @ 2005-04-25 18:06 UTC (permalink / raw)
To: Rene Rebe, Matthias-Christian Ott, git
In-Reply-To: <426CD703.5040009@exactcode.de>
Rene Rebe wrote:
> Hi,
>
> Matthias-Christian Ott wrote:
>
>> The "git" didn't try store small variables, which aren't referenced,
>> in the processor registers. It also didn't use the size_t type. I
>> corrected a C++ style comment too.
>
>
> Well, modern compilers take register as a non-binding hint. Your
> register storage specification for those loop counters will not make
> any change. You have not looked into the resulting binary?
Indeed, register was ALWAYS a non-binding hint. Today,
unless you have specific measurements showing that adding "register"
at some point improves the performance for a (somewhat common) situation,
you're better off NOT including "register" nowadays. Today's compilers
are generally better at allocating registers than
people-who-have-little-time.
Premature optimization is the root of all kinds of evil...
> Also // is valid C99 ...
It's not, strictly speaking, okay on old pre-C99 compilers.
But in practice, practically all C compilers from the last 10+ years
have accepted // comments as a very popular extension.
So using "//" is unlikely to be a portability problem, even on semi-old
compilers.
--- David A. Wheeler
^ permalink raw reply
* mod-times (was: keyword expansion)
From: tony.luck @ 2005-04-25 17:56 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: git
In-Reply-To: <20050425002343.GF10806@cip.informatik.uni-erlangen.de>
> I am aware that keyword expansion is at the moment at the very bottom of
> the todo list. However I need it. Has someone something ready to use? I
> am looking for the following informations:
>
> - Time stamp of the last modification of a file
One way to do this would be to rip on some of the core fundamentals of GIT
and store the time that an object was created inside the object. E.g.
blob size secs-since-1970 ...
Then "read-tree" could fill this into the cache, and checkout-cache could
set the mod-time on the file when it creates it, which would mean that you
could see the timestamp for a file simply by using "ls -l file".
I think we'd need some other justifications before this would stand any
hope of getting in though, since it makes such a huge incompatible change
to the basic GIT format :-) Maybe queue the idea for GIT2.0?
-Tony
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Horst von Brand @ 2005-04-25 17:51 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426CD1F1.2010101@tiscali.de>
Matthias-Christian Ott <matthias.christian@tiscali.de> said:
> [Proposed patch adding "register" snipped]
Somebody a long while ago told me there are 3 kinds of C compilers with
respect "register": Dumb ones (they don't even consider it, just do
business as usual, as they don't know any better), normal ones (they
consider "register" and honor it if they can), and bright ones (they don't
even consider it, as they do a much better job using registers than any
programmer could direct them to by wiring a value into a register). GCC
definitely falls on the brighter side, at least if you tell it to
optimize. I think "register" should be marked deprecated in C (and there
are few good texts that even mention the word today, so it is deprecated in
practice).
Better compare the code produced (with -S instead of -c you'll get
assembler output in .s, not object code in .o) before any optimization
proposal. But also consider that large real gains come from higher-level
changes (better data structures, more efficient algorithms) and not from
low-level changes (In any case, today's compilers are usually smart enough
to make low-level changes on their own, so you can (thankfully) concentrate
on writing clear, correct code; and let the compiler make it fast. Sure,
where it is in a stretch of hot code, executed hundereds of times a second
on millions of machines worldwide, extra loving care is warranted, but that
is another kettle of fish.).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Why /usr/bin/env in scripts
From: David A. Wheeler @ 2005-04-25 17:45 UTC (permalink / raw)
To: Philip Pokorny, Git Mailing List
In-Reply-To: <426C9E63.4050907@mindspring.com>
Philip Pokorny wrote:
> I notice that the first line of the pasky shell scripts is
>
> #!/usr/bin/env bash
>
> rather than what I'm more familiar with:
>
> #!/bin/bash
...
> So what am I missing? Is this a portability aid?
Correct. Bash gets installed in different places on different systems,
e.g., on OpenBSD bash is NOT in /bin or /usr/bin, but in /usr/local/bin.
Invoking "/bin/sh" on OpenBSD will _NOT_ get you bash, but a pdksh
variant that doesn't implement the bash capabilities some scripts require.
Using env this way an old trick; I don't know who originally came up
with it.
Technically, even this isn't 100% portable. Leading "#!" (shebang)
isn't implemented by a very few old systems (it's not in the Single User
Spec,
though it was introduced between v7 and v8 of Unix). Also,
you can find one or two really obscure systems where env isn't in /usr/bin
(OpenServer 5 and a few really old Linux distributions).
But env is ONLY in /usr/bin for the *BSDs.
This version runs on 99.999% of the Linux/Unix systems, and takes
essentially zero effort to implement; "more portable" solutions are so much
more work that few people bother if they're writing shell scripts.
--- David A. Wheeler
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Dmitry Torokhov @ 2005-04-25 17:38 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426D21FE.3040401@tiscali.de>
On 4/25/05, Matthias-Christian Ott <matthias.christian@tiscali.de> wrote:
> "register" and "auto" variables aren't relicts of the 60's, they're a
> part of the ISO-C 99 standard, I'm following, "man".
...
> [2] Erik de Castro Lopo, Peter Aitken, Bradley L. Jones: Teach Yourself
> C for Linux Programming in 21 Days; SAMS Publishing; 1999
It must be "Teach yourself C for Gentoo Linux Programming..." "...
Gentoo rocks! I changed all my variables to 'register' and now my
kernel runs 3x times faster than RehHat one" :)
Sorry, couldn't resist...
--
Dmitry
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org> @ 2005-04-25 17:36 UTC (permalink / raw)
To: Matthias-Christian Ott, git, Linux Kernel Mailing List,
Linus Torvalds
In-Reply-To: <3X9X6-5JP-27@gated-at.bofh.it>
Matthias-Christian Ott <matthias.christian@tiscali.de> wrote:
> The "git" didn't try store small variables, which aren't referenced, in
> the processor registers. It also didn't use the size_t type. I corrected
> a C++ style comment too.
I have compared functions using 'register' against functions not doing that.
Not using register allowed better optimization on my x86.
--
The most dangerous thing in the world is a second lieutenant with a map and
a compass.
^ permalink raw reply
* Re: Revised PPC assembly implementation
From: linux @ 2005-04-25 17:34 UTC (permalink / raw)
To: paulus; +Cc: git, linux
In-Reply-To: <17004.47876.414.756912@cargo.ozlabs.ibm.com>
>> Which lead to three questions:
>> - Is the stack set properly now?
> Not quite; you are saving 20 registers, so you need a 96-byte stack
> frame, like this:
> stwu %r1,-96(%r1)
> stmw %r13,16(%r1)
> ...
> lmw %r13,16(%r1)
> addi %r1,%r1,96
> blr
Huh? I'm saving 19 registers, r13..r31, and not saving 13, namely
r0..r12.
The dodgy thing *I'm* thinking of is saving %r2 (the TOC pointer)
and using it as an extra temporary. (The alternative is spilling
one of the "old" hash values to the stack, which is not
too big a disaster.)
>> - Is it any faster?
> I did 10 repetitions of my program that calls SHA1_Update with a
> 4096-byte block of zeroes 256,000 times. With my version, the average
> time was 4.6191 seconds with a standard deviation of 0.0157. With your
> version, the average was 4.6063 and the standard deviation 0.0148. So
> I would say that your version is probably just a little faster - of the
> order of 0.3% faster.
Damn. So that's actually *worse* than me earlier version which achieved
an (also piddling) 2% speedup?
As you can see, I tried to make the addition tree bushier, but I guess
it didn't help. Or the processor isn't out-of-order enough to find
the parallelism I made available.
Damn, I wish I had at that IBM pipeline profiling tool. If it could
just tell me which cycles didn't have both ALUs busy, I could solve it
in relatively little time.
The place that could really use scheduing help is the G4, which has three
integer ALUs, but can only *think* about executing the bottom three entries
in the reorder queue. So if one of those instructions isn't ready, it
stalls in the queue and idles the ALU with it.
Especially there, it may be necessary to interleave the EXPANDW code
with the round code to avoid having the (non-critical-path) EXPANDW
code scheduled ahead of critical-path round code.
The two critical-path inter-round dependencies are:
- summing into E to be rotated by 5 and added to D next round.
(this is the "A<<<5" code in the current round)
- rotating B left for use in the next round's F(a,b,c) function.
(this is the current round's C input)
Actually, the E variable isn't critical-path at all; it was last
modified several rounds ago.
Maybe I can improve the scheduling some more...
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Jan-Benedict Glaw @ 2005-04-25 17:18 UTC (permalink / raw)
To: git, Linux Kernel Mailing List, Matthias-Christian Ott,
Linus Torvalds
In-Reply-To: <20050425171359.GN10806@cip.informatik.uni-erlangen.de>
On Mon, 2005-04-25 19:13:59 +0200, Thomas Glanzmann <sithglan@stud.uni-erlangen.de> wrote:
> > Yeah, "register" is what you use after 21 days of programming
> > pracitce...
>
> actually it is introduced on day 2.
...and excessive use of "goto" being on day one?
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Valdis.Kletnieks @ 2005-04-25 17:22 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: Linus Torvalds, git, Linux Kernel Mailing List
In-Reply-To: <426D21FE.3040401@tiscali.de>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Mon, 25 Apr 2005 18:59:42 +0200, Matthias-Christian Ott said:
> And if you think "register" variables are outdated, please remove the
> CONFIG_REGPARM option from the Kernel source.
I think you fail to understand the difference between what CONFIG_REGPARM does
(namely, controlling the way parameters are passed to function calls) and what
the 'register' declaration does....
> [2] Erik de Castro Lopo, Peter Aitken, Bradley L. Jones: Teach Yourself
> C for Linux Programming in 21 Days; SAMS Publishing; 1999
Umm.. Yeah. "Teach yourself FOO in 21 days". Quite the outstanding authority
to cite. Gotta love the publisher too.. ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: unseeking?
From: Daniel Barkalow @ 2005-04-25 17:27 UTC (permalink / raw)
To: Zack Brown; +Cc: Petr Baudis, git
In-Reply-To: <20050425161854.GE11094@tumblerings.org>
On Mon, 25 Apr 2005, Zack Brown wrote:
> Hi,
>
> Thanks for all the help!
>
> On Sun, Apr 24, 2005 at 06:10:42PM -0400, Daniel Barkalow wrote:
> > > but I still don't see its significance. What do you get from a fork that
> > > you don't get from a regular old init and pull?
> >
> > Primarily, the ability to inspect and build the mainline tree. If you want
> > to take a look at what's going on in the mainline without getting it again
> > or messing with your working directory or local commits, you can do that.
>
> OK, I think I understand this so far. So, suppose I want to contribute to
> cogito. I would first do a git init on Pasky's cogito tree, to get it on my home
> system. This would be my home base, and whenever I wanted to do some work on the
> current state of his tree, I would fork off another branch.
>
> So, I want to do this. From inside cogito's root directory, I give the command
>
> git fork mycogito ../mycogito
>
> and ../mycogito is created. In this new directory, the .git directory
> contains only symlinks to ../cogito/HEAD, ../cogito/heads, ../cogito/objects,
> ../cogito/remotes, and ../cogito/tags, and an index file.
If you look carefully, ../cogito/.git/heads contains several files, one of
which is "mycogito", and the symlink in mycogito/.git/HEAD is to that one,
while the one in cogito/.git/HEAD is to a different one. So, while HEAD
points to a file in a shared directory, each fork points to a different
file.
> Question: when I make changes to mycogito and commit them, is only the index
> file in .git/ altered, or are my changes reflected in the cogito/ directory as
> well? If I do another fork of cogito, will I see mycogito's changes in the new
> fork?
The changes affect only the "mycogito" head, not the original head. On the
other hand, the files generated by the commit are accessible from the
original directory, so you can diff between your new head and the original
or mainline successors of it.
> So moving on, I now have this mycogito tree. But I don't do any edits yet. I
> just poke around for awhile, reading files. Finally I realize that there have
> probably been updates to the upstream sources, and I want to pull those in
> before I start my work. So, as I would do in the cogito directory, I give the
> command
>
> git pull pasky; git pull linus
>
> this works fine. There are no new updates to be had, and git tells me my tree is
> uptodate.
>
> so now I start work. I run aspell on the README file, and it catches some
> typos. I fix them and save the file but don't yet commit it. Now mycogito
> has some changes that I would ultimately like to push up to Pasky.
>
> Now I'm unclear what comes next. Do I just do a 'git diff' from the mycogito
> directory and post the results to the git list?
Now you commit in your directory. This gives you a new head for
mycogito. You can then do "git patch pasky" (or something of the sort,
check the help for the details) to get a patch for the your changes. You
can also do multiple commits and generate either a single patch or patches
corresponding to each commit.
> Suppose I want to keep working, changing more stuff in mycogito, but I
> also want to make sure that mycogito tracks the upstream sources.
>
> git merge pasky; git merge linus
>
> and give that command to bring the upstream changes into mycogito?
In general, you want to use "merge" when you've got local commits. You
also want to commit before doing this, so that you have a known state
for your version to revert to if you mess up merging.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Linus Torvalds @ 2005-04-25 17:23 UTC (permalink / raw)
To: Matthias-Christian Ott; +Cc: git, Linux Kernel Mailing List
In-Reply-To: <426D21FE.3040401@tiscali.de>
On Mon, 25 Apr 2005, Matthias-Christian Ott wrote:
>
> "register" and "auto" variables aren't relicts of the 60's, they're a
> part of the ISO-C 99 standard, I'm following, "man".
They _are_ relicts of the 60's. It's just that the C standard hasn't ever
had the reason to remove them.
> And if you think "register" variables are outdated, please remove the
> CONFIG_REGPARM option from the Kernel source.
That does something totally different. And doesn't use "register" at all.
Pass the toke, you've been hogging the drugs for way too long.
Linus
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox