[fpc-pascal] Boolean types

[Mark Morgan Lloyd]

Sorry about my lousy threading, our gateway rejects the occasional 
message (Florian, I'm sure this is nothing to do with your announced 
server change).

>>  > You need to cast nevertheless. It's just that they can be used in
>>  > place of e.g. BOOL parameters for WinAPI functions whereby the
>>  > argument value is passed like the underlying non-Boolean datatype.
>> 
>> Thanks Sven, noted and understood. In practice I've changed them all to 
>> qwords since this is the native size of the system being emulated, which 
 >
 > And why don't you use Boolean64? That's a 64 bit Boolean type with
 > True being 1 and False being 0 (like the normal 1 Byte one).

Because I'm still finding my way through the code I'm transcribing, 
which is in Javascript despite the author being an ALGOL user of many 
years standing, and I haven't entirely got my head around his 
bit-extraction and comparison stuff. Also, albeit simplistically, 
settling on a single type makes it a bit easier to approximate the 
C-style conditional which he's using heavily... his idea of bit 
manipulation is to use lots of / and % operators which I'll try to 
improve but only once I've got the emulator running the MCP (and 
preferably its test tape, even if I have to transcribe that as well).

>> is there an unobtrusive way of changing the property to effectively be
>> 
>> property PB1L: qword read fPB1L write fPB1L;
>> 
>> when assertions aren't being generated? The obvious way would be to use 
>> lots of  $IFOPT C+  but is there anything more concise and maintainable? 
>> Can methods be inlined, and could the compiler successfully optimise-out 
>> a method which was a simple assignment?
 >
 > As long as you don't declare the getter/setter methods as "virtual",
 > but as "inline" I *think* that it should work. Just test it and look
 > at the generated assembler code (using -al option). If it works then
 > then there should be no "call" instruction.

Thanks, I'll play with it. Although I think it might be some while 
before I dare to remove the assertions.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]