Deutsch   English   Français   Italiano  
<vldplu$10drp$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Origins Of Interrupts
Date: Sun, 5 Jan 2025 05:14:58 -0600
Organization: A noiseless patient Spider
Lines: 181
Message-ID: <vldplu$10drp$1@dont-email.me>
References: <vl7j8d$3k2o4$2@dont-email.me> <vl7lbc$1s3m$1@gal.iecc.com>
 <vl7mo8$3od64$1@dont-email.me> <vl95e9$6tj$1@gal.iecc.com>
 <mIVdP.468816$oR74.150363@fx16.iad>
 <ef4daddeddd6e481f93ff66c3ea4c5d8@www.novabbs.org>
 <vl9k1t$2q0r$1@dont-email.me>
 <680847eb7b601d8861e2c3a2e43b1782@www.novabbs.org>
 <vlbo2f$hnpk$1@dont-email.me> <vlbs6t$i8st$1@dont-email.me>
 <b0fbe94bc09c5645bb6bb1d79146072c@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 05 Jan 2025 12:16:15 +0100 (CET)
Injection-Info: dont-email.me; posting-host="bbaa49f4faa7b6b83ca3d925b1edf47e";
	logging-data="1062777"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18IAt7xCAo6WXRMVdb4ydLvk02njtM6sFc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:YwVZF2V+/jDzbPaleOaTrtv6apI=
Content-Language: en-US
In-Reply-To: <b0fbe94bc09c5645bb6bb1d79146072c@www.novabbs.org>
Bytes: 8552

On 1/4/2025 2:36 PM, MitchAlsup1 wrote:
> On Sat, 4 Jan 2025 17:47:09 +0000, Thomas Koenig wrote:
> 
>> Trying to find the relevance to computer architecture... and
>> not really succeeding :-)
> 
> Sometimes even we mundane computer architects run into things that are
> really FUN. Not very often in computer architecture, more often
> elsewhere.

Or, in my case, running into an issue of there seemingly not being much 
more I can improve on (in areas such as general integer performance).


BJX2 Baseline:
   Slightly better performance than RV64GC.
   Better code density;
   Better suited to 32 GPR usage vs 64.

BJX2 XG2:
   Better performance than RV64G or RV64GC
   Better code density than RV64G and RV64GC.


RV64G+Jx (Jx = Jumbo Prefix Extension):
   Better code density and performance than RV64G.
   Still worse than XG2.

RV64G+XG3RV:
    Roughly on par with XG2;
    Granted, XG3RV is "mostly" XG2 with the bits shuffled around.


XG3RV is arguably a more "heavy handed" solution compared with Jx. And, 
seemingly, I get some amount of disbelief mixed with apathy regarding 
the assertion that one can get performance improvements by using a 
prefix encoding to make immediate fields and displacements bigger (vs, 
the seemingly more popular proposal of "hey, why not use 48 bit 
encodings and define an all-new set of instructions?...").


Don't yet have XG3RV fully working on my Verilog core, seems it needs 
more debugging.



Then, seemingly, MIPS goes and for their RV64 cores adds a Load/Store 
Pair, but kinda screws it up by going with two fully independent 
source/dest register fields, and a 4 bit displacement.


Like, yes, it could help, but having a displacement field that doesn't 
even cover an average size stack frame is going to hinder its usefulness.

Though, in theory, could propose that the a jumbo-prefixed encoding 
could expand the displacement to 15 bits.

Also not as much of a fan of "snowflake" instructions that have an 
encoding scheme unique to a particular instruction (or behavior that is 
non-trivial and entirely novel).


Like, in terms of encoding and behavior, often it is novelty that is 
expensive:
Adding new immediate-field layouts or putting the register field in 
different bits;
Performs an action that can't be routed through already existing logic;
....


But, yeah, recently I have mostly been distracted with a lot of 3D printing:
   Trying to make parts for my electronics printer;
   A lot of random stuff.


Random stuff, eg:
Copying the mechanical interface for the Drill Master cordless drill 
battery, and proceeding to try to make my own battery for the thing...

But, my own version seems particularly janky and flimsy vs the original, 
but some of this could be:
Printed the box at 9% infill and with reduced wall thickness (mostly 
because I was previously printing TPU, and ended up printing it with 
more or less the settings I was using for the TPU parts, just with PLA);
Managed to make the screw-holes too small, which with 3D printing is its 
own set of problems.

Less elegant design, looks almost like one just stuck a plastic brick 
onto the bottom of the drill. But, technically, Harbor Freight no longer 
sells the "Drill Master" (or the batteries), having replaced them with 
the "Warrior" drills.


For the redone battery, have gone with NiMH AA cells (vs the original 
NiCd Sub-C cells):
   Nearly the same capacity and similar;
     2800mAh vs 3000mAh.
   Drill seems to be operating mostly within AA power ranges.
     Pulls ~ 1.3A no load, ~ 3A under modest load.
       Or, ~ 54W at 18V;
       As measured by a lab power supply.
     Generally, NiMH cells can tolerate discharge rates of up to ~ 3.0 C.
       Or, ~ 8A for a 2800mAh cell.
   AA's are were cheaper.
     And, for this, one needs 15 of them...


Granted, I do also have access to a more expensive drill (with LiFePO4 
batteries).

The Drill Master does have relatively low torque, which is sometimes a 
useful feature. It is not so great at drilling holes, but often useful 
if one just wants to spin stuff moderately quickly (or wants a drill 
where they can hold stuff free-hand and not have the drill yank it out 
of their hand).

Granted, does have enough torque to drive a 3/16" or 1/4" drill-bit into 
yellow pine or similar, which is probably all they were designing it for 
(don't bother with hole saws though, they don't work).

I have a more expensive cordless drill, but realized it had a 
torque-limit clutch feature (1-15, 1=weakest); setting it to around 4 or 
5 roughly matching the weaker drill.

The Drill-Master had some similar markings, but it doesn't really turn 
much and doesn't really seem to do anything (I suspect was more a 
cosmetic feature in this case).



Can note, TPU is turning out to be more useful than originally thought.
   Need something spring-like: TPU;
   Need something squishy: TPU;
   Need something that is flexible with a grippy resistance-fit: TPU;
   ...

Still not quite like rubber though, had hoped for something that was 
more rubber-like and less like vinyl, but alas. The material itself is 
stiff and not-very-stretchy, but walls are flexible and one can fudge 
its behaviors via settings and infill.

But, random cases where TPU seems like the best option keep coming up.

I also have a spool of Nylon, but not used it yet as it is apparently a 
bit ill-behaved and also was a lot more expensive (and a lot of the 
parts I could use it for, ended up doing with PETG).

Where:
   PLA: Cheapish, OK for bulk structural parts;
     Cracks/breaks if limits exceeded;
     Easier to drive screws into vs PETG, and also holds screws better.
       If speed is right, resistance heating can semi-melt the PLA,
         for a sort of thermal form-tapping
         Too fast though and the screw can melt the plastic.
     Seems easiest to remove from build-plate at around 40C.
       Hotter: Holds on strongly;
       Colder: Also stuck on.
   PETG: Slightly more expensive, more durable than PLA;
     Higher melting point;
     Harder to sand or file;
       But, resists wear a lot better.
     Doesn't accept screws as easily;
     Easiest to remove from build plate when cold:
       It basically self-releases when it cools down.
   TPU: Flexible, slight stretch, moderately more expensive.
     Sanding is not effective.
     Easiest to remove while hot.
       Best pull it off as soon as the printer finishes;
       The more it cools, the more "good and stuck on" it is;
       Generally needs glue stick as a release buffer;
         Else, apparently, it is not coming off the build plate (*1).

========== REMAINDER OF ARTICLE TRUNCATED ==========