On Tuesday, July 11, 2023 at 1:07:25 PM UTC+3, Terje Mathisen wrote:
> Michael S wrote:
> > On Monday, July 10, 2023 at 11:16:50 PM UTC+3, Scott Lurndal wrote:
> >> Michael S <already...@yahoo.com> writes:
> >>> On Monday, July 10, 2023 at 8:25:48=E2=80=AFPM UTC+3, Scott Lurndal wrote:
> >>>> Stephen Fuld <sf...@alumni.cmu.edu.invalid> writes:=20
> >>>>> On 7/10/2023 2:33 AM, Terje Mathisen wrote:=20
> >>>>>> John Levine wrote:=20
> >>>> =20
> >>>>>>> Cache? What's a cache? The PC was shipped in 1981 and the first=20
> >>>>>>> general purpose CPU chips I know with a cache were the 68030 in 1987=
> >>> =20
> >>>>>>> and i486 in 1989.=20
> >>>>>> =20
> >>>>>> That 486 had a combined code/data cache of just 8 KB, and that was sti=
> >>> ll=20
> >>>>>> enough to make a huge difference:=20
> >>>>> =20
> >>>>> Yup. Since we all know that increasing cache size is a diminishing=20
> >>>>> returns game,
> >>>> Is it? LLC is getting bigger (and wider as core counts increase)=20
> >>>> annually.=20
> >>>
> >>> Look at LLC per core.
> >>> Intel Penryn (2007) had 3 MB of L2 per core.
> >>> AMD Zen4 (2022) has 4 MB of L3 per core.
> >>> So 30% increase in 15 years. And even that moderate increase is not free
> >>> in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it's
> >>> more like 6-7 ns.
> >> Now also factor in the increase in core counts (> 100).
> >>
> >
> > In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.
> > The rest of increase in core count is due to MCM packaging rather than
> > Moore's law.
> >
> > In Intel's case, they had 28-core die in commercial product back in 2017.
> > I think, their latest and greatest Xeon has only 15 cores per die plus 1 spare.
> > Almost 2x *decrease* in 6 years.
> Unless you ignore the Larrabee descendants, since they started out with
> ~60 cores 15 years ago.
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

If we limit ourselves to what was available outside of Intel then MIC prototype
named Knights Ferry became available a little more than 12 years ago and it
had 32 cores.
The product, Knights Corner (60 cores) started shipping On 12 November 2012..
Knights Corner cores were a lot smaller and, outside of vector number crunching,
many times less capable that circa-2007 Penryn cores. So, in context of our
discussion, it makes sense to ignore both Knights Corner and its successor
Knights Landing, despite relatively more capable cores of the later.

On Tue, 11 Jul 2023 11:58:50 +0200, Terje Mathisen wrote:

> John Levine wrote:
>>
>> The 8089 I/O processor also had nearly the same pinout. Intel expected
>> you to use a combination of them but the CPUs were good enough that
>> people skipped the 8089s.
>>
> This did lead to some downstream issues with later cpus afair, mainly
> because IBM also ignored the Intel recommended IRQ setup.

The interrupt used by the array bounds check instruction in the 186/188
was the one IBM had chosen to use for "print screen".

The NEC V20 or V30 were fairly popular upgrades to 8088 and 8086 machines,
they were pinout compatible but implemented the 186/188 instruction set.

The 8089 was used with an 8086 in the Apricot PC, I had one. There wasn't
any documentation on how it was being used, I suppose I could have tried
disassembling the BIOS.

Michael S <already5chosen@yahoo.com> writes:
>On Monday, July 10, 2023 at 11:16:50=E2=80=AFPM UTC+3, Scott Lurndal wrote:
>> Michael S <already...@yahoo.com> writes:
>
>> >=20
>> >Look at LLC per core.=20
>> >Intel Penryn (2007) had 3 MB of L2 per core.=20
>> >AMD Zen4 (2022) has 4 MB of L3 per core.=20
>> >So 30% increase in 15 years. And even that moderate increase is not free=
>=20
>> >in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it'=
>s=20
>> >more like 6-7 ns.
>> Now also factor in the increase in core counts (> 100).=20
>>=20
>
>In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.
>The rest of increase in core count is due to MCM packaging rather than
>Moore's law.

There are general purpose chips (neither MCM nor chiplet-based) with _much_ higher
core count outside of the x86 world, even leaving aside aux processors such
as control processors and DSPs. The ThunderX chip had 48 cores, and supported
two-socket implementations almost a decade ago.

On Tuesday, July 11, 2023 at 4:42:07 PM UTC+3, Scott Lurndal wrote:
> Michael S <already...@yahoo.com> writes:
> >On Monday, July 10, 2023 at 11:16:50=E2=80=AFPM UTC+3, Scott Lurndal wrote:
> >> Michael S <already...@yahoo.com> writes:
> >
> >> >=20
> >> >Look at LLC per core.=20
> >> >Intel Penryn (2007) had 3 MB of L2 per core.=20
> >> >AMD Zen4 (2022) has 4 MB of L3 per core.=20
> >> >So 30% increase in 15 years. And even that moderate increase is not free=
> >=20
> >> >in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it'=
> >s=20
> >> >more like 6-7 ns.
> >> Now also factor in the increase in core counts (> 100).=20
> >>=20
> >
> >In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.
> >The rest of increase in core count is due to MCM packaging rather than
> >Moore's law.
> There are general purpose chips (neither MCM nor chiplet-based) with _much_ higher
> core count outside of the x86 world, even leaving aside aux processors such
> as control processors and DSPs. The ThunderX chip had 48 cores, and supported
> two-socket implementations almost a decade ago.

Yes, such chips exist.
The most notable is Ampere Computing Altra and AmpereOne series and Amazon
AWS Graviton2 and Graviton3.
However it's worth to mention that in newer AmpereOne and Graviton3 chips I/O and
memory controllers are already on multiple separate chiplets. So it would be logical to
predict that in their next designs they will abandon their current massive cores+caches
dies in favor of more manageable 16-core or 24-core chiplets as well.

BTW, I wouldn't count ThunderX as one of those general-purpose chips.
ThunderX per core performance was way too low to be called general purpose.
The real and almost exclusive purpose of ThunderX appears to be "to impress
Wall Street".

On 7/11/2023 8:42 AM, Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Monday, July 10, 2023 at 11:16:50=E2=80=AFPM UTC+3, Scott Lurndal wrote:
>>> Michael S <already...@yahoo.com> writes:
>>
>>>> =20
>>>> Look at LLC per core.=20
>>>> Intel Penryn (2007) had 3 MB of L2 per core.=20
>>>> AMD Zen4 (2022) has 4 MB of L3 per core.=20
>>>> So 30% increase in 15 years. And even that moderate increase is not free=
>> =20
>>>> in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today it'=
>> s=20
>>>> more like 6-7 ns.
>>> Now also factor in the increase in core counts (> 100).=20
>>> =20
>>
>> In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.
>> The rest of increase in core count is due to MCM packaging rather than
>> Moore's law.
>
> There are general purpose chips (neither MCM nor chiplet-based) with _much_ higher
> core count outside of the x86 world, even leaving aside aux processors such
> as control processors and DSPs. The ThunderX chip had 48 cores, and supported
> two-socket implementations almost a decade ago.
>

Saw a video recently where someone was messing with a 96-core ARM based
server chip (with a PCIe X16 slot allowing the use of a PC style
graphics card; running an ARM port of Windows).

The guy was then trying without much success to run modernish 3D games
on it (via x86 emulation), but its gaming performance here was a bit
lacking (giving "mostly playable" framerates mostly from early/mid 2000s
era games).

Granted, they weren't really designing the chip for sake of running
games off of Steam (with its performance being judged by how quickly it
could run mostly single-threaded workloads).

....

Thing would probably be a beast with highly multi-threaded workloads
though...

Terje Mathisen wrote:
> John Levine wrote:
>> According to BGB <cr88192@gmail.com>:
>>
>>> 8088 was apparently DIP40 with multiplexed Address/Data lines.
>>>
>>> Looks like the main difference here between 8086 and 8088 was that 8086
>>> had 16 pins being multiplexed Address/Data, and 8088 had 8 pins
>>> multiplexed.
>>
>> That's it. Otherwise they were the same.
>
> ---------------------------^were nearly the same.
>
> As I mentioned previously, the amount of prefetch code buffer space was
> different: 8 bytes on the 86, 6 bytes on the 88. I.e. easy to remember
> since both versions had both an 8 and a 6. :-)

8086 prefetch queue was three 16-bit words, 6 bytes if IP is even
or 5 bytes if IP is odd, and 8088 was 4 separate bytes,
stored in a circular buffer.

Inside the 8086 processor's instruction prefetch circuitry
http://www.righto.com/2023/01/inside-8086-processors-instruction.html

On 2023-07-11 11:58, Terje Mathisen wrote:
> John Levine wrote:
>>
>> That's it.  Otherwise they were the same.
>
> ---------------------------^were nearly the same.
>
> As I mentioned previously, the amount of prefetch code buffer space was
> different: 8 bytes on the 86, 6 bytes on the 88. I.e. easy to remember
> since both versions had both an 8 and a 6. :-)
Ken Shirriff claims at
https://www.righto.com/2023/01/inside-8086-processors-instruction.html
six bytes (three words) for the '86, and four bytes for the '88.

Michael S <already5chosen@yahoo.com> writes:
>On Tuesday, July 11, 2023 at 4:42:07=E2=80=AFPM UTC+3, Scott Lurndal wrote:
>> Michael S <already...@yahoo.com> writes:
>> >On Monday, July 10, 2023 at 11:16:50=3DE2=3D80=3DAFPM UTC+3, Scott Lurnd=
>al wrote:=20
>> >> Michael S <already...@yahoo.com> writes:=20
>> >
>> >> >=3D20=20
>> >> >Look at LLC per core.=3D20=20
>> >> >Intel Penryn (2007) had 3 MB of L2 per core.=3D20=20
>> >> >AMD Zen4 (2022) has 4 MB of L3 per core.=3D20=20
>> >> >So 30% increase in 15 years. And even that moderate increase is not f=
>ree=3D=20
>> >=3D20=20
>> >> >in terms of absolute latency. Back in 2007 we had it at ~4 ns. Today =
>it'=3D=20
>> >s=3D20=20
>> >> >more like 6-7 ns.=20
>> >> Now also factor in the increase in core counts (> 100).=3D20=20
>> >>=3D20
>> >=20
>> >In specific case of Zen4 die vs Penryn die, 8 cores vs 2 cores.=20
>> >The rest of increase in core count is due to MCM packaging rather than=
>=20
>> >Moore's law.
>> There are general purpose chips (neither MCM nor chiplet-based) with _muc=
>h_ higher=20
>> core count outside of the x86 world, even leaving aside aux processors su=
>ch=20
>> as control processors and DSPs. The ThunderX chip had 48 cores, and suppo=
>rted=20
>> two-socket implementations almost a decade ago.
>
>Yes, such chips exist.=20
>The most notable is Ampere Computing Altra and AmpereOne series and Amazo=
>n
>AWS Graviton2 and Graviton3.=20

There's a couple more that I'm aware of, but little has been
publically announced.

>However it's worth to mention that in newer AmpereOne and Graviton3 chips I=
>/O and
>memory controllers are already on multiple separate chiplets. So it would b=
>e logical to
>predict that in their next designs they will abandon their current massive =
>cores+caches
>dies in favor of more manageable 16-core or 24-core chiplets as well.

That does seem to be the general direction for future chips. It does add
some latency crossing from chiplet to chiplet, however.

>
>BTW, I wouldn't count ThunderX as one of those general-purpose chips.=20
>ThunderX per core performance was way too low to be called general purpose.
>The real and almost exclusive purpose of ThunderX appears to be "to impres=
>s
>Wall Street".

Further deponent sayeth not.

On 7/10/2023 11:38 AM, MitchAlsup wrote:
> On Monday, July 10, 2023 at 11:19:41 AM UTC-5, BGB wrote:
>> On 7/9/2023 8:56 PM, MitchAlsup wrote:
>>
>
>>>> Well:
>>>> MOV Imm25s, R0
>>>> Is sort of a sledgehammer solution, but like, it is workable in the
>>>> majority of cases...
>>> <
>>> MOV Rd,#123456789abcdef
>>> <
>>> works in all cases..........
> <
>> The ASM will work, but what it will generate will vary...
> <
> It generates::
> <
> OpCode = 001100, Rd, Rs1=0,{D=1,S1=1,S2=1},Rs3=0,Rs2=0
> 0x9abcdef
> 0x12345678
>>
>> Jumbo=True:
>> 96-bit Jumbo-load;
>> Executes in 1-cycle.
>>
>> Jumbo=False, Rn=R0..R31
>> MOV 0x0123, Rd
>> LDSH 0x4567, Rd
>> LDSH 0x89AB, Rd
>> LDSH 0xCDEF, Rd
>>
>> Can partly ignore R32..R63 for the false case, as anything with XGPR is
>> probably also going to have Jumbo.
>>
>> Theoretical though:
>> MOV 0x0123, R0
>> LDSH 0x4567, R0
>> LDSH 0x89AB, R0
>> LDSH 0xCDEF, R0
>> MOV R0, Rd
> <
> See how much easier it is with universal constants.
> <

The concern is mostly that, on "bottom end" 1-wide cores, the relative
cost of dealing with jumbo prefixes may not be justified (when,
technically, one can have a multi-op fallback case).

But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
preferable, with the main drawback that the WEXifier can't shuffle the
instructions around in this case. Though, this is more an issue with
BGBCC than anything else...

>>
>>> I use the equivalent of::
>>> <
>>> LDA IP,[any AGEN you want]
>>> <
>> Essentially N/E in my case.
>>
>> Could fake it as:
>> LEA.x ..., R1
>> JMP R1
> <
> Still eating instructions and registers and power.......
> <

But, if this doesn't actually come up in practice, it is kinda rendered
moot...

Like, the performance cost of the non-existence of a feature becomes
irrelevant if there is nothing that would actually use the feature had
it existed.

Granted, arguably, maybe it "could" be used as an alternate way of
implementing "switch()" or similar (taking over the role of "BRA Rn" or
"BRA.L Rn").

Where "BRA Rn" branches to 'PC+(Rn*2)' and "BRA.L Rn" to 'PC+(Rn*4)'.

>>> <
>>> Why have a limit ?? My GOT can be 62-bits in size leaving code and data another
>>> 62-bits without encroaching on OS space.
> <
>> I don't generally use a GOT, rather direct PC-rel for internal calls.
> <
> Internal calls use CALL, GOT calls use CALX, re-linked modules use CALA.

Internal:
BSR Disp20 (+/- 1MB)
LDIx + JSR R0 (+/- 32MB)
BSR Disp33 (+/- 4GB, Needs Jumbo)

Non-local:
BSR -> MOV.Q + JMP R1 (Baseline)
BSR -> BRA Abs48
...

GOT would be MOV.Q + JSR.

Probably a bit more involved if one were to use an ELF FDPIC variant.

Well, and/or define that the ELF ABI uses a variant of my existing PBO
ABI and thus requires the GBR save/reload to be handled on the callee
end (or, an intermediate with traditional FDPIC, where the new global
space is loaded from the GOT but passed as an implicit argument).

>>
>> The import/export tables may be managed by the PE/PEL loader.
>>
>> Where, say:
>> __declspec(dllimport) int TkWhatever();
>> Flags an import, but one needs to link against the DLL so the compiler
>> knows what DLL has the definition, and/or use a specialized listing file
>> (essentially a list of DLL exports).
>>
>> This being as opposed to using "import libraries" or similar (but, the
>> listings would serve a similar role to import libraries). Mostly needed
>> because the import table encodes the DLL (say, "SOMEDLL!TkWhatever").
>>
>> But, generally, the compiler can figure out roughly how big the program
>> is going to be and what sort of branches it needs to use (for actual
>> separate compilation, would need a "memory model" or similar).
>>
>>
>> Can note that it is not currently possible to share global variables
>> across DLL boundaries, only imported/exported functions.
>>
> Shame, shame; a linked module should resolve all extern names it
> has memory for.

For a long time, Windows DLL's had a similar restriction.

MS seemed to hack around it, AFAIK by importing an address to the
exported variable and then doing an indirect load. But, still requires
__declspec(dllimport).

This hasn't been a high priority in my case.

In theory, could mimic ELF SO behavior, but this would result in
comparably huge export tables, and larger SO's could risk breaking the
implicit assumption of there being fewer than 64K exports (due to the
internal use of 16-bit ordinal numbers and similar within PE/COFF).

Granted, theoretically, nothing in BJX2's design, per-se, prevents
defining an ELF ABI for it.

Though, it would likely be a modification of my existing PBO ABI design,
rather than something like FDPIC.

Functionally, wouldn't be that different from some of the PIE ABIs, but
with the main difference that in PIE ABI's, an initial PC-relative
calculation is used to initialize (or reinitialize) the value of the
global pointer.

In PBO, the initial global-pointer is supplied by the loader, and every
other image fetches its own value from an implicit lookup table (with
every DLL/SO being assigned a magic index into this table during initial
loading).

>>
>> Some of this might have been different had I used ELF as a basis instead.
>
>>> But you do have the ability to fix it, do you not ??
>> I would need some way for the assembler to know which notation is in use
>> (and/or a bulk rewrite of all the ASM code).
>>
>> Otherwise, the assembler has no way to look at:
>> ADD R4, R5, R6
>> And know which register is the destination...
>> R4=R5+R6
>> Or:
>> R6=R4+R5
>>
> A flag ?? An environment variable ??

Too loose. Something that is likely to turn the ASM code into confetti
would need to be directly present in the ASM code.

Even then, it would make a mess if copying ASM code from a location
using one convention to a location using the other.

Ideally, it would be unambiguous from the syntax.

On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
> On 7/10/2023 11:38 AM, MitchAlsup wrote:
> > On Monday, July 10, 2023 at 11:19:41 AM UTC-5, BGB wrote:
> >> On 7/9/2023 8:56 PM, MitchAlsup wrote:
> >>
> >
> >>>> Well:
> >>>> MOV Imm25s, R0
> >>>> Is sort of a sledgehammer solution, but like, it is workable in the
> >>>> majority of cases...
> >>> <
> >>> MOV Rd,#123456789abcdef
> >>> <
> >>> works in all cases..........
> > <
> >> The ASM will work, but what it will generate will vary...
> > <
> > It generates::
> > <
> > OpCode = 001100, Rd, Rs1=0,{D=1,S1=1,S2=1},Rs3=0,Rs2=0
> > 0x9abcdef
> > 0x12345678
> >>
> >> Jumbo=True:
> >> 96-bit Jumbo-load;
> >> Executes in 1-cycle.
> >>
> >> Jumbo=False, Rn=R0..R31
> >> MOV 0x0123, Rd
> >> LDSH 0x4567, Rd
> >> LDSH 0x89AB, Rd
> >> LDSH 0xCDEF, Rd
> >>
> >> Can partly ignore R32..R63 for the false case, as anything with XGPR is
> >> probably also going to have Jumbo.
> >>
> >> Theoretical though:
> >> MOV 0x0123, R0
> >> LDSH 0x4567, R0
> >> LDSH 0x89AB, R0
> >> LDSH 0xCDEF, R0
> >> MOV R0, Rd
> > <
> > See how much easier it is with universal constants.
> > <
>
> The concern is mostly that, on "bottom end" 1-wide cores, the relative
> cost of dealing with jumbo prefixes may not be justified (when,
> technically, one can have a multi-op fallback case).
<
40 gates (equivalent to 4-bits of flip-flop storage) and an instruction
buffer is all it takes (plus a good encoding strategy.)
>
>
> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
> preferable, with the main drawback that the WEXifier can't shuffle the
> instructions around in this case. Though, this is more an issue with
> BGBCC than anything else...
>
>
> >>
> >>> I use the equivalent of::
> >>> <
> >>> LDA IP,[any AGEN you want]
> >>> <
> >> Essentially N/E in my case.
> >>
> >> Could fake it as:
> >> LEA.x ..., R1
> >> JMP R1
> > <
> > Still eating instructions and registers and power.......
> > <
>
> But, if this doesn't actually come up in practice, it is kinda rendered
> moot...
<
No, it shifts the burden elsewhere--mostly to the compiler who now has to
deal with the myriad of expressions that with universal constants becomes
1.
>
> Like, the performance cost of the non-existence of a feature becomes
> irrelevant if there is nothing that would actually use the feature had
> it existed.
>
>
> Granted, arguably, maybe it "could" be used as an alternate way of
> implementing "switch()" or similar (taking over the role of "BRA Rn" or
> "BRA.L Rn").
>
> Where "BRA Rn" branches to 'PC+(Rn*2)' and "BRA.L Rn" to 'PC+(Rn*4)'.
>
>
> >>> <
> >>> Why have a limit ?? My GOT can be 62-bits in size leaving code and data another
> >>> 62-bits without encroaching on OS space.
> > <
> >> I don't generally use a GOT, rather direct PC-rel for internal calls.
> > <
> > Internal calls use CALL, GOT calls use CALX, re-linked modules use CALA..
>
> Internal:
> BSR Disp20 (+/- 1MB)
> LDIx + JSR R0 (+/- 32MB)
> BSR Disp33 (+/- 4GB, Needs Jumbo)
<
CALL DISP26 (±64M)
CALA DISP32 (±4GB)
CALA DISP64 (everywhere)
>
> Non-local:
> BSR -> MOV.Q + JMP R1 (Baseline)
> BSR -> BRA Abs48
> ...
CALX [Any address you want] // anywhere
>
>
> GOT would be MOV.Q + JSR.
<
CALX [IP,,&GOT-.+function#<<3]
>
>
> Probably a bit more involved if one were to use an ELF FDPIC variant.
>
> Well, and/or define that the ELF ABI uses a variant of my existing PBO
> ABI and thus requires the GBR save/reload to be handled on the callee
> end (or, an intermediate with traditional FDPIC, where the new global
> space is loaded from the GOT but passed as an implicit argument).
>
>
> >>
> >> The import/export tables may be managed by the PE/PEL loader.
> >>
> >> Where, say:
> >> __declspec(dllimport) int TkWhatever();
> >> Flags an import, but one needs to link against the DLL so the compiler
> >> knows what DLL has the definition, and/or use a specialized listing file
> >> (essentially a list of DLL exports).
> >>
> >> This being as opposed to using "import libraries" or similar (but, the
> >> listings would serve a similar role to import libraries). Mostly needed
> >> because the import table encodes the DLL (say, "SOMEDLL!TkWhatever").
> >>
> >> But, generally, the compiler can figure out roughly how big the program
> >> is going to be and what sort of branches it needs to use (for actual
> >> separate compilation, would need a "memory model" or similar).
> >>
> >>
> >> Can note that it is not currently possible to share global variables
> >> across DLL boundaries, only imported/exported functions.
> >>
> > Shame, shame; a linked module should resolve all extern names it
> > has memory for.
>
> For a long time, Windows DLL's had a similar restriction.
>
> MS seemed to hack around it, AFAIK by importing an address to the
> exported variable and then doing an indirect load. But, still requires
> __declspec(dllimport).
>
> This hasn't been a high priority in my case.
>
>
> In theory, could mimic ELF SO behavior, but this would result in
> comparably huge export tables, and larger SO's could risk breaking the
> implicit assumption of there being fewer than 64K exports (due to the
> internal use of 16-bit ordinal numbers and similar within PE/COFF).
>
> Granted, theoretically, nothing in BJX2's design, per-se, prevents
> defining an ELF ABI for it.
>
>
> Though, it would likely be a modification of my existing PBO ABI design,
> rather than something like FDPIC.
>
> Functionally, wouldn't be that different from some of the PIE ABIs, but
> with the main difference that in PIE ABI's, an initial PC-relative
> calculation is used to initialize (or reinitialize) the value of the
> global pointer.
>
> In PBO, the initial global-pointer is supplied by the loader, and every
> other image fetches its own value from an implicit lookup table (with
> every DLL/SO being assigned a magic index into this table during initial
> loading).
>
>
> >>
> >> Some of this might have been different had I used ELF as a basis instead.
> >
> >>> But you do have the ability to fix it, do you not ??
> >> I would need some way for the assembler to know which notation is in use
> >> (and/or a bulk rewrite of all the ASM code).
> >>
> >> Otherwise, the assembler has no way to look at:
> >> ADD R4, R5, R6
> >> And know which register is the destination...
> >> R4=R5+R6
> >> Or:
> >> R6=R4+R5
> >>
> > A flag ?? An environment variable ??
>
> Too loose. Something that is likely to turn the ASM code into confetti
> would need to be directly present in the ASM code.
<
# include file.h
>
> Even then, it would make a mess if copying ASM code from a location
> using one convention to a location using the other.
>
> Ideally, it would be unambiguous from the syntax.

On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
> On 7/10/2023 11:38 AM, MitchAlsup wrote:
>
> >> Theoretical though:
> >> MOV 0x0123, R0
> >> LDSH 0x4567, R0
> >> LDSH 0x89AB, R0
> >> LDSH 0xCDEF, R0
> >> MOV R0, Rd
> > <
> > See how much easier it is with universal constants.
> > <
>
> The concern is mostly that, on "bottom end" 1-wide cores, the relative
> cost of dealing with jumbo prefixes may not be justified (when,
> technically, one can have a multi-op fallback case).
>
>
> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
> preferable, with the main drawback that the WEXifier can't shuffle the
> instructions around in this case. Though, this is more an issue with
> BGBCC than anything else...
>
You keep arguing that more instructions are better than fewer instructions.
<
I know you are thinking your argument is:: that "BGB ISA" is not so bad that
BGB can't find solutions to these insundry issues using the existing BGB ISA.
<
But even a Touring machine with an infinite tape can do that too !
>

On 7/11/23 02:03, Thomas Koenig wrote:
> Brian G. Lucas <bagel99@gmail.com> schrieb:
>
>> Yes, a 16-bit instruction word with 16 registers is possible. And yes,
>> constants were a bit of a problem.
>>
>> See Motorola (then Freescale, then NXP) MCore. The Chinese licensed it
>> and called it CCore. There is even a Linux port to it.
>> I designed the original instruction set.
>
> I've just looked at it, and you certainly had your work cut out for you
> fitting that much functionality into 16 bits...
>
> Did it pay off with respect to code density?

Yes, in almost all the benchmarks we tested the code density was better
than the 68k.

On 7/11/23 04:12, Michael S wrote:
> On Tuesday, July 11, 2023 at 10:03:32 AM UTC+3, Thomas Koenig wrote:
>> Brian G. Lucas <bag...@gmail.com> schrieb:
>>> Yes, a 16-bit instruction word with 16 registers is possible. And yes,
>>> constants were a bit of a problem.
>>>
>>> See Motorola (then Freescale, then NXP) MCore. The Chinese licensed it
>>> and called it CCore. There is even a Linux port to it.
>>> I designed the original instruction set.
>> I've just looked at it, and you certainly had your work cut out for you
>> fitting that much functionality into 16 bits...
>>
>> Did it pay off with respect to code density?
>
> It looks like MCore lost internal battle within Freescale to e200 family.
> e200 tries to achieve competitive code density by means of VLE variant of
> PPC32 ISA.
> The outcome, of course, does not mean that e200 code density is as good
> as MCore, but does mean that it is (was) good enough for a target market.
>
The E200 and other 32-bit PPCs were more targeted to automotive and other
similar applications. MCore was targeted at radios/cellphones and the like.
MCore lost the battle to ARM Thumb, which came slightly after.

On Tuesday, July 11, 2023 at 5:58:55 AM UTC-4, Terje Mathisen wrote:

> As I mentioned previously, the amount of prefetch code buffer space was
> different: 8 bytes on the 86, 6 bytes on the 88. I.e. easy to remember
> since both versions had both an 8 and a 6. :-)
> >

4 bytes on the 8088, 3 words (6 bytes) on the 8086.

- Tim

On Tuesday, July 11, 2023 at 8:36:00 AM UTC-4, Robert Swindells wrote:
>>
> The NEC V20 or V30 were fairly popular upgrades to 8088 and 8086 machines,
> they were pinout compatible but implemented the 186/188 instruction set.

Plus a few other instructions (bit field insert delete, a BCD string instructions,
another REP variant) plus full 8080 mode.

- Tim

On Sunday, July 9, 2023 at 4:49:50 PM UTC-4, MitchAlsup wrote:
> > I guess a question is if it had been used in the PC instead of x86, if
> > Motorola could have then made it performance competitive with what later
> > x86 systems became?...
> <
> If 68K was used instead of 8086, PC would have been more like LISA.
> {{which evolved into MacIntosh.}
> >

I think the Atari ST is closer to what the PC would have been capabilty wise.

> 68K was out performing 8086 in that era
> After 486 it was all done.

I always got the impression that Moto management just DID NOT UNDERSTAND
that they could not just create on product and coast on it for years. Intel management
(at the time) did seem to understand that, although they wasted a bunch of time
on the iAPX32. If you look at the time line, there was a big pause between 1979 and 1984,
and by 1984 Motorola was definitely playing catch-up. Also, all those weird indirect modes they
added to the '020 probably delayed things (and I suspect they were put in there because
of Apple, but I have never confirmed that).

- Tim

On 7/11/2023 2:00 PM, MitchAlsup wrote:
> On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
>> On 7/10/2023 11:38 AM, MitchAlsup wrote:
>>
>>>> Theoretical though:
>>>> MOV 0x0123, R0
>>>> LDSH 0x4567, R0
>>>> LDSH 0x89AB, R0
>>>> LDSH 0xCDEF, R0
>>>> MOV R0, Rd
>>> <
>>> See how much easier it is with universal constants.
>>> <
>>
>> The concern is mostly that, on "bottom end" 1-wide cores, the relative
>> cost of dealing with jumbo prefixes may not be justified (when,
>> technically, one can have a multi-op fallback case).
>>
>>
>> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
>> preferable, with the main drawback that the WEXifier can't shuffle the
>> instructions around in this case. Though, this is more an issue with
>> BGBCC than anything else...
>>
> You keep arguing that more instructions are better than fewer instructions.

In some cases:
When LUT cost factors more than performance (eg, when otherwise it wont
fit in the target device or similar);
When other factors favor that everything be kept as 32-bit instructions.

It being a lot easier to shuffle fixed-length 32-bit instructions than
variable length instructions; and if each 64-bit instruction used forms
a "wall" for the shuffling algorithm, this isn't ideal (may end up
costing more cycles than it saves).

So, it is a lot of cases of, "Which is worse?".

You can load a value into a register, creating a dependency, and needing
an extra cycle, but instructions can still be shuffled. Or, one can use
a 64-bit encoding, but then note that the WEXifier can't move the
offending instruction, or move other instructions around it.

The compiler tries to weight these factors based on the code being
generated, the value of the constant, and various other fine-tuning
heuristics.

Well, also things like whether the ISA profile actually allows certain
encodings.

Though, for Jumbo encodings with the WEXifier enabled, usually:
If the constant (which failed to fit directly in an immediate field)
fits into a single 32-bit instruction, load it using an instruction;
If it would need more than one instruction word, it ends up preferable
to use a jumbo encoding instead.

So:
y=x+510; //direct, single instruction
y=x+65521; //two 32-bit instructions
y=x+0xDEADBEEF; //OK, now use a jumbo prefix.

In the two-op case, it being possible to shuffle the instructions, and
probably execute one or both in parallel with other instructions.

> <
> I know you are thinking your argument is:: that "BGB ISA" is not so bad that
> BGB can't find solutions to these insundry issues using the existing BGB ISA.
> <
> But even a Touring machine with an infinite tape can do that too !

The goal is not "perfection" nor even "perfectly elegant", but more
cost/benefit; best performance relative to cheapest cost, balancing cost
against performance and similar as needed.

So, one can mostly optimize the "oh man, this sucks real bad" cases.

In the case of constants, this would be stuff like needing to do a
PC-relative memory load or similar.

There are many cases where I have instructions that are unnecessary in a
strictly minimalist sense; but which exist more because they help with
performance.

And, other cases where it makes sense to "just take the loss" for the
fraction of a percent of times it might come up (or, ignore cases that
are unlikely to happen in practice).

I don't think I am doing that badly, as there are a lot of other ISA's
that do a lot worse in these areas.

On Tuesday, July 11, 2023 at 6:27:20 PM UTC-4, BGB-Alt wrote:
> On 7/11/2023 2:00 PM, MitchAlsup wrote:
> > On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
> >> On 7/10/2023 11:38 AM, MitchAlsup wrote:
> >>
> >>>> Theoretical though:
> >>>> MOV 0x0123, R0
> >>>> LDSH 0x4567, R0
> >>>> LDSH 0x89AB, R0
> >>>> LDSH 0xCDEF, R0
> >>>> MOV R0, Rd
> >>> <
> >>> See how much easier it is with universal constants.
> >>> <
> >>
> >> The concern is mostly that, on "bottom end" 1-wide cores, the relative
> >> cost of dealing with jumbo prefixes may not be justified (when,
> >> technically, one can have a multi-op fallback case).
> >>
> >>
> >> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
> >> preferable, with the main drawback that the WEXifier can't shuffle the
> >> instructions around in this case. Though, this is more an issue with
> >> BGBCC than anything else...
> >>
> > You keep arguing that more instructions are better than fewer instructions.
> In some cases:
> When LUT cost factors more than performance (eg, when otherwise it wont
> fit in the target device or similar);
> When other factors favor that everything be kept as 32-bit instructions.
>
>
> It being a lot easier to shuffle fixed-length 32-bit instructions than
> variable length instructions; and if each 64-bit instruction used forms
> a "wall" for the shuffling algorithm, this isn't ideal (may end up
> costing more cycles than it saves).
>
> So, it is a lot of cases of, "Which is worse?".
>
> You can load a value into a register, creating a dependency, and needing
> an extra cycle, but instructions can still be shuffled. Or, one can use
> a 64-bit encoding, but then note that the WEXifier can't move the
> offending instruction, or move other instructions around it.
>
>
> The compiler tries to weight these factors based on the code being
> generated, the value of the constant, and various other fine-tuning
> heuristics.
>
> Well, also things like whether the ISA profile actually allows certain
> encodings.
>
>
> Though, for Jumbo encodings with the WEXifier enabled, usually:
> If the constant (which failed to fit directly in an immediate field)
> fits into a single 32-bit instruction, load it using an instruction;
> If it would need more than one instruction word, it ends up preferable
> to use a jumbo encoding instead.
>
> So:
> y=x+510; //direct, single instruction
> y=x+65521; //two 32-bit instructions
> y=x+0xDEADBEEF; //OK, now use a jumbo prefix.
>
> In the two-op case, it being possible to shuffle the instructions, and
> probably execute one or both in parallel with other instructions.
> > <
> > I know you are thinking your argument is:: that "BGB ISA" is not so bad that
> > BGB can't find solutions to these insundry issues using the existing BGB ISA.
> > <
> > But even a Touring machine with an infinite tape can do that too !
> The goal is not "perfection" nor even "perfectly elegant", but more
> cost/benefit; best performance relative to cheapest cost, balancing cost
> against performance and similar as needed.

One goal is something that works. An issue with perfection and elegance may
be its predictability. I think predictable things may be more susceptible to
malicious attacks. I think there needs to be a certain amount of entropy in the
design.

>
> So, one can mostly optimize the "oh man, this sucks real bad" cases.
>
> In the case of constants, this would be stuff like needing to do a
> PC-relative memory load or similar.
>
>
>
> There are many cases where I have instructions that are unnecessary in a
> strictly minimalist sense; but which exist more because they help with
> performance.
>
> And, other cases where it makes sense to "just take the loss" for the
> fraction of a percent of times it might come up (or, ignore cases that
> are unlikely to happen in practice).
>
>
> I don't think I am doing that badly, as there are a lot of other ISA's
> that do a lot worse in these areas.

IMO one has to be prepared to scrap, burn, and rebuild to make significant
changes to a design. I think I am into the double-digits in my scrap and
rebuild cycle. Learning how to scrap and rebuild fast and efficiently.

I prefer postfixed constants. Postfix constants can be treated as part of the
preceding instruction and fetched at the same time, and they do not require
interlocks. One cycle to fetch both the instruction and postfixes. Postfixes
can keep the instruction size constant. It is tempting to allow two different
postfixed constants in a single instruction so that things like store
immediate could be supported. One issue is the instruction length with
two 128-bit postfixed constants would be about 360-bits. Fetching two
instructions at a time would mean fetching up to 720-bits. The cache line
is only 512-bits wide. Also, the use of a postfix is identified by a register
code, 63, a second register code would need to be dedicated for a second
postfix. Since it is only occasionally useful to support two constants in an
instruction, for now only a single postfix is supported.

On Tuesday, July 11, 2023 at 6:26:23 PM UTC-5, robf...@gmail.com wrote:
> On Tuesday, July 11, 2023 at 6:27:20 PM UTC-4, BGB-Alt wrote:
> > On 7/11/2023 2:00 PM, MitchAlsup wrote:
> > > On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
> > >> On 7/10/2023 11:38 AM, MitchAlsup wrote:
> > >>
> > >>>> Theoretical though:
> > >>>> MOV 0x0123, R0
> > >>>> LDSH 0x4567, R0
> > >>>> LDSH 0x89AB, R0
> > >>>> LDSH 0xCDEF, R0
> > >>>> MOV R0, Rd
> > >>> <
> > >>> See how much easier it is with universal constants.
> > >>> <
> > >>
> > >> The concern is mostly that, on "bottom end" 1-wide cores, the relative
> > >> cost of dealing with jumbo prefixes may not be justified (when,
> > >> technically, one can have a multi-op fallback case).
> > >>
> > >>
> > >> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
> > >> preferable, with the main drawback that the WEXifier can't shuffle the
> > >> instructions around in this case. Though, this is more an issue with
> > >> BGBCC than anything else...
> > >>
> > > You keep arguing that more instructions are better than fewer instructions.
> > In some cases:
> > When LUT cost factors more than performance (eg, when otherwise it wont
> > fit in the target device or similar);
> > When other factors favor that everything be kept as 32-bit instructions..
> >
> >
> > It being a lot easier to shuffle fixed-length 32-bit instructions than
> > variable length instructions; and if each 64-bit instruction used forms
> > a "wall" for the shuffling algorithm, this isn't ideal (may end up
> > costing more cycles than it saves).
> >
> > So, it is a lot of cases of, "Which is worse?".
> >
> > You can load a value into a register, creating a dependency, and needing
> > an extra cycle, but instructions can still be shuffled. Or, one can use
> > a 64-bit encoding, but then note that the WEXifier can't move the
> > offending instruction, or move other instructions around it.
> >
> >
> > The compiler tries to weight these factors based on the code being
> > generated, the value of the constant, and various other fine-tuning
> > heuristics.
> >
> > Well, also things like whether the ISA profile actually allows certain
> > encodings.
> >
> >
> > Though, for Jumbo encodings with the WEXifier enabled, usually:
> > If the constant (which failed to fit directly in an immediate field)
> > fits into a single 32-bit instruction, load it using an instruction;
> > If it would need more than one instruction word, it ends up preferable
> > to use a jumbo encoding instead.
> >
> > So:
> > y=x+510; //direct, single instruction
> > y=x+65521; //two 32-bit instructions
> > y=x+0xDEADBEEF; //OK, now use a jumbo prefix.
> >
> > In the two-op case, it being possible to shuffle the instructions, and
> > probably execute one or both in parallel with other instructions.
> > > <
> > > I know you are thinking your argument is:: that "BGB ISA" is not so bad that
> > > BGB can't find solutions to these insundry issues using the existing BGB ISA.
> > > <
> > > But even a Touring machine with an infinite tape can do that too !
> > The goal is not "perfection" nor even "perfectly elegant", but more
> > cost/benefit; best performance relative to cheapest cost, balancing cost
> > against performance and similar as needed.
> One goal is something that works. An issue with perfection and elegance may
> be its predictability. I think predictable things may be more susceptible to
> malicious attacks. I think there needs to be a certain amount of entropy in the
> design.
> >
> > So, one can mostly optimize the "oh man, this sucks real bad" cases.
> >
> > In the case of constants, this would be stuff like needing to do a
> > PC-relative memory load or similar.
> >
> >
> >
> > There are many cases where I have instructions that are unnecessary in a
> > strictly minimalist sense; but which exist more because they help with
> > performance.
> >
> > And, other cases where it makes sense to "just take the loss" for the
> > fraction of a percent of times it might come up (or, ignore cases that
> > are unlikely to happen in practice).
> >
> >
> > I don't think I am doing that badly, as there are a lot of other ISA's
> > that do a lot worse in these areas.
> IMO one has to be prepared to scrap, burn, and rebuild to make significant
> changes to a design. I think I am into the double-digits in my scrap and
> rebuild cycle. Learning how to scrap and rebuild fast and efficiently.
>
> I prefer postfixed constants. Postfix constants can be treated as part of the
> preceding instruction and fetched at the same time, and they do not require
> interlocks. One cycle to fetch both the instruction and postfixes. Postfixes
> can keep the instruction size constant. It is tempting to allow two different
> postfixed constants in a single instruction so that things like store
> immediate could be supported. One issue is the instruction length with
> two 128-bit postfixed constants would be about 360-bits. Fetching two
<
In a similar vein, I choose 64-bit constants and 128-bit fetches as the low
end base line.
<
I chose 64-bit constants because I was doing a 64-bit machine and 64-bit
constants are a perfect match. Since the constants are universal, I have
easy access to 64-bit displacements--and support Fortran common blocks
of any size (up to about 2^62). Fortran programmers can go back and pass
everything in common blocks......one can port dusty deck programs change
the sizes of array bounds and it all just works.
<
I chose 128-bit fetches because (over on the data side) the architecture
is inherently misaligned, and misaligned 64-bit accesses may need a
pair of aligned 64-bit datums. Over on the fetch side, I wanted the inst
cache to be identical with the data cache for minimum design effort.
So, presto 128-bit fetches it was.
<
The maximal length of a My 66000 instruction is 5 words, and I am
fetching 4. There is an instruction buffer between fetch and decode
(proper). So, by the time one is decoding a maximal length instruction
one only has to check if the subsequent fetch hit the cache. If it did,
the last word is present; and all 5-words pass through decode in a
single cycle.
<
Since the average instruction is between 4 and 5 bytes, AND because
one has to have an instruction buffer, I scan forward in the IB for
branch instructions. I prefetch the targets of the branch into IB.
By the time I get to decode the branch the target is present and
instructions at the target flow through decode. The cycle count
of an average branch is 1.03 cycles. Not bad for a machine without
a branch predictor !
<
And finally, once one gets 3-5 instructions ahead of where decode
is, one can turn off fetching to save power. The code cache is used
35% of the available cycles (including branch target fetches).
<
The data cache is accessed at a similar rate and theoretically a 2×
cache could share code and data accesses and not be much of
a bottleneck. Simulation indicates a code cache plus a data cache
is 1% slower (8Kb-thoruhg-64Kb) than a combined cache of 2×
the size. 1% is likely lost in the noise and separate L1s removes
a lot of potential interference.
<
> instructions at a time would mean fetching up to 720-bits. The cache line
> is only 512-bits wide. Also, the use of a postfix is identified by a register
> code, 63, a second register code would need to be dedicated for a second
> postfix. Since it is only occasionally useful to support two constants in an
> instruction, for now only a single postfix is supported.

On 7/11/2023 6:26 PM, robf...@gmail.com wrote:
> On Tuesday, July 11, 2023 at 6:27:20 PM UTC-4, BGB-Alt wrote:
>> On 7/11/2023 2:00 PM, MitchAlsup wrote:
>>> On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
>>>> On 7/10/2023 11:38 AM, MitchAlsup wrote:
>>>>
>>>>>> Theoretical though:
>>>>>> MOV 0x0123, R0
>>>>>> LDSH 0x4567, R0
>>>>>> LDSH 0x89AB, R0
>>>>>> LDSH 0xCDEF, R0
>>>>>> MOV R0, Rd
>>>>> <
>>>>> See how much easier it is with universal constants.
>>>>> <
>>>>
>>>> The concern is mostly that, on "bottom end" 1-wide cores, the relative
>>>> cost of dealing with jumbo prefixes may not be justified (when,
>>>> technically, one can have a multi-op fallback case).
>>>>
>>>>
>>>> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
>>>> preferable, with the main drawback that the WEXifier can't shuffle the
>>>> instructions around in this case. Though, this is more an issue with
>>>> BGBCC than anything else...
>>>>
>>> You keep arguing that more instructions are better than fewer instructions.
>> In some cases:
>> When LUT cost factors more than performance (eg, when otherwise it wont
>> fit in the target device or similar);
>> When other factors favor that everything be kept as 32-bit instructions.
>>
>>
>> It being a lot easier to shuffle fixed-length 32-bit instructions than
>> variable length instructions; and if each 64-bit instruction used forms
>> a "wall" for the shuffling algorithm, this isn't ideal (may end up
>> costing more cycles than it saves).
>>
>> So, it is a lot of cases of, "Which is worse?".
>>
>> You can load a value into a register, creating a dependency, and needing
>> an extra cycle, but instructions can still be shuffled. Or, one can use
>> a 64-bit encoding, but then note that the WEXifier can't move the
>> offending instruction, or move other instructions around it.
>>
>>
>> The compiler tries to weight these factors based on the code being
>> generated, the value of the constant, and various other fine-tuning
>> heuristics.
>>
>> Well, also things like whether the ISA profile actually allows certain
>> encodings.
>>
>>
>> Though, for Jumbo encodings with the WEXifier enabled, usually:
>> If the constant (which failed to fit directly in an immediate field)
>> fits into a single 32-bit instruction, load it using an instruction;
>> If it would need more than one instruction word, it ends up preferable
>> to use a jumbo encoding instead.
>>
>> So:
>> y=x+510; //direct, single instruction
>> y=x+65521; //two 32-bit instructions
>> y=x+0xDEADBEEF; //OK, now use a jumbo prefix.
>>
>> In the two-op case, it being possible to shuffle the instructions, and
>> probably execute one or both in parallel with other instructions.

Say:
y0=x+510; //direct, single instruction
y1=x+65521; //two 32-bit instructions
y2=x+4093; //two 32-bit instructions
y3=x+0xDEADBEEF; //OK, now use a jumbo prefix.

MOV 4093, R3 | MOV 65521, R1 | ADD R4, 510, R5
ADD R4, R1, R6 | ADD R4, R3, R7
ADD R4, 0xDEADBEEF, R8

So: Latency, 3 cycles; 7 instruction words.

Whereas, if jumbo encodings were used:
ADD R4, 510, R5
ADD R4, 65521, R6
ADD R4, 4093, R7
ADD R4, 0xDEADBEEF, R8

Latency, 4 cycles; 7 instruction words.

But, in this case:
ADD R4, 0xDEADBEEF, R8 //2 words, 1 cycle
Is better than:*3
MOV 0xDEADBEEF, R1
ADD R4, R1, R8
3 words, 2 cycles.

Since the constant load does not fit into a single 32-bit instruction
word, and thus has all of the drawback and none of the merit in this case.

Constants in the +/- 16777215 range are in a gray area, since this does
fit into a 32-bit instruction word; but can only use R0 and can only
exist in Lane 1 (thus leaving less opportunity for shuffling and bundling).

It is theoretically possible (within the encoding scheme), that one
could have, say:
ADD R4, 0xDEADBEEF, R8 | MOV.Q (R9, 120), R17

As, say:
FEDE-ADBE-F284-00EF-F119-B40F

However, this is not currently allowed within the rules.

The situation could be improved if the WEXifier worked in terms of
abstract instructions, rather than being applied "after the fact" on top
of the generated machine-code, but alas...

There is a whole lot of stuff here that probably should have been done
differently in retrospect.

Things that might have made sense:
Splitting code generation, assembly, and linking, into at least
partially disjoint stages;
Using a listing to assemble instructions rather than giant "switch()"
blocks and if/else logic;
Scheduling and bundling in terms of abstract instructions rather than
working on already-generated machine-code;
....

A lot of the compiler architecture is a big pile of hacks.

With major compiler stages being:
Preprocess;
Parse;
Convert ASTs to RIL;
Convert RIL to 3AC;
Convert 3AC to machine code;
WEXifier;
Emit final PE/COFF (or PEL4) image.

Didn't include assembler or linker stages mostly because early on, they
did not seem necessary.

They did sort of exist for an earlier x86 backend, but were not retained.

Originally, the SH backend didn't bother with any of this (owing to the
relative simplicity of the instructions). And, the BJX2 backend was
basically a direct fork of the original SH backend.

>>> <
>>> I know you are thinking your argument is:: that "BGB ISA" is not so bad that
>>> BGB can't find solutions to these insundry issues using the existing BGB ISA.
>>> <
>>> But even a Touring machine with an infinite tape can do that too !
>> The goal is not "perfection" nor even "perfectly elegant", but more
>> cost/benefit; best performance relative to cheapest cost, balancing cost
>> against performance and similar as needed.
>
> One goal is something that works. An issue with perfection and elegance may
> be its predictability. I think predictable things may be more susceptible to
> malicious attacks. I think there needs to be a certain amount of entropy in the
> design.
>

Possibly.

Though, ironically, some parts of my compiler involve the use of random
number generators...

>>
>> So, one can mostly optimize the "oh man, this sucks real bad" cases.
>>
>> In the case of constants, this would be stuff like needing to do a
>> PC-relative memory load or similar.
>>
>>
>>
>> There are many cases where I have instructions that are unnecessary in a
>> strictly minimalist sense; but which exist more because they help with
>> performance.
>>
>> And, other cases where it makes sense to "just take the loss" for the
>> fraction of a percent of times it might come up (or, ignore cases that
>> are unlikely to happen in practice).
>>
>>
>> I don't think I am doing that badly, as there are a lot of other ISA's
>> that do a lot worse in these areas.
>
> IMO one has to be prepared to scrap, burn, and rebuild to make significant
> changes to a design. I think I am into the double-digits in my scrap and
> rebuild cycle. Learning how to scrap and rebuild fast and efficiently.
>

There are tradeoffs:
Big design changes may require big changes to the compiler, or break
binary compatibility with existing code, ...

Sometimes design changes are OK, but I do generally try to limit the
number of "breaking changes" when possible.

> I prefer postfixed constants. Postfix constants can be treated as part of the
> preceding instruction and fetched at the same time, and they do not require
> interlocks. One cycle to fetch both the instruction and postfixes. Postfixes
> can keep the instruction size constant. It is tempting to allow two different
> postfixed constants in a single instruction so that things like store
> immediate could be supported. One issue is the instruction length with
> two 128-bit postfixed constants would be about 360-bits. Fetching two
> instructions at a time would mean fetching up to 720-bits. The cache line
> is only 512-bits wide. Also, the use of a postfix is identified by a register
> code, 63, a second register code would need to be dedicated for a second
> postfix. Since it is only occasionally useful to support two constants in an
> instruction, for now only a single postfix is supported.

On 7/11/2023 7:02 PM, MitchAlsup wrote:
> On Tuesday, July 11, 2023 at 6:26:23 PM UTC-5, robf...@gmail.com wrote:
>> On Tuesday, July 11, 2023 at 6:27:20 PM UTC-4, BGB-Alt wrote:
>>> On 7/11/2023 2:00 PM, MitchAlsup wrote:
>>>> On Tuesday, July 11, 2023 at 1:33:42 PM UTC-5, BGB wrote:
>>>>> On 7/10/2023 11:38 AM, MitchAlsup wrote:
>>>>>
>>>>>>> Theoretical though:
>>>>>>> MOV 0x0123, R0
>>>>>>> LDSH 0x4567, R0
>>>>>>> LDSH 0x89AB, R0
>>>>>>> LDSH 0xCDEF, R0
>>>>>>> MOV R0, Rd
>>>>>> <
>>>>>> See how much easier it is with universal constants.
>>>>>> <
>>>>>
>>>>> The concern is mostly that, on "bottom end" 1-wide cores, the relative
>>>>> cost of dealing with jumbo prefixes may not be justified (when,
>>>>> technically, one can have a multi-op fallback case).
>>>>>
>>>>>
>>>>> But, yeah, for most cases, the use of jumbo-prefix encodings is "mostly"
>>>>> preferable, with the main drawback that the WEXifier can't shuffle the
>>>>> instructions around in this case. Though, this is more an issue with
>>>>> BGBCC than anything else...
>>>>>
>>>> You keep arguing that more instructions are better than fewer instructions.
>>> In some cases:
>>> When LUT cost factors more than performance (eg, when otherwise it wont
>>> fit in the target device or similar);
>>> When other factors favor that everything be kept as 32-bit instructions.
>>>
>>>
>>> It being a lot easier to shuffle fixed-length 32-bit instructions than
>>> variable length instructions; and if each 64-bit instruction used forms
>>> a "wall" for the shuffling algorithm, this isn't ideal (may end up
>>> costing more cycles than it saves).
>>>
>>> So, it is a lot of cases of, "Which is worse?".
>>>
>>> You can load a value into a register, creating a dependency, and needing
>>> an extra cycle, but instructions can still be shuffled. Or, one can use
>>> a 64-bit encoding, but then note that the WEXifier can't move the
>>> offending instruction, or move other instructions around it.
>>>
>>>
>>> The compiler tries to weight these factors based on the code being
>>> generated, the value of the constant, and various other fine-tuning
>>> heuristics.
>>>
>>> Well, also things like whether the ISA profile actually allows certain
>>> encodings.
>>>
>>>
>>> Though, for Jumbo encodings with the WEXifier enabled, usually:
>>> If the constant (which failed to fit directly in an immediate field)
>>> fits into a single 32-bit instruction, load it using an instruction;
>>> If it would need more than one instruction word, it ends up preferable
>>> to use a jumbo encoding instead.
>>>
>>> So:
>>> y=x+510; //direct, single instruction
>>> y=x+65521; //two 32-bit instructions
>>> y=x+0xDEADBEEF; //OK, now use a jumbo prefix.
>>>
>>> In the two-op case, it being possible to shuffle the instructions, and
>>> probably execute one or both in parallel with other instructions.
>>>> <
>>>> I know you are thinking your argument is:: that "BGB ISA" is not so bad that
>>>> BGB can't find solutions to these insundry issues using the existing BGB ISA.
>>>> <
>>>> But even a Touring machine with an infinite tape can do that too !
>>> The goal is not "perfection" nor even "perfectly elegant", but more
>>> cost/benefit; best performance relative to cheapest cost, balancing cost
>>> against performance and similar as needed.
>> One goal is something that works. An issue with perfection and elegance may
>> be its predictability. I think predictable things may be more susceptible to
>> malicious attacks. I think there needs to be a certain amount of entropy in the
>> design.
>>>
>>> So, one can mostly optimize the "oh man, this sucks real bad" cases.
>>>
>>> In the case of constants, this would be stuff like needing to do a
>>> PC-relative memory load or similar.
>>>
>>>
>>>
>>> There are many cases where I have instructions that are unnecessary in a
>>> strictly minimalist sense; but which exist more because they help with
>>> performance.
>>>
>>> And, other cases where it makes sense to "just take the loss" for the
>>> fraction of a percent of times it might come up (or, ignore cases that
>>> are unlikely to happen in practice).
>>>
>>>
>>> I don't think I am doing that badly, as there are a lot of other ISA's
>>> that do a lot worse in these areas.
>> IMO one has to be prepared to scrap, burn, and rebuild to make significant
>> changes to a design. I think I am into the double-digits in my scrap and
>> rebuild cycle. Learning how to scrap and rebuild fast and efficiently.
>>
>> I prefer postfixed constants. Postfix constants can be treated as part of the
>> preceding instruction and fetched at the same time, and they do not require
>> interlocks. One cycle to fetch both the instruction and postfixes. Postfixes
>> can keep the instruction size constant. It is tempting to allow two different
>> postfixed constants in a single instruction so that things like store
>> immediate could be supported. One issue is the instruction length with
>> two 128-bit postfixed constants would be about 360-bits. Fetching two
> <
> In a similar vein, I choose 64-bit constants and 128-bit fetches as the low
> end base line.
> <

Low end, in my case:
Direct immediate only;
32-bit fetch.

> I chose 64-bit constants because I was doing a 64-bit machine and 64-bit
> constants are a perfect match. Since the constants are universal, I have
> easy access to 64-bit displacements--and support Fortran common blocks
> of any size (up to about 2^62). Fortran programmers can go back and pass
> everything in common blocks......one can port dusty deck programs change
> the sizes of array bounds and it all just works.
> <
> I chose 128-bit fetches because (over on the data side) the architecture
> is inherently misaligned, and misaligned 64-bit accesses may need a
> pair of aligned 64-bit datums. Over on the fetch side, I wanted the inst
> cache to be identical with the data cache for minimum design effort.
> So, presto 128-bit fetches it was.
> <

OK.

Minimal config can only do 64-bit Load/Store.

Pipeline has enough space to represent up to a 33-bit immediate value
(though, as noted, the largest effective immediate that can be encoded
directly in this case is 25 bits).

The original design would need a 3R1W register file, but demoting
indexed Load/Store to optional on the small end allows for a 2R1W
register file.

Typically no FPU or MMU in this case.

> The maximal length of a My 66000 instruction is 5 words, and I am
> fetching 4. There is an instruction buffer between fetch and decode
> (proper). So, by the time one is decoding a maximal length instruction
> one only has to check if the subsequent fetch hit the cache. If it did,
> the last word is present; and all 5-words pass through decode in a
> single cycle.
> <
> Since the average instruction is between 4 and 5 bytes, AND because
> one has to have an instruction buffer, I scan forward in the IB for
> branch instructions. I prefetch the targets of the branch into IB.
> By the time I get to decode the branch the target is present and
> instructions at the target flow through decode. The cycle count
> of an average branch is 1.03 cycles. Not bad for a machine without
> a branch predictor !
> <
> And finally, once one gets 3-5 instructions ahead of where decode
> is, one can turn off fetching to save power. The code cache is used
> 35% of the available cycles (including branch target fetches).
> <
> The data cache is accessed at a similar rate and theoretically a 2×
> cache could share code and data accesses and not be much of
> a bottleneck. Simulation indicates a code cache plus a data cache
> is 1% slower (8Kb-thoruhg-64Kb) than a combined cache of 2×
> the size. 1% is likely lost in the noise and separate L1s removes
> a lot of potential interference.
> <

I had always used separate Code and Data caches for L1.

Timothy McCaffrey <timcaffrey@aol.com> writes:
>Also, all those weir=
>d indirect modes they
>added to the '020 probably delayed things (and I suspect they were put in t=
>here because
>of Apple, but I have never confirmed that).

Seems unlikely to me. Apollo, HP and Sun were using 68000s since
1981, while Apple's Lisa was introduced only in 1983 at a high price
(and it sold few), and the MacIntosh was introduced in 1984. The
68020 design was completed in the summer of 1983, so why should
Motorola put the modes in because of Apple? Apple used the 68020 only
in the MacIntosh II in 1987, so it's not as if Apple was particularly
eager to use the 68020.

Maybe Mitch Alsup knows how the indirect modes were added to the
68020. My guess would be that they were added because the VAX had
them, and the 68020 architects had not heard of the RISC research (or
did not take it seriously).

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

MitchAlsup <MitchAlsup@aol.com> schrieb:

> I chose 64-bit constants because I was doing a 64-bit machine and 64-bit
> constants are a perfect match. Since the constants are universal, I have
> easy access to 64-bit displacements--and support Fortran common blocks
> of any size (up to about 2^62). Fortran programmers can go back and pass
> everything in common blocks......one can port dusty deck programs change
> the sizes of array bounds and it all just works.

There is one additional problem (outside the scope of an ISA):
Integer sizes.

FORTRAN up to 77 (which is what dusty decks are, by definition) are
only had one integer size, which is 32 bits on today's platforms.
Compilers have switches to set default integer sizes, but these
switches make the compiler violate the Fortran standard because
suddenly the size of an INTEGER is twice the size of a REAL,
which is likely to mess up COMMON-block based storage management
in dusty deck programs.

When trying to bring an old FORTRAN program into the 64-bit world,
some decisions and some work will still be required. A significant
first step would probably be to change the memory management to
dynamic style (which has only been in the language for ~30 years
now :-)

EricP wrote:
> Terje Mathisen wrote:
>> John Levine wrote:
>>> According to BGB  <cr88192@gmail.com>:
>>>
>>>> 8088 was apparently DIP40 with multiplexed Address/Data lines.
>>>>
>>>> Looks like the main difference here between 8086 and 8088 was that 8086
>>>> had 16 pins being multiplexed Address/Data, and 8088 had 8 pins
>>>> multiplexed.
>>>
>>> That's it.  Otherwise they were the same.
>>
>> ---------------------------^were nearly the same.
>>
>> As I mentioned previously, the amount of prefetch code buffer space
>> was different: 8 bytes on the 86, 6 bytes on the 88. I.e. easy to
>> remember since both versions had both an 8 and a 6. :-)
>
> 8086 prefetch queue was three 16-bit words, 6 bytes if IP is even
> or 5 bytes if IP is odd, and 8088 was 4 separate bytes,
> stored in a circular buffer.
>
> Inside the 8086 processor's instruction prefetch circuitry
> http://www.righto.com/2023/01/inside-8086-processors-instruction.html

Thanks, that's new to me! I just dug up my very old asm code which did
work on all the cpus I tried it on:

get_prefetch proc near

; This code can either overwrite the prefetch queue from the front or from
; the back, the following IF determines which will be used.

IF 1
std ; Overwrite from the back
mov di,offset last_opcode
ELSE
cld ; Overwrite from the front
mov di,offset first_opcode
ENDIF
mov cx,MAX_PREFETCH
push cx
push di
mov al,41h ; INC CX opcode
rep stosb ; Restore code if multiple
pop di ; calls to this subroutine!
pop cx

mov ax,0FBh ; == STI opcode, NOP if repeated

ALIGN 16 ; PARA alignment for 486+!

IF ALIGN_COUNT
REPT ALIGN_COUNT
NOP
ENDM
ENDIF

; The following block of code, from DoTest to first_opcode, is exactly
; 16 bytes long, so first_opcode will have the same alignment as DoTest.

DoTest:

mov bx,1234h ; dummy value for MUL/DIV

jmp short $+2 ; Flush prefetch queue

cli ; No IRQs to mix up the result
mul bx
div bx ; MUl/DIV pairs are short and
mul bx ; slow opcodes, to fill the
div bx ; prefetch queue totally!

rep stosb ; Will try to overwrite code
; already in the prefetch q

first_opcode label byte
REPT MAX_PREFETCH - 1 ; starting from the end.
inc cx
ENDM
last_opcode label byte
inc cx

sti
cld
mov ax,cx
ret

get_prefetch endp

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Bernd Linsel wrote:
> On 2023-07-11 11:58, Terje Mathisen wrote:
>> John Levine wrote:
>>>
>>> That's it.  Otherwise they were the same.
>>
>> ---------------------------^were nearly the same.
>>
>> As I mentioned previously, the amount of prefetch code buffer space
>> was different: 8 bytes on the 86, 6 bytes on the 88. I.e. easy to
>> remember since both versions had both an 8 and a 6. :-)
>
> Ken Shirriff claims at
> https://www.righto.com/2023/01/inside-8086-processors-instruction.html
> six bytes (three words) for the '86, and four bytes for the '88.
>
>
Yeah, as I replied to Eric, I misremembered. Checking my code I did use
6 bytes of prefetch (starting from an aligned address) as the 8086
marker. 5 might have been even safer, but a long reverse REP STOSB will
take long enough that all 6 slots will have time to fill up, and only
the bytes beyond that will be overwritten (as seen from the code
prefetcher).

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"