PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking machine-dependent mappings (such as character string over binary integer) and the like. Of course, >this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and >Unicode have largely eaten the world. Compare that to the madness in IBM’s eight pre-360
product families >alone.
(Sorry, I lost the context on this post)
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking
machine-dependent mappings (such as character string over binary
integer) and the like. Of course, >this is largely a dead issue
today, since two's-complement integers of size 2^n bits, IEEE
floating point, and >Unicode have largely eaten the world.
Compare that to the madness in IBM’s eight pre-360 product
families >alone.
Of course there were problems with this, also. It was vey simple to
shoot yourself in the foot and code something the machine didn’t
support. I think multicians.org has a story about how a misaligned
structure caused horrendous inefficiency. Something as simple as
reorganizing the fields (forgot the details) solved the problem.
(Sorry, I lost the context on this post)
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking machine-dependent
mappings (such as character string over binary integer) and the like. Of
course, >this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and >Unicode have largely
eaten the world. Compare that to the madness in IBM’s eight pre-360
product families >alone.
Of course there were problems with this, also. It was vey simple to shoot yourself in the foot and code something the machine didn’t support. I think multicians.org has a story about how a misaligned structure caused
horrendous inefficiency. Something as simple as reorganizing the fields (forgot the details) solved the problem.
On 11/7/20 1:45 PM, Peter Flass wrote:.
(Sorry, I lost the context on this post)
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking machine-dependent
mappings (such as character string over binary integer) and the like. Of >> course, >this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and >Unicode have largely >> eaten the world. Compare that to the madness in IBM’s eight pre-360
product families >alone.
Of course there were problems with this, also. It was vey simple to shoot yourself in the foot and code something the machine didn’t support. I think
multicians.org has a story about how a misaligned structure caused horrendous inefficiency. Something as simple as reorganizing the fields (forgot the details) solved the problem.
COBOL had the same problem; it really follows logically in any language
that has structures, though newer languages, from C to Swift, seem
simply to ignore it—I suppose it’s just assumed that everything gets aligned willy-nilly. (And, of course, PL/I is the only language that has bitstrings, which are where the effects of unalighment are most hideous.
On 11/7/20 1:45 PM, Peter Flass wrote:
(Sorry, I lost the context on this post)
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking machine-dependent
mappings (such as character string over binary integer) and the like. Of >> course, >this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and >Unicode have largely >> eaten the world. Compare that to the madness in IBM’s eight pre-360
product families >alone.
Of course there were problems with this, also. It was vey simple to shoot yourself in the foot and code something the machine didn’t support. I think
multicians.org has a story about how a misaligned structure caused horrendous inefficiency. Something as simple as reorganizing the fields (forgot the details) solved the problem.
COBOL had the same problem; it really follows logically in any language
that has structures, though newer languages, from C to Swift, seem
simply to ignore it—I suppose it’s just assumed that everything gets aligned willy-nilly. (And, of course, PL/I is the only language that has bitstrings, which are where the effects of unalighment are most hideous.
On Sat, 7 Nov 2020 11:45:12 -0700, Peter Flass <p......@yahoo.com>.
wrote about PL/I machine independence:
(Sorry, I lost the context on this post)It was posted by John W. Kennedy, with whom I used to exchange
messages on the old IBM PC Co. BBS in Atlanta, more than 25 years ago.
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking
machine-dependent mappings (such as character string over binary
integer) and the like. Of course, >this is largely a dead issue
today, since two's-complement integers of size 2^n bits, IEEE
floating point, and >Unicode have largely eaten the world.
Compare that to the madness in IBM’s eight pre-360 product
families >alone.
Of course there were problems with this, also. It was vey simple to
shoot yourself in the foot and code something the machine didn’t support. I think multicians.org has a story about how a misaligned structure caused horrendous inefficiency. Something as simple as reorganizing the fields (forgot the details) solved the problem.
MULTICS ran on the GE-645 and its descendants. These were 36-bit word addressable machines that distinguished between bytes and characters. Accessing bytes and characters within words required either tally.
driver words or Extended Instruction Set (EIS) instructions.
These
suffered some serious performance issues -- tally driver words were excruciatingly slow. Consequently, aligning data items within
structures was of paramount importance.
[For the curious: a byte was a 9-bit field that held an ASCII or
EBCDIC character with a visible parity bit (if wanted), while a
character was a 6-bit field holding a GBCD or HBCD character.]
On 11/7/20 1:45 PM, Peter Flass wrote:
(Sorry, I lost the context on this post)
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking machine-dependent
mappings (such as character string over binary integer) and the like. Of >>> course, >this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and >Unicode have largely >>> eaten the world. Compare that to the madness in IBM’s eight pre-360
product families >alone.
Of course there were problems with this, also. It was vey simple to shoot
yourself in the foot and code something the machine didn’t support. I think
multicians.org has a story about how a misaligned structure caused
horrendous inefficiency. Something as simple as reorganizing the fields
(forgot the details) solved the problem.
COBOL had the same problem; it really follows logically in any language
that has structures, though newer languages, from C to Swift, seem
simply to ignore it—I suppose it’s just assumed that everything gets aligned willy-nilly. (And, of course, PL/I is the only language that has bitstrings, which are where the effects of unalighment are most hideous.
get |fortune377 I/O error: smart remark generator failed
In article <R.....@giganews.com>,.
John W Kennedy <j.....@gmail.com> writes:
On 11/7/20 1:45 PM, Peter Flass wrote:
(Sorry, I lost the context on this post)
PL/I put a great deal more effort into making data declarations
universal, by specifying exact precisions, >blocking machine-dependent >>> mappings (such as character string over binary integer) and the like. Of >>> course, >this is largely a dead issue today, since two's-complement
integers of size 2^n bits, IEEE floating point, and >Unicode have largely
eaten the world. Compare that to the madness in IBM’s eight pre-360 >>> product families >alone.
Of course there were problems with this, also. It was vey simple to shoot >> yourself in the foot and code something the machine didn’t support. I think
multicians.org has a story about how a misaligned structure caused
horrendous inefficiency. Something as simple as reorganizing the fields >> (forgot the details) solved the problem.
COBOL had the same problem; it really follows logically in any language that has structures, though newer languages, from C to Swift, seem
simply to ignore it—I suppose it’s just assumed that everything gets aligned willy-nilly. (And, of course, PL/I is the only language that has bitstrings, which are where the effects of unalighment are most hideous.
C (and compatibles) can have padding in a structure for alignment..
The actual size of a structure includes sufficient padding so that.
each of an array of structures would be aligned. You can order your
fields with the most stringent alignment requirements first, and
probably minimize interior padding, but odds are there will be some
padding at the end. Some compilers may provide additional magic for unaligned where that's supported (if with some performance hit), but
they don't have to, and magic isn't portable without lots of conditional preprocessor directives. If you really want a portable external form, you end up using some library that will convert to a standardized
serialized form. Java definitely includes such capabilities; but
libraries like XDR (part of ONC/RPC aka SunRPC) can perform a similar function for C, etc.
But the whole point of a low-level language is that it's up to you to NOT shoot yourself in the foot.
If you want both performance and a portable.
external representation, except for Java you're going to have to work at it a little. And in C (and C++ etc) in particular, most types don't necessarily have a portable size, except that char is pretty much always an 8-bit byte nowadays, and sizeof(long long) >= sizeof(long) >= sizeof(int) >= sizeof(short).
ILP32 (ints, longs, and pointers all 32-bit) is common on 32-bit systems, and
LP64 (longs and pointers 64-bit) is common on 64-bit systems, but other arrangements are possible.
Unfortunately, C does not natively support BCD (which can be better when you want to avoid rounding errors in the decimal representation), although it can be done with an appropriate library...
which makes every operation a
function call. C++ can at least provide the syntactic sugar to hide such details.
On Sunday, December 6, 2020 at 3:27:31 PM UTC+11, Richard L. Hamilton wrote=
:
In article <R.....@giganews.com>,t=20
John W Kennedy <j.....@gmail.com> writes:=20
On 11/7/20 1:45 PM, Peter Flass wrote:=20
(Sorry, I lost the context on this post)=20
=20
PL/I put a great deal more effort into making data declarations=20
universal, by specifying exact precisions, >blocking machine-dependen=
Of=20mappings (such as character string over binary integer) and the like.=
=20course, >this is largely a dead issue today, since two's-complement=
gely=20integers of size 2^n bits, IEEE floating point, and >Unicode have lar=
re-360=20eaten the world. Compare that to the madness in IBM=E2=80=99s eight p=
oot=20product families >alone.=20=20
Of course there were problems with this, also. It was vey simple to sh=
port. I think=20yourself in the foot and code something the machine didn=E2=80=99t sup=
s=20multicians.org has a story about how a misaligned structure caused=20
horrendous inefficiency. Something as simple as reorganizing the field=
=20(forgot the details) solved the problem.=20=20
=20
COBOL had the same problem; it really follows logically in any language=
erything gets=20that has structures, though newer languages, from C to Swift, seem=20
simply to ignore it=E2=80=94I suppose it=E2=80=99s just assumed that ev=
s=20aligned willy-nilly. (And, of course, PL/I is the only language that ha=
.bitstrings, which are where the effects of unalighment are most hideous=
.
C (and compatibles) can have padding in a structure for alignment.=20.
So can PL/I.
.
The actual size of a structure includes sufficient padding so that=20=20
each of an array of structures would be aligned. You can order your=20
fields with the most stringent alignment requirements first, and=20
probably minimize interior padding, but odds are there will be some=20
padding at the end. Some compilers may provide additional magic for=20
unaligned where that's supported (if with some performance hit), but=20
they don't have to, and magic isn't portable without lots of conditional=
preprocessor directives. If you really want a portable external form, you==20
end up using some library that will convert to a standardized=20=20
serialized form. Java definitely includes such capabilities; but=20
libraries like XDR (part of ONC/RPC aka SunRPC) can perform a similar=20
function for C, etc.=20
=20
But the whole point of a low-level language is that it's up to you to NOT=
shoot yourself in the foot..
As it is with any language, high or low.
.
If you want both performance and a portable.it=20
external representation, except for Java you're going to have to work at =
a little. And in C (and C++ etc) in particular, most types don't necessar=ily=20
have a portable size, except that char is pretty much always an 8-bit byt=e=20
nowadays, and sizeof(long long) >=3D sizeof(long) >=3D sizeof(int) >=3D s=izeof(short).=20
ILP32 (ints, longs, and pointers all 32-bit) is common on 32-bit systems,=and=20
LP64 (longs and pointers 64-bit) is common on 64-bit systems, but other==20
arrangements are possible.=20you=20
=20
Unfortunately, C does not natively support BCD (which can be better when =
want to avoid rounding errors in the decimal representation), although it==20
can be done with an appropriate library...
Why bother? PL/I has BCD.
Not every system has a PL/I compiler. Too bad. Some things, like area variables,
seem kind of cool to me. (one could create similar functionality in other languages, but I have yet to find a good implementation of what amounts to sub-allocation within a larger space)
On 2020-12-15 02:20, Richard L. Hamilton wrote:
Not every system has a PL/I compiler. Too bad. Some things, like area variables,
seem kind of cool to me. (one could create similar functionality in other
languages, but I have yet to find a good implementation of what amounts to >> sub-allocation within a larger space)
AREA variables are extremely useful, and in the last few years they've become even more useful thanks to two RFE's filled by yours truly,
<https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=31632> and <https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=100073>
which are especially effective when working with XML or JSON generated list and
tree structures, instead of having to free these item by item, a simple "area =
empty();" statement, which translates to just a single MVC removes the entire list/tree.
And for what it's worth, it should be relatively easy to implement the equivalent of AREA variables in other languages, especially if you restrict yourself to only allocating consecutive chunks, which is what the "ALLOCNEXT" builtin does.
AREA variables are preceded by a 16-byte area containing the start of a linked
list that keeps track of the free chunks and a bit more:
dcl 1 * union,
2 my_area area (1000), /* Actual area */
2 ar_ea, /* Internal structure */
3 use_list bit (1), /* Free list in use */
3 filler char (3),
3 nab fixed bin (31), /* Next available byte */
3 ffree fixed bin (31), /* Offset of first free byte */
3 eol fixed bin (31), /* Always 0, end of free list */
3 contents char (1000); /* Contents */
"nab" and "ffree" are relative to the start of "contents". I'll see if I can find the small program I used the above in.
Sadly, "ALLOCNEXT" returns "sysnull" is there is no space in the area, rather than signalling the "AREA" condition. If it would have done the latter, which I
simulated in my code, the process of building lists/trees in "CONTROLLED" AREA
variables could have been made even easier.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 437 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 181:24:54 |
| Calls: | 9,133 |
| Files: | 13,428 |
| Messages: | 6,034,561 |