* Re: [FILE] GNU BIT
From: Petr Baudis @ 2005-04-25 20:52 UTC (permalink / raw)
To: Andreas Gal; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504242308460.6454@sam.ics.uci.edu>
Dear diary, on Mon, Apr 25, 2005 at 08:24:24AM CEST, I got a letter
where Andreas Gal <gal@uci.edu> told me that...
> HELP
>
> Try "bit --help" to get some simple instructions how to use BIT. All
> commands have builtin help as well. Try "bit commit --help". Not all
> options are always implemented. Feel free to send me a patch.
Do you intend to licence it as free software? Also, you call it "GNU
BIT". Does that mean it is part of the GNU project?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: [PATCH GIT 0.6] make use of register variables & size_t
From: Arjan van de Ven @ 2005-04-25 20:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias-Christian Ott, git, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0504251147290.18901@ppc970.osdl.org>
On Mon, 2005-04-25 at 11:50 -0700, Linus Torvalds wrote:
>
> 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.
afaik gcc just otherwise ignores it entirely.
^ permalink raw reply
* Re: git "tag" objects implemented - and a re-done commit
From: Linus Torvalds @ 2005-04-25 20:42 UTC (permalink / raw)
To: Andreas Gal; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504251318290.11481@sam.ics.uci.edu>
On Mon, 25 Apr 2005, Andreas Gal wrote:
>
> Are tag objects referenced by trees (and thus limited in scope) or are
> they stand-alone entities in the repository? The latter would be bad for
> shared object storages.
They are totally stand-alone, and I don't see why that would be bad for
shared object storage.
In fact, the whole point of them is that since they are named by the SHA1
hash of the content, there are no shared object issues. Two different tags
by two different developers will have different names, exactly the same
way two different releases will have different names.
And if two different developers tag exactly the same object with exactly
the same tag-name and exactly the same signature, then they get the same
tag object, and that's fine. They should.
> Also, if I delete and recreate tags, will the old tag remain in the tree
> or will the file in the object storage disapear?
Tags in no way affect the entry they name. When you remove - or add - a
tag object, nothing happens to anything else.
Linus
^ permalink raw reply
* Re: git "tag" objects implemented - and a re-done commit
From: Andreas Gal @ 2005-04-25 20:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504251213530.18901@ppc970.osdl.org>
Are tag objects referenced by trees (and thus limited in scope) or are
they stand-alone entities in the repository? The latter would be bad for
shared object storages. Also, if I delete and recreate tags, will the old
tag remain in the tree or will the file in the object storage disapear?
So far all objects were always persistent, which is a nice property to
have.
Andreas
On Mon, 25 Apr 2005, Linus Torvalds wrote:
>
> 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
> -
> 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
* 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
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