Den 2019-08-31 kl. 17:58, skrev Johnny Billquist:
No, I mean an efficient C abi based on our needs. What C under VMS does is more of academic interest :-)On 2019-08-31 16:19, Anders Magnusson wrote:Den 2019-08-31 kl. 14:04, skrev Johnny Billquist:Not in the C ABI, that's the point :-) The only things that are needed in a function call are:On 2019-08-31 05:13, Mouse wrote:Things that CALL do:Push requested register on stack at entry, and automatically restores them again at return.Saves AP and sets up new AP.Saves and sets up new FP.Also: - Longword-aligns SP. - Fiddles some trap enables based on the entry mask.- Sets up fixed condition codes in the stack frame, which the procedurecan fiddle and then have loaded into the PSW by RET. - If CALLS is used instead of CALLG, RET pops additional longwords. - Produces UNPREDICTABLE behaviour in various cases I doubt anyone cares about (such as CALLS SP,dst or CALLS R0,@(R0)+).Right. And maybe some of those things can really be skipped without any negative effects, but I have a feeling that the main gain by JSB is just that by not doing a bunch of things you gain speed. But it is at a cost, and many times you actually want those things as well, and if you do all of them, then the gain from JSB are gone.- Remember return address - Save/restore callee-saved regs (if needed) - Allocate space on stack (if needed)With the "C ABI" you are meaning the Unix (GNU?) C ABI then. Because C under VMS would be using AP, otherwise it wouldn't work combining with any standard libraries or code from other compilers, or whatever...
I just don't want to do a lot of memory cycles that are unneccessary.
Well, no. Since SP/FP/AP have the same values during the whole function execution (modulo VLAs etc...) it's just a matter of which offset is used.Saving/restoring regs take the same time whether or not CALLS is used, so I removed that from the calculation.AP is never needed, and FP only if VLAs are used (or alloca called).You mean it is not used? So then the compiler is constantly computing the offsets from SP? Well, I guess you could definitely do this, but it's a lot messier.
I don't get how the compilers ever would be an issue? They do the same as they always do. Compatibility is a different issue (but a very small one, and not difficult to solve either, especially for VAX...)That's the whole reason for the existence of AP to start with.Experience gained from the PDP-11. You often ended up with ad-hoc solutions that more or less did what a dedicated AP register would do, in the first place, and have it way more standardized had benefits.Of course, with Unix, some of those benefits a almost irrelevant, as most things end up using the same compiler backend. Back in the DEC days, you had all kind of programming languages, and having a nicely standardized calling convention made life much easier and better.Oh well. Then yes. Either change the compiler to actually make use of the AP, or skip that whole part.The work it change pcc to use this ABI was less than an hour, so it's was not a giant work. Especially since all other (modern) archs use similar ABIs.Well, it does mean it's incompatible with all existing compiled code, which is an issue in it self. Not to mention the question of what the gain is in the end, since we do need more manual (well, compiler managed) bookkeeping, which otherwise was done in hardware.
Exactly my point. The only thing that might be a problem is difference in rounding, VAX rounding instead of IEEE. And the chance that anyone would do serious IEEE-required calculations on a VAX is close to NIL. This is for all common calculations. The rest will generate a trap and will be handled in software, like other emulated instructions.That would be far too much inneccessary work. I think making VAX FP act as IEEE is easy and lightweight. Trying to fool zillions of packages are really time-consuming for no gain.2) Make VAX use IEEE floats :-)Personally, I would not use this. I prefer to actively break code thatblindly assumes IEEE floating-point, so I can fix it. (So far, I have found more such code than I have code that legitimately depends on the IEEE behaviour in cases where it differs from the VAX behaviour; indeed, I can't recall a non-artificial example of the latter. Not that I've found all that much of the former.)I agree in the sense that most code do not actually need IEEE, and if they crash because of this, it is almost always artificial creations that explicitly fails, and not the actual meaningful code.But it does raise the point if we should just fix it/fake it so that those stupid artificial tests pass, and just keep the VAX FP for the rest, so that the code will run, also when you have VAX FP.Well, my thinking was mostly to make silly thing pass that are caught today. I don't know if we still trap some INFs, for example, which IEEE allows.So, not doing some big effort. Essentially just becoming even less strict, and just let things roll as much as possible with the minimal amount of changes. Let people get bad values, and funny resolts instead of trapping. We're talking about people running this software on VAXen, and I do not expect that anything serious will be affected or broken by such changes.
-- Ragge