PiDP-8/I SoftwareCheck-in [cb743198fd]
Not logged in

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fleshed out the discussion of malloc() in the CC8 manual, turning it into a new sub-section, "Fun Trivia: The History of malloc()".
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | cc8-octal-output
Files: files | file ages | folders
SHA3-256:cb743198fd6ad249dfe80ff2a6004376f517b93383c398c2cd3987a9347e8dc1
User & Date: tangent 2019-02-22 11:40:54
Context
2019-03-17
04:51
Merged in trunk improvements Closed-Leaf check-in: 9492282084 user: tangent tags: cc8-octal-output
2019-02-22
11:40
Fleshed out the discussion of malloc() in the CC8 manual, turning it into a new sub-section, "Fun Trivia: The History of malloc()". check-in: cb743198fd user: tangent tags: cc8-octal-output
11:12
Found malloc() in UNIX V7, so added that info to the CC8 manual's poin on "no malloc() in CC8". check-in: 4b64cfdc4c user: tangent tags: cc8-octal-output
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to doc/cc8-manual.md.

1504
1505
1506
1507
1508
1509
1510



1511
1512
1513

1514






1515
1516
1517
1518
1519
1520
1521











1522
1523
1524


1525
1526
1527
1528
1529
1530
1531
There is no `malloc()` in this C library and no space reserved for its
heap in [the user data field](#udf). Everything in a CC8 program is
statically-allocated, if you’re using stock C-level mechanisms. If your
program needs additional dynamically-allocated memory, you’ll need to
arrange access to it some other way, such as [via inline
assembly](#asm).




(Fun trivia: there is no “`malloc()`” in K&R C, either, at least as far
as the first edition of “[The C Programming Language”][krc] goes. Early
in the book they give a simple function called `alloc()` that just

divvied up a large static `char[]` array for its callers. Then in an






appendix, they give a smarter alternative based on the old Unix syscall
[`sbrk(2)`][sbrk]. The impression given is that memory allocation isn’t
part of the language, it’s part of the operating system, and different
implementations of C were expected to provide this facility in local
ways. In the roughly contemporaneous UNIX V7, there *is* a `malloc()`
implementation in its `libc` that works on the same basic principles,
though if K&R `alloc()` is the ancestor of V7 `malloc()`, there’s a long











evolutionary chain between them.)

[sbrk]: https://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html




### <a id="vonn"></a>There Are No Storage Type Distinctions

It may surprise you to learn that literals are placed in the same field
as globals and the call stack.








>
>
>
|
|
|
>
|
>
>
>
>
>
>
|
|
|
|
<
<
<
>
>
>
>
>
>
>
>
>
>
>
|


>
>







1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528



1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
There is no `malloc()` in this C library and no space reserved for its
heap in [the user data field](#udf). Everything in a CC8 program is
statically-allocated, if you’re using stock C-level mechanisms. If your
program needs additional dynamically-allocated memory, you’ll need to
arrange access to it some other way, such as [via inline
assembly](#asm).


#### Fun Trivia: The History of `malloc()`

There is no “`malloc()`” in K&R C, either, at least as far as the first
edition of “[The C Programming Language”][krc] goes. About halfway into
the book they give a simple function called `alloc()` that just
determined whether the requested amount of space was available within a
large static `char[]` array it managed for its callers. If so, it
advanced the pointer that much farther into the buffer and returned that
pointer. The corresponding `free()` implementation just chopped the
globally-allocated space off again, so if you called that `alloc()`
twice and freed the first pointer, the second would be invalid, too!

Then in Appendix A, Kernighan & Ritchie give a much smarter alternative
based on the old Unix syscall [`sbrk(2)`][sbrk]. The impression given is
that memory allocation isn’t part of the language, it’s part of the
operating system, and different implementations of C were expected to
provide this facility in local ways.




[V6 UNIX][v6ux] preceded K&R C by several years, and there is no
`malloc()` there, either. There’s an `alloc()` implementation in its
`libc` that’s scarcely more complicated than the `char[]` based one
first presented in K&R. There is no `free()` in V6: new allocations just
keep extending the amount of core requested.

`malloc()` apparently first appeared about a year after K&R was
published, in [V7 UNIX][v7ux]. It and its corresponding `free()` call
are based on similar techniques to the `sbrk()`-based `alloc()` and
`free()` published in K&R Appendix A, though clearly with quite a lot of
evolution between the two.

[sbrk]: https://pubs.opengroup.org/onlinepubs/7908799/xsh/brk.html
[v6ux]: https://en.wikipedia.org/wiki/Version_6_Unix
[v7ux]: https://en.wikipedia.org/wiki/Version_7_Unix


### <a id="vonn"></a>There Are No Storage Type Distinctions

It may surprise you to learn that literals are placed in the same field
as globals and the call stack.