Re: Epic Fail

[Albert van der Horst]

In article <WtGdnStmxf37o8vO...@supernews.com>,
Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote:
>>
>> Even so. You probably haven't studied jonesforth a bit, or you would
>> realize that the later versions have part in assembler, and the
>> remainder is in Forth. So it is not the diametrically opposed approach
>> you make it out to be.
>
>I don't think I've said that it is a diametrically opposed approach.
>I have said that the kernel is written in assembler, and for that
>reason it is a PITA to work on.
>
>>>> If you really do everything in Forth, then you have to write an ELF
>>>> as well as a COFF toolkit in Forth, an awesome and unfruitful
>>>> undertaking, and it still restricted to linux and window.
>>>
>>>That's no big deal, really: you only need a skeleton subset of ELF.
>>>You can always write a simple bootstrap loader in a few lines of
>>>assembly if you really care. But the question of whether you have to
>>>leave the Forth environment to change Forth really is important, IMO.
>>>I've done it both ways, and Forth-in-Forth is better if you want to
>>>make experimental changes.
>>
>
>> Been there. Simple changes to ELF headers, such as fully allowed by
>> the ELF documents will make ELF-tools balk on your executables. So
>> the simple question, dump my header such that I can see what I'm
>> doing, may fail. If you use strip (a gcc tool)
>
>No it isn't.
>
>> on an executable that
>> is not generated by a gcc tool, you risk ending with an empty file.
>
>a. No GCC tool generates executables, and
>b. So don't do that, then.
>
>> Good luck getting a bug report accepted for that.
>
>I'd just fix the bug.

Really, fixing bugs in GNU tools? Mere mortals can't pull that off.
(I could though.)

Let's make it more concrete.

I've this yourforth which is supposedly the simplest forth in
assembler. One segment. It assembles in under a millisecond:

"
albert@cherry:~/PROJECT/yourforth$ time fasm yourforth.fas
flat assembler version 1.70.03 (16384 kilobytes memory)
2 passes, 15197 bytes.

real 0m0.008s
user 0m0.000s
sys 0m0.008s
albert@cherry:~/PROJECT/yourforth$ file yourforth
yourforth: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), \
statically linked, stripped
"

Are you with me? So far so good. (This Forth passes a regression test,
and even Hayes suite, after loading a lot of extensions.)
"
albert@cherry:~/PROJECT/yourforth$ strip yourforth
albert@cherry:~/PROJECT/yourforth$ ls -l yourforth
-rwxr-xr-x 1 albert albert 176 Apr 22 13:14 yourforth
albert@cherry:~/PROJECT/yourforth$ yourforth
Segmentation fault
"

So the gnu tool `` strip '' fails a simple test on the simplest of Forths.
It just has to conclude that there are no symbols and leave. Instead it
trims it to an unbelievable 176 bytes.

I'm not inspired to fix this bug. If the writers of the program cannot
come up with the idea to test it on a program that is as simple as
this, I'm pretty sure I'll end up with rewriting the tool myself.

(All this on Debian stable 64-bit, same result on a stone age Suse.)

>
>> Now that is the kind of effort people might be lured to expend to get
>> started with their own compiler. Learning ELF. Cheese!
>
>What has any of this to do with people writing their own Forth? Are
>we supposed to be encouraging people to write yet more Forths? Why?

Okay let's deter people from writing their own Forths by requiring
ELF expertise. ;-)

The curriculums surely should have assignments to write a simple
compiler. Enough Eclipse already!

>
>Andrew.
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst