Tuesday, April 19, 2016

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

Robert Wessel <robertwessel2@yahoo.com>: Apr 18 08:03PM -0500

On Sun, 17 Apr 2016 21:59:59 -0400, Jerry Stuckle
>> typical x86 implementations. As do many of the implementations on
>> RISCs that also lack hardware stacks.
 
>I didn't say the compiler had to generate storage requests to the OS.
 
 
I didn't say it either.
 
 
 
>And no, the R13 linked list format is *not* just used for functions that
>call or are called from the outside. It is used quite extensively with
>internal calls also - including setting up the above pseudo-stack.
 
 
In the context of C or C++ programs, the traditional S/360 method is
not used for most internal calls. You generally need to specify
traditional linkage explicitly (via either #pragma linkage or a
specification on the extern statement) on those functions where it's
needed. At least for normal C/C++ since the later OS/390 days. The
(normally used) XPLink convention uses R4 to address a typical
"hardware-style" stack, and reserves various registers for passing
parameters and return values.
 
MetalC is different, and does use the R13-based linked list by
default.
 
 
>But either way, there is no hardware stack. I will agree it is an
>emulation. But C does not require a stack. Only a way to create a
>unique storage area when a function is called.
 
 
C does not require a hardware-style stack. It does, for at least some
programs, require a stack in the general CS sense.
Robert Wessel <robertwessel2@yahoo.com>: Apr 18 08:06PM -0500

On Mon, 18 Apr 2016 21:40:56 +0200, David Brown
>> with entirely different instruction sets.
 
>OK. As I said, I am not familiar with the cpus IBM use in their big
>systems, other than the Power processors.
 
 
Creating a "hardware-style" stack using a register as a base is as
straight-forward on Z as you'd expect (and as is done by the C
compiler by default), and using a linked-list is not "easier" (except
in the sense that the linked-list approach is the system calling
convention, so if you interface to other things you will need to use
the old calling convention).
David Brown <david.brown@hesbynett.no>: Apr 19 09:27AM +0200

On 18/04/16 22:20, Scott Lurndal wrote:
> 6 digit value from address 40 relative to base register 0 and
> use that as the address in memory for the stack (also relative to
> base 0), and will update it as data is pushed on the stack.
 
From your wiki (I read a little, but not all), it looks like there is a
call stack for holding return addresses and some registers, but you
don't have direct access to it for use as a data stack. Is that right?
But surely you could have a data stack if you wanted - use one of the
index registers as your data stack pointer, pointing to a block of
contiguous memory.
 
>> instructions, and addressing modes for working with linked lists, and
>> not also be able to use these for accessing a stack.
 
> Registers? Who needs them :-).
 
The MAXQ architecture has no registers as such - everything is memory
mapped. And it has only one instruction - "move". All ALU operations,
branches, etc., are handled by reading and writing to memory mapped
addresses:
 
<https://www.maximintegrated.com/en/app-notes/index.mvp/id/3222>
 
(I haven't programmed one of these, but we considered one of those
microcontrollers for a project a good many years ago.)
 
 
I have also programmed on a device which had 32 registers - but no ram!
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 19 12:17PM +0200

On 19.04.2016 09:27, David Brown wrote:
> mapped. And it has only one instruction - "move". All ALU operations,
> branches, etc., are handled by reading and writing to memory mapped
> addresses:
 
As I recall the PDP-11 also had memory mapped registers.
 
However, at the time, I was in college, all I did of programming with
the PDP-11 was "Hello, world!" in assembly. This was due to all
information about how to use the machines being channeled through
classroom lectures, and to me the lectures were excruciatingly boring
and slooooow, a kind of psychological terror warfare. Well OK, I also
used PDP-11 machines to test an NC "direct connection" single board
computer that another student and I developed in MP/L-86, and moved the
disks of one PDP-11 machine from the college to the machine hall of
Kongsberg Våpenfabrikk, and it worked just fine there (I was not sure
whether that would work). So it's weird. I was surrounded by PDP-11
machines and used them for some tasks, but I failed to see how elegant
they were on the inside. Possibly put off by PIP and STAT commands. :(
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Apr 19 12:27PM +0200

On 19/04/16 12:17, Alf P. Steinbach wrote:
> whether that would work). So it's weird. I was surrounded by PDP-11
> machines and used them for some tasks, but I failed to see how elegant
> they were on the inside. Possibly put off by PIP and STAT commands. :(
 
I don't know much about the PDP-11 itself, but the TI msp430
microcontroller cpu ISA is heavily based on that of the PDP-11. The cpu
registers are not memory mapped, but hardware registers and I/O
registers are memory mapped. At the time of the PDP-11, I believe it
was standard practice for I/O access to be separate from memory access,
using different instructions (you still get this on some processors and
microcontrollers) - the PDP-11 was unusual in that I/O access was done
using the same instructions and address space as RAM access. (The
msp430 is a very nice ISA - I have enjoyed working with it in both
assembly and C.)
 
You will be familiar with the AVR architecture, I hope? It has 32 8-bit
registers, which are also available in the memory map.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 19 02:45PM +0200

On 19.04.2016 12:27, David Brown wrote:
 
> You will be familiar with the AVR architecture, I hope? It has 32 8-bit
> registers, which are also available in the memory map.
 
Oh this is very off-topic, but sorry, no, I'm not familiar with the AVR
architecture (I just googled it). AFAIK I never programmed a Harvard
architecture machine. But I note that one of the designers was named
Alf, which surely is a good sign, and that judging by the names, Alf
Egil Bogen and Vegard Wollan, they both appear to be Norwegians. :)
 
But re separation of i/o instructions, just a historical silly-fact:
 
the Intel 8086 was designed with two co-processors, namely the 8087 math
coprocessor, and the 8089 i/o coprocessor! I think it must have been a
design IBM lifted from their mainframes. But I've never heard of the
8089 being used in any real machine, and don't even know if it was ever
actually produced. There must be a name for that kind of technology. An
apparent big advance, which turns out to be nothing?
 
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Apr 19 03:28PM +0200

On 19/04/16 14:45, Alf P. Steinbach wrote:
> architecture machine. But I note that one of the designers was named
> Alf, which surely is a good sign, and that judging by the names, Alf
> Egil Bogen and Vegard Wollan, they both appear to be Norwegians. :)
 
Exactly - the AVR was designed by Atmel in Trondheim. It is one of the
most popular 8-bit microcontroller architectures, with a wide variety of
devices. The main development of the microcontroller and tools is in
Trondheim, though some peripherals are designed elsewhere. So as a true
Norwegian patriot, you need to know about this architecture!
 
Actually, it is somewhat relevant for this subthread, since the AVR has
no [SP + offset] addressing mode, making stacked data inconvenient to
access. In some AVR compilers, there is a separate data stack using the
Y index register (which has [Y + offset] addressing modes) independent
of the call-return stack.
 
And yes, it is Harvard architecture - the code/flash address space is
separate from the data/I/O address space, which is a source of great
irritation to C and C++ programmers.
 
scott@slp53.sl.home (Scott Lurndal): Apr 19 02:07PM


>From your wiki (I read a little, but not all), it looks like there is a
>call stack for holding return addresses and some registers, but you
>don't have direct access to it for use as a data stack. Is that right?
 
Correct, although IX3 (index register 3) by convention holds the
"frame pointer" for the current frame. It's automatically adjusted
by VEN/RET (and the older NTR/EXT). The ASP instruction will adjust
the TOS value at BASE.+40.6.UN based on the literal value in the A
syllable of the instruction to provide space for local storage
(and the GENERATE intrinsic in the SPRITE language which is similar to alloca()
from BSD).
 
Local variables will be indexed via IX3.
 
IX1, IX2 and IX3 are in actuality located at BASE.+8.7.SN, BASE.+16.7.SN
and BASE.+24.7.SN (3 8-digit fields). Around 1982, we redesigned the
processor architecture (maintaining backward compability) to enhance
addressing (to allow a single program to use more than 500KBytes
and to support systems with more than 10,000,000 bytes of main memory).
At that time, we added four more index registers not tied to memory
(known as the mobile IX) and enhanced the ISA to accommodate them.
 
BASE.+24.7.SN indicates a data item at an offset of 24 digits
from the base of the memory area which is is a 7-digit signed
numeric field (8 digits in length with the leading sign digit).
 
The second (following the sign) of an Index register is a base-indicant
which selects one of 8 memory areas. So BASE.+24.IX4.3.UN, if IX1 has
the value C2001000 formally describes a three digit (nibble) field starting
1024 digits into memory area two for the current task.
 
> But surely you could have a data stack if you wanted - use one of the
>index registers as your data stack pointer, pointing to a block of
>contiguous memory.
 
Right, there were no PUSH/POP type operations in the ISA, so it would
be manually crafted. Not that different from the IBM360 and successors.
 
On the other hand, most systems in the late 60's and early 70's had
limited memory (systems with a million bytes of memory didn't show up
until the mid 70's). Magtape (and the more expensive disk/pack) storage
was used instead. Watching a 12-unit mag-tape sort/merge was pretty
impressive, especially on the drives that could read backwards.
scott@slp53.sl.home (Scott Lurndal): Apr 19 02:09PM

>On 19.04.2016 09:27, David Brown wrote:
 
>As I recall the PDP-11 also had memory mapped registers.
 
You may be remembering the PDP-8, which had an accumulator and
the single-bit link register.
 
The PDP-11 (and the successor VAX) had regular registers
and useful addressing modes.
 
 
>they were on the inside. Possibly put off by PIP and STAT commands. :(
 
Should have used UnixV6 instead of RSX-11M/RSTS-E.
scott@slp53.sl.home (Scott Lurndal): Apr 19 02:11PM


> There must be a name for that kind of technology. An
>apparent big advance, which turns out to be nothing?
 
iAPX 432.
 
:-)
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 19 05:38PM +0200

On 19.04.2016 16:09, Scott Lurndal wrote:
> the single-bit link register.
 
> The PDP-11 (and the successor VAX) had regular registers
> and useful addressing modes.
 
My photocopied PDP-11 manual is down in the bottom of some box.
 
And all I could find in Wikipedia was that the Program Status Word
register was memory mapped.
 
It would however be strange if only one single register was memory
mapped, so I googled further and found an online PDF of a manual (in
non-machine-readable form, just scans of the pages), where I found that
at [1]least the "control registers" PS, SL, PIR, PIA and PB, whatever
those acronyms stand for, were memory mapped, in the range 17 777 770
through 17 777 776. Now that's seven addresses and five registers.
Counting also the PSW (unless the names here refer to parts of it!) we
have six registers.
 
 
>> they were on the inside. Possibly put off by PIP and STAT commands. :(
 
> Should have used UnixV6 instead of RSX-11M/RSTS-E.
 
Yep.
 
 
Cheers!,
 
- Alf
 
Notes:
[1] <url: http://i.stack.imgur.com/oX15F.png>, emphasis added by me. I
find SO is a nice service for posting images quickly to imgur.
Robert Wessel <robertwessel2@yahoo.com>: Apr 19 11:12AM -0500

On Tue, 19 Apr 2016 12:17:55 +0200, "Alf P. Steinbach"
>> branches, etc., are handled by reading and writing to memory mapped
>> addresses:
 
>As I recall the PDP-11 also had memory mapped registers.
 
 
IIRC, and as far as the general purpose registers are concerned...
that was true on some low-end machines, but not on the high end
machines. A number of machines had control registers for various
purposes and those were often memory mapped.
Robert Wessel <robertwessel2@yahoo.com>: Apr 19 11:27AM -0500

On Tue, 19 Apr 2016 14:45:17 +0200, "Alf P. Steinbach"
>8089 being used in any real machine, and don't even know if it was ever
>actually produced. There must be a name for that kind of technology. An
>apparent big advance, which turns out to be nothing?
 
 
While Intel called what the 8089 provided an I/O channel (or rather, a
pair of them), and that's not unreasonable, they really looked nothing
at all like S/360 channels.
 
The 8089 was not a coprocessor like the 8087, it was basically a fully
independent processor that used the same mechanism that a multi-socket
8086 system would use to allow multiple CPUs to share the system bus.
Nor did it implement any instructions* that you could add to your 8086
program. And the 8089 wasn't really tied to the 8086 like the 8087
was).
 
 
*8089 assembler was nothing like 8086, but it was a (rather weird)
general purpose ISA, but heavily biased towards supporting the I/O
functions and the DMA hardware in the 8089. Basically you'd write a
specific program that would be stored in the 8089s address space
(which could be partially independent of the main system address
space) for the 8089 to run, and then use shared memory to set up
control blocks and messages to pass between the main 8086 CPU and the
8089 to handle work - there were also interrupts coming back fro the
8089 and a way to poke the 8089, the later usually mapped to an 8086
I/O port.
Robert Wessel <robertwessel2@yahoo.com>: Apr 19 11:38AM -0500

On Tue, 19 Apr 2016 14:07:29 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
 
>On the other hand, most systems in the late 60's and early 70's had
>limited memory (systems with a million bytes of memory didn't show up
>until the mid 70's).
 
 
There were S/360s which could be equipped with more than 1MB of memory
by the late 60s. I'm having trouble finding a good online source,
since many of these machines had their memory capacity expanded over
their lifetimes, but here's a 1968 article about a 360/91 (which had a
minimum configuration of 1MB, and shipped in 1967) with 2MB:
 
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2091.html
 
IIRC, you could order model 65s, 67s, 75s and 85s (as well as the 91s)
with 1MB (and in some cases more) memory before the 1960s expired.
Vir Campestris <vir.campestris@invalid.invalid>: Apr 19 09:25PM +0100

On 19/04/2016 15:09, Scott Lurndal wrote:
> and useful addressing modes.
 
>> they were on the inside. Possibly put off by PIP and STAT commands. :(
 
> Should have used UnixV6 instead of RSX-11M/RSTS-E.
 
Don't know about the 8 or 11 (though if you want to know, ask on
uk.d-i-y) but I recall the PDP10. First assembler I ever learned. The
first 16 memory locations were the registers, so to copy from register
to register you just set the memory address to a low number.
 
I heard once that they really were registers - to do a fast strchr or
such you should copy your code into the registers and execute it there.
 
Incidentally you could use any of those registers except 0 for a stack -
so if you were so inclined you could have 15 stacks!
 
Andy
jt@toerring.de (Jens Thoms Toerring): Apr 19 10:38PM

> And yes, it is Harvard architecture - the code/flash address space is
> separate from the data/I/O address space, which is a source of great
> irritation to C and C++ programmers.
 
I've just, for the first time, started working with micrcontrollers
with a Harvard architecture (Microchip PIC24F) and was tasked with
writing a bootloader for it. So I guess I'm now aware of what Har-
vard architecture implies, but I'm not really irritated - it's
just having to use functions/special instructions for reading/
writing from/to program memory space. But that's not different
from having to use special functions for I/O ports etc. - and
in "normal", e.g. desktop applications one can't write to pro-
gram space anyway nowadays. So what would a C or C++ program-
mer be greatly irritated about? Just curious;-)
 
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
David Brown <david.brown@hesbynett.no>: Apr 20 12:55AM +0200

On 20/04/16 00:38, Jens Thoms Toerring wrote:
> gram space anyway nowadays. So what would a C or C++ program-
> mer be greatly irritated about? Just curious;-)
 
> Best regards, Jens
 
When you only have a few occasions to access flash data, it's not bad.
But if you have a lot of flash data, it gets annoying to have to use
extra function calls all the time. It gets particularly annoying when
you are using arrays, or when if you have strings, and arrays of strings
(using function calls to find the address of the string in the array,
then another function call to get the data at that address). Much of
this depends on the details of how your particular compiler implements
flash data - some compilers have extensions that make it reasonably simple.
 
And if you ever need functions that might want either data in flash or
data in ram, it gets worse. Often on such devices, you will have a
"strcpy" function for ram to ram, and a "strcpy_p" (or similar name) for
copying from flash to ram.
 
How much of an issue it will be depends on the tasks in hand. It may
also be possible to make useful C++ classes to hide the messy details.
 
In contrast, on microcontrollers you usually don't have special
functions for I/O ports - they are mostly directly mapped in memory, and
you access them as volatile variables at fixed addresses (with addresses
fixed by linker scripts, assembly modules, compiler extensions, or
simply macros that cast an integer literal into a pointer with the right
volatile type and right address).
Jerry Stuckle <jstucklex@attglobal.net>: Apr 19 06:57PM -0400

On 4/18/2016 6:39 PM, Alf P. Steinbach wrote:
> stack, regardless of the implementation details.
 
> Cheers & hth.,
 
> - Alf (nonsense fighter)
 
So then please tell us - how does one implement C on an IBM mainframe -
which does have a stack pointer nore does it support push, pop, call,
return, etc. instructions?
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Apr 19 07:02PM -0400

On 4/18/2016 9:03 PM, Robert Wessel wrote:
 
>> I didn't say the compiler had to generate storage requests to the OS.
 
> I didn't say it either.
 
Then why would it be slow?
 
> (normally used) XPLink convention uses R4 to address a typical
> "hardware-style" stack, and reserves various registers for passing
> parameters and return values.
 
That depends on which compiler you are using. There is no "standard"
(as there is in the R13 save area standard).
 
> MetalC is different, and does use the R13-based linked list by
> default.
 
Yes, it depends on which compiler you are using.
 
>> unique storage area when a function is called.
 
> C does not require a hardware-style stack. It does, for at least some
> programs, require a stack in the general CS sense.
 
Which could be implemented as a linked list, allocated from the heap or
any or a number of different ways.
 
But many people reading this newsgroup are only aware of the X86
processors, and think the X86 stack is the only type there is.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: Apr 19 07:11PM -0400

On 4/18/2016 3:40 PM, David Brown wrote:
> that this is the case for the IBM mainframes you refer to - you have
> worked with them, and I have not. I am just curious what the cpu ISA
> looks like.
 
It really doesn't matter if they can implement a plain stack or not. A
linked list can easily be used (and I was using them in the 80's on IBM
mainframes). There are no push, pop, call, return, etc. instructions,
and no stack pointer register.
 
But if you want to get into the architecture, I suggest you do some
googling. It is readily available (and off topic here).
 
 
> But I don't see how you could have an ISA that has reasonable registers,
> instructions, and addressing modes for working with linked lists, and
> not also be able to use these for accessing a stack.
 
Linked lists can be just as efficient as stacks. They don't take many
instructions. And they do have some advantages - for instance,
libraries could have their own storage area. This way the main program
only has to worry about the storage it needs - not what libraries need.
This was quite important back in the 80's when even mainframes were
limited to 16MB of storage.
 
>> with entirely different instruction sets.
 
> OK. As I said, I am not familiar with the cpus IBM use in their big
> systems, other than the Power processors.
 
Power processors are closer to X86 systems than they are to IBM mainframes.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
somurgeyunus@gmail.com: Apr 19 12:04PM -0700

1. Construct your own library by generating .c and .h files. Your library should include the following functions:
a. sumOfIntegersDivisibleBy3(n) : returns sum of integers divisible by 3 between 1 and n.
b. factorial(n) : returns factorial of the number n
c. power(x,y) : calculates xy
d. isDivisible(x,y) : finds whether x is divisible by y. i.e. isDivisible(35,5) returns 1, isDivisible(32,5) returns 0
2. Write a program that includes your library. In the main function you will have a loop with sentinel continuation condition. You should allow the user to select any of the functions provided by your library to make some calculations. Use switch statement to execute the selected operation. When the user makes a selection, according to the selected operation print some directives to the screen, take arguments from the user and print the result. Then the program should wait for the next selection.
For all coding, you should provide very detailed comments within your code. Please select function names and variable names self-commenting as well. Do not use math standard library functions.
You are encouraged to prepare your functions in pseudocode first. However, this assignment does not require submission of your pseudocodes.
Example user interface should be similar to the following (red entries represent the user inputs):
Please make a selection with the corresponding number of any operation:
1. sumOfIntegersDivisibleBy3
2. factorial
3. power
4. is divisible
9. Exit
3
Please enter two integers x and y to calculate x^y
2 3
Result is: 8
Please make a selection with the corresponding number of any operation:
1. sumOfIntegersDivisibleBy3
2. factorial
3. power
.
.
legalize+jeeves@mail.xmission.com (Richard): Apr 19 07:08PM

[Please do not mail me a copy of your followup]
 
We won't do your homework for you.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Barry Schwarz <schwarzb@dqel.com>: Apr 19 03:17PM -0700

On Tue, 19 Apr 2016 12:04:50 -0700 (PDT), somurgeyunus@gmail.com
wrote:
 
>1. Construct your own library by generating .c and .h files. Your library should include the following functions:
 
You do realize that C and C++ are two different languages?
 
--
Remove del for email
Jens Kallup <jkallup@web.de>: Apr 19 08:19PM +0200

Hello programmers,
 
I searched for a way to code an editor component/application with XLib
functions - native, no special window manager.
I can get display, create window, and map it to screen.
The displaying of text (atm: fixed length) is not the problem.
The problem is, to handle the Events correctly.
So, wenn I push a key that the text move to right, or to left, if DEL
is pressed.
And then the mouse (mark text, and copy it to clipboard)
It would be intressting to open a discussion to this:
- how to start,
- what next ...
and so on.
 
Thanks for helping hands
Jens
jt@toerring.de (Jens Thoms Toerring): Apr 19 08:04PM

> - how to start,
> - what next ...
> and so on.
 
That's much too complex a topic to be covered in a newgroup
posting (and then it would be off-topic to comp.lang.c++).
You'll have to get a book, probably best is Adrian Nye, "Xlib
Programming Manual for Version 11". You'll have to set a mask
for all events you want to receive for a window (and be pre-
pared to deal with not only KeyPress, KeyRelease, ButtonPress,
ButtonRelease and MotionNotify, but also Expose and ResizeRe-
quest events). Then you basically wait in a loop for XEvents
coming in and react to them. The details can be "interesting".
 
Question: why not use one of the existing libraries (Qt, Gtk
and a lot more) that wrap Xlib (and often many others) and
are much easier to use and tend to be better documented as
well? It's about 20 years since I've written a program just
using bare Xlib...
Best regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
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)