6502.org

Posted: **Mon Aug 25, 2025 7:09 pm**

barnacle wrote:

Could always use int128_t...

That sounds like another number type.

Posted: **Tue Aug 26, 2025 12:04 am**

BigDumbDinosaur wrote:

BigEd wrote:

paragraph?

I've seen references to a paragraph in the past, but they were usually for a range of 1K or 4K bytes.

I'm curious where else this term was used besides x86-land! I'd go with "paragraph" for familiarity's sake, but if not, "sentence" seems a fitting choice

Posted: **Tue Aug 26, 2025 12:22 am**

Google tells me that would be a centumvigintioctet.

"paragraph" seems to be the standard term for 16 bytes, I've encountered it in various places for at least a couple of decades. It does appear to originate in 80x86 memory segmentation, but I've seen it used in refering to blocks in IP headers and things like that.

Posted: **Tue Aug 26, 2025 2:05 am**

super long long double

Posted: **Tue Aug 26, 2025 2:12 am**

I'm pretty sure that the VAX architecture called it an octaword.

Posted: **Tue Aug 26, 2025 2:16 am**

jgharston wrote:

Google tells me that would be a centumvigintioctet.

That kinda sounds like a brain tumor.

barrym95838 wrote:

I'm pretty sure that the VAX architecture called it an octaword.

Sounds like a sea creature.

Posted: **Tue Aug 26, 2025 4:25 am**

It maybe not be sexy, or amusing, but "hexadecabyte" would be accurate and within the normative nomenclature. What ever TF that means.

Posted: **Tue Aug 26, 2025 2:12 pm**

I had a quick search for units which are 16 times bigger than some subunit, and found

Balthazar is 16 bottles
Pound is 16 ounces
Kilderkin was originally 16 ale gallons
Rundlet barrel is 16 gallons
Tun wine barrel was sometimes 16 Kilderkin
jīn or catty (or kati) is 16 tael or liǎng (weight) (or in Vietnamese, cân is 16 lạng)

Posted: **Tue Aug 26, 2025 5:36 pm**

BigEd wrote:

Balthazar is 16 bottles

Reminds me of my Navy days and the speed at which the average sailor could consume beer.

BTW, this fixation on a name for a 16-byte whatever comes from a piece of software on which I am working that maintains a table containing information about detected devices on my POC unit’s SCSI bus. In organizing the table, I decided to make the “slot” size for each device an even multiple of 16 bytes, which simplifies debugging. The smallest amount of memory that Supermon 816 can dump is 16 bytes, so defining a slot size as a multiple of 16 bytes makes looking at a slot’s content a shorter dump command—less typing.

In order to automate the creation of the device table slot size to an even 16 bytes, I came up with a gawdawful bit of code, which is near the end of the below table structure definitions:

Code: Select all

;===============================================================================
;
;DEVICE INFORMATION STORAGE DEFINITIONS
;
s_dibsiz =s_word                  ;field size: block size
s_diflag =s_word                  ;field size: status flag
s_dibyts =s_lword                 ;field size: total bytes
s_dimodl =s_sspid+s_byte          ;field size: model
s_disern =s_sernm+s_byte          ;field size: serial number
s_ditype =s_word                  ;field size: type
s_divend =s_vendr+s_byte          ;field size: vendor
;
;	—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;	Basic Inquiry Structure Fields
;	—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;
o_bqvend =0                       ;vendor
o_bqmodl =o_bqvend+s_divend       ;model
;
;	—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;	Device Info Structure Fields
;	—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;
o_diflag =0                       ;status flag...
;
;			x0000000x0000000
;			|       |
;			+———————+——————————> 1: active device
;
o_ditype =o_diflag+s_diflag       ;type
o_divend =o_ditype+s_ditype       ;vendor
o_dimodl =o_divend+s_divend       ;model
o_disern =o_dimodl+s_dimodl       ;serial number
o_diblkt =o_disern+s_disern       ;total blocks
o_diblku =o_diblkt+s_sdcap        ;usable blocks
o_diblkf =o_diblku+s_sdcap        ;free blocks
o_dibsiz =o_diblkf+s_sdcap        ;block size
o_dibyts =o_dibsiz+s_dibsiz       ;total bytes
o_di_end =o_dibyts+s_dibyts       ;end of structure
;
;	—-—-—-—-—-—-—-—
;	Structure Sizes
;	—-—-—-—-—-—-—-—
;
s_bqslot =o_bqmodl+s_dimodl       ;basic inquiry
;
s_dlslot =o_di_end+{{16-{o_di_end@16}}*{{o_di_end@16}!=0}} ;...  <<<———
;
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;			The above expression rounds the device info slot
;			size up to a multiple of 16 bytes for debugging
;			convenience.
;			—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-—-
;
s_ditab  =s_dlslot*n_scsiid       ;size of device info table

In the Kowalski assembler, the curly braces ({ }) are the equivalent of parentheses in algebraic expressions. The @ in o_di_end@16 is the symbol for modulus. s_dlslot is the resulting slot size, rounded up to a multiple of 16 bytes. That is just begging to be a macro...

My dilemma came in adding a comment to the source code to describe what was going on...I couldn’t seem to conjure a word to refer to a 16-byte chunk of memory.

BTW, I also have similar concoctions for aligning data structures to even words, double words and pages, again to simplify debugging. Because I use them so much, they are all defined in macros.

Code: Select all

wrdalign .macro                ;word-align program counter
         *=*+{{*@2}!=0}
         .endm

dwalign  .macro                ;double word-align program counter
         *=*+{{4-{*@4}}*{{*@4}!=0}}
         .endm

pagalign .macro                ;page-align program counter
         *=*+{{256-{*@256}}*{{*@256}!=0}}
         .endm

Posted: **Tue Aug 26, 2025 6:14 pm**

BigDumbDinosaur wrote:

Code: Select all

s_dlslot =o_di_end+{{o_di_end/16}*{{o_di_end@16}!=0}} ;...  <<<———

In the Kowalski assembler, the curly braces ({ }) are the equivalent of parentheses in algebraic expressions. The @ in o_di_end@16 is the symbol for modulus. s_dlslot is the resulting slot size, rounded up to the nearest 16 bytes. That is just begging to be a macro...

I still can't quite work out what that line does, it is not very similar to the other assignment examples you posted, are you sure it is correct?

I would have probably have written it as " (x+15) & ~15 " but perhaps those operators are not available in the assembler. Maybe " 16 * {{x+15} / 16} " would work though?

Quote:

Code: Select all

dwalign  .macro                ;double word-align program counter
         *=*+{{32-{*@32}}*{{*@32}!=0}}
         .endm

I think those are meant to be 4 as well.

Posted: **Tue Aug 26, 2025 6:39 pm**

gfoot wrote:

BigDumbDinosaur wrote:

Code: Select all

s_dlslot =o_di_end+{{o_di_end/16}*{{o_di_end@16}!=0}} ;...  <<<———

I still can't quite work out what that line does, it is not very similar to the other assignment examples you posted, are you sure it is correct?

It is correct—I’ve used the algorithm in several places.

All it does is figure out if o_di_end, the size of a slot, is evenly divisible by 16 and if not, adds to the slot size to bring it up to a 16-byte multiple.

Quote:

I would have probably have written it as " (x+15) & ~15 " but perhaps those operators are not available in the assembler. Maybe " 16 * {{x+15} / 16} " would work though?

Depends on what the expression ~15 means. In the Kowalski assembler, that would evaluate as 4,294,967,280, as the unary operator ~ would exclusive-OR 15 with $FFFFFFFF (internally, all labels and symbols are 32-bit, unsigned quantities).

Quote:

Code: Select all

dwalign  .macro                ;double word-align program counter
         *=*+{{32-{*@32}}*{{*@32}!=0}}
         .endm

I think those are meant to be 4 as well.

Yer right! I copied the wrong thing.

Posted: **Tue Aug 26, 2025 7:47 pm**

Oh, how about "line"

Posted: **Tue Aug 26, 2025 8:47 pm**

BigDumbDinosaur wrote:

It is correct—I’ve used the algorithm in several places.

I don't think it's right either. Have a closer look - it does not do what you're claiming. If o_di_end is not a multiple of 16, it's adding o_di_end/16. That's only going to give you a multiple of 16 for a few values, by coincidence.

Perhaps you meant o_di_end + (16 - o_di_end@16)*((o_di_end@16) != 0). That's still a round-about way of doing things. I would also go with one of gfoot's alternatives - they're the idiomatic ways of rounding up to a multiple.

The comment is misleading too. The word "nearest" has no place here: it's rounding up to a multiple of 16 (or it should be). 34 should round up to 48, despite 32 being the nearest multiple of 16.

Posted: **Wed Aug 27, 2025 4:25 am**

barrym95838 wrote:

I'm pretty sure that the VAX architecture called it an octaword.

This is from people who measured time in microfortnights.

Seriously, I loved DEC minicomputers. Never used a PDP-11 much, but enough to have bought a PiDP-11 kit. Still have to allocate the time to build it. I drool over the PiDP-8 and especially the PiDP-10.
Some day...

The PDP-10 was the first "real" computer I ever used. That was in my freshman year of college, then they replaced it with a VAX 11/780. There was supposedly a "star trek" game which showed up on that system. When you started it up, the number and size of the ships in your fleet would vary. Later, it was discovered that the ships depended on the files in your account and when you lost a ship, the corresponding file was deleted. That program supposedly did not survive very long once that little fact was discovered. I still wonder whether that was an urban legend or real.

Because of all of the time I spent programming DOS and 16-bit Windows, a paragraph is 16 bytes.

Posted: **Wed Aug 27, 2025 5:29 am**

John West wrote:

BigDumbDinosaur wrote:

It is correct—I’ve used the algorithm in several places.

I don't think it's right either. Have a closer look - it does not do what you're claiming. If o_di_end is not a multiple of 16, it's adding o_di_end/16. That's only going to give you a multiple of 16 for a few values, by coincidence.

Perhaps you meant o_di_end + (16 - o_di_end@16)*((o_di_end@16) != 0). That's still a round-about way of doing things.

I apologize for this mess. One of the blessings (?) of old age is deteriorating vision. I am having increasing problems with reading that the ophthalmologist has been unable solve with different glasses. When I copied and pasted that, I evidently grabbed the wrong line of code (it was in a file I was using for testing). The correct line, which does work, is now in my post.

This vision thing has tripped me up a number of times, e.g., TXY when I meant TYX, etc.. I often simply can’t see the error and unless the assembler catches it due to it being a nonsense instruction or pseudo-op, it sneaks into the code. As of late, I seem to be spending more debugging time fixing typos than actually fixing bugs.

Quote:

I would also go with one of gfoot's alternatives - they're the idiomatic ways of rounding up to a multiple.

The XOR operation in the Kowalski assembler operates on 32 bits. It can’t be directly used as gfoot illustrated. Something such as <{~15} might work, but I haven’t tried it.

Quote:

The comment is misleading too. The word "nearest" has no place here: it's rounding up to a multiple of 16 (or it should be). 34 should round up to 48, despite 32 being the nearest multiple of 16.

Yer right on that. It’s a “round up to” operation, not “nearest.”

6502.org

IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME

Re: IN SEARCH OF A NAME