Tuesday, January 5, 2016

Digest for comp.lang.c++@googlegroups.com - 19 updates in 2 topics

scott@slp53.sl.home (Scott Lurndal): Jan 05 02:04PM

>is 8, 16, 24, 32, 36 and 64.
 
>As I said, I've never met one which is not twos complement (ie -1 is
>some number of FFFs).
 
I have used one, and am aware of another where a negative value is
not represented in twos (or even ones) complement. Now, both are
obsolete (yet one was running production code as late as 2010 for
a california city).
 
In Burroughs medium systems mainframes, memory is addressible to
the digit (nibble) and arithmetic is done on BCD values. The sign
digit (0xC for +, 0xD for -) occupies the leading digit of the field.
 
A null pointer is represented by the 8 digit (base 16) value CiEEEEEE
where the 'i' can be any value from 0 to 7 (it's a base indicant to select
which of the 8 active base-limit pairs to use).
 
http://vseries.lurndal.org/doku.php?id=instructions:add
http://vseries.lurndal.org/doku.php?id=instructions:slt
 
Similarly the IBM 1401 and other BCD systems.
 
https://en.wikipedia.org/wiki/IBM_1401
 
C (and C++) aren't a good match for such architectures.
scott@slp53.sl.home (Scott Lurndal): Jan 05 02:06PM

>complement. No bits set is +0, all bits set is -0. The two compare
>equal so it is an artifact of the representation - in one's complement,
>all bits set is equal to no bits set.
 
 
-0 also exists in BCD architectures. In general, it's treated by
the hardware as identical to +0.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 03:59PM

On Tue, 05 Jan 2016 14:06:13 GMT
> >complement, all bits set is equal to no bits set.
 
> -0 also exists in BCD architectures. In general, it's treated by
> the hardware as identical to +0.
 
And in any sign-and-magnitude representation of signed integers
generally.
 
I saw your interesting post on BCD systems, which I took to mean that
they use 4-bit binary coded decimal for their numbers. I don't think
such systems could validly run a C++11 program, because §3.9.1/4
requires a standard power-of-2 per bit representation of unsigned
integers, something which is also assumed by §4.7/2 dealing with
unsigned overflow. I am not as familiar with the C11 standard but I
suspect that a BCD system may be able to run C. In particular
§6.3.1.3/2 of C11 on unsigned overflow does not assume power-of-2
representation, and although its effect is identical to §4.7/2 of C++11
on such representations, its requirements work OK for others (systems
would have to ensure that all necessary bit transformations are made so
that initialization or assignment of -1 to their unsigned integer type
sets the unsigned integer to its maximum value, which happens to be
all-bits-set for power-of-2 representations). Perhaps something else
in C rules out BCD, I don't know.
 
I remember many years ago having some hardware based logic in an
electronic device using BCD for its numbers. That is as close as I
have ever come to it. It struck me then as wasteful of storage, albeit
very convenient in that particular usage.
 
Chris
scott@slp53.sl.home (Scott Lurndal): Jan 05 04:44PM

>generally.
 
>I saw your interesting post on BCD systems, which I took to mean that
>they use 4-bit binary coded decimal for their numbers.
 
I was one of the OS engineers for the Burroughs BCD systems three
decades ago. We did look (circa 1984) at porting V6 C to the
architecture, but it would have been very limiting; The architecture
allows variable length numeric fields of one to 100 digits. We looked
at mapping 'unsigned int' to a 8-digit (32-bit) field, but the largest
magnitude number supported would be 9,999,999 which wasn't particularly
useful. It was really designed as a target for COBOL compilers.
 
Making it more difficult, the user-level architecture included segmentation (up to
seven active data and one code segment at any time, with a non-local
function call instruction (virtual enter, VEN) to switch to a different
set of eight "segments". Each segment maxed out at 1 million digits
(i.e. a 6-digit address within the segment).
 
nullptr was a 6-digit EEEEEE (8-digits in an index register to allow
selection of one of the 8 active segments).
 
Segment 0, which contained the stack and the first three index registers
(which were mapped to addresses 8-15, 16-23 and 24-31) was generally
the same in all of an application environments (sets of segments).
The stack pointer was mapped to address 40-45 in segment zero.
 
Each process (task) had its own segment zero. Code segments (being
immutable) were shared as necessary both within a task and between
tasks.
 
Application APIS (core-to-core(synchronous) and storage queues(asynchronous))
allowed data to be shared between cooperating tasks.
 
Debugging was dead simple given that everything was in BCD.
 
The architecture did not have bit shifting capabilities[*], but did have
bit test, bit set and bit clear instructions as well as the logical
bit manipulation instructions (and, or, not).
 
[*] although the processor internally had a barrel shifter to efficiently
store and access nibbles using COTS memory parts (post magnetic core).
 
Early 70's versions (the architecture dates to 1965) didn't trap on
'undigit arithmetic' and the results were 'undefined'. Later architectures
would trap such operations; several customers had funky code that relied
on undigit (e.g. bcd values of 0xa - 0xf) arithmetic which was one of the
few backward compatability issues we had over the 30 year life of the
architecture; most applications written in 1966 still ran in 1996 on
the latest version of the hardware (a good thing, since the source for
many of those applications had been lost).
 
City of Santa Ana replaced their V380 (built 1987) with 20 windows
boxes in 2010, which was the last system I'm aware of that was still
in production. The system is now operational at the Living Computer
Museum in Seattle, Wash.
 
scott
 
Rosario19 <Ros@invalid.invalid>: Jan 05 06:23PM +0100

On Mon, 4 Jan 2016 23:08:47 +0000, Chris Vine wrote:
>complement. No bits set is +0, all bits set is -0. The two compare
>equal so it is an artifact of the representation - in one's complement,
>all bits set is equal to no bits set.
 
+0 or -0 are == 0
in what i have seen not exist in mathematic...
fixed point float would not have them too
 
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 07:24PM

On Tue, 05 Jan 2016 16:44:40 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
[snip]
> boxes in 2010, which was the last system I'm aware of that was still
> in production. The system is now operational at the Living Computer
> Museum in Seattle, Wash.
 
That's an interesting historical perspective. You must be about my age.
 
Having just looked at the museum's website I will see if I can fit in a
visit the next time I am at the west coast. I am a UK resident and
don't go there that often as it is such a long haul - I was last there
at the end of September to watch the Dodgers-Giants series (seeing
Bumgarner, Kershaw and Greinke pitching in the space of 2 days was
persuasive).
 
Chris
scott@slp53.sl.home (Scott Lurndal): Jan 05 07:57PM

>On Tue, 05 Jan 2016 16:44:40 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>[snip]
[snip burroughs description]
>at the end of September to watch the Dodgers-Giants series (seeing
>Bumgarner, Kershaw and Greinke pitching in the space of 2 days was
>persuasive).
 
Yes, I'm able to frequently attend Giants games during the season
(although they take more parking away every year and I'm no longer
much interested in weekday night games so I've been attending fewer
games lately :-).
 
Many of my friends from the UK (Burroughs had offices in Citygate,
Uxbridge, Milton Keynes and other locations that I used to visit)
consider american baseball akin to rounders.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 08:26PM

On Tue, 05 Jan 2016 19:57:27 GMT
> (although they take more parking away every year and I'm no longer
> much interested in weekday night games so I've been attending fewer
> games lately :-).
 
Stay in SF. Hotel prices are high but the public transport system there
is fantastic (and there are some decent bars to call in at on the way
back to Market if that is where you are picking up your tram/bus/train).
AT&T Park is one of the great venues.

> Many of my friends from the UK (Burroughs had offices in Citygate,
> Uxbridge, Milton Keynes and other locations that I used to visit)
> consider american baseball akin to rounders.
 
This is getting off topic so I will end it here, but having spent a
part of my formative years in the US I am ambidextrous with respect to
baseball and cricket (and other sports for that matter). I guess I
would have to say that the best sporting competition in the world in my
opinion is the European Champions League.
 
Chris
scott@slp53.sl.home (Scott Lurndal): Jan 05 08:38PM

>is fantastic (and there are some decent bars to call in at on the way
>back to Market if that is where you are picking up your tram/bus/train).
>AT&T Park is one of the great venues.
 
I can take CalTrain to the stadium, but it takes well over an hour
each way. I live 50 miles south of PacBell^H^H^H^H^H^H^H AT&T park.
 
s
Vir Campestris <vir.campestris@invalid.invalid>: Jan 05 09:38PM

On 04/01/2016 22:24, Chris Vine wrote:
> affect the clear intention. (However, behaviour in the reverse
> direction, namely on overflow on conversion to signed, is not
> guaranteed. It is implementation defined - §4.7/3.)
 
Sorry, I snipped too much.
 
They told me not to use ~0...
 
Andy
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 05 01:08PM +0100

A bit off-topic, but, since clc++ never had a charter I feel safe, ;-)
 
I finally got cppx to compile with MinGW g++ (next step is adding
Unicode console i/o support for g++), but when I tried to commit to
GitHub the "GitHub" GUI thingy didn't seem to present all changes and
new files.
 
Sure enough, after committing it listed like 30 new changes, which I
then had to commit again.
 
And after that, a single remaining change that I had to commit.
 
Surely it's not meant to work like that, incremental commits?
 
I haven't used Git earlier so it's all new to me, including that I
haven't the foggiest idea what the difference is between committing and
pushing changes (sync) to GitHub.
 
 
Cheers & thanks for not biting me now,
 
- Alf
 
https://github.com/alf-p-steinbach/cppx/commits/plutonium
Christian Gollwitzer <auriocus@gmx.de>: Jan 05 01:44PM +0100

Am 05.01.16 um 13:08 schrieb Alf P. Steinbach:
 
> I haven't used Git earlier so it's all new to me, including that I
> haven't the foggiest idea what the difference is between committing and
> pushing changes (sync) to GitHub.
 
Are you talking about some GUI from GitHub? I've only ever used pure git
from the commandline, where it works like this
 
1) git commit -a
This opens up an editor with an overview of the changes, you enter a
description to cimmit your changes. These are then stored locally only
(in the .git folder)
 
2) git push
send all commits to the server (github, in that case), i.e. publish them.
 
If you have new files, you need to "git add" them, to be included in the
commit. If you leave off the "-a" from the commit, it only includes
changes in the files which you explicitly "added" to the commit. The -a
adds all files that are already under version control.
 
"git pull" is the opposite of "push" and it updates your local copy with
the changes from the server. As opposed to a centralized VCS like CVS or
SVN, you do not need to push everything to the server - you can happily
commit to your local repo, and once you think it is working as desired,
you "push" it to the server. The more professional users like the kernel
developers also perform a rebase operation, which allows you to bundle
several commits into one before you publish the changes. Personally, I
do not do this, I publish every typo correction.
 
Christian
 
 
Christian Gollwitzer <auriocus@gmx.de>: Jan 05 01:46PM +0100

Am 05.01.16 um 13:44 schrieb Christian Gollwitzer:
>> pushing changes (sync) to GitHub.
 
> Are you talking about some GUI from GitHub? I've only ever used pure git
> from the commandline, where it works like this
 
PS: On Windows, I've used TortoiseSVN in the past, which nicely
integrates with the explorer. Maybe you try TortoiseGIT?
 
Christian
Darko Miletic <darko.miletic@gmail.com>: Jan 05 09:56AM -0300

On 05/01/16 09:08, Alf P. Steinbach wrote:
> then had to commit again.
 
> And after that, a single remaining change that I had to commit.
 
> Surely it's not meant to work like that, incremental commits?
 
In general it should not behave like that. In any case the best results
are obtained by using command line git client. There you have the full
control over everything and it mostly works once configured.
 
For example let us assume you have your project in foo dir.
Open the command line, position yourself in that dir. Execute:
git add -A
git commit -m "My latest changes"
git push origin mybranchname
 
That's it. All this assumes that your git is properly configured, that
you have github keys in place, that your .gitignore is correct etc.
 
What does that mean? It means:
* Install git client - https://git-scm.com/download/win (for windows)
* configure git client
from command line execute:
git config --global user.name "Your Name"
git config --global user.email yourmail@domain.tld
git config --global core.filemode false
git config --global core.autocrlf false
git config --global color.ui true
git config --global merge.renamelimit 10000
git config --global push.default simple
 
* generate and configure github ssh keys
https://help.github.com/articles/generating-ssh-keys/
 
However if you are into gui for vcs than check this one out -
https://tortoisegit.org/
"Öö Tiib" <ootiib@hot.ee>: Jan 05 05:23AM -0800

On Tuesday, 5 January 2016 14:46:39 UTC+2, Christian Gollwitzer wrote:
> > from the commandline, where it works like this
 
> PS: On Windows, I've used TortoiseSVN in the past, which nicely
> integrates with the explorer. Maybe you try TortoiseGIT?
 
The TortoiseSVN and TortoiseHG are fine but TortoiseGit was screwing everything
up badly last I tried. Command line is ok and Atlassian SourceTree and SmartGit
seemed at least working and helpful unlike that TortoiseGit.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 02:13PM

On Tue, 2016-01-05, Christian Gollwitzer wrote:
>> pushing changes (sync) to GitHub.
 
> Are you talking about some GUI from GitHub? I've only ever used pure git
> from the commandline, where it works like this
 
Fortunately, a Git repo at GitHub works just like any other Git repo.
It's plausible that there's a GUI there where you can mess up in
interesting ways, but if so, there's no need to use it.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 05 05:37PM

On Tue, 2016-01-05, Christian Gollwitzer wrote:
> This opens up an editor with an overview of the changes, you enter a
> description to cimmit your changes. These are then stored locally only
> (in the .git folder)
 
Note that that's just one of many ways of producing commits.
 
> 2) git push
> send all commits to the server (github, in that case), i.e. publish them.
 
Well ...
 
The more general form is 'git push <remote> <my_commit>:<your_branch>',
so 'git push github master:master' means:
 
"Dear github, please take your "master" branch and make it so
that its tip becomes my commit called "master". You may steal
as many commits from me as you need. And if you refuse because
doing it would mean something more disruptive than just adding a
string of commits on top of your present "master", that's ok
too; I'll survive (and perhaps add a --force next time)."
 
> the changes from the server. As opposed to a centralized VCS like CVS or
> SVN, you do not need to push everything to the server - you can happily
> commit to your local repo, and once you think it is working as desired,
 
And once you see it's split into commits in a nice and logical way.
You can do pretty much anything to the commits as long as they're unpublished,
using e.g. rebase -i.
 
> developers also perform a rebase operation, which allows you to bundle
> several commits into one before you publish the changes. Personally, I
> do not do this, I publish every typo correction.
 
YMMV, but that's one of the best things about Git. You don't have to
be professional to appreciate that -- just perhaps a bit more
interested in the history than the average person.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 07:43PM

On Tue, 5 Jan 2016 13:08:58 +0100
 
> I haven't used Git earlier so it's all new to me, including that I
> haven't the foggiest idea what the difference is between committing
> and pushing changes (sync) to GitHub.
 
git seems to be available as a windows binary so I would strongly
suggest that you use that.
 
git is a distributed system. 'commit' commits to your local
repository. 'push' pushes the changes you have committed locally to
another repository that you happen to have chosen to commit to (or have
set as your remote repository). pushing may or may not succeed. It
should succeed if you are the only one pushing to the remote repository,
unless something else has gone adrift.
 
Chris
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 05 07:50PM

On Tue, 5 Jan 2016 19:43:46 +0000
> git is a distributed system. 'commit' commits to your local
> repository. 'push' pushes the changes you have committed locally to
> another repository that you happen to have chosen to commit to (or
^^^^^^
push
Chris
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)