On 4/11/2023 12:36 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>> This being partly because:
>>>> Variable size stack frames are evil;
>>>> If one excludes large allocations from the stack (including large
>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>> programs.
>>>
>>> It's not 1989 anymore.
>>>
>>
>> ?...
>>
>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>
> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.
>

But, the actual transition to 32 bits didn't really happen until the
Win9X era in the late 1990s... (even if the i386 and i486 existed
sooner, and games like Doom and similar made use of them).

When I switched to XP X64, it was sort of a sad send-off for the
remaining programs I only had in 16-bit forms. Can still run them in
emulators, but then they can't access the native filesystem, limiting
their usefulness. Granted, most of these programs were also limited to
8.3 filenames, so it arguably wasn't a huge loss...

Also, when I first started learning C, it was in the context of a C
compiler that mostly only targeted MS-DOS and Win16.

Granted, I soon ended up jumping to Cygwin, which targeted native Win32,
once the limitations of 16-bit DOS and Win16 programming became more
apparent (also around the time I did the Win95 to WinNT jump).

Similarly, despite x86-64 coming out when I was in high-school, the
general move to 64-bit Windows didn't really fully happen until Windows
10, where many people with Windows 7 installs were still using 32-bit
versions.

And, even now, one still sees a lot of 32-bit processes in Task Manager
and similar.

> Not to mention the dozens of mainframe and minicomputers available with
> large memory spaces from the last 1960s.
>
> [*] Although in 1979, 4MB was a large amount of physical memory, VMS
> had working sets and paging, as did the 370 successors and most other
> mainframe lines. Even the PDP-10 had 256k words (36-bit) of magnetic
> core memory.

Yeah, these weren't really anything I had seen.

Had seen a video recently where someone was trying to get a late 70s
PDP-11 working. Externally, it could have almost been passed off as late
80s tech, except when the case was taken off, things got a bit weird.

Seemingly, the "beige box era" started a little earlier than I would
have thought. Also a complete absence of bright funky colors, tie die
patterns, wood-grain, or lava-lamps, as usually associated with that
era. Then again, it seems like beige/brown/etc were common colors for
clothing and carpet and similar (based on TV/etc), so maybe its use on
computers wasn't that far off.

I guess, beige box era started to end when PCs started to do white and
gray and similar. Then pretty much everyone settled on black by the
mid/late 2000s (until present).

And, with my FPGA project, I am currently using an old beige PS/2
mechanical keyboard, as this was the only one I could get to work in my
case (on 3.3v).

Where, say, keyboard eras:
Old: DIN-5, no F11 or F12 or cursor keys;
Don't have anything this old.
Medium old:
DIN-5 or PS/2, no "Windows key" or similar;
Slightly less old:
PS/2, has Windows key but little else "funky";
Slightly Later:
PS/2, pointless web-browsing related keys and similar
Say, one has keys with the Internet Explorer and MS Outlook icons;
...
Newer still:
USB, web keys are gone, mostly replaced by media player keys.

Had discovered there is apparently supposed to be a feature with many
USB keyboards and mice, that if both D+ and D- are pulled high by the
host, they switch back to behaving like a PS/2 device.

I had a USB keyboard I had used previously (old FPGA board had a USB ->
PS/2 translator chip), but this trick does not appear to work with it.

Curiously, it does seem to work with an optical mouse. Could almost add
this as a feature to my USB interface module, but would need to use two
more IO pins for pull-up / pull-down control for each USB port.

But, I guess I could also do it externally via a switch, and maybe add
something to my Verilog code to detect that the port is held in the '11'
link state and then enable a PS2 interface for the pins (possibly MUXed
with the dedicated PS/2 port pins; TBD).

Still have not had much luck getting "actual" USB working.
I suspect I am still missing something here.

....

MitchAlsup wrote:
> On Tuesday, April 11, 2023 at 12:36:39 PM UTC-5, Scott Lurndal wrote:
>> BGB <cr8...@gmail.com> writes:
>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>>> BGB <cr8...@gmail.com> writes:
>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>> Michael S <already...@yahoo.com> writes:
>>>>
>>>>> This being partly because:
>>>>> Variable size stack frames are evil;
>>>>> If one excludes large allocations from the stack (including large
>>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>>> programs.
>>>>
>>>> It's not 1989 anymore.
>>>>
>>>
>>> ?...
>>>
>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.
>>
>> Not to mention the dozens of mainframe and minicomputers available with
>> large memory spaces from the last 1960s.
> <
> CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,
> IBM 360s, 370s, 30x0s,
> Univac 1108,
> S.E.L., InterData 32,
> PDP 6, PDP 10, PDP 11, VAX, Alpha,
> All RISC architectures,
> :: all had flat address spaces.
>>
>> [*] Although in 1979, 4MB was a large amount of physical memory, VMS
>> had working sets and paging, as did the 370 successors and most other
>> mainframe lines. Even the PDP-10 had 256k words (36-bit) of magnetic
>> core memory.
> <
> When I bought my first computer in 1995, It came with 4 MB, and after using
> it for 2 days, I went out and bought 16MB more. Since windows 3.1 did not
> use more than 16 MB, I configured the other 4MB as the disk cache, and
> turned off the swapper. My 33 MHz 486 outran my wife's 100 MHz Pentium.

I let my father-in-law buy me a pair of Columbia PC clones in 1982, I
then used them to develop software for his downtown Oslo business.

These were really beefy machines with 256 or 384 kB RAM, one of them
even had a 10 MB hard drive in addition to the 5.25" floppy drive.

> <
> The real question is why anyone would want something other than a large flat
> address space ??
>
It rather seems like a solved problem, just like 2's complement binary
integers.

Terje

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

On Tuesday, April 11, 2023 at 1:55:49 PM UTC-4, MitchAlsup wrote:

> The real question is why anyone would want something other than a large flat
> address space ??

When you have worked on a system that basically does sanity checking *all the time*
you really miss it when you start working on "shoot yourself in the foot" C programming boxes.

It was great getting a log from the customer that told where/what the problem was.
Most of the time, it was all I needed to figure out (and fix) the problem.

With C, you get a segfault (if you're lucky), probably down in some unrelated function and
long after the real problem happened. (Yes, I know there are better languages out there
now).

Many years ago we had a product that transitioned from real-mode to protected-mode
on 16 bit x86. There was an amazing number errors discovered during the process.
I suspect it would be the same with much of today's code.

- Tim

On Tuesday, April 11, 2023 at 1:55:49 PM UTC-4, MitchAlsup wrote:

> > Not to mention the dozens of mainframe and minicomputers available with
> > large memory spaces from the last 1960s.
> <
> CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,

CDC 180 series was segment/selector/descriptor based (they had a 6000 series emulation mode).

> IBM 360s, 370s, 30x0s,
> Univac 1108,

I believe the Univac 2200 expanded the address space by adding something similar to 386 protected mode segments/selectors.

> S.E.L., InterData 32,
> PDP 6, PDP 10, PDP 11, VAX, Alpha,

You didn't mention DG Nova, but the follow-on processors added segment/selectors (if I remember "Soul of a New Machine" correctly).

> All RISC architectures,
> :: all had flat address spaces.

I believe the Honeywell/GE systems (at least the ones used for Multics) used segment/selectors (i.e. 386 protected mode like).

Prime, a big name late 70s, early 80s, I think built something very similar to the Honeywell box.

The HP 3000 mini computer architecture (70s..80s) used the Burroughs large system as inspiration, so the address space was not flat.

- Tim

On 4/11/2023 12:47 PM, MitchAlsup wrote:
> On Tuesday, April 11, 2023 at 12:24:46 PM UTC-5, BGB wrote:
>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>> BGB <cr8...@gmail.com> writes:
>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>> Michael S <already...@yahoo.com> writes:
>>>
>>>> This being partly because:
>>>> Variable size stack frames are evil;
>>>> If one excludes large allocations from the stack (including large
>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>> programs.
>>>
>>> It's not 1989 anymore.
>>>
>> ?...
>>
>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>>
>> Where, say:
>> CS, program;
>> DS = SS, global variables and stack.
>> Also heap for "small" or "tiny" model.
>> ES, stomped for sake of "far" pointers.
> <
> You mean 1995...............

I started learning C in the mid/late 90s, and this stuff was still around.

However, I soon realized "16-bit sucks" and jumped over to Cygwin...

My PC at the time was IIRC a 486 DX2-66.

>>
>> Comparably, 128K is massive...
>>
> But 16GB is standard today. 128K× BIGGER.

??? !

I was pretty sure it was still 1MB for Windows, 8MB for Linux.
Yes, in 64-bit processes.

> <
>>
>> I have tested, and a lot of stuff does not work with a 16K or 32K stack,
>> whereas 64K is borderline (say, Doom works, but Quake overflows the stack).
>>
>> Meanwhile, 128K usually works, and 256K if one "wants to be safe".
> <
> Why not just let the stack grow to whatever size it needs to be.
> It is relatively easy to put SP = 0x7FFFFFFFFFFFFFFF0 and
> ..................................... heap = 0x40000000000000000 and
> never run out of either. (2^62-bit virtual range.)
> <
> Virtual memory works, and hides the complexities of doing it the easy way.
> <

Last I checked, the OS's generally use 40 or 48 bits of virtual address
space.

On BJX2, one could still probably have multi-GB stacks in virtual
memory, but I am not sure I see much point.

A 1MB stack being sufficient is nearly universal.

It is mostly when one goes smaller that annoyances start popping up, but
practically, apart from code occasionally trying to put an oversize
array on the stack, 128K or similar is sufficient.

If virtual memory were more proven in my case, "sure, why not use 1MB?...".

Practically, it means needing to figure out the "SDcard CRC or whatever"
situation (so, one can write blocks to the SDcard without it being like
"hahaha, no").

Otherwise, stuff was "mostly working" on the otherwise read-only access
to the SDcard.

>> Windows typically uses 1MB for the stack, but this seems overkill IME,
>> and also Windows always operates with virtual memory enabled.
>>
> My architecture comes out of reset with the MMUs turned on and working.
> Why would you not want virtual memory enabled ??

Dealing with page-tables and/or TLB Miss handling at boot time seems
like needless issues.

As for why it isn't enabled by default post boot:
For a while, I was stuck with debugging virtual memory enough that
turning it on didn't cause significant reliability issues (such as
freezing or crashing due to TLB miss ISRs).

This is now mostly stable, but I had the "enable virtual memory" code
keyed to the "is there a pagefile?" handling.

But, trying to use a page-file when the underlying media is effectively
read-only, doesn't work out so well...

Could potentially add some "check if we can actually read-write to the
page-file, and disable swap, while otherwise leaving virtual memory
enabled" logic, but have not done so.

There is handling (and an address range for) "virtual memory but
directly mapped to underlying physical memory".

However, the way this is currently implemented would not allow for
dynamically growing the stack (would need to add stuff for "reserved but
not committed" handling in this case; which is currently only
implemented for pagefile backed virtual memory).

As is, its handling is more like: If you request 1MB, it is going to
give you 1MB worth of physically-mapped pages (though, unlike with the
NOMMU mode, these pages need not be contiguous, so memory fragmentation
is at least slightly less of an issue in this case).

Note that as-is, pretty much all of the pagefile backed memory is
currently effectively funneled through a 32MB chunk of physical memory.

Previously, there was also an issue where the stack did not work if it
were put into virtual memory (sorta fixed now; had to get a little hack
with the system-call mechanism to put the syscall parameters and data
into designated memory buffers). But, seemingly still only works with
direct-mapped (crashes and instability result if trying to put it into
pagefile backed memory).

For some reason, program executable code also does not work reliably if
it is put into pagefile backed memory.

However, seemingly the ".data"/".bss" sections and the program heap can
be put into pagefile-backed memory without much issue.

Pretty much all of this is likely more TestKern related issues than
actual hardware-level limitations.

>>
>
>>
>> Say, 128MB of physical-mapped RAM doesn't go very far if one is
>> allocating 1MB for stack buffers and similar.
> <
> As long as your working set is 128KB or smaller it does not mater how
> big the allocation is, what matters is the working set.

Only if you have virtual memory...

With physically-mapped modes (AKA: NOMMU mode), or with direct VA->PA
allocation, once memory is allocated to the stack, one isn't getting it
back until the program terminates or similar.

Also, larger allocations are much worse effected by things like memory
fragmentation in these cases.

Similarly, there are "reasons" why my PBO ABI (and also ELF FDPIC) split
up the text/rodata/... and data/bss sections into two separately managed
chunks...

Granted, this isn't entirely invisible.

And, the effects of some of this are partly why there are not (yet)
Quake2 or Quake3 ports (beyond just the performance issues).

Both effectively use more memory than is viable for NOMMU...

Basically, Quake3 needs ~ 100MB in relatively large contiguous chunks
(after size-tuning it a bit to allow "the hunk" to be smaller), which
does not work for 128MB NOMMU.

Quake 2 is similar, as while it doesn't look much different from Quake 1
in some areas, it pretty much immediately ends up trying to allocate
upwards of 200MB of large contiguous "hunk" memory regions (seemingly
uses multiple "hunk" regions unlike both Quake 1 and 3).

....

But, once pagefile backed virtual memory is more settled, may consider
resuming work on porting these (nevermind if both would likely still be
too slow to be playable...).

Had also noted that despite Doom being able to run on machines with 4MB
of RAM, it seemingly actually requires closer to around 20MB to get the
Doom engine to work (the "4MB" part was seemingly accomplished via a
pagefile or similar in the case of DOS4GW, don't know the specifics
though), ...

I sorta have BtMini2 working, but ironically this was trying to shoehorn
an engine with a Minecraft style terrain system into a memory footprint
more comparable to Quake 1.

Sorta limited due to its overly short draw-distance, and how visibility
lags behind player movement (on the BJX2 core, it is not exactly
difficult to outrun the visible part of the scene).

So, in this case, more a "proof of concept" than anything actually playable.

....

On Tuesday, April 11, 2023 at 8:32:07 AM UTC-5, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:
> >On 4/10/2023 4:13 PM, Scott Lurndal wrote:
> >> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>> Michael S <already...@yahoo.com> writes:
>
> >This being partly because:
> >Variable size stack frames are evil;
> >If one excludes large allocations from the stack (including large
> >arrays), one may find that 128k of stack space is sufficient for most
> >programs.
<
> It's not 1989 anymore.
<
Algol60 had no where other than the stack to put dynamically allocated
arrays.......

On Tuesday, April 11, 2023 at 9:36:34 AM UTC-5, robf...@gmail.com wrote:
> On Tuesday, April 11, 2023 at 9:32:07 AM UTC-4, Scott Lurndal wrote:
> > BGB <cr8...@gmail.com> writes:
> > >On 4/10/2023 4:13 PM, Scott Lurndal wrote:
> > >> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> > >>> Michael S <already...@yahoo.com> writes:
> >
> > >This being partly because:
> > >Variable size stack frames are evil;
> > >If one excludes large allocations from the stack (including large
> > >arrays), one may find that 128k of stack space is sufficient for most
> > >programs.
> > It's not 1989 anymore.
> I may be a bit out of date here, but, I think some rules still apply.
> Passing large objects like arrays as parameters on the stack is not
> generally a good idea. It may lead to copying lots of memory around
> uselessly. Objects can be allocated on the stack but usually they are
> allocated on the heap especially if they are large, so they can be
> managed. Allocating them on the stack forces them to be deallocated
> at method return.
<
> I usually try and statically allocate any buffers that are known to be
> large and can be of a fixed size. This causes the program to fail right
> away at startup, instead of in the middle after processing tons of
> records. It also frees the program from doing memory management
> work while it is running, and moves the work to startup and shutdown.
<
The very vast majority of things I malloc() are structures of dynamic
size (cache descriptors, TLB descriptors, number of cores, ....) at
initialization time, that then stay allocated until the program terminates.
<
> But a lot depends on the purpose and type of application.
> Having said my two cents, I do use a lot more stack space in programs
> that I used to, simply because the space is available. It can reduce
> development time, not thinking through every algorithm. Development
> time cost. I used to do a lot of high-speed development with
> “throw-away” apps.

BGB <cr88192@gmail.com> writes:
>On 4/11/2023 12:47 PM, MitchAlsup wrote:
>> On Tuesday, April 11, 2023 at 12:24:46 PM UTC-5, BGB wrote:
>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>>> BGB <cr8...@gmail.com> writes:
>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>> Michael S <already...@yahoo.com> writes:
>>>>
>>>>> This being partly because:
>>>>> Variable size stack frames are evil;
>>>>> If one excludes large allocations from the stack (including large
>>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>>> programs.
>>>>
>>>> It's not 1989 anymore.
>>>>
>>> ?...
>>>
>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>>>
>>> Where, say:
>>> CS, program;
>>> DS = SS, global variables and stack.
>>> Also heap for "small" or "tiny" model.
>>> ES, stomped for sake of "far" pointers.
>> <
>> You mean 1995...............
>
>I started learning C in the mid/late 90s, and this stuff was still around.
>
>However, I soon realized "16-bit sucks" and jumped over to Cygwin...
>
>My PC at the time was IIRC a 486 DX2-66.
>
>
>>>
>>> Comparably, 128K is massive...
>>>
>> But 16GB is standard today. 128K× BIGGER.
>
>??? !
>
>I was pretty sure it was still 1MB for Windows, 8MB for Linux.
>Yes, in 64-bit processes.

$ ulimit -a
address space limit (Kibytes) (-M) unlimited
core file size (blocks) (-c) 0
cpu time (seconds) (-t) unlimited
data size (Kibytes) (-d) unlimited
file size (blocks) (-f) unlimited
locks (-x) unlimited
locked address space (Kibytes) (-l) 64
message queue size (Kibytes) (-q) 800
nice (-e) 0
nofile (-n) 1024
nproc (-u) 1024
pipe buffer size (bytes) (-p) 4096
max memory size (Kibytes) (-m) unlimited
rtprio (-r) 0
socket buffer size (bytes) (-b) 4096
sigpend (-i) 63878
stack size (Kibytes) (-s) 8192
swap size (Kibytes) (-w) not supported
threads (-T) not supported
process size (Kibytes) (-v) unlimited

8MB for stack is the default.

>
>

>> <
>> Virtual memory works, and hides the complexities of doing it the easy way.
>> <
>
>Last I checked, the OS's generally use 40 or 48 bits of virtual address
>space.

The ARMv8 systems I work with are configurable from 16 bits to 52 bits VA's
on a per-process basis.

>> My architecture comes out of reset with the MMUs turned on and working.
>> Why would you not want virtual memory enabled ??
>
>Dealing with page-tables and/or TLB Miss handling at boot time seems
>like needless issues.

I presume that the MMUs are turned on with an identity[*] mapping. So no
page faults/misses.

[*] PA == VA.

"robf...@gmail.com" <robfi680@gmail.com> writes:
>On Tuesday, April 11, 2023 at 9:32:07=E2=80=AFAM UTC-4, Scott Lurndal wrote=
>:
>> BGB <cr8...@gmail.com> writes:=20
>> >On 4/10/2023 4:13 PM, Scott Lurndal wrote:=20
>> >> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:=20
>> >>> Michael S <already...@yahoo.com> writes:=20
>>=20
>> >This being partly because:=20
>> >Variable size stack frames are evil;=20
>> >If one excludes large allocations from the stack (including large=20
>> >arrays), one may find that 128k of stack space is sufficient for most=20
>> >programs.
>> It's not 1989 anymore.
>
>I may be a bit out of date here, but, I think some rules still apply.
>Passing large objects like arrays as parameters on the stack is not
>generally a good idea. It may lead to copying lots of memory around
>uselessly. Objects can be allocated on the stack but usually they are
>allocated on the heap especially if they are large, so they can be
>managed. Allocating them on the stack forces them to be deallocated
>at method return.

"forces" is not correct. "allows" is more appropriate.

There's no single answer, but modern stacks are multiple megabytes
and there is no reason to invoke a heap allocator when the stack
works perfectly well, particularly for the example above (which
someone had elided) where the allocated data is only used in
the function itself. Heap allocation is not overhead free,
stack allocation is (both are subject to paging residency overhead by
the OS, of course).

Where the allocation size is unbounded and unknown at compile time
one may choose at runtime from which (stack or heap) that the memory
is allocated based on allocation size, or may simply use the heap
(which also has size constraints, of course.) Posix systems
have per-process resource limits for both the stack and heap.

32-bit systems add additional constraints on both heap and
stack sizes due to the limited virtual address space (2GB or
3GB depending on OS configuration).

I generally use mmap() for larger than a page allocations rather than abusing
the heap allocator (malloc). In bare metal applications where performance
and reliability is required, pool allocators are generally preferred.

On Tuesday, April 11, 2023 at 4:44:56 PM UTC-4, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:
> >On 4/11/2023 12:47 PM, MitchAlsup wrote:
> >> On Tuesday, April 11, 2023 at 12:24:46 PM UTC-5, BGB wrote:
> >>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
> >>>> BGB <cr8...@gmail.com> writes:
> >>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
> >>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>>>>>> Michael S <already...@yahoo.com> writes:
> >>>>
> >>>>> This being partly because:
> >>>>> Variable size stack frames are evil;
> >>>>> If one excludes large allocations from the stack (including large
> >>>>> arrays), one may find that 128k of stack space is sufficient for most
> >>>>> programs.
> >>>>
> >>>> It's not 1989 anymore.
> >>>>
> >>> ?...
> >>>
> >>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
> >>>
> >>> Where, say:
> >>> CS, program;
> >>> DS = SS, global variables and stack.
> >>> Also heap for "small" or "tiny" model.
> >>> ES, stomped for sake of "far" pointers.
> >> <
> >> You mean 1995...............
> >
> >I started learning C in the mid/late 90s, and this stuff was still around.
> >
> >However, I soon realized "16-bit sucks" and jumped over to Cygwin...
> >
> >My PC at the time was IIRC a 486 DX2-66.
> >
> >
> >>>
> >>> Comparably, 128K is massive...
> >>>
> >> But 16GB is standard today. 128K× BIGGER.
> >
> >??? !
> >
> >I was pretty sure it was still 1MB for Windows, 8MB for Linux.
> >Yes, in 64-bit processes.
> $ ulimit -a
> address space limit (Kibytes) (-M) unlimited
> core file size (blocks) (-c) 0
> cpu time (seconds) (-t) unlimited
> data size (Kibytes) (-d) unlimited
> file size (blocks) (-f) unlimited
> locks (-x) unlimited
> locked address space (Kibytes) (-l) 64
> message queue size (Kibytes) (-q) 800
> nice (-e) 0
> nofile (-n) 1024
> nproc (-u) 1024
> pipe buffer size (bytes) (-p) 4096
> max memory size (Kibytes) (-m) unlimited
> rtprio (-r) 0
> socket buffer size (bytes) (-b) 4096
> sigpend (-i) 63878
> stack size (Kibytes) (-s) 8192
> swap size (Kibytes) (-w) not supported
> threads (-T) not supported
> process size (Kibytes) (-v) unlimited
>
> 8MB for stack is the default.
> >
> >
>
> >> <
> >> Virtual memory works, and hides the complexities of doing it the easy way.
> >> <
> >
> >Last I checked, the OS's generally use 40 or 48 bits of virtual address
> >space.
> The ARMv8 systems I work with are configurable from 16 bits to 52 bits VA's
> on a per-process basis.
> >> My architecture comes out of reset with the MMUs turned on and working..
> >> Why would you not want virtual memory enabled ??
> >
> >Dealing with page-tables and/or TLB Miss handling at boot time seems
> >like needless issues.
> I presume that the MMUs are turned on with an identity[*] mapping. So no
> page faults/misses.
>
> [*] PA == VA.

Yes, no TLB misses occur during boot.

The Thor2023 MMU automagically initializes a fixed way of the TLB with entries
for the last 256kB of memory on reset, as an identity map, to allow the boot
ROM to be reached. Once the ROM is active one of the first things it does is
add entries to the TLB for I/O and RAM. The processor reset vector goes to
$F…FD0000. There is a scratchpad RAM in the boot address space at
$F…FCxxxx.
Getting the system to boot is a bit scary, but it works much the same way as if
there were no MMU. CPU access is halted until the TLB ready signal is active.
Memory accesses take two extra clock cycles for the map. Two clock is not
much compared to the access time of the DRAM.

On 4/11/2023 1:02 PM, Scott Lurndal wrote:
> MitchAlsup <MitchAlsup@aol.com> writes:
>> On Tuesday, April 11, 2023 at 12:36:39=E2=80=AFPM UTC-5, Scott Lurndal wrot=
>> e:
>>> BGB <cr8...@gmail.com> writes:=20
>>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:=20
>>>>> BGB <cr8...@gmail.com> writes:=20
>>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:=20
>>>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:=20
>>>>>>>> Michael S <already...@yahoo.com> writes:=20
>>>>> =20
>>>>>> This being partly because:=20
>>>>>> Variable size stack frames are evil;=20
>>>>>> If one excludes large allocations from the stack (including large=20
>>>>>> arrays), one may find that 128k of stack space is sufficient for most=
>> =20
>>>>>> programs.=20
>>>>> =20
>>>>> It's not 1989 anymore.=20
>>>>> =20
>>>> =20
>>>> ?...=20
>>>> =20
>>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?.=
>> ..
>>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1=
>> 985.=20
>>> =20
>>> Not to mention the dozens of mainframe and minicomputers available with=
>> =20
>>> large memory spaces from the last 1960s.=20
>> <
>> CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,
>> IBM 360s, 370s, 30x0s,=20
>> Univac 1108,
>
> You left out all the Burroughs boxen, not flat, but large.
>
>
>> S.E.L., InterData 32,=20
>> PDP 6, PDP 10, PDP 11, VAX, Alpha,
>> All RISC architectures,
>> :: all had flat address spaces.
>>> =20
>>> [*] Although in 1979, 4MB was a large amount of physical memory, VMS=20
>>> had working sets and paging, as did the 370 successors and most other=20
>>> mainframe lines. Even the PDP-10 had 256k words (36-bit) of magnetic=20
>>> core memory.
>> <
>> When I bought my first computer in 1995, It came with 4 MB, and after using=
>
> I had an Amiga 1000 in 1986, and had a motorola 88k VME box (SVR3) from 1992-1997
> that I brought home from work when we replaced them with Unisys S/8400 boxes.
>

Well, at least I existed in '86 ...
Wasn't doing much with computers yet though.

Apparently the Amiga's had dedicated hardware mixer chips.

I had on-off considered possibly doing something similar for BJX2,
partly as this could allow it to play S3M tracker music and similar
without eating the CPU.

I might do it a little differently though, likely with 16 channels with
separate left and right volume. Preferably, it could also be used for
game sound effect mixing.

While, theoretically, S3M can do 32 voices at the same time, pretty much
none I had looked at do so, so probably don't need that many voices.

Would probably make sense for it to support 8-bit PCM and A-Law with a
variable sample rate per-channel (probably 1 MHz with a 16-bit clock
divisor).

Not done much yet, not sure if worth the cost (vs just continuing to mix
stuff in software).

Do have a hardware FM synthesis module at least (as opposed to doing
MIDI playback in software). But, MIDI playback in software is a similar
sort of issue (in a computational sense) to S3M playback (and hardware
that could do S3M style mixing could also be used for wavetable MIDI or
similar as well).

>> =20
>> it for 2 days, I went out and bought 16MB more. Since windows 3.1 did not
>> use more than 16 MB, I configured the other 4MB as the disk cache, and=20
>> turned off the swapper. My 33 MHz 486 outran my wife's 100 MHz Pentium.
>
> My first owned computer was a Pentium Pro dual processor system using
> the providence mobo (homebuilt):
>
> https://www.amazon.com/PR440FX-PROVIDENCE-PENTIUM-UWSCSI-MOTHERBOARD/dp/B00MX3PBZG
>
> Replaced 7 years later with an IBM 2 processor intel server.
>

Fairly early on, my parents had a 486SX-33.

My first PC (was given, second-hand) was an 8088 with CGA, but this was
old even then (and was kinda annoyed that I could neither run Windows
nor Doom on the thing). It ran the MS-DOS command-line, and Sim City,
but not a whole lot else...

It also had a 5.25" floppy drive and a fairly small HDD.

I got a 486DX2-66 some time after, and was able to put Win95 on it
(still fairly new at the time). Then, parents went an got a Pentium II
with Win98 (which could run Quake and Quake 2 much more effectively;
they were basically unplayable on my 486).

>> <
>> The real question is why anyone would want something other than a large fla=
>> t=20
>> address space ??
>
> Indeed.
>

If seen as 48-bit, the address space on BJX2 is flat.

The 96-bit space is "flat-ish", though the pointer format and similar
does effectively preclude having memory objects larger than 256TB.

Still can be treated as a large flat address space as far as pointer
arithmetic and __int128 are concerned (using int128 for intptr_t and
diffptr_t and similar in 128-bit ABI mode).

Currently, I suspect that the 128-bit ABI is basically "massive
overkill" for the foreseeable future, so have mostly shelved this idea
for now.

If anything, in the near term, the 96-bit space would likely serve to
allow an OS kernel to be able to have pointers into every user process
at the same time, while allowing each user processes to seemingly have
its own 48-bit address space.

Or, potentially, for programs to optionally share pointers into memory
held within a different logical process (with an explicit "huge"
modifier to tell the compiler to give them a 128-bit pointer).

On 4/11/2023 10:55 AM, MitchAlsup wrote:
> On Tuesday, April 11, 2023 at 12:36:39 PM UTC-5, Scott Lurndal wrote:
>> BGB <cr8...@gmail.com> writes:
>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>>> BGB <cr8...@gmail.com> writes:
>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>> Michael S <already...@yahoo.com> writes:
>>>>
>>>>> This being partly because:
>>>>> Variable size stack frames are evil;
>>>>> If one excludes large allocations from the stack (including large
>>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>>> programs.
>>>>
>>>> It's not 1989 anymore.
>>>>
>>>
>>> ?...
>>>
>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.
>>
>> Not to mention the dozens of mainframe and minicomputers available with
>> large memory spaces from the last 1960s.
> <
> CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,
> IBM 360s, 370s, 30x0s,
> Univac 1108,

Sort of, but not really. The actual 1108 (not its successors), had up
to 262K (they used that value for 2**18) words of memory, approximately
1 MB in today's terms. But it was logically divided into "banks", each
with a base and a limit for addressing and protection. Typical programs
had one I-bank (for instructions) and a D-bank (for data). Both of these
were pointed to by hardware registers. But if you wanted more memory
than would fit into a single bank, you could get it by instantiating
additional banks. All banks used the same addresses but there were
instructions to "point" a bank, that is, load its base and limits into
one of the two hardware bank base and limit registers. This was decided
not "flat".

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Tuesday, April 11, 2023 at 3:23:36 PM UTC-5, BGB wrote:
> On 4/11/2023 12:47 PM, MitchAlsup wrote:

> Last I checked, the OS's generally use 40 or 48 bits of virtual address
> space.
>
So, given a 48-bit VAS, how many stacks of size 1MB can you fit ??
<
How hard do you have to look to find a PC with less than 16GB of main memory ??
>
> On BJX2, one could still probably have multi-GB stacks in virtual
> memory, but I am not sure I see much point.
>
> A 1MB stack being sufficient is nearly universal.
>
> It is mostly when one goes smaller that annoyances start popping up, but
> practically, apart from code occasionally trying to put an oversize
> array on the stack, 128K or similar is sufficient.
>
> If virtual memory were more proven in my case, "sure, why not use 1MB?...".
>
>
> Practically, it means needing to figure out the "SDcard CRC or whatever"
> situation (so, one can write blocks to the SDcard without it being like
> "hahaha, no").
>
> Otherwise, stuff was "mostly working" on the otherwise read-only access
> to the SDcard.
> >> Windows typically uses 1MB for the stack, but this seems overkill IME,
> >> and also Windows always operates with virtual memory enabled.
> >>
> > My architecture comes out of reset with the MMUs turned on and working.
> > Why would you not want virtual memory enabled ??
<
> Dealing with page-tables and/or TLB Miss handling at boot time seems
> like needless issues.
<
That is one of the points of my architecture. The MMU is always on, and
the Boot ROM has page tables for (well) the Boot ROM. This prevents all
sorts of bad-actors altering ROM to take over. So, Boot, itself, does not
take pagefaults, but it certainly does take TLB misses. In fact, you cannot
take pagefaults until you find, configure, and initialize DRAM and some
kind of paging-disk (hard or spinning iron).
>
> There is handling (and an address range for) "virtual memory but
> directly mapped to underlying physical memory".
<
If this is what you want, you can have a TLB entry that maps all of
virtual = physical in one PTE.
>
But I don't understand why you would allow Boot to read things that are
execute only, or to write things that are read-only. ?!? Boot must be as secure
as anything else, you later you have to add special modes (and crap) so that
you Boot without allowing bad-actors a shot at the system (Root kit and all that).
<
> >> Say, 128MB of physical-mapped RAM doesn't go very far if one is
> >> allocating 1MB for stack buffers and similar.
> > <
> > As long as your working set is 128KB or smaller it does not mater how
> > big the allocation is, what matters is the working set.
> Only if you have virtual memory...
<
Which I have by the time that Boot relinquishes control to GuestOS.
<

On 4/11/2023 12:51 PM, Timothy McCaffrey wrote:
> On Tuesday, April 11, 2023 at 1:55:49 PM UTC-4, MitchAlsup wrote:
>
>>> Not to mention the dozens of mainframe and minicomputers available with
>>> large memory spaces from the last 1960s.
>> <
>> CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,
>
> CDC 180 series was segment/selector/descriptor based (they had a 6000 series emulation mode).
>
>> IBM 360s, 370s, 30x0s,
>> Univac 1108,
>
> I believe the Univac 2200 expanded the address space by adding something similar to 386 protected mode segments/selectors.

Not really. The story of the 1108 and its successors adapting to larger
and larger memories (both the maximum physical memory, and the maximum
memory a program could address is a long and complex one, with several
steps and a lot of "uglyness". The requirements for backward
compatibility are bitch. :-(

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On Tuesday, April 11, 2023 at 3:44:56 PM UTC-5, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:
> >On 4/11/2023 12:47 PM, MitchAlsup wrote:
> >> On Tuesday, April 11, 2023 at 12:24:46 PM UTC-5, BGB wrote:
> >>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
> >>>> BGB <cr8...@gmail.com> writes:
> >>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
> >>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>>>>>> Michael S <already...@yahoo.com> writes:
> >>>>
> >>>>> This being partly because:
> >>>>> Variable size stack frames are evil;
> >>>>> If one excludes large allocations from the stack (including large
> >>>>> arrays), one may find that 128k of stack space is sufficient for most
> >>>>> programs.
> >>>>
> >>>> It's not 1989 anymore.
> >>>>
> >>> ?...
> >>>
> >>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
> >>>
> >>> Where, say:
> >>> CS, program;
> >>> DS = SS, global variables and stack.
> >>> Also heap for "small" or "tiny" model.
> >>> ES, stomped for sake of "far" pointers.
> >> <
> >> You mean 1995...............
> >
> >I started learning C in the mid/late 90s, and this stuff was still around.
> >
> >However, I soon realized "16-bit sucks" and jumped over to Cygwin...
> >
> >My PC at the time was IIRC a 486 DX2-66.
> >
> >
> >>>
> >>> Comparably, 128K is massive...
> >>>
> >> But 16GB is standard today. 128K× BIGGER.
> >
> >??? !
> >
> >I was pretty sure it was still 1MB for Windows, 8MB for Linux.
> >Yes, in 64-bit processes.
> $ ulimit -a
> address space limit (Kibytes) (-M) unlimited
> core file size (blocks) (-c) 0
> cpu time (seconds) (-t) unlimited
> data size (Kibytes) (-d) unlimited
> file size (blocks) (-f) unlimited
> locks (-x) unlimited
> locked address space (Kibytes) (-l) 64
> message queue size (Kibytes) (-q) 800
> nice (-e) 0
> nofile (-n) 1024
> nproc (-u) 1024
> pipe buffer size (bytes) (-p) 4096
> max memory size (Kibytes) (-m) unlimited
> rtprio (-r) 0
> socket buffer size (bytes) (-b) 4096
> sigpend (-i) 63878
> stack size (Kibytes) (-s) 8192
> swap size (Kibytes) (-w) not supported
> threads (-T) not supported
> process size (Kibytes) (-v) unlimited
>
> 8MB for stack is the default.
> >
> >
>
> >> <
> >> Virtual memory works, and hides the complexities of doing it the easy way.
> >> <
> >
> >Last I checked, the OS's generally use 40 or 48 bits of virtual address
> >space.
> The ARMv8 systems I work with are configurable from 16 bits to 52 bits VA's
> on a per-process basis.
<
My 66000 can use 23-bit, 33-bit, 43-bit, 53-bit, and 63-bit Virtual address spaces
on a per process basis. {I doubt that 13-bits can be used in any realistic way, though}
<
> >> My architecture comes out of reset with the MMUs turned on and working..
> >> Why would you not want virtual memory enabled ??
> >
> >Dealing with page-tables and/or TLB Miss handling at boot time seems
> >like needless issues.
<
> I presume that the MMUs are turned on with an identity[*] mapping. So no
> page faults/misses.
>
> [*] PA == VA.
<
They COULD be, but I am assuming that Boot contains translation tables for Boot.
The trick is that by the time the core starts executing instructions (yes, the very
first instruction) all the control registers have been initialized by (who other than
Boot). All the registers and control registers arrive with "control".
<
If Boot wanted to make PA = VA there is a PTE for that.
But since (effectively) CR3 arrives with control the MMU is functional by the
time the first instruction is fetched.

On 4/11/2023 2:00 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 4/11/2023 12:36 PM, Scott Lurndal wrote:
>>> BGB <cr88192@gmail.com> writes:
>>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>>>> BGB <cr88192@gmail.com> writes:
>>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>
>>>>>> This being partly because:
>>>>>> Variable size stack frames are evil;
>>>>>> If one excludes large allocations from the stack (including large
>>>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>>>> programs.
>>>>>
>>>>> It's not 1989 anymore.
>>>>>
>>>>
>>>> ?...
>>>>
>>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>>>
>>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.
>>>
>>
>> But, the actual transition to 32 bits didn't really happen until the
>> Win9X era
>
> Nonsense. There were a number of unix systems running in i386 long
> before the toy windows systems were available. Not to mention
> all the 32- bit risc systems in the late 80s and early 90's.
>

Pretty much all the computers people "actually used" were running DOS
and Windows, with an x86 chip of some sort.

Did encounter Macs and similar a few times, but they were rare (Apple
being "mostly dead" at the time, but seemingly coming "back from the
dead" with OSX and the iPhone; but their products are still not much
different than throwing a pile of money into a fire).

Did also randomly encounter an Apple II/e and C64 and similar at various
points, but never really seriously did much on them (a Apple II or C64
being very limited compared with a PC running Win95 or similar); these
being seemingly archaic to me at the time...

Never saw much of them again, until seeing people on YouTube who were
really into them (and some of their engineering aspects being kinda
interesting).

> Nobody took DOS or Win3.1 or even Win95 seriously. It wasn't until
> NT that windows got any traction in the server world, and even then
> it took until NT4 for it to be somewhat usable.

Admittedly.

I switched to dual booting Linux (Slackware) and NT4 in 7th grade, as I
was annoyed by endless crashing from Win95 (and after a crash
irrecoverably lost the contents of my PC's HDD).

NT4 not crashing all the time was a worthwhile tradeoff even if many
programs refused to run on it.

BGB <cr88192@gmail.com> writes:
>On 4/11/2023 2:00 PM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 4/11/2023 12:36 PM, Scott Lurndal wrote:
>>>> BGB <cr88192@gmail.com> writes:
>>>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>>>>>> BGB <cr88192@gmail.com> writes:
>>>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>>>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>>>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>>>
>>>>>>> This being partly because:
>>>>>>> Variable size stack frames are evil;
>>>>>>> If one excludes large allocations from the stack (including large
>>>>>>> arrays), one may find that 128k of stack space is sufficient for most
>>>>>>> programs.
>>>>>>
>>>>>> It's not 1989 anymore.
>>>>>>
>>>>>
>>>>> ?...
>>>>>
>>>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
>>>>
>>>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.
>>>>
>>>
>>> But, the actual transition to 32 bits didn't really happen until the
>>> Win9X era
>>
>> Nonsense. There were a number of unix systems running in i386 long
>> before the toy windows systems were available. Not to mention
>> all the 32- bit risc systems in the late 80s and early 90's.
>>
>
>Pretty much all the computers people "actually used" were running DOS
>and Windows, with an x86 chip of some sort.

That's certainly not my experience. Sun, solbourne and SGI workstations
dominated the 90s, starting with the apollo workstations in the second
half of the 80s.

On Tuesday, April 11, 2023 at 5:09:45 PM UTC-5, Scott Lurndal wrote:
> BGB <cr8...@gmail.com> writes:
> >On 4/11/2023 2:00 PM, Scott Lurndal wrote:
> >> BGB <cr8...@gmail.com> writes:
> >>> On 4/11/2023 12:36 PM, Scott Lurndal wrote:
> >>>> BGB <cr8...@gmail.com> writes:
> >>>>> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
> >>>>>> BGB <cr8...@gmail.com> writes:
> >>>>>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
> >>>>>>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>>>>>>>> Michael S <already...@yahoo.com> writes:
> >>>>>>
> >>>>>>> This being partly because:
> >>>>>>> Variable size stack frames are evil;
> >>>>>>> If one excludes large allocations from the stack (including large
> >>>>>>> arrays), one may find that 128k of stack space is sufficient for most
> >>>>>>> programs.
> >>>>>>
> >>>>>> It's not 1989 anymore.
> >>>>>>
> >>>>>
> >>>>> ?...
> >>>>>
> >>>>> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...
> >>>>
> >>>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.
> >>>>
> >>>
> >>> But, the actual transition to 32 bits didn't really happen until the
> >>> Win9X era
> >>
> >> Nonsense. There were a number of unix systems running in i386 long
> >> before the toy windows systems were available. Not to mention
> >> all the 32- bit risc systems in the late 80s and early 90's.
> >>
> >
> >Pretty much all the computers people "actually used" were running DOS
> >and Windows, with an x86 chip of some sort.
> That's certainly not my experience. Sun, solbourne and SGI workstations
> dominated the 90s, starting with the apollo workstations in the second
> half of the 80s.
<
I was assigned an Apollo workstation when I arrived at Motorola in 1983.
{The network was crap (losing tokens) but the rest of the machine was solid..}

On 4/11/2023 4:54 PM, MitchAlsup wrote:
> On Tuesday, April 11, 2023 at 3:23:36 PM UTC-5, BGB wrote:
>> On 4/11/2023 12:47 PM, MitchAlsup wrote:
>
>> Last I checked, the OS's generally use 40 or 48 bits of virtual address
>> space.
>>
> So, given a 48-bit VAS, how many stacks of size 1MB can you fit ??

A lot.

Granted, my concern is more for the cases where one is not using virtual
memory.

> <
> How hard do you have to look to find a PC with less than 16GB of main memory ??

Not very hard...

https://www.amazon.com/Dell-Optiplex-3020-Computer-Bit-Multi-Language/dp/B08XZ53J4X

Just one example of many others...

Bigger question is if one wants to both with a PC with less than 16GB of
RAM with modern Windows....

>>
>> On BJX2, one could still probably have multi-GB stacks in virtual
>> memory, but I am not sure I see much point.
>>
>> A 1MB stack being sufficient is nearly universal.
>>
>> It is mostly when one goes smaller that annoyances start popping up, but
>> practically, apart from code occasionally trying to put an oversize
>> array on the stack, 128K or similar is sufficient.
>>
>> If virtual memory were more proven in my case, "sure, why not use 1MB?...".
>>
>>
>> Practically, it means needing to figure out the "SDcard CRC or whatever"
>> situation (so, one can write blocks to the SDcard without it being like
>> "hahaha, no").
>>
>> Otherwise, stuff was "mostly working" on the otherwise read-only access
>> to the SDcard.
>>>> Windows typically uses 1MB for the stack, but this seems overkill IME,
>>>> and also Windows always operates with virtual memory enabled.
>>>>
>>> My architecture comes out of reset with the MMUs turned on and working.
>>> Why would you not want virtual memory enabled ??
> <
>> Dealing with page-tables and/or TLB Miss handling at boot time seems
>> like needless issues.
> <
> That is one of the points of my architecture. The MMU is always on, and
> the Boot ROM has page tables for (well) the Boot ROM. This prevents all
> sorts of bad-actors altering ROM to take over. So, Boot, itself, does not
> take pagefaults, but it certainly does take TLB misses. In fact, you cannot
> take pagefaults until you find, configure, and initialize DRAM and some
> kind of paging-disk (hard or spinning iron).
>

I went the route of having MMU disabled on reset, with the kernel being
loaded with the MMU still disabled (the kernel then sets up virtual
memory for its own use).

Had originally wanted to have the page-table stuff in the Boot ROM, but
ended up not doing it that way (mostly because the ROM is 32K, and I
have ended up eating up a lot of it mostly doing boot-time sanity checks
for the CPU).

Also misc stuff like eliminating the hardware character ROM (in favor of
glyph RAM), which means the Boot ROM now needs to have all the font
glyphs to be able to display text (but did take note that I can fit
pretty much all of ASCII into 5x6 pixel character cells, which can then
be unpacked to the 8x8 cells needed for the display hardware).

>>
>> There is handling (and an address range for) "virtual memory but
>> directly mapped to underlying physical memory".
> <
> If this is what you want, you can have a TLB entry that maps all of
> virtual = physical in one PTE.

But, one can also have a bit in the MMU control register, and have it
not set, then the TLB is like, "Yep, VA==PA".

Originally, TLB also disabled itself during interrupts, but timing
turned into a problem, so this responsibility was moved to the L1 caches.

And, this in turn is because it is basically impossible to handle a TLB
Miss inside of an ISR with a software-managed TLB.

But, as a drawback, it also means that in my case, handling a system
call basically requires full context switches.

Say:
Program -> SysCall ISR
Saves off program registers into task context;
Switches to kernel SysCall handler task context;
Reloads SysCall handler registers;
Return from ISR (into supervisor mode).
SysCall handler does its thing;
SysCall handler triggers SysCall ISR to pass control to program;
Above process repeats.

Possibly not the most efficient mechanism possible.

Could be it more efficient to do it more like RISC-V, but multiple sets
of banked registers would be expensive.

But, can be generalized to allow things like COM-style calls between
arbitrary processes without any additional overhead (one needs a
task/thread whose sole existence is merely to handle incoming method
calls on exported COM objects...).

I had planned to rework TKRA-GL to being able to work this way, possibly
also dispatching the request to a GL backend running on a different
core, but haven't gotten this fully implemented yet (this is a bit of a
restructuring effort).

Also the frontend/backend interface isn't quite as straightforward as
naively wrapping every OpenGL call (this would result in excessive
overhead in some cases). Effectively, one needs to keep a lot of state
on the client side, and then preferably only talk to the backend when it
is time to "actually draw something" or similar (so, "glDrawArrays()" or
similar will call into the backend; but glEnable/glDisable/... will not).

There is no standardized interface for such a "OpenGL frontend/backend
COM-object interface" that I am aware of though to use as a design
reference.

>>
> But I don't understand why you would allow Boot to read things that are
> execute only, or to write things that are read-only. ?!? Boot must be as secure
> as anything else, you later you have to add special modes (and crap) so that
> you Boot without allowing bad-actors a shot at the system (Root kit and all that).
> <

Probably at this stage, no one is going to root-kit the SDcard.
This is an issue beyond the scope of what I will address at the moment
though.

There is pretty much nothing the boot ROM can do that would be useful
against a compromised OS kernel.

The most it could do would be to reject booting from untrusted removable
media or similar.

For most of my life though, on the PC side of things, it was sufficient
to be like:
"Is there 55-AA?", "Yes", "Boot it."

I went with something vaguely similar to the RasPi.

Namely:
Check SDCard for a bootloader file ("BOOTLOAD.SYS");
Boot ROM needs to understand FAT32, etc;
If found, load it;
Else, print error message and die.

Where, "BOOTLOAD.SYS" is the same 'PEL4' binary format used by TestKern.
Theoretically, did also add code (untested) for ELF images and similar,
and for more conventional PE/COFF.

If I wanted to get fancy, I could maybe consider allowing BOOTLOAD.SYS
to be like:
#!/bin/tkshell.sys
Or similar.

Or, maybe consider changing it to "BOOTBJX2.SYS" or similar, or maybe
have it default to looking inside a folder (as opposed to the root
directory).

>>>> Say, 128MB of physical-mapped RAM doesn't go very far if one is
>>>> allocating 1MB for stack buffers and similar.
>>> <
>>> As long as your working set is 128KB or smaller it does not mater how
>>> big the allocation is, what matters is the working set.
>> Only if you have virtual memory...
> <
> Which I have by the time that Boot relinquishes control to GuestOS.
> <
>

Seems unnecessary IMO.

Having anything non-trivial set up that the ROM needs to pass off to the
OS kernel, seems like a potential mess (as opposed to starting the
kernel in a more or less "bare metal" state).

BGB <cr88192@gmail.com> writes:
>On 4/11/2023 8:32 AM, Scott Lurndal wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> This being partly because:
>>> Variable size stack frames are evil;
>>> If one excludes large allocations from the stack (including large
>>> arrays), one may find that 128k of stack space is sufficient for most
>>> programs.
>>
>> It's not 1989 anymore.
>>
>
>?...
>
>AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?...

The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1985.

Not to mention the dozens of mainframe and minicomputers available with
large memory spaces from the last 1960s.

[*] Although in 1979, 4MB was a large amount of physical memory, VMS
had working sets and paging, as did the 370 successors and most other
mainframe lines. Even the PDP-10 had 256k words (36-bit) of magnetic
core memory.

On Tuesday, April 11, 2023 at 12:24:46 PM UTC-5, BGB wrote:
> On 4/11/2023 8:32 AM, Scott Lurndal wrote:
> > BGB <cr8...@gmail.com> writes:
> >> On 4/10/2023 4:13 PM, Scott Lurndal wrote:
> >>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>>> Michael S <already...@yahoo.com> writes:
> >
> >> This being partly because:
> >> Variable size stack frames are evil;
> >> If one excludes large allocations from the stack (including large
> >> arrays), one may find that 128k of stack space is sufficient for most
> >> programs.
> >
> > It's not 1989 anymore.
> >
> ?...
>
> AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?....
>
> Where, say:
> CS, program;
> DS = SS, global variables and stack.
> Also heap for "small" or "tiny" model.
> ES, stomped for sake of "far" pointers.
<
You mean 1995...............
>
> Comparably, 128K is massive...
>
But 16GB is standard today. 128K× BIGGER.
<
>
> I have tested, and a lot of stuff does not work with a 16K or 32K stack,
> whereas 64K is borderline (say, Doom works, but Quake overflows the stack).
>
> Meanwhile, 128K usually works, and 256K if one "wants to be safe".
<
Why not just let the stack grow to whatever size it needs to be.
It is relatively easy to put SP = 0x7FFFFFFFFFFFFFFF0 and
...................................... heap = 0x40000000000000000 and
never run out of either. (2^62-bit virtual range.)
<
Virtual memory works, and hides the complexities of doing it the easy way.
<
> Windows typically uses 1MB for the stack, but this seems overkill IME,
> and also Windows always operates with virtual memory enabled.
>
My architecture comes out of reset with the MMUs turned on and working.
Why would you not want virtual memory enabled ??
>

>
> Say, 128MB of physical-mapped RAM doesn't go very far if one is
> allocating 1MB for stack buffers and similar.
<
As long as your working set is 128KB or smaller it does not mater how
big the allocation is, what matters is the working set.
>

On Tuesday, April 11, 2023 at 11:21:46 AM UTC-4, Scott Lurndal wrote:
> "robf...@gmail.com" <robf...@gmail.com> writes:
> >On Tuesday, April 11, 2023 at 9:32:07=E2=80=AFAM UTC-4, Scott Lurndal wrote=
> >:
> >> BGB <cr8...@gmail.com> writes:=20
> >> >On 4/10/2023 4:13 PM, Scott Lurndal wrote:=20
> >> >> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:=20
> >> >>> Michael S <already...@yahoo.com> writes:=20
> >>=20
> >> >This being partly because:=20
> >> >Variable size stack frames are evil;=20
> >> >If one excludes large allocations from the stack (including large=20
> >> >arrays), one may find that 128k of stack space is sufficient for most=20
> >> >programs.
> >> It's not 1989 anymore.
> >
> >I may be a bit out of date here, but, I think some rules still apply.
> >Passing large objects like arrays as parameters on the stack is not
> >generally a good idea. It may lead to copying lots of memory around
> >uselessly. Objects can be allocated on the stack but usually they are
> >allocated on the heap especially if they are large, so they can be
> >managed. Allocating them on the stack forces them to be deallocated
> >at method return.
> "forces" is not correct. "allows" is more appropriate.
>
> There's no single answer, but modern stacks are multiple megabytes
> and there is no reason to invoke a heap allocator when the stack
> works perfectly well, particularly for the example above (which
> someone had elided) where the allocated data is only used in
> the function itself. Heap allocation is not overhead free,
> stack allocation is (both are subject to paging residency overhead by
> the OS, of course).
>
> Where the allocation size is unbounded and unknown at compile time
> one may choose at runtime from which (stack or heap) that the memory
> is allocated based on allocation size, or may simply use the heap
> (which also has size constraints, of course.) Posix systems
> have per-process resource limits for both the stack and heap.
>
> 32-bit systems add additional constraints on both heap and
> stack sizes due to the limited virtual address space (2GB or
> 3GB depending on OS configuration).
>
> I generally use mmap() for larger than a page allocations rather than abusing
> the heap allocator (malloc). In bare metal applications where performance
> and reliability is required, pool allocators are generally preferred.

There is a "new" C feature, the cleanup attribute. It causes a cleanup function whenever
a variable goes out of scope:

https://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html

Better than using alloca() IMNSHO.

- Tim

Timothy McCaffrey <timcaffrey@aol.com> writes:
>On Tuesday, April 11, 2023 at 11:21:46=E2=80=AFAM UTC-4, Scott Lurndal wrot=
>e:
>> "robf...@gmail.com" <robf...@gmail.com> writes:=20

>> >Passing large objects like arrays as parameters on the stack is not=20
>> >generally a good idea. It may lead to copying lots of memory around=20
>> >uselessly. Objects can be allocated on the stack but usually they are=20
>> >allocated on the heap especially if they are large, so they can be=20
>> >managed. Allocating them on the stack forces them to be deallocated=20
>> >at method return.
>> "forces" is not correct. "allows" is more appropriate.=20
>>=20
>> There's no single answer, but modern stacks are multiple megabytes=20
>> and there is no reason to invoke a heap allocator when the stack=20
>> works perfectly well, particularly for the example above (which=20
>> someone had elided) where the allocated data is only used in=20
>> the function itself. Heap allocation is not overhead free,=20
>> stack allocation is (both are subject to paging residency overhead by=20
>> the OS, of course).=20
>>=20
>> Where the allocation size is unbounded and unknown at compile time=20
>> one may choose at runtime from which (stack or heap) that the memory=20
>> is allocated based on allocation size, or may simply use the heap=20
>> (which also has size constraints, of course.) Posix systems=20
>> have per-process resource limits for both the stack and heap.=20
>>=20
>> 32-bit systems add additional constraints on both heap and=20
>> stack sizes due to the limited virtual address space (2GB or=20
>> 3GB depending on OS configuration).=20
>>=20
>> I generally use mmap() for larger than a page allocations rather than abu=
>sing=20
>> the heap allocator (malloc). In bare metal applications where performance=
>=20
>> and reliability is required, pool allocators are generally preferred.
>
>
>There is a "new" C feature, the cleanup attribute. It causes a cleanup fun=
>ction whenever
>a variable goes out of scope:
>
>https://echorand.me/site/notes/articles/c_cleanup/cleanup_attribute_c.html

For the most part, I use C++ which has had cleanup functions
from day one.

>
>Better than using alloca() IMNSHO.

If you are fortunate enough to have access to a compiler
that supports the new standard cleanup attribute; we're still using gcc 4.8.

And GCC has had a similar attribute for many years, albeit non-portable.

__attribute__ (cleanup(function))

MitchAlsup <MitchAlsup@aol.com> writes:
>On Tuesday, April 11, 2023 at 12:36:39=E2=80=AFPM UTC-5, Scott Lurndal wrot=
>e:
>> BGB <cr8...@gmail.com> writes:=20
>> >On 4/11/2023 8:32 AM, Scott Lurndal wrote:=20
>> >> BGB <cr8...@gmail.com> writes:=20
>> >>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:=20
>> >>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:=20
>> >>>>> Michael S <already...@yahoo.com> writes:=20
>> >>=20
>> >>> This being partly because:=20
>> >>> Variable size stack frames are evil;=20
>> >>> If one excludes large allocations from the stack (including large=20
>> >>> arrays), one may find that 128k of stack space is sufficient for most=
>=20
>> >>> programs.=20
>> >>=20
>> >> It's not 1989 anymore.=20
>> >>=20
>> >=20
>> >?...=20
>> >=20
>> >AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?.=
>..
>> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1=
>985.=20
>>=20
>> Not to mention the dozens of mainframe and minicomputers available with=
>=20
>> large memory spaces from the last 1960s.=20
><
>CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,
>IBM 360s, 370s, 30x0s,=20
>Univac 1108,

You left out all the Burroughs boxen, not flat, but large.

>S.E.L., InterData 32,=20
>PDP 6, PDP 10, PDP 11, VAX, Alpha,
>All RISC architectures,
>:: all had flat address spaces.
>>=20
>> [*] Although in 1979, 4MB was a large amount of physical memory, VMS=20
>> had working sets and paging, as did the 370 successors and most other=20
>> mainframe lines. Even the PDP-10 had 256k words (36-bit) of magnetic=20
>> core memory.
><
>When I bought my first computer in 1995, It came with 4 MB, and after using=

I had an Amiga 1000 in 1986, and had a motorola 88k VME box (SVR3) from 1992-1997
that I brought home from work when we replaced them with Unisys S/8400 boxes.

>=20
>it for 2 days, I went out and bought 16MB more. Since windows 3.1 did not
>use more than 16 MB, I configured the other 4MB as the disk cache, and=20
>turned off the swapper. My 33 MHz 486 outran my wife's 100 MHz Pentium.

My first owned computer was a Pentium Pro dual processor system using
the providence mobo (homebuilt):

https://www.amazon.com/PR440FX-PROVIDENCE-PENTIUM-UWSCSI-MOTHERBOARD/dp/B00MX3PBZG

Replaced 7 years later with an IBM 2 processor intel server.

><
>The real question is why anyone would want something other than a large fla=
>t=20
>address space ??

Indeed.

On Tuesday, April 11, 2023 at 1:02:13 PM UTC-5, Scott Lurndal wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >On Tuesday, April 11, 2023 at 12:36:39=E2=80=AFPM UTC-5, Scott Lurndal wrot=
> >e:
> >> BGB <cr8...@gmail.com> writes:=20
> >> >On 4/11/2023 8:32 AM, Scott Lurndal wrote:=20
> >> >> BGB <cr8...@gmail.com> writes:=20
> >> >>> On 4/10/2023 4:13 PM, Scott Lurndal wrote:=20
> >> >>>> an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:=20
> >> >>>>> Michael S <already...@yahoo.com> writes:=20
> >> >>=20
> >> >>> This being partly because:=20
> >> >>> Variable size stack frames are evil;=20
> >> >>> If one excludes large allocations from the stack (including large=20
> >> >>> arrays), one may find that 128k of stack space is sufficient for most=
> >=20
> >> >>> programs.=20
> >> >>=20
> >> >> It's not 1989 anymore.=20
> >> >>=20
> >> >=20
> >> >?...=20
> >> >=20
> >> >AFAIK, back then stack sizes then were usually smaller, say, 8K or 16K?.=
> >..
> >> The VAX had a 32-bit flat address space in 1978[*]. The i386 had one by 1=
> >985.=20
> >>=20
> >> Not to mention the dozens of mainframe and minicomputers available with=
> >=20
> >> large memory spaces from the last 1960s.=20
> ><
> >CDC 6600, 7600, CRAY 1, 1S, XMP, YMP,
> >IBM 360s, 370s, 30x0s,=20
> >Univac 1108,
>
> You left out all the Burroughs boxen, not flat, but large.
<
Intentionally ! I also left out ICL, Burroughs 5000 and 6000, GE 645, ...
>
>
> >S.E.L., InterData 32,=20
> >PDP 6, PDP 10, PDP 11, VAX, Alpha,
> >All RISC architectures,
> >:: all had flat address spaces.
> >>=20
> >> [*] Although in 1979, 4MB was a large amount of physical memory, VMS=20
> >> had working sets and paging, as did the 370 successors and most other=20
> >> mainframe lines. Even the PDP-10 had 256k words (36-bit) of magnetic=20
> >> core memory.
> ><
> >When I bought my first computer in 1995, It came with 4 MB, and after using=
>
> I had an Amiga 1000 in 1986, and had a motorola 88k VME box (SVR3) from 1992-1997
> that I brought home from work when we replaced them with Unisys S/8400 boxes.
<
So, you had one of my 88K machines.....................interdesting.............
<
I use the word "my" because that was pretty much my ISA, pipeline, and interconnect.
>
> >=20
> >it for 2 days, I went out and bought 16MB more. Since windows 3.1 did not
> >use more than 16 MB, I configured the other 4MB as the disk cache, and=20
> >turned off the swapper. My 33 MHz 486 outran my wife's 100 MHz Pentium.
> My first owned computer was a Pentium Pro dual processor system using
> the providence mobo (homebuilt):
>
> https://www.amazon.com/PR440FX-PROVIDENCE-PENTIUM-UWSCSI-MOTHERBOARD/dp/B00MX3PBZG
>
> Replaced 7 years later with an IBM 2 processor intel server.
>
> ><
> >The real question is why anyone would want something other than a large fla=
> >t=20
> >address space ??
>
> Indeed.