On 2019-09-01 09:14, Anders Magnusson wrote:
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, when you said "Not in the C ABI", it sounded like some established ABI, not just the proposed one.
And my point was only that there is no one unique C ABI. There are several.
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.
How can that be?
If I do a
void foo(int x)
{
char foo[x];
}
the compiler have no clue about how much stack it will need.
And before anyone starts screaming that you cannot do this, since the
size have to be a constant known at compile time, this was changed to be
allowed in C11.
But I can certainly buy that we can always have the arguments on the stack, meaning AP is not truly needed, but referencing through FP could be done.
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...)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.
Well, of course, the compiler always have to solve things in the end, but it does mean you might need something like a frame pointer. Either the hardware provides one already, or your compiler needs to set one up.
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.
Right. So we are thinking the same thing. Good.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol