Re: Loops (was Re: do { quit; } else { })

On 22/04/2025 12:28, bart wrote:

On 22/04/2025 02:06, Waldek Hebisch wrote:

bart <bc@freeuk.com> wrote:

 

I've seen a 33KB C file that expanded to 4MB after preprocessing. Macros
are evil.

>
If macros were forbiden authors would probably write 4MB "by hand"
(or rather using editor cut and paste).  Actually, creating first
version probably would be not that hard, but maintanence would
take a lot of effort (due to volume).

  It would probably be done by a script. This resulting code is not something to be written or consumed by a human. Which is an odd thing to say about a HLL.
 The example below is not as bad: the lines are only up to 1K chars instead of 50K.
 (I thought my own generated C code was poor; it's actually a million times more readable.)
 

Of course, macro generated code is likely to contain significant
fraction of useless instructions, but removing them by hand would
be substantial work.  And trying to directly produce trimmed
version would need a lot of work.  It is much cheaper to
depend on optimizer to remove redundancies and useless instructions.

 How about writing decent, sensible code in the first place?
 

Assuming that hand written version would be 80% smaller, you would
have 800KB to write, that is more than 20 times the original
source.  So in this case macros probably saved about 95% of
work needed when coding without macros.

 You haven't seen this example, you don't know how bad it is, or how effective it was as a solution to whatever problem it was trying to solve, and yet YOU'RE MAKING EXCUSES FOR IT!
 This is a really odd phenomenon: is there no C code on the planet, that anybody here will admit that is badly written? Or that might be forced into being badly written due to shortcomings of the language?
 Here's a challenge for everyone here: please post an example, or a link to an example, that you think is truly appalling code.
 

Here's a nice example:
>
         op_arith(L, l_addi, luai_numadd);
>
Innocent-looking isn't it? It expands to this:
>
{TValue*v1=(&((base+((((int)((((i)>>((((0+7)+8)+1)))&((~((~(Instruction)0)<<(8)))<<(0)))))))))->val);TValue*v2=(&((base+((((int)((((i)>>(((((0+7)+8)+1)+8)))&((~((~(Instruction)0)<<(8)))<<(0)))))))))->val);{StkId
ra=(base+(((int)((((i)>>((0+7)))&((~((~(Instruction)0)<<(8)))<<(0)))))));if(((((v1))->tt_)==(((3)|((0)<<4))))&&((((v2))->tt_)==(((3)|((0)<<4))))){lua_Integer
i1=(((v1)->value_).i);lua_Integer
i2=(((v2)->value_).i);pc++;{TValue*io=((&(ra)->val));((io)->value_).i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));((io)->tt_=(((3)|((0)<<4))));};}else{lua_Number
n1;lua_Number
n2;if((((((v1))->tt_)==(((3)|((1)<<4))))?((n1)=(((v1)->value_).n),1):(((((v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)(((((v1)->value_).i)))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?((n2)=(((v2)->value_).n),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=((lua_Number)(((((v2)->value_).i)))),1):0))){pc++;{TValue*io=((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|((1)<<4))));};}};};};
>
 From this, I had to find the bug in my compiler.

>
Not bad, I sometimes had to look for bugs in much bigger piece of
code.

 So that means there's nothing wrong with it? Remember this is one expression.
 

(Lua is an interpreter; I write interpreters and they are several times
faster than Lua for equivalant inputs. I don't need to use such tricks.)

>
IIUC Lua has some interesting properties.  Above I see masking and
tag manipulations, presumably this is needed to implement Lua
properties.

 Here you are making excuses again. Yes, Lua uses tags on some 64-bit value; so what? That can be done using ordinary code. Or if macros have to be used, they can be simple too.
 My own product uses apparently inefficient 128-bit values, it does everything 'wrong' but it uses readable HLL code with minimal use of macros, and yet it can run at several times the speed of Lua even unoptimised. You don't need to write gobbledygook.
 BTW here is that macro definition from Lua:
   #define op_arith(L,iop,fop) {  \
    TValue *v1 = vRB(i);  \
    TValue *v2 = vRC(i);  \
    op_arith_aux(L, v1, v2, iop, fop); }
 It calls yet more macros, and those in turn call others; here are a few for vRB:
    #define vRB(i)    s2v(RB(i))
   #define s2v(o)    (&(o)->val)
   #define RB(i)    (base+GETARG_B(i))
   #define GETARG_A(i)    getarg(i, POS_A, SIZE_A)
   #define getarg(i,pos,size)    (cast_int(((i)>>(pos)) & MASK1(size,0)))
   #define cast_int(i)    cast(int, (i))
   #define MASK1(n,p)    ((~((~(Instruction)0)<<(n)))<<(p))
   #define cast(t, exp)    ((t)(exp))
 I think the maximum depth here is 7-deep:
    op_arith -> vRB -> RB -> GETARG -> getarg -> cast_int -> cast
 This is not normal coding; it has replaced using functions to build programs, with macros. And it has replaced coding in C, with functional-style coding via the macro language.
 So what language would say this program is written in?
 

 I would expect that Lua has more than one artithemetic
operation, so sharing code saves coding effort (actually, most
of tag mainipulations probably can be shared by all Lua instructions).

 Any reason to uses *seven* levels of macro invocation? That is all in one branch.
 Do you think that's too many? Perhaps only 3 levels would have sufficed. Or would you automatically say it was reasonable no matter how many levels there were, just to disagee with me and to side with a fellow C programmer?
 

I don't see any serious problem with this.  It's not the way /I/ would code things, but I have different aims for my code than the Lua folks have for theirs.  I don't know what all these macros do, or what all the abbreviations are - but that's because I don't know anything about the internals of the Lua byte-code interpreter and virtual machine.
What I /do/ see here is that everything is built up with small parts combined and layered - that's how you do structured programming.  It's a bit excessive IMHO in how much it is split up (perhaps the programmers are used to Forth), but that's a matter of taste.
It doesn't matter that it is macros rather than functions - except that macros will probably give more efficient end results than functions would on weaker compilers that can't handle inlining well.  (The compiler still needs to do good expression optimisation for efficient results.)  Lua is intended to be portable to a wide range of different compilers of different capabilities.
The Lua programmers never intend humans to read the expansion of the macros - that is completely unnecessary.  Get each macro right individually, and the final result is correct - again, that's the way structured programming is done.
The cryptic names do mean it would take more effort to learn to understand what's going on here for people involved in maintaining the code, but that only applies to a very few people.  It doesn't even apply to most C compiler implementers - they just need to read the C standards and write a compiler that follows the C rules, and it should have no problem compiling the Lua virtual machine.
Instead of thinking of this as some kind of abuse of C macros or incomprehensible expanded expressions, consider it more as a domain-specific language written in C macros with the intention of making it easier to write the higher level parts of the Lua virtual machine.  You are not expected to be able to read the expanded C code any more than the average C programmer is expected to be able to read generating binary images.