David Heffernan

Has anybody looked at the equivalent for msvc, gcc, clang, etc?

I submitted a QP report for InterlockedCompareExchange128 not restoring rbx

To me it is much cleaner to comment at the top of the routine which register each parameter travels in, and then stick to registers. That allows you to see teg register usage directly rather than having an extra level of indirection.

You are restoring volatile registers there. That's wrong. Most egregious is where you restore rax which has the return value. Ah, i read the bit where you say "the others do nothing". I guess the compiler knows they are volatile / used for param/return passing. I'd remove them all the same. You really must stop using parameter names in asm because it obfuscates the fact they they live in registers, and which ones.

Probably remove that +8. But I'm guessing there. I'd never write asm using variable names. You simply have to write the whole thing using registers to keep track of what it where.

Wrong. It also lets the compiler out the meta data, the unwind data, needed to restore the register in case of an exception. Read Allen's article.

CAS from OTL does restore rbx, but it should do so using .pushnv, for the reasons that Allen's article explains.

No it is not. It modifies rbx and does not restore it.

This is the point that I've been making all along.

Not being able to do that one thing would hardly invalidate the entire enterprise. We'd still be able to use the type as procedure argument which is the main thing we are striving for. But the whole argument is predicted on this single pass. It's no big deal to pass over each type section twice to process forward declarations. Won't make a blind bit of difference to performance. Bottom line is that it is perfectly possible to do this if Emba wanted to.

If what you say were true, then class forward references would not exist.

I can't see where RBX is restored in that InterlockedCompareExchange128 code. It's a NV register. Function needs to start with .PUSHNV RBX I can't vouch for the rest of what it does.

You can't be doing multithreaded programming where "whilst still not perfect" as a valid statement. It's got to be right.

Not sure it's relevant but that x64 should use .PUSHNV to preserve rbx. And I think that also makes .NOFRAME incorrect.

The FMX bitmap that you save is a compressed bitmap. The VCL bitmap is a Windows bitmap, uncompressed.

I don't think that mixing VCL and FMX will work. So I'd just rule that out.

Wouldn't it just be easier to detect the webcam without trying to mix FMX into the system?

With over a million lines of code, it's an epic task to migrate. I can't believe that the increase in compiler time would be significant.

C# compilation is pretty darn fast. Delphi compilation for 64 bit on Windows is not exactly fast. I'm sure that a first pass to define record type layouts followed by a second pass for everything else would not be costly. This isn't going to be about compilation speedy. It's about the pain of refactoring the front end.

It is possible. Plenty of languages can handle this. Emba could implement it if they chose to.

Well no, of course not. So we are stuck with this second rate language.

The argument is that its a single pass compile. So make it two pass. Simples.

You should be able to forward declare their methods. No reason not to be able to do that.

Bloody annoying that this can't be done

I personally don't think you can do better than helpers. That's what I do.