Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #235466 > unrolled thread

boxing all integers (was Re: Resources to learn common lisp?)

Back to article view | Back to alt.folklore.computers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  boxing all integers (was Re: Resources to learn common lisp?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-29 17:52 -0300
    Re: boxing all integers (was Re: Resources to learn common lisp?) Alan Bawden <alan@csail.mit.edu> - 2026-08-30 17:24 -0400
      Re: boxing all integers (was Re: Resources to learn common lisp?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-31 03:11 -0300
    origin of XGP fonts (was Re: reprints of old AI memos) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-28 10:44 -0300
      Re: origin of XGP fonts (was Re: reprints of old AI memos) Peter Flass <Peter@Iron-Spring.com> - 2026-09-28 07:33 -0700
        Re: origin of XGP fonts (was Re: reprints of old AI memos) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-28 22:53 +0800

#235466 — boxing all integers (was Re: Resources to learn common lisp?)

Alan Bawden <alan@csail.mit.edu> writes:
> Paul Rubin <no.email@nospam.invalid> writes:
>> All CPython integers are boxed, but small ones (-5 through +250 or
>> something like that) are pre-allocated.  Sounds awful but I think some
>> Lisps also have done that.
>
> For example, PDP-10 MacLisp.  The PDP-10 is a word addressed machine,
> where addresses are 18 bits, and words are 36 bits.  PDP-10 integers are
> 36 bits long, so pretty much your only choice for representing fixnums
> is as an 18-bit pointer to a 36-bit signed integer, i.e. "boxed".

I had no idea!  Never having used it, I had always assumed that MACLISP
shared the behavior of things like SBCL, Smalltalk, and recent versions
of Python — transparently overflowing from fixnums to bignums.

One advantage of the transparent-overflow approach is that most of the
time users don’t care what the actual fixnum limit is — it’s “just” a
performance optimization, in that your arithmetic starts consing when
you exceed the limit.

This does mean, however, that by default, for example on SBCL, all of
your arithmetic is stuffed full of overflow checks, which has
performance costs of its own.

>  • If an intermediate fixnum needs to be allocated, say to pass as an
>    argument to another function, it can be allocated in a special area
>    of memory that has fixnum type, but that is managed as a stack -- the
>    GC doesn't touch it.  That temporary number is then popped out of
>    existence after the function call returns.  This does mean that the
>    compiler has to constantly worry that an object that it is about to
>    store someplace permanent might be a stack allocated "PDL number".
>    The utility that replaces a potential PDL number with a permanent
>    number is named "PDLNMK", and every serious MacLisp programmer knows
>    exactly what it does because it frequently appears in our compiled
>    code.

This is an interesting idea; I imagine it’s a pretty big performance
win, particularly since MACLISP predates generational garbage collection
(and, I imagine, never had it bolted on).  Consing *per se* is pretty
fast in a pointer-bumping allocator; what used to kill you was the GC,
and generational GC largely solved that problem.  Still, I'm pretty sure
that Java, LuaJIT, Chez Scheme, V8, and SpiderMonkey don’t box their
fixnums.

> There's a paper by Guy Steele titled "Fast Arithmetic in MacLisp" that
> describes all these techniques in detail: <hdl.handle.net/1721.1/6279>.

Thank you very much!  I’d never read it.  For the peanut gallery, that’s
AIM-421.pdf, MD5 158106732f63bf268ffe4c1728950710.

Kragen

[toc] | [next] | [standalone]

#235486

Kragen Javier Sitaker <kragen@canonical.org> writes:

> Alan Bawden <alan@csail.mit.edu> writes:
>> For example, PDP-10 MacLisp.  The PDP-10 is a word addressed machine,
>> where addresses are 18 bits, and words are 36 bits.  PDP-10 integers are
>> 36 bits long, so pretty much your only choice for representing fixnums
>> is as an 18-bit pointer to a 36-bit signed integer, i.e. "boxed".
>
> I had no idea!  Never having used it, I had always assumed that MACLISP
> shared the behavior of things like SBCL, Smalltalk, and recent versions
> of Python — transparently overflowing from fixnums to bignums.
>
> One advantage of the transparent-overflow approach is that most of the
> time users don’t care what the actual fixnum limit is — it’s “just” a
> performance optimization, in that your arithmetic starts consing when
> you exceed the limit.

Note that MacLisp _does_ have "transparent-overflow" arithmetic, you
just have to use `PLUS`, `TIMES` and `DIFFERENCE` instead of `+`, `*`
and `-`.  The `+` family is fixnum-only, but the `PLUS` family handles
all types of numbers.

There is also a flonum-only family: `+$`, `*$`, `-$`, etc.

The names `PLUS`, `TIMES`, `DIFFERENCE`, etc. are taken from LISP 1.5,
so you can think of them as the "true" Lisp arithmetic functions.  `+`,
`+$` and friends are just MacLisp extensions for efficient machine
arithmetic.

-- 
Alan Bawden

[toc] | [prev] | [next] | [standalone]

#235488

Alan Bawden <alan@csail.mit.edu> writes:
> Kragen Javier Sitaker <kragen@canonical.org> writes:
>> I had no idea!  Never having used it, I had always assumed that MACLISP
>> shared the behavior of things like SBCL, Smalltalk, and recent versions
>> of Python — transparently overflowing from fixnums to bignums.
>
> Note that MacLisp _does_ have "transparent-overflow" arithmetic, you
> just have to use `PLUS`, `TIMES` and `DIFFERENCE` instead of `+`, `*`
> and `-`.  The `+` family is fixnum-only, but the `PLUS` family handles
> all types of numbers.

I see!  Thank you for explaining.

Kragen

[toc] | [prev] | [next] | [standalone]

#235709 — origin of XGP fonts (was Re: reprints of old AI memos)

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> Kragen Javier Sitaker wrote:
>> I wonder where they [the XGP fonts] came from?
>
> I read a story somwhere, but I forgot the details and where I found it.
> It was something like getting a font catalog from a major foundry and
> digitizing it by hand.
>
> People also made their own; the AST file format is just a text file with
> pixel data, and on ITS there's FED (font "editor") to display a font on
> the 340 or a Knight TV.  I think SAIL had something else, certaily so
> when TeX and Metafont were developed.
>
> "The Last Whole XGP Font Catalog" (play on "Last Whole Earth Catalog")
> has a lot to say about the XGP.

I was reading Butler Lampson’s 01988 retrospective on the Alto today
<https://dl.acm.org/doi/abs/10.1145/61975.66921> and he answered this
question:

: The first imager, written by Peter Deutsch, drove the Xerox Graphics
: Printer.  This machine is slow (five pages/minute) and low resolution
: (200 dots/inch); it is also asynchronous, so the imager can take as
: long as it likes to generate each line of the raster. Only crude
: imaging software was developed for it, together with a few fonts.
: Raster fonts were unheard of at the time, except in 5 × 7 and 7 × 9
: resolution for terminals, or at very high resolution for expensive
: photo-typesetters. The XGP fonts were developed entirely manually,
: using an editor that allows the operator to turn individual dots in
: the roughly 20 × 20 matrix on and off. They had to be new designs,
: since it is impractical to faithfully copy a printer’s font at such
: low resolution. These XGP fonts were later widely used in
: universities.


Kragen

[toc] | [prev] | [next] | [standalone]

#235710 — Re: origin of XGP fonts (was Re: reprints of old AI memos)

On 9/28/26 06:44, Kragen Javier Sitaker wrote:
> Lars Brinkhoff <lars.spam@nocrew.org> writes:
>> Kragen Javier Sitaker wrote:
>>> I wonder where they [the XGP fonts] came from?
>>
>> I read a story somwhere, but I forgot the details and where I found it.
>> It was something like getting a font catalog from a major foundry and
>> digitizing it by hand.
>>
>> People also made their own; the AST file format is just a text file with
>> pixel data, and on ITS there's FED (font "editor") to display a font on
>> the 340 or a Knight TV.  I think SAIL had something else, certaily so
>> when TeX and Metafont were developed.
>>
>> "The Last Whole XGP Font Catalog" (play on "Last Whole Earth Catalog")
>> has a lot to say about the XGP.
> 
> I was reading Butler Lampson’s 01988 retrospective on the Alto today
> <https://dl.acm.org/doi/abs/10.1145/61975.66921> and he answered this
> question:
> 
> : The first imager, written by Peter Deutsch, drove the Xerox Graphics
> : Printer.  This machine is slow (five pages/minute) and low resolution
> : (200 dots/inch); it is also asynchronous, so the imager can take as
> : long as it likes to generate each line of the raster. Only crude
> : imaging software was developed for it, together with a few fonts.
> : Raster fonts were unheard of at the time, except in 5 × 7 and 7 × 9
> : resolution for terminals, or at very high resolution for expensive
> : photo-typesetters. The XGP fonts were developed entirely manually,
> : using an editor that allows the operator to turn individual dots in
> : the roughly 20 × 20 matrix on and off. They had to be new designs,
> : since it is impractical to faithfully copy a printer’s font at such
> : low resolution. These XGP fonts were later widely used in
> : universities.
> 
> 

The SAIL fonts were, at one point, available from one of the PC 
shareware sites. I imagine they are still kicking around somewhere. I 
played with them at one time, I think the major obstacle is that they 
were (IIRC) 200dpi.

[toc] | [prev] | [next] | [standalone]

#235711 — Re: origin of XGP fonts (was Re: reprints of old AI memos)

On 9/28/2026 10:33 PM, Peter Flass wrote:
> On 9/28/26 06:44, Kragen Javier Sitaker wrote:
>> Lars Brinkhoff <lars.spam@nocrew.org> writes:
>>> Kragen Javier Sitaker wrote:
>>>> I wonder where they [the XGP fonts] came from?
>>>
>>> I read a story somwhere, but I forgot the details and where I found it.
>>> It was something like getting a font catalog from a major foundry and
>>> digitizing it by hand.
>>>
>>> People also made their own; the AST file format is just a text file with
>>> pixel data, and on ITS there's FED (font "editor") to display a font on
>>> the 340 or a Knight TV.  I think SAIL had something else, certaily so
>>> when TeX and Metafont were developed.
>>>
>>> "The Last Whole XGP Font Catalog" (play on "Last Whole Earth Catalog")
>>> has a lot to say about the XGP.
>>
>> I was reading Butler Lampson’s 01988 retrospective on the Alto today
>> <https://dl.acm.org/doi/abs/10.1145/61975.66921> and he answered this
>> question:
>>
>> : The first imager, written by Peter Deutsch, drove the Xerox Graphics
>> : Printer.  This machine is slow (five pages/minute) and low resolution
>> : (200 dots/inch); it is also asynchronous, so the imager can take as
>> : long as it likes to generate each line of the raster. Only crude
>> : imaging software was developed for it, together with a few fonts.
>> : Raster fonts were unheard of at the time, except in 5 × 7 and 7 × 9
>> : resolution for terminals, or at very high resolution for expensive
>> : photo-typesetters. The XGP fonts were developed entirely manually,
>> : using an editor that allows the operator to turn individual dots in
>> : the roughly 20 × 20 matrix on and off. They had to be new designs,
>> : since it is impractical to faithfully copy a printer’s font at such
>> : low resolution. These XGP fonts were later widely used in
>> : universities.
>>
>>
> 
> The SAIL fonts were, at one point, available from one of the PC 
> shareware sites. I imagine they are still kicking around somewhere. I 
> played with them at one time, I think the major obstacle is that they 
> were (IIRC) 200dpi.

A slight tangent on the discussion of pixel fonts.  I seem to recall
reading the Microsoft's .FON specification -- I don't know if it's
still available on their website, but no matter -- and it supported
coloured fonts.  I don't recall if each individual pixel was colour-
able, or just the character, or the whole set.

It seems nobody ever used this, not even Microsoft.

Other than video games, I don't know anyone using two or more colours
per character in a pixel font.


Does alt.folklore.computers know better?
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via XS News
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [standalone]

Back to top | Article view | alt.folklore.computers

csiph-web