struct by value

[Jon]

Er, duh.

You're talking about trying to write assembly to interface with another
language's calling conventions. This is an EXEMPLAR of "unportable".

That said, in most cases, the ABI stays pretty stable for a fairly
long time, meaning that you should be able to predict the argument
passing behaviors for any specific function for any specific target
quite well.

Well that's some relief then.

Down this path lies madness. You're going to waste more time than you
save, by several orders of magnitude.

I won't know that it is not viable until I fail at it though. I don't
know of how many obstacles are on the road ahead of me. One that I'm sure
is there but I won't get to for awhile is concurrency and how it
complicates the compiler-writer's job.

 

[Jon]

[... different mechanisms for struct parameters and func values ...]
OK, then, here is something I don't understand: if those compilers
do
that, how am I supposed to write an assembly language
prologue/epilogue
to interface such things if arguments are not passed on the stack?

The same way you would in any circumstances: by understanding the
calling convention used by the compiler, which is probably based
on the ABI for the platform.

So then, unportably since a simple change of the compiler would
muck-up
the assumptions.

You began with the *goal* of writing non-portable code, and
now you raise the objection that it's non-portable? "Doctor, it
hurts when I stick my thumb in my eye."

Also, you've missed the meaning of the last phrase in Keith's
post: "... which is probably based on the ABI for the platform."
Unless you're writing to the bare metal with no O/S in sight, a
platform will have established conventions for communication between
a programming language and the O/S services,

Yes! That's exactly the task at hand! I want to be able to call C
functions from Assembly Language (which of course is documented in many
places and I'm not asking how to do that here).

and often for at least
some of the communication between different languages. A compiler
for the platform will perforce follow those conventions, or it will
find itself unable to get along with other languages and/or the O/S.

It is true that a platform ABI may omit some items of interest
to some of its supported languages. An O/S whose services deal only
in integers and addresses and bags of bytes may not prescribe how
floating-point values should be passed around.

There's one of those potential obstacles for me: implementing floating
point (IEEE standard should help though), but maybe I won't need to go
that far.

Few platforms say
how a Lisp-style List is passed, or even encoded. And sometimes it
may happen that language X has an X-specific type and that two X
compilers manage the type differently, so components built by the
gxx and MSX compilers don't play nicely together. Well, that's life:
If you want to join the games, you have to learn the rules.

Or create new ones. =)

If C is not the right language for your purposes, use a different
language.

I'll still have to interface C though.

That will be far more productive than whining

Who's whining? I'm taking the bull by the horns!

-- and it will
also be more productive than trying to twist C to your liking, whether
with macro magic, assembly abracadabra, or library lunacy. Trust me:
I've been there, I bear the scars.

Perhaps you didn't go far enough?

 

[Keith Thompson]

Would you care to restate that?

I meant "just because they're structures".

[...]

 

[Jon]

I meant "just because they're structures".

I don't do it for performance reasons really, I forward-think to the time
when I'll have to write the code to generate assembly to pass structs and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

 

[Eric Sosman]

[...]
Also, you've missed the meaning of the last phrase in Keith's
post: "... which is probably based on the ABI for the platform."
Unless you're writing to the bare metal with no O/S in sight, a
platform will have established conventions for communication between
a programming language and the O/S services,

Yes! That's exactly the task at hand! I want to be able to call C
functions from Assembly Language (which of course is documented in many
places and I'm not asking how to do that here).

Well then, don't complain about the importabilities inherent
in your chosen course.

There's one of those potential obstacles for me: implementing floating
point (IEEE standard should help though), but maybe I won't need to go
that far.

You still don't understand. Appealing to a standard that talks
about the representations of F-P numbers and the operations on them
gives you *no* help in figuring out how to hand them from place to
place. Since you have not yet grasped this rather essential (and
rather basic) point, I urge you to stop in your tracks before you do
yourself and others harm. You are a three-year-old trying to drive
an eighteen-wheeler, able to reach the pedals only if you crouch so
low you can't see through the windshield.

Quite seriously:

YOU DON'T KNOW WHAT YOU'RE DOING.

But, okay, all right, you'll have to learn for yourself. Callow
youth has never in all the history of Man listened to the voice of
experience, and you appear to be no exception.

Or create new ones. =)

If you run the bases backwards, you are out. O-U-T, out, and no
amount of squawking about your highly original rules will convince the
umpire otherwise.

I'll still have to interface C though.

I don't see why. "If C is not the right language..." means there's
no reason for C to enter your picture at all. If C *does* enter your
picture, it follows that C *is* the right language (for suitable and
variable definitions of "right"), and if so you need to learn about C.

Who's whining? I'm taking the bull by the horns!

You are whining. And slinging the bull, too.

Perhaps you didn't go far enough?

Perhaps. Beyond madness, failure, and defeat, say some mystics,
lies salvation. I count myself a skeptic.

 

[Ian Collins]

news:[email protected]... [...]
I agree with Ian that passing small structures by pointer just
because
they're pointers is premature optimization.

Would you care to restate that?

I meant "just because they're structures".

I don't do it for performance reasons really, I forward-think to the time
when I'll have to write the code to generate assembly to pass structs and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

How often do you do that? That last time I had to do that was in the 80s...

 

[Keith Thompson]

news:[email protected]... [...]
I agree with Ian that passing small structures by pointer just
because
they're pointers is premature optimization.

Would you care to restate that?

I meant "just because they're structures".

I don't do it for performance reasons really, I forward-think to the time
when I'll have to write the code to generate assembly to pass structs and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

You mentioned that you're writing a compiler. For what language? If
it's a C compiler, you have to be able to pass structures by value.

 

[Jon]

[...]
I agree with Ian that passing small structures by pointer just
because
they're pointers is premature optimization.

Would you care to restate that?

I meant "just because they're structures".

I don't do it for performance reasons really, I forward-think to the
time
when I'll have to write the code to generate assembly to pass structs
and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

You mentioned that you're writing a compiler. For what language? If
it's a C compiler, you have to be able to pass structures by value.

For what language? Isn't it obvious (?): The Better C/C++! You not need
be so elementary with me as I'm probably in the top 20% as far as the
body of knowledge goes (that's the "short answer", if you want the "long"
answer, just ask, but it will bore the room to death and bring out every
warrior in the place for sure, just kidding).

 

[Jon]

[...]
I agree with Ian that passing small structures by pointer just
because
they're pointers is premature optimization.

Would you care to restate that?

I meant "just because they're structures".

I don't do it for performance reasons really, I forward-think to the
time
when I'll have to write the code to generate assembly to pass structs
and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

How often do you do that? That last time I had to do that was in the
80s...

Thanks. I've *never* done it! You *had* to do it? I'm doing it because I
*want* to do it.

 

[Ian Collins]

[...]
I agree with Ian that passing small structures by pointer just
because
they're pointers is premature optimization.

Would you care to restate that?

I meant "just because they're structures".


I don't do it for performance reasons really, I forward-think to the
time
when I'll have to write the code to generate assembly to pass structs
and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

How often do you do that? That last time I had to do that was in the
80s...

Thanks. I've *never* done it! You *had* to do it? I'm doing it because I
*want* to do it.

Yes, back in the days before compilers learnt how to optimise. These
days with common compiler techniques like RVO, there's no point.

 

[Jon]

[snipped "troll bait"]

The question becomes, is he or isn't he? Kennedy thought he was
successful in baiting me but I said no he was not so maybe you're just
trying to up the ante?

 

[Jon]

On 10/17/10 02:50 PM, Jon wrote:
[...]
I agree with Ian that passing small structures by pointer just
because
they're pointers is premature optimization.

Would you care to restate that?

I meant "just because they're structures".


I don't do it for performance reasons really, I forward-think to the
time
when I'll have to write the code to generate assembly to pass
structs
and
passing an address is a whole lot simpler (trivial in comparison to
pass-struct-by-value).

How often do you do that? That last time I had to do that was in the
80s...

Thanks. I've *never* done it! You *had* to do it? I'm doing it because
I
*want* to do it.

Yes, back in the days before compilers learnt how to optimise. These
days with common compiler techniques like RVO, there's no point.

And I thought RVO was a C++ thing! There's no point to what?

 

[Seebs]

For what language? Isn't it obvious (?): The Better C/C++! You not need
be so elementary with me as I'm probably in the top 20% as far as the
body of knowledge goes (that's the "short answer", if you want the "long"
answer, just ask, but it will bore the room to death and bring out every
warrior in the place for sure, just kidding).

Have you heard of Dunning-Kruger?

-s

 

[Jon]

Have you heard of Dunning-Kruger?

Have you heard of rape?

 

[Keith Thompson]

Have you heard of rape?

*PLONK*