ZORRAM












Quote:

MEGA_RJ_MICAL wrote: Quote: MEGA_RJ_MICAL wrote: ZORRAM LAPTOP ANNOUNCED Quote: BigD wrote: Yep, but it is spelt with one 'R' (Violent Ken just can't spell) and is limited to 128MB of Ram! are you truly THAT spastic? /m!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@cdimauro

Yes, going from 32bit to 64bit such a creative concept :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@cdimauro

Quote:

So no PMMU is available yet.

Yes, but I have a viable concept of implementing mmu (68040 compatible of course). That’s why I am moving Emu68 to hypervisor, so that I can use supervisor mode mmu for all translations I could need.

Regarding other instructions- all of them as well as all addressing modes should work. Among missing things are the trace modes (t-bits from SR) and eventually wrongly computed ccr flags. Everything missing is somewhere on the schedule.

80-bit fpu is not implemented for now and, if ever, has the lowest priority for me. For most things the double resolution is enough. For very few rare cases (including macos) this could be an issue though. But all demos I tested as well as ray tracers are happy with the fpu as it is now.

cdimauro Quote:

Indeed. The documentation looks wrong.

It looks like the "Bumblebee" core may be a Chinese designed core. Maybe they switched from the SiFive E24 core to the Bumblebee either to reduced the area/transistors or because it was cheaper to license the IP. U.S based SiFive designs are not free which is one of the misnomers that everything RISC-V is open hardware so free. There are license free RISC-V cores but Intel wouldn't have offered $2 billion for the fabless semiconductor business SiFive if it gave everything away for free. Embedded businesses usually want professional tested cores and customer service ... for as cheap as possible.

cdimauro Quote:

I agree. The only thing which is not know is how many transistors are required for such RISC-V implementation, to make a comparison with the 68000. Another thing is that I don't know if the original 68000 could be reimplemented using less transistors, because micro-architecture engineers may have acquired a better knowledge / technologies after 44 years.

The smallest ARM core is the 2 stage Cortex-M0+ which is used in the RP2040 SoC. It is ~50,000 transistors depending on options and only supports a subset of Thumb 1 and 2 (likely better code density than RISC-V C and 68000 but more instructions to execute). Actual transistors will vary depending on whether single cycle or area optimized multiplication and shift are selected. The 3 stage ARM1 with no hardware multiply was ~25,000 transistors and ARM2 ~30,000 transistors with hardware multiplication (both no caches). The Cortex-M0+ is likely using significantly more transistors for low power features (power gating, low power modes, etc.). The ~68,000 transistors of the 68000 includes hardware multiply, some nice features and has good code compression but it was a quick to market microcoded design where the microcode used 1/3 to 1/4 of the transistors by some estimates. I wouldn't be surprised if the TG68K VHDL core configured as 68000 used fewer transistors in an ASIC. Minimal RISC cores are a little smaller at this tiny size which is really for ultra low power embedded use. I couldn't find transistors used for ColdFire cores which save a few transistors over the 68k while mostly using the same encodings but it wasn't worth it in my opinion. ARM and RISC-V can have that market while the 68k has more standard features, better performance and better code density which was the idea behind the original 68000. There were 8 bit CPUs which were much smaller than the 68000, like the 6502 using ~3500 transistors, but the humble little 68000 was not only loved for embedded use but scaled up all the way to the workstation market.

cdimauro Quote:

Interesting. That's why the A53 is so much used: it's the best selling ARM core.

There are likely more chips sold with ARM Cortex-A53 CPUs than any x86-64 CPU as well. The economies of scale of the embedded market are mind boggling. The Cortex-A53 isn't even that good as in order superscalar RISC cores consistently have disappointing performance but it fills the role of the smallest area AArch64 CPU. Customers think they need 64 bit to avoid being left behind and the end of ARM support while ARM marketing has certainly made this look true. Many customers would be better off with a 32 bit in order Cortex-A7 using Thumb 2 and using 30% less memory but this core is even more performance challenged. In order superscalar RISC cores are terrible, especially without an instruction scheduler. The article, "Assembly still matters: Cortex-A53 vs M1" clearly shows that instruction scheduling is so difficult that compilers can't generate good code for them.

https://tech-blog.sonos.com/posts/assembly-still-matters-cortex-a53-vs-m1/

The Cortex-A53 isn't even worst case but far from it for embedded use. It has 32 GP registers, an orthogonal ISA and symmetrical superscalar execution (pipes can we switched depending on unit requirements) but the fat ISA makes supporting superscalar execution of all instructions difficult and of course the 3 cycle load-to-use stalls and only one load/store unit makes instruction scheduling very difficult (lack of superscalar and timing documentation also contributes). The new "standard" AArch64 ISA can't efficiently use the same code for both in order and OoO CPUs because the in order code is so mangled by the instruction scheduler and adds so many instructions that it won't even perform well on OoO CPUs. Compare this to the 1994 in order 68060 where "45%-55% of instructions issued as pairs/triplets (existing 680X0 code)" according to the "The Superscalar Hardware Architecture of the MC68060". This is amazing considering data dependent instructions, two memory accessing instructions in a row and the number of instructions which were not made capable of superscalar operation. There is room for improvement too as the data cache could be dual ported (perhaps with adding another pipe) and more instructions could be made superscalar capable (SWAP is simple with a 32 bit result yet is pOEP only for example). The 68060 double/triplet instruction issues are only down 5%-10% compared to 68060 optimized and scheduled code and either should run nicely on an OoO 68k beast. I couldn't find pairs/triplets issued for RISC CPUs but I suspect in order supercalar RISC CPUs are barely superscalar without an instruction scheduler.

cdimauro Quote:

I also talked recently with a friend of mine which is working at STMicroelectronics (automotive area / products) and it seems that the company has also no interest at all on developing its own architectures (whereas it had some when I joined the company for my internship + thesis. Notably, the LX, which my responsible used to simulate my JPEG 2000 decoder implementation for their embedded market). All companies seem to have given-up in favor of ARM. A now RISC-V as well. They prefer off-the-shelf designs, which could be directly used as they need, with no costs other than licenses. It makes sense from some perspective, but it's quite depressing since everything seems to be flat and creativity is killed (no chance for better products to be developed).

It's easy, safe and cheap to use a la carte ARM. There is good margin to be made making custom SoCs for customers especially with a good business reputation. They get good at it and resist change and innovation. Many big businesses lose their innovation and actively suppress industry innovation. It is usually smaller more flexible businesses willing to take greater risks which come along and revolutionize the industry. This is already part of computer history where Chuck Peddle tried to convince Motorola to create a cost reduced CPU only to be told that it would eat into 6800 sales which they wanted to protect while maintaining the status quo. Then Motorola turned around and revolutionized the market with the 68000 when they decided to retake their embedded market share and desktop/PC and workstation markets all together with one product. Then they turned around and threw it all away for PPC RISC hype.

Last edited by matthey on 12-Sep-2022 at 01:25 AM.
Last edited by matthey on 12-Sep-2022 at 12:40 AM.

michalsc Quote:

80-bit fpu is not implemented for now and, if ever, has the lowest priority for me. For most things the double resolution is enough. For very few rare cases (including macos) this could be an issue though. But all demos I tested as well as ray tracers are happy with the fpu as it is now.

Double precision rounding is changing the results compared to an extended precision FPU. Most of the time it won't cause problems but it certainly can. I don't expect it is a problem for the CBM ieee libraries which set double precision rounding for the program using the libraries as I recall. It is also not likely to be a problem for GCC compiled programs which use double precision algorithms although they do not change from the default of extended precision rounding likely because rounding each instruction's results is slower on real hardware. GCC results may vary from a double precision FPU but the extra precision is usually not a problem as the GCC double precision algorithms do not try to use the extra precision. Vbcc and some older compilers use shorter (fewer instructions needed) extended precision algorithms which depend on the extra precision. Vbcc failed a test suite before a release due to it being executed on UAE with a dual precision FPU where it passed on real hardware. The 68040 and 68060 FPSP packages also use extended precision algorithms so using a 68040.library or 68060.library based on this code could have problems too.

Last edited by matthey on 12-Sep-2022 at 01:08 AM.

@matthey

Quote:

Double precision rounding is changing the results compared to an extended precision FPU. Most of the time it won't cause problems but it certainly can.

Yes, I am aware of that risks and that's why I have mentioned macOS (in shapeshifter/fusion) which most likely suffers from that. But there are still so many things to do that I shift that improving of FPU far, far away, with low priority. Maybe I will change that in some undefined future, especially since aarch64 gives me plenty of 64/128 bit registers which I could use for purposes of 80-bit FPU. In that case I would, however, most likely implement only the FPU subset which is available on 68040/68060 only. The rest would then go, as on real cpus, through FPSP.

Quote:

The 68040 and 68060 FPSP packages also use extended precision algorithms so using a 68040.library or 68060.library based on this code could have problems too.

Luckily this is not an issue on Emu68, since it provides its own 68040.library. I do not need FPSP support libraries here, since the FPU implements all 68881/68882 instructions by itself.

@michalsc

Btw, regarding hypervisor:



it seems everything is up and ready to get it really running now.

@cdimauro

Quote:

Musashi is slow. That's why people uses Emu68.

From Sysinfo, Musashi 68040 emulation is slightly faster than Amiga 4000/040. Name a 68040 @ 25Mhz accelerator card for the Amiga 500 in the $150 to $180 AUD price range.

Barebone TF1260 (missing the 68060 CPU) cost more than Pistorm/RPi 3a/Emu68/preconfigured 32 GB microSD (from Poland).

Quote:

Amiberry is also slower than Emu68.

Offering multiple options can enable the end user to trade between capability and performance like WinUAE's.

Quote:

It doesn't generate many FPS, but it's quite playable.

The lowest resolution mode for Emu68's RTG is 640x480 instead of 320x200/240.

For retro gaming PC ports that use VGA Mode 13h/Mode X, Emu68's RTG needs support 320x200/240 resolution since Amiga OCS/ECS lacks AGA's 320x200/256 resolution 256 color mode.

Quote:

Strange. Both are using 64-bit FP.

For MacOS 8.0/8.1 via Shapeshifter 3.11, the scroll bar button is stuck at the top, but the user can still scroll the file items down or up via the arrow buttons.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

matthey wrote: michalsc Quote: 80-bit fpu is not implemented for now and, if ever, has the lowest priority for me. For most things the double resolution is enough. For very few rare cases (including macos) this could be an issue though. But all demos I tested as well as ray tracers are happy with the fpu as it is now. Double precision rounding is changing the results compared to an extended precision FPU. Most of the time it won't cause problems but it certainly can. I don't expect it is a problem for the CBM ieee libraries which set double precision rounding for the program using the libraries as I recall. It is also not likely to be a problem for GCC compiled programs which use double precision algorithms although they do not change from the default of extended precision rounding likely because rounding each instruction's results is slower on real hardware. GCC results may vary from a double precision FPU but the extra precision is usually not a problem as the GCC double precision algorithms do not try to use the extra precision. Vbcc and some older compilers use shorter (fewer instructions needed) extended precision algorithms which depend on the extra precision. Vbcc failed a test suite before a release due to it being executed on UAE with a dual precision FPU where it passed on real hardware. The 68040 and 68060 FPSP packages also use extended precision algorithms so using a 68040.library or 68060.library based on this code could have problems too.

For my Emu68 microSD config, I renamed 68040.library from my AmigaOS 3.2's LIBS and the AmigaOS installation didn't complain about the missing 68040.library. Booting the same microSD on WinUAE has resulted in AmigaOS installation complaining about the missing 68040.library.
My conclusion is that Emu68 has a built-in 68040.library.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

The lowest resolution mode for Emu68's RTG is 640x480 instead of 320x200/240. For retro gaming PC ports that use VGA Mode 13h/Mode X, Emu68's RTG needs support 320x200/240 resolution since Amiga OCS/ECS lacks AGA's 320x200/256 resolution 256 color mode.

You can use low res modes on Emu68 without any issues. Just define them in p96mode tool. If you do, please remove double scan flag, otherwise the aspect ratio will be broken.

@michalsc

Quote:

michalsc wrote: @Hammer Quote: The lowest resolution mode for Emu68's RTG is 640x480 instead of 320x200/240. For retro gaming PC ports that use VGA Mode 13h/Mode X, Emu68's RTG needs support 320x200/240 resolution since Amiga OCS/ECS lacks AGA's 320x200/256 resolution 256 color mode. You can use low res modes on Emu68 without any issues. Just define them in p96mode tool. If you do, please remove double scan flag, otherwise the aspect ratio will be broken.

It took me a while to figure out the P96mode tool i.e. enter the resolution value and press the return key i.e. implied apply button. I'm used to WinUAE's RTG setup method that skips the P96mode tool usage. There could be a UI issue with the P96mode tool i.e. I don't like the "implied" data entry method and prefer the explicit data entry method.

I'm aware of P96 V3.1.1 UI improvements.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Stock PiStorm/RPI 3a/Emu68 with Quake (Quake-gcc-2.95.3.030, 320x200) demo3 benchmark scored 65.28 fps

From https://thandor.net/benchmark/33
Pentium II 266 scored 64.1 fps
Celeron 300A scored 67.8 fps

https://en.wikipedia.org/wiki/Instructions_per_second
Based on Pentium Pro's 2.7 IPC, Celeron 300A has about 810 MIPS.

With 320x240 resolution, my PiStorm/RPI 3a/Emu68's Quake II performance is smoother when compared to the cited youtube video.

PiStorm supports RPi 3a (quad-core 64-bit ARM Cortex-A53 processor clocked at 1.4 GHz) and the slower RPi Zero 2W (quad-core 64-bit ARM Cortex-A53 processor clocked at 1 GHz). RPi 3a can be end-user overclocked that voids Raspberry's warranty.

PiStorm/RPI 3a/Emu68's temperature is about 52 degrees C with the A500's lid closed.

Last edited by Hammer on 13-Sep-2022 at 06:07 AM.
Last edited by Hammer on 13-Sep-2022 at 05:51 AM.
Last edited by Hammer on 13-Sep-2022 at 05:49 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Threading

Nice solution for allowing older single-threaded apps to run on a multi-threaded OS.

https://www.osnews.com/story/135304/multi-threading-and-globals-on-pumpkin-os/

_________________
All the way, with 68k

agami Quote:

Nice solution for allowing older single-threaded apps to run on a multi-threaded OS. https://www.osnews.com/story/135304/multi-threading-and-globals-on-pumpkin-os/

Duplicate everything global? The Amiga can do that too. It gives an instance of AmigaOS for each task/process (I believe this is what AxRunTime does on Linux). It works fine and increases security but eliminates code sharing which is one of the biggest advantages of the AmigaOS. The benefit of shared libraries, pure programs and the tiny footprint of the AmigaOS goes away. We can have hundreds if not thousands of separate AmigaOS instances on modern high performance PCs so why not while we emulate the 68k CPU and Amiga chipset. It would be a virtual Amiga or virtually not an Amiga.

Last edited by matthey on 16-Sep-2022 at 02:16 PM.
Last edited by matthey on 16-Sep-2022 at 06:38 AM.

@Hammer

Quote:

Hammer wrote: PiStorm supports RPi 3a (quad-core 64-bit ARM Cortex-A53 processor clocked at 1.4 GHz) and the slower RPi Zero 2W (quad-core 64-bit ARM Cortex-A53 processor clocked at 1 GHz).

I have been interested in using the Pi Zero in various projects several years, but every time I look at buying one they are out of stock! Now people are saying they won't be available until some time next year.

Very frustrating, particularly with the performance that PiStorm is getting now. Guess I will just have to be satisfied with the Vampire for now...

bhabbott Quote:

I have been interested in using the Pi Zero in various projects several years, but every time I look at buying one they are out of stock! Now people are saying they won't be available until some time next year. Very frustrating, particularly with the performance that PiStorm is getting now. Guess I will just have to be satisfied with the Vampire for now...

You want more Amiga "performance" but you don't want to see the 68k Amiga modernized? Would RISC OS users be better off using old dying and expensive Acorn Archimedes hardware rather than cheap modernized RPis? Are Amiga users better off using RPi hardware in their old dying and expensive 68k Amigas?

@matthey

Of course the new OS would have code sharing for new 64bit multi-threaded apps.
It would be uneconomical to work on solutions which enable the same for legacy apps from 30+ years ago.

_________________
All the way, with 68k

@kolla

Quote:

kolla wrote: @cdimauro Yes, going from 32bit to 64bit such a creative concept :)

I forgive you only because you're just a user and you have no knowledge about computer architectures.

Specifically, and to rebut your statement, you can take a look to what happened when AMD decided to extend IA-32 to 64-bit with its x86-64 ISA: a HORRIBLE patch came out, which further complicated the architecture and relative implementations (so called microarchitectures).

By comparison, you can take a look at my NEx64T specifically for the 64-bit version, because you can think of it as a 64-bit extension of IA-32. It's also binary-incompatible with IA-32 (yes: x86-64 is NOT binary compatible as well!), however it has A LOT of advantages compared to what AMD did. You can have a very brief view here: https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44169&start=0&post_id=841312&order=0&viewmode=flat&pid=0&forum=17#841312

BTW, I've designed NEx64T after my 64-bit "rethinking" of the 68k (which I've called C64K) and it was strongly influenced by this work. However and after 11 years spent on NEx64T (which evolved over the time: I've produced 10 versions of it) I've acquired much more experience, so I would redesign C64K in a different way now.

This just to highlight that designing an architecture is NOT an easy task and it's not all about "filling the opcode space where there's some hole". And the more constraints you have the more difficult becomes designing an advanced ISA.

@michalsc

Quote:

michalsc wrote: @cdimauro Quote: So no PMMU is available yet. Yes, but I have a viable concept of implementing mmu (68040 compatible of course). That’s why I am moving Emu68 to hypervisor, so that I can use supervisor mode mmu for all translations I could need.

That was my guess when you've written about it.

Is it fully 68040 compatible (all details implemented)? Or "compatible-enough" for the existing software? Because there are differences with ARM's PMMU (of course).

BTW, I saw your other message about the hypervisor: you're close to the goal.
Quote:

Regarding other instructions- all of them as well as all addressing modes should work. Among missing things are the trace modes (t-bits from SR) and eventually wrongly computed ccr flags. Everything missing is somewhere on the schedule.

Trace mode isn't that interesting. Besides for debuggers. So, currently it's not important.

OK, so you're on a good track to cover all 68k instructions.
Quote:

80-bit fpu is not implemented for now and, if ever, has the lowest priority for me. For most things the double resolution is enough. For very few rare cases (including macos) this could be an issue though. But all demos I tested as well as ray tracers are happy with the fpu as it is now.

I agree. In fact, I never used it on WinUAE as well (as most of the people, I think).

Plus... for the MacOS emulation there are better products that could be natively used.

@matthey

Quote:

matthey wrote: cdimauro Quote: Indeed. The documentation looks wrong. It looks like the "Bumblebee" core may be a Chinese designed core. Maybe they switched from the SiFive E24 core to the Bumblebee either to reduced the area/transistors or because it was cheaper to license the IP. U.S based SiFive designs are not free which is one of the misnomers that everything RISC-V is open hardware so free. There are license free RISC-V cores but Intel wouldn't have offered $2 billion for the fabless semiconductor business SiFive if it gave everything away for free. Embedded businesses usually want professional tested cores and customer service ... for as cheap as possible.

Intel's interest was primarily to let SiFive use its fabs instead of the competitors' ones.

So, interest on RISC-V is only "collateral".
Quote:

cdimauro Quote: I agree. The only thing which is not know is how many transistors are required for such RISC-V implementation, to make a comparison with the 68000. Another thing is that I don't know if the original 68000 could be reimplemented using less transistors, because micro-architecture engineers may have acquired a better knowledge / technologies after 44 years. The smallest ARM core is the 2 stage Cortex-M0+ which is used in the RP2040 SoC. It is ~50,000 transistors depending on options and only supports a subset of Thumb 1 and 2 (likely better code density than RISC-V C and 68000 but more instructions to execute). Actual transistors will vary depending on whether single cycle or area optimized multiplication and shift are selected. The 3 stage ARM1 with no hardware multiply was ~25,000 transistors and ARM2 ~30,000 transistors with hardware multiplication (both no caches).

It's quite difficult to compete with such very low numbers. I mean: for some CISC.
Quote:

The Cortex-M0+ is likely using significantly more transistors for low power features (power gating, low power modes, etc.). The ~68,000 transistors of the 68000 includes hardware multiply, some nice features and has good code compression but it was a quick to market microcoded design where the microcode used 1/3 to 1/4 of the transistors by some estimates. I wouldn't be surprised if the TG68K VHDL core configured as 68000 used fewer transistors in an ASIC. Minimal RISC cores are a little smaller at this tiny size which is really for ultra low power embedded use. I couldn't find transistors used for ColdFire cores which save a few transistors over the 68k while mostly using the same encodings but it wasn't worth it in my opinion. ARM and RISC-V can have that market

Indeed. They have a clear win where only a little number of transistors counts. No question here.
Quote:

Many customers would be better off with a 32 bit in order Cortex-A7 using Thumb 2 and using 30% less memory but this core is even more performance challenged. In order superscalar RISC cores are terrible, especially without an instruction scheduler. The article, "Assembly still matters: Cortex-A53 vs M1" clearly shows that instruction scheduling is so difficult that compilers can't generate good code for them. https://tech-blog.sonos.com/posts/assembly-still-matters-cortex-a53-vs-m1/

You've already shared it AFAIR and it was a very cool reading, thanks!
Quote:

The Cortex-A53 isn't even worst case but far from it for embedded use. It has 32 GP registers, an orthogonal ISA and symmetrical superscalar execution (pipes can we switched depending on unit requirements) but the fat ISA makes supporting superscalar execution of all instructions difficult and of course the 3 cycle load-to-use stalls and only one load/store unit makes instruction scheduling very difficult (lack of superscalar and timing documentation also contributes). The new "standard" AArch64 ISA can't efficiently use the same code for both in order and OoO CPUs because the in order code is so mangled by the instruction scheduler and adds so many instructions that it won't even perform well on OoO CPUs.

Well, Apple's M1 shows that you need no assembly tricks & optimizations to get out the most of performances. But because it's an OoO MONSTER!
Quote:

Compare this to the 1994 in order 68060 where "45%-55% of instructions issued as pairs/triplets (existing 680X0 code)" according to the "The Superscalar Hardware Architecture of the MC68060". This is amazing considering data dependent instructions, two memory accessing instructions in a row and the number of instructions which were not made capable of superscalar operation. There is room for improvement too as the data cache could be dual ported (perhaps with adding another pipe) and more instructions could be made superscalar capable (SWAP is simple with a 32 bit result yet is pOEP only for example). The 68060 double/triplet instruction issues are only down 5%-10% compared to 68060 optimized and scheduled code and either should run nicely on an OoO 68k beast.

Going above 2-ways for in-order microarchitectures isn't beneficial. 3-ways makes sense only for OoO uarchs.

Regarding the 68k, I don't care about the SWAP instruction. Except for emulation purposes (of 32-bit little-endian architectures).
Quote:

I couldn't find pairs/triplets issued for RISC CPUs but I suspect in order supercalar RISC CPUs are barely superscalar without an instruction scheduler.

They need it to reduce dependencies & use-after-loads.