tack-devel — Discussion for developers of the ACK.

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[David G. <dg...@co...>]

This is the Z8000 code generator and assembler in the current version of
the ACK.

Bear in mind that ACKPACK probably *didn't* have the Z8000 code generator
integrated into it, given that there doesn't appear to have been a Minix
port for it and the compiler support looks fairly unfinished. So there's
definitely work to do.

Incidentally, re Minix: I also have this:
https://github.com/davidgiven/minix2 It's a Minix 1.7 and 2.0 distribution
wrapped in some useful scripts for easy development on Linux --- a single
script will build a bootable image from source, start it in qemu to do
builds, unpack it again afterwards, etc. It doesn't have Minix 1.5 or 1.2
in it because I haven't figured out how to boot them in qemu yet. It's got
all the source *except* the ACKPACK compiler, which wasn't in the standard
distributions. It'd be awesome to get source for everything.

On Sun, 31 Mar 2019 at 00:36 Christian Groessler <ch...@gr...>
wrote:

> Hi,
> On 3/22/19 9:26 PM, David Given wrote:
>
> I had a play with the code. The Z8000 code generator builds and runs and
> generates code, but of course I have no idea whether it generates working
> code. The assembler does not; in common with a lot of the very old
> architectures it's runs in assembler/linker mode, where it generates
> non-relocatable binaries rather than .o files which can be linked together.
> This would need fixing. (I've done it before and it's not a lot of work.)
>
>
> You "played" with which code exactly?
>
>
> Of course, it still needs a plat with a syscall library, startup code etc
> before it'll do anything useful.
>
>
> I'm aware of that, but that I'm considering to be part of porting Minix to
> the M20.
>
>
> What OS does the M20 run?
>
>
> It typically runs "PCOS", a proprietary Olivetti OS. There's also
> CP/M-8000 available for it.
>
> For PCOS, there is a rather old gcc version available at
> ftp://ftp.groessler.org/pub/chris/olivetti_m20/misc/z8kgcc/ . CP/M comes
> with it's own C compiler.
>
>
> But for porting Minix 1.5 to the M20 I'd like to use (ideally) the same
> ACK compiler version which was used for the other versions (8086 PC, M68K
> Atari, Amiga).
>
>
> regards,
> chris
>
>
>
>
> On Fri, 22 Mar 2019, 18:54 Christian Groessler, <ch...@gr...>
> wrote:
>
>> Not in the way the 8086 did with its segment registers.
>>
>> But the CPU has output pins which indicate if a memory access is an
>> instruction fetch or data access. And the M20 implements (at least) one
>> segment where this is used. So address X points to different physical
>> memory, depending on whether it's an instruction or data access.
>>
>> regards,
>> chris
>>
>>
>> On 3/22/19 5:48 PM, David Given wrote:
>>
>> Did the Z8000 do split I/D? The 8086 cheated because both code *and* data
>> got different 64kB address spaces, so you could have 64kB of code and still
>> have 64kB of data. I don't think you could fit the compiler into a single
>> 64kB space.
>>
>> There is a Z8000 code generator in the ACK but it's based on the old
>> _old_ code generator model and was last touched in the 1990s, so I don't
>> know whether it works or what the code quality is like. Plus, of course,
>> then you need to make it fit.
>>
>>
>> On Fri, 22 Mar 2019 at 14:05 Christian Groessler <ch...@gr...>
>> wrote:
>>
>>> Hi,
>>>
>>> On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
>>> > Good question! I survived, and I produced those binaries back then.
>>> But this was a very long time ago,
>>> > and my memory has never been any good... nor are my archiving
>>> skills... When I find some time, I’ll
>>> > see if I can do some digging. From what I remember, the only real
>>> problem was getting the compiler front-end
>>> > to fit in 64K instruction space and 64K data space. For that, we took
>>> out the C preprocessor (which was/is built-in
>>> > into the C frontend) and made it a separate pass, and we also took out
>>> the floating-point library. Other than that,
>>> > I don’t remember exactly, but I think it was just a little bit of
>>> tweaking.
>>>
>>>
>>> It would be great if you would find this version.
>>>
>>> I'm toying with the idea to port Minix 1.5 to the Olivetti M20, a Z8000
>>> based computer. The Z8000 has 64K segments as well.
>>>
>>> regards,
>>> chris
>>>
>>>
>>>
>>> _______________________________________________
>>> Tack-devel mailing list
>>> Tac...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>>
>>

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[Christian G. <ch...@gr...>]

Hi,

On 3/22/19 9:26 PM, David Given wrote:
> I had a play with the code. The Z8000 code generator builds and runs 
> and generates code, but of course I have no idea whether it generates 
> working code. The assembler does not; in common with a lot of the very 
> old architectures it's runs in assembler/linker mode, where it 
> generates non-relocatable binaries rather than .o files which can be 
> linked together. This would need fixing. (I've done it before and it's 
> not a lot of work.)


You "played" with which code exactly?


> Of course, it still needs a plat with a syscall library, startup code 
> etc before it'll do anything useful.


I'm aware of that, but that I'm considering to be part of porting Minix 
to the M20.


> What OS does the M20 run?


It typically runs "PCOS", a proprietary Olivetti OS. There's also 
CP/M-8000 available for it.

For PCOS, there is a rather old gcc version available at 
ftp://ftp.groessler.org/pub/chris/olivetti_m20/misc/z8kgcc/ . CP/M comes 
with it's own C compiler.


But for porting Minix 1.5 to the M20 I'd like to use (ideally) the same 
ACK compiler version which was used for the other versions (8086 PC, 
M68K Atari, Amiga).


regards,
chris



>
> On Fri, 22 Mar 2019, 18:54 Christian Groessler, <ch...@gr... 
> <mailto:ch...@gr...>> wrote:
>
>     Not in the way the 8086 did with its segment registers.
>
>     But the CPU has output pins which indicate if a memory access is
>     an instruction fetch or data access. And the M20 implements (at
>     least) one segment where this is used. So address X points to
>     different physical memory, depending on whether it's an
>     instruction or data access.
>
>     regards,
>     chris
>
>
>     On 3/22/19 5:48 PM, David Given wrote:
>>     Did the Z8000 do split I/D? The 8086 cheated because both code
>>     /and/ data got different 64kB address spaces, so you could have
>>     64kB of code and still have 64kB of data. I don't think you could
>>     fit the compiler into a single 64kB space.
>>
>>     There is a Z8000 code generator in the ACK but it's based on the
>>     old _old_ code generator model and was last touched in the 1990s,
>>     so I don't know whether it works or what the code quality is
>>     like. Plus, of course, then you need to make it fit.
>>
>>
>>     On Fri, 22 Mar 2019 at 14:05 Christian Groessler
>>     <ch...@gr... <mailto:ch...@gr...>> wrote:
>>
>>         Hi,
>>
>>         On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
>>         > Good question! I survived, and I produced those binaries
>>         back then. But this was a very long time ago,
>>         > and my memory has never been any good... nor are my
>>         archiving skills... When I find some time, I’ll
>>         > see if I can do some digging. From what I remember, the
>>         only real problem was getting the compiler front-end
>>         > to fit in 64K instruction space and 64K data space. For
>>         that, we took out the C preprocessor (which was/is built-in
>>         > into the C frontend) and made it a separate pass, and we
>>         also took out the floating-point library. Other than that,
>>         > I don’t remember exactly, but I think it was just a little
>>         bit of tweaking.
>>
>>
>>         It would be great if you would find this version.
>>
>>         I'm toying with the idea to port Minix 1.5 to the Olivetti
>>         M20, a Z8000
>>         based computer. The Z8000 has 64K segments as well.
>>
>>         regards,
>>         chris
>>
>>
>>
>>         _______________________________________________
>>         Tack-devel mailing list
>>         Tac...@li...
>>         <mailto:Tac...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/tack-devel
>>

[Tack-devel] Some questions on testing

[Carl E. C. <cec...@ya...>]

Greetings,
                  Some simple questions on testing and lua scripts.

In the current build system how can i add some test targets as i am not at all familiar with lua...

For example i have created some tests for the system module and using cmake its easy to add them and run them using the test target... any example with build.lua? 

Another question... what do you feel about adding some reference binaries for testing and then diff them with the ones built for?  Or you feel its a wrong approach? My idea was mainly for the archiver as well as the assemblers but maybe its a wrong approach ..

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[David G. <dg...@co...>]

I had a play with the code. The Z8000 code generator builds and runs and
generates code, but of course I have no idea whether it generates working
code. The assembler does not; in common with a lot of the very old
architectures it's runs in assembler/linker mode, where it generates
non-relocatable binaries rather than .o files which can be linked together.
This would need fixing. (I've done it before and it's not a lot of work.)

Of course, it still needs a plat with a syscall library, startup code etc
before it'll do anything useful.

What OS does the M20 run?

On Fri, 22 Mar 2019, 18:54 Christian Groessler, <ch...@gr...> wrote:

> Not in the way the 8086 did with its segment registers.
>
> But the CPU has output pins which indicate if a memory access is an
> instruction fetch or data access. And the M20 implements (at least) one
> segment where this is used. So address X points to different physical
> memory, depending on whether it's an instruction or data access.
>
> regards,
> chris
>
>
> On 3/22/19 5:48 PM, David Given wrote:
>
> Did the Z8000 do split I/D? The 8086 cheated because both code *and* data
> got different 64kB address spaces, so you could have 64kB of code and still
> have 64kB of data. I don't think you could fit the compiler into a single
> 64kB space.
>
> There is a Z8000 code generator in the ACK but it's based on the old _old_
> code generator model and was last touched in the 1990s, so I don't know
> whether it works or what the code quality is like. Plus, of course, then
> you need to make it fit.
>
>
> On Fri, 22 Mar 2019 at 14:05 Christian Groessler <ch...@gr...>
> wrote:
>
>> Hi,
>>
>> On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
>> > Good question! I survived, and I produced those binaries back then. But
>> this was a very long time ago,
>> > and my memory has never been any good... nor are my archiving skills...
>> When I find some time, I’ll
>> > see if I can do some digging. From what I remember, the only real
>> problem was getting the compiler front-end
>> > to fit in 64K instruction space and 64K data space. For that, we took
>> out the C preprocessor (which was/is built-in
>> > into the C frontend) and made it a separate pass, and we also took out
>> the floating-point library. Other than that,
>> > I don’t remember exactly, but I think it was just a little bit of
>> tweaking.
>>
>>
>> It would be great if you would find this version.
>>
>> I'm toying with the idea to port Minix 1.5 to the Olivetti M20, a Z8000
>> based computer. The Z8000 has 64K segments as well.
>>
>> regards,
>> chris
>>
>>
>>
>> _______________________________________________
>> Tack-devel mailing list
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[Christian G. <ch...@gr...>]

Not in the way the 8086 did with its segment registers.

But the CPU has output pins which indicate if a memory access is an 
instruction fetch or data access. And the M20 implements (at least) one 
segment where this is used. So address X points to different physical 
memory, depending on whether it's an instruction or data access.

regards,
chris


On 3/22/19 5:48 PM, David Given wrote:
> Did the Z8000 do split I/D? The 8086 cheated because both code 
> /and/ data got different 64kB address spaces, so you could have 64kB 
> of code and still have 64kB of data. I don't think you could fit the 
> compiler into a single 64kB space.
>
> There is a Z8000 code generator in the ACK but it's based on the old 
> _old_ code generator model and was last touched in the 1990s, so I 
> don't know whether it works or what the code quality is like. Plus, of 
> course, then you need to make it fit.
>
>
> On Fri, 22 Mar 2019 at 14:05 Christian Groessler <ch...@gr... 
> <mailto:ch...@gr...>> wrote:
>
>     Hi,
>
>     On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
>     > Good question! I survived, and I produced those binaries back
>     then. But this was a very long time ago,
>     > and my memory has never been any good... nor are my archiving
>     skills... When I find some time, I’ll
>     > see if I can do some digging. From what I remember, the only
>     real problem was getting the compiler front-end
>     > to fit in 64K instruction space and 64K data space. For that, we
>     took out the C preprocessor (which was/is built-in
>     > into the C frontend) and made it a separate pass, and we also
>     took out the floating-point library. Other than that,
>     > I don’t remember exactly, but I think it was just a little bit
>     of tweaking.
>
>
>     It would be great if you would find this version.
>
>     I'm toying with the idea to port Minix 1.5 to the Olivetti M20, a
>     Z8000
>     based computer. The Z8000 has 64K segments as well.
>
>     regards,
>     chris
>
>
>
>     _______________________________________________
>     Tack-devel mailing list
>     Tac...@li...
>     <mailto:Tac...@li...>
>     https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[David G. <dg...@co...>]

Did the Z8000 do split I/D? The 8086 cheated because both code *and* data
got different 64kB address spaces, so you could have 64kB of code and still
have 64kB of data. I don't think you could fit the compiler into a single
64kB space.

There is a Z8000 code generator in the ACK but it's based on the old _old_
code generator model and was last touched in the 1990s, so I don't know
whether it works or what the code quality is like. Plus, of course, then
you need to make it fit.


On Fri, 22 Mar 2019 at 14:05 Christian Groessler <ch...@gr...>
wrote:

> Hi,
>
> On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
> > Good question! I survived, and I produced those binaries back then. But
> this was a very long time ago,
> > and my memory has never been any good... nor are my archiving skills...
> When I find some time, I’ll
> > see if I can do some digging. From what I remember, the only real
> problem was getting the compiler front-end
> > to fit in 64K instruction space and 64K data space. For that, we took
> out the C preprocessor (which was/is built-in
> > into the C frontend) and made it a separate pass, and we also took out
> the floating-point library. Other than that,
> > I don’t remember exactly, but I think it was just a little bit of
> tweaking.
>
>
> It would be great if you would find this version.
>
> I'm toying with the idea to port Minix 1.5 to the Olivetti M20, a Z8000
> based computer. The Z8000 has 64K segments as well.
>
> regards,
> chris
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[Christian G. <ch...@gr...>]

Hi,

On 3/11/19 8:13 AM, Jacobs, C.J.H. via Tack-devel wrote:
> Good question! I survived, and I produced those binaries back then. But this was a very long time ago,
> and my memory has never been any good... nor are my archiving skills... When I find some time, I’ll
> see if I can do some digging. From what I remember, the only real problem was getting the compiler front-end
> to fit in 64K instruction space and 64K data space. For that, we took out the C preprocessor (which was/is built-in
> into the C frontend) and made it a separate pass, and we also took out the floating-point library. Other than that,
> I don’t remember exactly, but I think it was just a little bit of tweaking.


It would be great if you would find this version.

I'm toying with the idea to port Minix 1.5 to the Olivetti M20, a Z8000 
based computer. The Z8000 has 64K segments as well.

regards,
chris

Re: [Tack-devel] Information for installation guide update

[George K. <ke...@gm...>]

On Fri, Mar 8, 2019 at 1:19 PM Carl Eric Codere via Tack-devel
<tac...@li...> wrote:
> cvmach conversion program to convert from a.out to platform specific binaries.

The only cvmach is in plat/osx/cvmach; I named it because it converts
ack.out to Mach-O, the executable format of Mac OS X. Perhaps it
should be cvmacho, but I forgot the 'o'. It gets installed at
lib/ack/cvmach. Other cv tools in lib/ack would need different names,
but cvmach is the only cv tool in lib/ack for now.

There is a cv in lib/ack/pdpv7/cv that converts ack.out to Unix v7
a.out. If we follow that pattern, cvmach would get installed twice in
lib/ack/osx386/cv and lib/ack/osxppc/cv.

George Koehler

Re: [Tack-devel] Location of some utility functions

[Carl E. C. <cec...@ya...>]

Greetings,
                Ok i take your reccomnendations in that case... no modules/src/util for the moment. 

In regards to tests, i am happy to see you are open to my suggestion as i do feel that having the tests in the same location as the source is important as i see some modules are quite interesting and could eventually be reused in other projects so having those in one place makes it easier if someone else wants to reuse them ... including build scripts. 

Carl



-------- Original message --------
From: David Given <dg...@co...> 
Date: 2019/03/12  18:32  (GMT+08:00) 
To: Carl Eric Codere <cec...@ya...> 
Cc: tac...@li... 
Subject: Re: [Tack-devel] Location of some utility functions 

For getackhome() I'd probably say that system's the right place. getopt... hmm. Getopt is actually standard, mandated by Posix, so any respectable system ought to have it. We'd only want it as a fallback for other systems. I don't thing modules is the right place for this kind of thing, as it's not part of the compiler proper, but I'm not sure what would be. Maybe it'd be simplest to create a modules/src/emu for emulation libraries. I'm not terribly keen on a general util module because they end up dumping grounds for all kinds of random things, and we already have several of those...

Regarding testsuites: I'd been vaguely intending to put test suites in the tests/ directory, with a hierarchy mirroring the source (so tests/modules/src/whatever...).But I'm not particularly wed to that, and the only tests which have actually shown up are the compiler tests proper. Maybe it would be better put them next to the source.


On Tue, 12 Mar 2019 at 09:00 Carl Eric Codere via Tack-devel <tac...@li...> wrote:
Greetings,
                Some other questions from my side, I need to know where some of the "utility" functions should be located in:

My understanding is that any system specific stuff that might not be portable should be in system.h, so for example, as i see should be added:
* sys_gettmpnam() used by several utilities
* sys_tmpfile() used by several utilities.
.
...

Am I correct?

Now for non-system specific stuff, i see hash tables for example should go in module module/src/data.

But what about other specific stuff that is common and not associated with any module today?
* getackhome() ?
* getopt() if ever needed...

I will not necessarily create this additional module now, just want your advice for future if ever it is needed?
I was thinking modules/src/util, does it make sense?

Finally for each module if i add a testsuit, is it ok if i create a subdirectory called test containing the testsuit for that module? Putting it a root of the module can cause some IDE's some trouble :) 

Comments welcome...
Carl



Carl




_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel

Re: [Tack-devel] Location of some utility functions

[David G. <dg...@co...>]

For getackhome() I'd probably say that system's the right place. getopt...
hmm. Getopt is actually standard, mandated by Posix, so any respectable
system ought to have it. We'd only want it as a fallback for other systems.
I don't thing modules is the right place for this kind of thing, as it's
not part of the compiler proper, but I'm not sure what would be. Maybe it'd
be simplest to create a modules/src/emu for emulation libraries. I'm not
terribly keen on a general util module because they end up dumping grounds
for all kinds of random things, and we already have several of those...

Regarding testsuites: I'd been vaguely intending to put test suites in the
tests/ directory, with a hierarchy mirroring the source (so
tests/modules/src/whatever...).But I'm not particularly wed to that, and
the only tests which have actually shown up are the compiler tests proper.
Maybe it would be better put them next to the source.


On Tue, 12 Mar 2019 at 09:00 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                 Some other questions from my side, I need to know where
> some of the "utility" functions should be located in:
>
> My understanding is that any system specific stuff that might not be
> portable should be in system.h, so for example, as i see should be added:
> * sys_gettmpnam() used by several utilities
> * sys_tmpfile() used by several utilities.
> .
> ...
>
> Am I correct?
>
> Now for non-system specific stuff, i see hash tables for example should go
> in module module/src/data.
>
> But what about other specific stuff that is common and not associated with
> any module today?
> * getackhome() ?
> * getopt() if ever needed...
>
> I will not necessarily create this additional module now, just want your
> advice for future if ever it is needed?
> I was thinking modules/src/util, does it make sense?
>
> Finally for each module if i add a testsuit, is it ok if i create a
> subdirectory called test containing the testsuit for that module? Putting
> it a root of the module can cause some IDE's some trouble :)
>
> Comments welcome...
> Carl
>
>
>
> Carl
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

[Tack-devel] Location of some utility functions

[Carl E. C. <cec...@ya...>]

Greetings,                Some other questions from my side, I need to know where some of the "utility" functions should be located in:
My understanding is that any system specific stuff that might not be portable should be in system.h, so for example, as i see should be added:
* sys_gettmpnam() used by several utilities* sys_tmpfile() used by several utilities.....

Am I correct?
Now for non-system specific stuff, i see hash tables for example should go in module module/src/data.
But what about other specific stuff that is common and not associated with any module today?* getackhome() ?* getopt() if ever needed...

I will not necessarily create this additional module now, just want your advice for future if ever it is needed?
I was thinking modules/src/util, does it make sense?
Finally for each module if i add a testsuit, is it ok if i create a subdirectory called test containing the testsuit for that module? Putting it a root of the module can cause some IDE's some trouble :) 

Comments welcome...Carl



Carl

Re: [Tack-devel] [Spam] MINIX 1.5 and ACK

[Jacobs, C.J.H. <c.j...@vu...>]

> On 9 Mar 2019, at 19:14, u-...@ae... wrote:
> 
> On Sat, Mar 09, 2019 at 12:08:09AM +0100, David Given wrote:
>> That's known as ACKPACK, and it's a special cut-down version of the ACK
>> which forked off a while ago. I don't know anything about that one.
>> 
>> +u...@ae... <u-...@ae...>, you maintain ACKPACK, don't you? Do you
>> have a download site for it?
>> 
>> 
>> On Fri, 8 Mar 2019 at 23:59 Christian Groessler <ch...@gr...> wrote:
>> 
>>> Hi,
>>> 
>>> I'm new here.
>>> 
>>> I've got the MINIX 1.5 distribution (from back then, supporting PC 8086
>>> and 80286, and M68K Amiga, Atari, Mac) which includes the source code of
>>> most of the system. The notably exception is the source code of the
>>> compiler.
>>> 
>>> Is the source code of this version of ACK publicly available?
> 
> It would be a challenge to figure out how exactly the compiler binaries
> supplied with Minix 1.5 were built. I doubt that this information survived
> since then.

Good question! I survived, and I produced those binaries back then. But this was a very long time ago,
and my memory has never been any good... nor are my archiving skills... When I find some time, I’ll
see if I can do some digging. From what I remember, the only real problem was getting the compiler front-end
to fit in 64K instruction space and 64K data space. For that, we took out the C preprocessor (which was/is built-in
into the C frontend) and made it a separate pass, and we also took out the floating-point library. Other than that,
I don’t remember exactly, but I think it was just a little bit of tweaking.

Best wishes,

Ceriel Jacobs

Re: [Tack-devel] Information for installation guide update

[Carl E. C. <cec...@ya...>]

 Greetings,               Yes, i also noticed that each binary was rebuilt for each platform, i was thinking it was for this same reason as you said. :) 
In regards to the install guide, i am slowly to update it so it becomes a bit more current. At the same time it permits me to learn more about troff and ms :) 
And yes, you were right on your previous affirmation on building ACK, I am trying to figure out how to bootstrap it through cmake, and it is indeed giving me a headache ...
Thanks for the clarifications, they are very helpful!Carl 
    On Saturday, March 9, 2019, 3:23:04 AM GMT+8, David Given <dg...@co...> wrote:  
 
 That's mostly correct, and how it's intended to work. However, there's a lot of historical baggage. Before 6.0 there was just a mach directory which contained a mixture of platform-dependent and platform-independent code. I've been moving stuff into plat as I've been working on it but there's still a lot of very old and unused things left in mach.
Most of the current platforms don't use specific cv programs. Instead they use either aslod or aelflod (in utils). OSX is the single exception. Meanwhile, nearly all the old cv programs in mach are unused. I believe the one exception there is the PDP11 one, and that should really be moved into plat/pdpv7 as it's specific to V7 Unix.
My guess would be that any tool to produce hex or srec would live in plat/utils, as this would be generic to multiple architectures --- call it ahexlod, say. You'd still use led to link your program.
Incidentally, regarding mach: every tool there is built for every plat. So if you have two different 8080 platforms, you get two assemblers, code generators, etc. The reason for this is that plats might have different compilation options. For example: I've just done a tonne of work getting the 8080 code generator into decent shape for Fuzix and CP/M, and one of the opimisations there is to use rst instructions to call common helper routines. Another 8080-based plat might not want these, and so would build the code generator with different flags to disable this feature. (This is part of what makes the ACK a pain to build.)
Re the floating point library: it's in mach/proto/fp. The only mach which uses it so far is i86.

On Fri, 8 Mar 2019 at 19:19 Carl Eric Codere via Tack-devel <tac...@li...> wrote:

Greetings,               I am trying to update a bit the install guide, especially in regards to the source directory structure, so i can use it as my own reference, just want to make sure i understand correctly?
"mach" shall now contain the CPU specific code but which is operating system independent, in other words:
cg     the backend code generator   (*.m => *.s)ncg     the new backend code generator (*.m => *.s)mcg     the modified backend code generatoras     the CPU specific assembler (*.s => *.o) or     assembler/linker (*.s + libraries => a.out)cv     conversion programs for a.out files. Replaced by cvmach in the "plat" directory.dl     down-load programs. Moved to cvmach in the "plat" directory.top     the target optimizerint     source for an interpreterce     code expander (fast back-end)
libem to create runtime system used by code generatorslibend library defining end, edata, etextlibfp configuration data to create floating point librarylibdb to create debugger support library

libce to create runtime system used by code expanders

While the "plat" directory contains the following:
cvmach conversion program to convert from a.out to platform specific binaries.emu         system specific platform emulator or simulator used for testing.include system-dependent include fileslibsys system-dependent library used to interface with the operating system.

Some questions?1. Are the above hypothesis correct?2. As you can see above, from me dl / cv are now in "plat", but maybe i am wrong in this case? Where would a converter that converts to Intel HEX or Motorola SREC be placed? Or this is just too hypothetic now!?3. Where is the software floating point arithmetic emulation layer? Does it actually exist? Sorry for this stupid question, but i cannot to find it!


Carl

_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel

_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel
  

Re: [Tack-devel] MINIX 1.5 and ACK

[<u-...@ae...>]

On Sat, Mar 09, 2019 at 12:08:09AM +0100, David Given wrote:
> That's known as ACKPACK, and it's a special cut-down version of the ACK
> which forked off a while ago. I don't know anything about that one.
> 
> +u...@ae... <u-...@ae...>, you maintain ACKPACK, don't you? Do you
> have a download site for it?
> 
> 
> On Fri, 8 Mar 2019 at 23:59 Christian Groessler <ch...@gr...> wrote:
> 
> > Hi,
> >
> > I'm new here.
> >
> > I've got the MINIX 1.5 distribution (from back then, supporting PC 8086
> > and 80286, and M68K Amiga, Atari, Mac) which includes the source code of
> > most of the system. The notably exception is the source code of the
> > compiler.
> >
> > Is the source code of this version of ACK publicly available?

It would be a challenge to figure out how exactly the compiler binaries
supplied with Minix 1.5 were built. I doubt that this information survived
since then.

Nevertheless, it is possible to rebuild a Minix-specific version of ack,
the so called ackpack. The source is publicly available, even though
not visible very much, because the corresponding package subtree has
been deleted.

My involvement in ackpack is of different kind, it is on ia32 Linux
where I ported ackpack and the Minix-2 standard C library (very handy
as a compact and clean ANSI C environment, with a generous license).

I doubt that you could build/self-host ackpack under Minix-1.x, but
Minix-2 is well suited for this (on ia32, possibly not on i86).

Here follow the pointers to the sources:

https://web.archive.org/web/20060405092432/http://packages.minix3.org/software/ackpack.tar.bz2

(An almost identical tar file used to be available at
 https://web.archive.org/web/20090706093854/http://www.minix3.org/software/ackpack.tar.bz2
but looked missing today, may be just a glitch at archive.org ?
The difference in the contents is only in rcs tags.)

otherwise

https://git.minix3.org/index.cgi?p=bigports.git;a=tree;hb=4b758;h=10b88
(unfortunately snapshots do not seem to be available from there)

otherwise

git clone git://git.minix3.org/bigports
git checkout e2cdd3d778f8003c828ec3aa642ee4669dec77d5

there see the ackpack directory

Hope this helps
Rune

Re: [Tack-devel] MINIX 1.5 and ACK

[David G. <dg...@co...>]

That's known as ACKPACK, and it's a special cut-down version of the ACK
which forked off a while ago. I don't know anything about that one.

+u...@ae... <u-...@ae...>, you maintain ACKPACK, don't you? Do you
have a download site for it?


On Fri, 8 Mar 2019 at 23:59 Christian Groessler <ch...@gr...> wrote:

> Hi,
>
> I'm new here.
>
> I've got the MINIX 1.5 distribution (from back then, supporting PC 8086
> and 80286, and M68K Amiga, Atari, Mac) which includes the source code of
> most of the system. The notably exception is the source code of the
> compiler.
>
> Is the source code of this version of ACK publicly available?
>
> regards,
> chris
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

[Tack-devel] MINIX 1.5 and ACK

[Christian G. <ch...@gr...>]

Hi,

I'm new here.

I've got the MINIX 1.5 distribution (from back then, supporting PC 8086 
and 80286, and M68K Amiga, Atari, Mac) which includes the source code of 
most of the system. The notably exception is the source code of the 
compiler.

Is the source code of this version of ACK publicly available?

regards,
chris

Re: [Tack-devel] ACK_HOME and em_path

[<u-...@ae...>]

On Fri, Mar 08, 2019 at 08:09:00PM +0100, u-...@ae... wrote:
> > The easiest way i see is  to have em_path.h to contain all important directory defines directly relative to the root directory (either the environment variable or hard coded path) this generated at build time, so we can support both, and it has practically no impact on existing codes? What do you think?
> 
> It sounds good, to define all paths so that they are derived at run time,
> but isn't this already the case? (not looking at the source right now)

I now checked with the (5.5) code and it looks exactly like what you
describe: there is a default path defined at build time (possible to
be overriden at run time) and one relative path.

Which other directory defines you suggest to introduce there and why?

I can only guess that this was for the various system administration
tastes' sake (?)

If correct, it would mean complicating the compiler for no reason.

Please keep the structure straightforward, consistently documented,
with as small connection to the system administration as possible.

*** The fewer assumptions, the less headache for all parties. ***

I appreciate your and David's efforts. That's why I care when precious
time is spent on dicussing how to best support something which is
marginally relevant, impossible to solve in general and at the same time
an easy task for independent external means in every particular case.

If not otherwise, it is far easier to map a single-file-tree software
to a particular storage structure than to adapt from a _differing_
non-trivial file structure.

Rune

Re: [Tack-devel] Information for installation guide update

[David G. <dg...@co...>]

That's mostly correct, and how it's *intended* to work. However, there's a
lot of historical baggage. Before 6.0 there was just a mach directory which
contained a mixture of platform-dependent and platform-independent code.
I've been moving stuff into plat as I've been working on it but there's
still a lot of very old and unused things left in mach.

Most of the current platforms don't use specific cv programs. Instead they
use either aslod or aelflod (in utils). OSX is the single exception.
Meanwhile, nearly all the old cv programs in mach are unused. I believe the
one exception *there* is the PDP11 one, and that should really be moved
into plat/pdpv7 as it's specific to V7 Unix.

My guess would be that any tool to produce hex or srec would live in
plat/utils, as this would be generic to multiple architectures --- call it
ahexlod, say. You'd still use led to link your program.

Incidentally, regarding mach: every tool there is built *for every plat*.
So if you have two different 8080 platforms, you get two assemblers, code
generators, etc. The reason for this is that plats might have different
compilation options. For example: I've just done a tonne of work getting
the 8080 code generator into decent shape for Fuzix and CP/M, and one of
the opimisations there is to use rst instructions to call common helper
routines. Another 8080-based plat might not want these, and so would build
the code generator with different flags to disable this feature. (This is
part of what makes the ACK a pain to build.)

Re the floating point library: it's in mach/proto/fp. The only mach which
uses it so far is i86.


On Fri, 8 Mar 2019 at 19:19 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                I am trying to update a bit the install guide, especially
> in regards to the source directory structure, so i can use it as my own
> reference, just want to make sure i understand correctly?
>
> "mach" shall now contain the CPU specific code but which is operating
> system independent, in other words:
>
> cg     the backend code generator   (*.m => *.s)
> ncg     the new backend code generator (*.m => *.s)
> mcg     the modified backend code generator
> as     the CPU specific assembler (*.s => *.o) or
>     assembler/linker (*.s + libraries => a.out)
> cv     conversion programs for a.out files. Replaced by cvmach in the
> "plat" directory.
> dl     down-load programs. Moved to cvmach in the "plat" directory.
> top     the target optimizer
> int     source for an interpreter
> ce     code expander (fast back-end)
>
> libem to create runtime system used by code generators
> libend library defining end, edata, etext
> libfp configuration data to create floating point library
> libdb to create debugger support library
>
> libce to create runtime system used by code expanders
>
>
> While the "plat" directory contains the following:
>
> cvmach conversion program to convert from a.out to platform specific
> binaries.
> emu         system specific platform emulator or simulator used for
> testing.
> include system-dependent include files
> libsys system-dependent library used to interface with the operating
> system.
>
>
> Some questions?
> 1. Are the above hypothesis correct?
> 2. As you can see above, from me dl / cv are now in "plat", but maybe i am
> wrong in this case? Where would a converter that converts to Intel HEX or
> Motorola SREC be placed? Or this is just too hypothetic now!?
> 3. Where is the software floating point arithmetic emulation layer? Does
> it actually exist? Sorry for this stupid question, but i cannot to find it!
>
>
>
> Carl
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] ACK_HOME and em_path

[David G. <dg...@co...>]

Do we need to support both? I mean, the only downside is that if you're
installing into /opt, your hierarchy ends up looking like
/opt/ack/share/ack/stuff.

Changing this would require a fair bit of replumbing as relative paths are
everywhere. Take a look at lib/descr/fe, for example. I've just tried
changing things in the driver frontend and it's *not* easy code to work
with.

On Fri, 8 Mar 2019 at 18:45 Carl Eric Codere <cec...@ya...> wrote:

> Greetings,
>               Ok, I would rather call it ACK_HOME personally if you don't
> mind? As agreed we check the environment variable first then, we get the
> hard coded value if the variable is not available.
>
> On the other hand, I think we need to support 2 types of directory
> structures, at least as i see it, because the current one is /usr/local is
> clean for UNIX systems, but it is not if you use /opt/ or for all other
> systems... I would keep the one in the install documentation.
>
> The easiest way i see is  to have em_path.h to contain all important
> directory defines directly relative to the root directory (either the
> environment variable or hard coded path) this generated at build time, so
> we can support both, and it has practically no impact on existing codes?
> What do you think?
>
> Carl
>
>
>
> On Friday, March 8, 2019, 3:41:41 AM GMT+8, David Given <dg...@co...>
> wrote:
>
>
> Yup, it's just the compiler driver. It needs to know where the descr files
> are, which it then uses to set things like the include and library paths
> and where to find all the other tools.
>
> Requiring the end user to set an environment variable is possible, but
> pretty antisocial; after installation the tools are expected to Just Work.
> On platforms like DOS and Windows applications traditionally add their
> variables to the environment. On Unix-y systems this requires a manual step
> and should be avoided, hence the filesystem conventions. (I maintain a
> couple of Debian packages and I don't think requiring the user to edit
> their .profile after installation of a system package would get past
> review.)
>
> For precompiled binaries, whoever's doing the packaging is always going to
> have to pick *something*, hopefully something appropriate for the
> platform they're packaging. On a Linux system that'll nearly always be
> /usr. On a BSD it'll probably be /usr/local (simply because of different
> conventions there). If the binaries are intended to be installed by end
> users, then they will obviously have to set the environment variable,
> because there's no fixed location that'll work. The value shipped by
> default doesn't have to be globally right, merely convenient for developers
> --- /usr/local is the typical choice here because it works in most places.
>
> So what we need is:
>
> (a) a hardcoded location, which will be used in the normal situation;
> (b) a way to override that if necessary.
>
> Hence the existing behaviour with em_path.h and ACKDIR.
>
>
> On Thu, 7 Mar 2019 at 17:42 Carl Eric Codere <cec...@ya...> wrote:
>
> Greetings,
> ��������������� Thanks for clearing this
> point of, i did not grow up in UNIX environments... so i was not sure on
> this one.
>
> As i said in a previous email, i have some crazy ideas, but the other
> platforms for ACK that I immediately see on top of the linux, BSD, MacOS
> are of course native Windows, MS-DOS and maybe AmigaOS.. And I see from the
> code I have looked up to now, it would be possible ... as long as
> addressable code space is more than 64K...
>
> Because of technical limitations on some of those platforms, i would not
> actually build ACK on those platforms, but more cross compile to have ACK
> available for those platforms... I do feel it is possible...� But of
> course its a very long way off before this can be achieved .... :)
>
>
> Carl
>
>
>
>
> On 2019-03-08 00:24, David Given wrote:
>
> /opt vs /usr/local has been a long-standing holy war --- there's really
> very little in it. There both intended for add-on packages not supplied
> with the system. I grew up with /usr/local, so that's the one I picked.
> Anyone building distributable binaries will customise the setting anyway.
>
> When you say 'other platforms', which ones do you mean? AFAIK OSX, Cygwin
> and Haiku all use /usr/local, or close-enough.
>
>
> On Thu, 7 Mar 2019 at 17:18 Carl Eric Codere <cec...@ya...> wrote:
>
>
> Greetings,
> ����������������� Actually I am more
> confused after your answer! If I build ACK for the MS-DOS target, what
> would be the value of EM_DIR in this case? C:/ack ? On Windows, it would
> really depend, there is a standard location, but it could be anywhere else.
> In all cases, i will keep as proposed and my comment does not change
> anything.
>
> Regarding the install paths, i see that the new installation paths are
> different than the ones provided in the original ACK installation guide...
> and also different than the recommendation from the linux foundation.
>
> The linux foundation recommends /opt/<package> with the different standard
> subdirectories under it... but maybe this is for binary installs only, and
> it does not apply to other UNIX flavors?
> The issue with the new directory structure which I have seen is hardly
> portable to other platforms except UNIX like systems... i see lib/ack and
> share/ack.
>
> Sorry for all this trouble and questions...
> Carl
>
>
>
>
>
> On 2019-03-07 23:02, David Given wrote:
>
> Filesystem layouts are pretty standard, actually, so precompiled binaries
> will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending
> on whether the binaries are supplied by the distribution or third-party.
> (Or {share,libexec} for the BSDs.
>
>
> On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...> wrote:
>
> Greetings,
> ���������������� Ok to keep as backup, it
> makes sense, on the other hand, for those systems where prebuilt binaries
> will be provided, this constant will not be very useful...
>
>
>
> Carl
>
> On 2019-03-07 21:28, David Given wrote:
>
> We do still need the hard-coded path as a fall back --- we can't require
> end users to set an environment variable just to run a normal binary. I
> think we're going to need to keep em_path.h to configure this.
>
> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
>
> Greetings,
> � � � � � � � � Ok! Message well received... simply using
> ACK_HOME with no magic tricks then!!
>
> Carl
>
>
>
>
> -------- Original message --------
> From: u-...@ae...
> Date: 2019/03/07 16:49 (GMT+08:00)
> To: Carl Eric Codere < <cec...@ya...>cec...@ya...>
> Cc: tac...@li...
> Subject: Re: [Tack-devel] ACK_HOME and em_path
>
> Hello Carl Erik,
>
> On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel
> wrote:
> > Greetings,
>
> > ������������� Is it ok if eventually em_path.h
> is completely removed and is replaced by something that is checked at
> runtime instead of compile time? I do feel that doing this at compile time
> gives a bit of a limit on moving the install directory.
>
>
> >
> > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I
> already implemented it in the ANSI C porting.
> >
> > Now for EM_DIR, I propose the following:
> > * ACK_HOME environment variable would need to be set for it be used and
> should point to ACK install directory.
>
> Consequently using a dedicated environment variable is good.
>
> > Now the additional question, let us assume ACK_HOME is not set, do we
> simply fail, or do we try to check additional things, like the following:
> > ** If argv[0] contains a path, from there find and set ACK_HOME by
> deducing the installation path?
> > ** If argv[0] contains no path, search the PATH environment variable for
> the executable and from there deduce the installation path?
>
> IMO (basically any) implicit heuristic search is harmful.
>
> It makes un-/underconfigured installs deceptively look "right" and
> leads to headaches when things assumed to "magically just work" subtly
> work not exactly as one expected.
>
> Neither argv[0] nor PATH are reliable pointers to the actually needed
> resources, nor the path to the running executable, even when it could be
> reliably found out on some platform.
>
> Nor should they be assumed/constrained to be set up for such use,
> because they also are under other unrelated constraints and carry or may
> carry other important functions as well.
>
> In other words, compiler development and system administration are
> different domains, it is highly unreliable to make assumptions across
> their borders.
>
> As a matter of fact, I have to go out of my way to prevent possible harm
> from gcc's resource guesses from its argv[0].
>
> Please do not make ack act in such fashion.
>
> Rune
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

Re: [Tack-devel] ACK_HOME and em_path

[<u-...@ae...>]

On Fri, Mar 08, 2019 at 05:45:09PM +0000, Carl Eric Codere via Tack-devel wrote:
>  Greetings,              Ok, I would rather call it ACK_HOME personally if you don't mind? As agreed we check the environment variable first then, we get the hard coded value if the variable is not available.  

May be rather not?
Why invent a new name when there is an established one (ACKDIR?)?

> On the other hand, I think we need to support 2 types of directory structures, at least as i see it, because the current one is /usr/local is clean for UNIX systems, but it is not if you use /opt/ or for all other systems... I would keep the one in the install documentation.

Again, I think it is misdirected to make an effort directed at numerous
(lot more than two) and generally incompatible with each other styles
of system administration.

It is not a problem at all to handle as an integrator, but becomes
unnecessary bikeshedding, assumptions and constraints for the (Ack)
developers.

The documentation can (and IMHO strongly should) always refer to "$ACKDIR".

A distribution-specific documentation can always do a substitution,
especially if it is left as an explicit macro in the doc sources.
The build system can do such a substitution, if it does not already (?)
Having said that, explicitly referring to a variable is safest.

Good if it is easy to find out in the docs "in this installation (which
you read about) '$ACKDIR' is /...... and the compiler driver knows this,
but you can always set $ACKDIR in your shell explicitly if you mean to
use a separate copy/build/instance of Ack"

If, say, an OS distribution wishes to split a single tree into many
(which can be reasonable or not, but this by its nature is a problem
outside our knowledge horizon), this is easy to do with symbolic links.

Some platforms do not have symlinks-alikes, but hey, the corresponding
ditributors _if_ they need separated trees can argue for what they need
and why. _Then_ we can take up this discussion again. Some platforms
do not have hierarchical file naming, shall we cope with this also? May
be! But not before the need is apparent.

> The easiest way i see is  to have em_path.h to contain all important directory defines directly relative to the root directory (either the environment variable or hard coded path) this generated at build time, so we can support both, and it has practically no impact on existing codes? What do you think?

It sounds good, to define all paths so that they are derived at run time,
but isn't this already the case? (not looking at the source right now)

Rune

[Tack-devel] Information for installation guide update

[Carl E. C. <cec...@ya...>]

Greetings,               I am trying to update a bit the install guide, especially in regards to the source directory structure, so i can use it as my own reference, just want to make sure i understand correctly?
"mach" shall now contain the CPU specific code but which is operating system independent, in other words:
cg     the backend code generator   (*.m => *.s)ncg     the new backend code generator (*.m => *.s)mcg     the modified backend code generatoras     the CPU specific assembler (*.s => *.o) or     assembler/linker (*.s + libraries => a.out)cv     conversion programs for a.out files. Replaced by cvmach in the "plat" directory.dl     down-load programs. Moved to cvmach in the "plat" directory.top     the target optimizerint     source for an interpreterce     code expander (fast back-end)
libem to create runtime system used by code generatorslibend library defining end, edata, etextlibfp configuration data to create floating point librarylibdb to create debugger support library

libce to create runtime system used by code expanders

While the "plat" directory contains the following:
cvmach conversion program to convert from a.out to platform specific binaries.emu         system specific platform emulator or simulator used for testing.include system-dependent include fileslibsys system-dependent library used to interface with the operating system.

Some questions?1. Are the above hypothesis correct?2. As you can see above, from me dl / cv are now in "plat", but maybe i am wrong in this case? Where would a converter that converts to Intel HEX or Motorola SREC be placed? Or this is just too hypothetic now!?3. Where is the software floating point arithmetic emulation layer? Does it actually exist? Sorry for this stupid question, but i cannot to find it!


Carl

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

 Greetings,              Ok, I would rather call it ACK_HOME personally if you don't mind? As agreed we check the environment variable first then, we get the hard coded value if the variable is not available.  
On the other hand, I think we need to support 2 types of directory structures, at least as i see it, because the current one is /usr/local is clean for UNIX systems, but it is not if you use /opt/ or for all other systems... I would keep the one in the install documentation.
The easiest way i see is  to have em_path.h to contain all important directory defines directly relative to the root directory (either the environment variable or hard coded path) this generated at build time, so we can support both, and it has practically no impact on existing codes? What do you think?
Carl


    On Friday, March 8, 2019, 3:41:41 AM GMT+8, David Given <dg...@co...> wrote:  
 
 Yup, it's just the compiler driver. It needs to know where the descr files are, which it then uses to set things like the include and library paths and where to find all the other tools.
Requiring the end user to set an environment variable is possible, but pretty antisocial; after installation the tools are expected to Just Work. On platforms like DOS and Windows applications traditionally add their variables to the environment. On Unix-y systems this requires a manual step and should be avoided, hence the filesystem conventions. (I maintain a couple of Debian packages and I don't think requiring the user to edit their .profile after installation of a system package would get past review.)
For precompiled binaries, whoever's doing the packaging is always going to have to pick something, hopefully something appropriate for the platform they're packaging. On a Linux system that'll nearly always be /usr. On a BSD it'll probably be /usr/local (simply because of different conventions there). If the binaries are intended to be installed by end users, then they will obviously have to set the environment variable, because there's no fixed location that'll work. The value shipped by default doesn't have to be globally right, merely convenient for developers --- /usr/local is the typical choice here because it works in most places.
So what we need is:
(a) a hardcoded location, which will be used in the normal situation;(b) a way to override that if necessary.
Hence the existing behaviour with em_path.h and ACKDIR.

On Thu, 7 Mar 2019 at 17:42 Carl Eric Codere <cec...@ya...> wrote:

  Greetings,
 ��������������� Thanks for clearing this point of, i did not grow up in UNIX environments... so i was not sure on this one. 
 
 As i said in a previous email, i have some crazy ideas, but the other platforms for ACK that I immediately see on top of the linux, BSD, MacOS are of course native Windows, MS-DOS and maybe AmigaOS.. And I see from the code I have looked up to now, it would be possible ... as long as addressable code space is more than 64K... 
 
 Because of technical limitations on some of those platforms, i would not actually build ACK on those platforms, but more cross compile to have ACK available for those platforms... I do feel it is possible...� But of course its a very long way off before this can be achieved .... :)
 
 Carl
 
 
 
 On 2019-03-08 00:24, David Given wrote:
  
 /opt vs /usr/local has been a long-standing holy war --- there's really very little in it. There both intended for add-on packages not supplied with the system. I grew up with /usr/local, so that's the one I picked. Anyone building distributable binaries will customise the setting anyway. 
  When you say 'other platforms', which ones do you mean? AFAIK OSX, Cygwin and Haiku all use /usr/local, or close-enough. 
   
  On Thu, 7 Mar 2019 at 17:18 Carl Eric Codere <cec...@ya...> wrote:
  
  
 Greetings,
 ����������������� Actually I am more confused after your answer! If I build ACK for the MS-DOS target, what would be the value of EM_DIR in this case? C:/ack ? On Windows, it would really depend, there is a standard location, but it could be  anywhere else. In all cases, i will keep as proposed and my comment does not change anything.
 
 Regarding the install paths, i see that the new installation paths are different than the ones provided in the original ACK installation guide... and also different than the recommendation from the linux foundation.
 
 The linux foundation recommends /opt/<package> with the different standard subdirectories under it... but maybe this is for binary installs only, and it does not apply to other UNIX flavors? 
 The issue with the new directory structure which I have seen is hardly portable to other platforms except UNIX like systems... i see lib/ack and share/ack.
 
 Sorry for all this trouble and questions... 
 Carl   
 
 
 
 
 On 2019-03-07 23:02, David Given wrote:
    
 Filesystem layouts are pretty standard, actually, so precompiled binaries will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending on whether the binaries are supplied by the distribution or third-party. (Or {share,libexec} for the BSDs. 
   
 
   
  On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...> wrote:
   
   
  
  Greetings,
 ���������������� Ok to keep as backup, it makes sense, on the other hand, for those systems where prebuilt binaries will be provided, this constant will not be very useful... 
   
  
   
  
   
 
 Carl 
     
 On 2019-03-07 21:28, David Given wrote:
   
  
   
  
  
 We do still need the hard-coded path as a fall back --- we can't require end users to set an environment variable just to run  a normal binary. I think we're going to need to keep em_path.h to configure this. 
 
  
  
   
  
  
  On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <tac...@li...> wrote:
   
  
  
   
  
  
  
  Greetings, � � � � � � � � Ok! Message well received... simply using ACK_HOME with no magic tricks then!!   
  Carl  
  
  
  
   
  
  
  
  
  
 
 -------- Original message --------
 From: u-...@ae... 
 Date: 2019/03/07 16:49 (GMT+08:00) 
 To: Carl Eric Codere <cec...@ya...> 
 Cc: tac...@li... 
 Subject: Re: [Tack-devel] ACK_HOME and em_path 
 
 Hello Carl Erik,
 
 On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via Tack-devel wrote:
 > Greetings,
  
  
  
  
   
  
  
  
  > ������������� Is it ok if eventually em_path.h is completely removed and is replaced by something that is checked at runtime instead of compile time? I do feel that doing this at compile time gives a bit of a limit on moving the install directory. 
  
  
  
   
  
  
  
 
 > 
 > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and I already implemented it in the ANSI C porting.
 > 
 > Now for EM_DIR, I propose the following:
 > * ACK_HOME environment variable would need to be set for it be used and should point to ACK install directory.
 
 Consequently using a dedicated environment variable is good.
 
 > Now the additional question, let us assume ACK_HOME is not set, do we simply fail, or do we try to check additional  things, like the following:
 > ** If argv[0] contains a path, from there find and set ACK_HOME by deducing the installation path?
 > ** If argv[0] contains no path, search the PATH environment variable for the executable and from there deduce the  installation path?
 
 IMO (basically any) implicit heuristic search is harmful.
 
 It makes un-/underconfigured installs deceptively look "right" and
 leads to headaches when things assumed to "magically just work" subtly
 work not exactly as one expected.
 
 Neither argv[0] nor PATH are reliable pointers to the actually needed
 resources, nor the path to the running executable, even when it could be
 reliably found out on some platform.
 
 Nor should they be assumed/constrained to be set up for such use,
 because they also are under other unrelated constraints and carry or may
 carry other important functions as well.
 
 In other words, compiler development and system administration are
 different domains, it is highly unreliable to make assumptions across
 their borders.
 
 As a matter of fact, I have to go out of my way to prevent possible harm
 from gcc's resource guesses from its argv[0].
 
 Please do not make ack act in such fashion.
 
 Rune
 
  
  
  
  
   
  
  
  
 _______________________________________________
 Tack-devel mailing list
 Tac...@li...
 https://lists.sourceforge.net/lists/listinfo/tack-devel
 
  
  
  
  
  
 
 
_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel
  

Re: [Tack-devel] ACK_HOME and em_path

[David G. <dg...@co...>]

Yup, it's just the compiler driver. It needs to know where the descr files
are, which it then uses to set things like the include and library paths
and where to find all the other tools.

Requiring the end user to set an environment variable is possible, but
pretty antisocial; after installation the tools are expected to Just Work.
On platforms like DOS and Windows applications traditionally add their
variables to the environment. On Unix-y systems this requires a manual step
and should be avoided, hence the filesystem conventions. (I maintain a
couple of Debian packages and I don't think requiring the user to edit
their .profile after installation of a system package would get past
review.)

For precompiled binaries, whoever's doing the packaging is always going to
have to pick *something*, hopefully something appropriate for the platform
they're packaging. On a Linux system that'll nearly always be /usr. On a
BSD it'll probably be /usr/local (simply because of different conventions
there). If the binaries are intended to be installed by end users, then
they will obviously have to set the environment variable, because there's
no fixed location that'll work. The value shipped by default doesn't have
to be globally right, merely convenient for developers --- /usr/local is
the typical choice here because it works in most places.

So what we need is:

(a) a hardcoded location, which will be used in the normal situation;
(b) a way to override that if necessary.

Hence the existing behaviour with em_path.h and ACKDIR.


On Thu, 7 Mar 2019 at 17:42 Carl Eric Codere <cec...@ya...> wrote:

> Greetings,
> ��������������� Thanks for clearing this
> point of, i did not grow up in UNIX environments... so i was not sure on
> this one.
>
> As i said in a previous email, i have some crazy ideas, but the other
> platforms for ACK that I immediately see on top of the linux, BSD, MacOS
> are of course native Windows, MS-DOS and maybe AmigaOS.. And I see from the
> code I have looked up to now, it would be possible ... as long as
> addressable code space is more than 64K...
>
> Because of technical limitations on some of those platforms, i would not
> actually build ACK on those platforms, but more cross compile to have ACK
> available for those platforms... I do feel it is possible...� But of
> course its a very long way off before this can be achieved .... :)
>
>
> Carl
>
>
>
>
> On 2019-03-08 00:24, David Given wrote:
>
> /opt vs /usr/local has been a long-standing holy war --- there's really
> very little in it. There both intended for add-on packages not supplied
> with the system. I grew up with /usr/local, so that's the one I picked.
> Anyone building distributable binaries will customise the setting anyway.
>
> When you say 'other platforms', which ones do you mean? AFAIK OSX, Cygwin
> and Haiku all use /usr/local, or close-enough.
>
>
> On Thu, 7 Mar 2019 at 17:18 Carl Eric Codere <cec...@ya...> wrote:
>
>>
>> Greetings,
>> ����������������� Actually I am more
>> confused after your answer! If I build ACK for the MS-DOS target, what
>> would be the value of EM_DIR in this case? C:/ack ? On Windows, it would
>> really depend, there is a standard location, but it could be anywhere else.
>> In all cases, i will keep as proposed and my comment does not change
>> anything.
>>
>> Regarding the install paths, i see that the new installation paths are
>> different than the ones provided in the original ACK installation guide...
>> and also different than the recommendation from the linux foundation.
>>
>> The linux foundation recommends /opt/<package> with the different
>> standard subdirectories under it... but maybe this is for binary installs
>> only, and it does not apply to other UNIX flavors?
>> The issue with the new directory structure which I have seen is hardly
>> portable to other platforms except UNIX like systems... i see lib/ack and
>> share/ack.
>>
>> Sorry for all this trouble and questions...
>> Carl
>>
>>
>>
>>
>>
>> On 2019-03-07 23:02, David Given wrote:
>>
>> Filesystem layouts are pretty standard, actually, so precompiled binaries
>> will be built to use /usr/{share,lib} or /usr/local/{share,lib} depending
>> on whether the binaries are supplied by the distribution or third-party.
>> (Or {share,libexec} for the BSDs.
>>
>>
>> On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya...> wrote:
>>
>> Greetings,
>>> ���������������� Ok to keep as backup,
>>> it makes sense, on the other hand, for those systems where prebuilt
>>> binaries will be provided, this constant will not be very useful...
>>>
>>
>>>
>>> Carl
>>>
>>> On 2019-03-07 21:28, David Given wrote:
>>>
>> We do still need the hard-coded path as a fall back --- we can't require
>>> end users to set an environment variable just to run a normal binary. I
>>> think we're going to need to keep em_path.h to configure this.
>>>
>>> On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel <
>>> tac...@li...> wrote:
>>>
>>> Greetings,
>>>> � � � � � � � � Ok! Message well received... simply
>>>> using ACK_HOME with no magic tricks then!!
>>>>
>>>> Carl
>>>>
>>>
>>>>
>>>>
>>>> -------- Original message --------
>>>> From: u-...@ae...
>>>> Date: 2019/03/07 16:49 (GMT+08:00)
>>>> To: Carl Eric Codere <cec...@ya...>
>>>> Cc: tac...@li...
>>>> Subject: Re: [Tack-devel] ACK_HOME and em_path
>>>>
>>>> Hello Carl Erik,
>>>>
>>>> On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere via
>>>> Tack-devel wrote:
>>>> > Greetings,
>>>>
>>> > ������������� Is it ok if eventually
>>>> em_path.h is completely removed and is replaced by something that is
>>>> checked at runtime instead of compile time? I do feel that doing this at
>>>> compile time gives a bit of a limit on moving the install directory.
>>>>
>>>
>>>> >
>>>> > For TMP_DIR, getenv() is used instead, this one is a no-brainer, and
>>>> I already implemented it in the ANSI C porting.
>>>> >
>>>> > Now for EM_DIR, I propose the following:
>>>> > * ACK_HOME environment variable would need to be set for it be used
>>>> and should point to ACK install directory.
>>>>
>>>> Consequently using a dedicated environment variable is good.
>>>>
>>>> > Now the additional question, let us assume ACK_HOME is not set, do we
>>>> simply fail, or do we try to check additional things, like the following:
>>>> > ** If argv[0] contains a path, from there find and set ACK_HOME by
>>>> deducing the installation path?
>>>> > ** If argv[0] contains no path, search the PATH environment variable
>>>> for the executable and from there deduce the installation path?
>>>>
>>>> IMO (basically any) implicit heuristic search is harmful.
>>>>
>>>> It makes un-/underconfigured installs deceptively look "right" and
>>>> leads to headaches when things assumed to "magically just work" subtly
>>>> work not exactly as one expected.
>>>>
>>>> Neither argv[0] nor PATH are reliable pointers to the actually needed
>>>> resources, nor the path to the running executable, even when it could be
>>>> reliably found out on some platform.
>>>>
>>>> Nor should they be assumed/constrained to be set up for such use,
>>>> because they also are under other unrelated constraints and carry or may
>>>> carry other important functions as well.
>>>>
>>>> In other words, compiler development and system administration are
>>>> different domains, it is highly unreliable to make assumptions across
>>>> their borders.
>>>>
>>>> As a matter of fact, I have to go out of my way to prevent possible harm
>>>> from gcc's resource guesses from its argv[0].
>>>>
>>>> Please do not make ack act in such fashion.
>>>>
>>>> Rune
>>>>
>>>> _______________________________________________
>>>> Tack-devel mailing list
>>>> Tac...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>>>
>>>
>

[Tack-devel] OT (Re: ACK_HOME and em_path)

[<u-...@ae...>]

On Thu, Mar 07, 2019 at 05:24:37PM +0100, David Given wrote:
> /opt vs /usr/local has been a long-standing holy war --- there's really
> very little in it. There both intended for add-on packages not supplied
> with the system. I grew up with /usr/local, so that's the one I picked.
> Anyone building distributable binaries will customise the setting anyway.
> 
> When you say 'other platforms', which ones do you mean? AFAIK OSX, Cygwin
> and Haiku all use /usr/local, or close-enough.

OT for the list and this thread, but all those "holy wars" about
"where stuff should be placed on every machine" were/are a result of
a misconception.

It is the hardcoded paths which make the exact placement "critical".

As soon as one distingushes between

1. "having the stuff" (any path is good enough)
2. "running the stuff" (what we need is a reference in the PATH or menus
   or alike, I call this "inlaying")
3. "letting the program know where to find what it needs" (which
   is to give it environment variables or alike, instead of hardwiring
   this into the binaries)

then it becomes apparent that the "administrative syncronization of paths
everywhere" is an artificial (and of course not solvable :) problem,
created by the intention to hardwire the references instead of letting
them be specified as-needed.

Rune

Re: [Tack-devel] ACK_HOME and em_path

[Carl E. C. <cec...@ya...>]

Greetings,
                   Actually I am more confused after your answer! If I 
build ACK for the MS-DOS target, what would be the value of EM_DIR in 
this case? C:/ack ? On Windows, it would really depend, there is a 
standard location, but it could be anywhere else. In all cases, i will 
keep as proposed and my comment does not change anything.

Regarding the install paths, i see that the new installation paths are 
different than the ones provided in the original ACK installation 
guide... and also different than the recommendation from the linux 
foundation.

The linux foundation recommends /opt/<package> with the different 
standard subdirectories under it... but maybe this is for binary 
installs only, and it does not apply to other UNIX flavors?
The issue with the new directory structure which I have seen is hardly 
portable to other platforms except UNIX like systems... i see lib/ack 
and share/ack.

Sorry for all this trouble and questions...
Carl




On 2019-03-07 23:02, David Given wrote:
> Filesystem layouts are pretty standard, actually, so precompiled 
> binaries will be built to use /usr/{share,lib} or 
> /usr/local/{share,lib} depending on whether the binaries are supplied 
> by the distribution or third-party. (Or {share,libexec} for the BSDs.
>
>
> On Thu, 7 Mar 2019 at 15:52 Carl Eric Codere <cec...@ya... 
> <mailto:cec...@ya...>> wrote:
>
>     Greetings,
>                      Ok to keep as backup, it makes sense, on the
>     other hand, for those systems where prebuilt binaries will be
>     provided, this constant will not be very useful...
>
>
>     Carl
>
>     On 2019-03-07 21:28, David Given wrote:
>>     We do still need the hard-coded path as a fall back --- we can't
>>     require end users to set an environment variable just to run a
>>     normal binary. I think we're going to need to keep em_path.h to
>>     configure this.
>>
>>     On Thu, 7 Mar 2019 at 12:16 Carl Eric Codere via Tack-devel
>>     <tac...@li...
>>     <mailto:tac...@li...>> wrote:
>>
>>         Greetings,
>>                         Ok! Message well received... simply using
>>         ACK_HOME with no magic tricks then!!
>>
>>         Carl
>>
>>
>>
>>         -------- Original message --------
>>         From: u-...@ae... <mailto:u-...@ae...>
>>         Date: 2019/03/07 16:49 (GMT+08:00)
>>         To: Carl Eric Codere <cec...@ya...
>>         <mailto:cec...@ya...>>
>>         Cc: tac...@li...
>>         <mailto:tac...@li...>
>>         Subject: Re: [Tack-devel] ACK_HOME and em_path
>>
>>         Hello Carl Erik,
>>
>>         On Thu, Mar 07, 2019 at 01:10:06AM +0000, Carl Eric Codere
>>         via Tack-devel wrote:
>>         > Greetings,
>>         >               Is it ok if eventually em_path.h is
>>         completely removed and is replaced by something that is
>>         checked at runtime instead of compile time? I do feel that
>>         doing this at compile time gives a bit of a limit on moving
>>         the install directory.
>>         >
>>         > For TMP_DIR, getenv() is used instead, this one is a
>>         no-brainer, and I already implemented it in the ANSI C porting.
>>         >
>>         > Now for EM_DIR, I propose the following:
>>         > * ACK_HOME environment variable would need to be set for it
>>         be used and should point to ACK install directory.
>>
>>         Consequently using a dedicated environment variable is good.
>>
>>         > Now the additional question, let us assume ACK_HOME is not
>>         set, do we simply fail, or do we try to check additional
>>         things, like the following:
>>         > ** If argv[0] contains a path, from there find and set
>>         ACK_HOME by deducing the installation path?
>>         > ** If argv[0] contains no path, search the PATH environment
>>         variable for the executable and from there deduce the
>>         installation path?
>>
>>         IMO (basically any) implicit heuristic search is harmful.
>>
>>         It makes un-/underconfigured installs deceptively look
>>         "right" and
>>         leads to headaches when things assumed to "magically just
>>         work" subtly
>>         work not exactly as one expected.
>>
>>         Neither argv[0] nor PATH are reliable pointers to the
>>         actually needed
>>         resources, nor the path to the running executable, even when
>>         it could be
>>         reliably found out on some platform.
>>
>>         Nor should they be assumed/constrained to be set up for such use,
>>         because they also are under other unrelated constraints and
>>         carry or may
>>         carry other important functions as well.
>>
>>         In other words, compiler development and system
>>         administration are
>>         different domains, it is highly unreliable to make
>>         assumptions across
>>         their borders.
>>
>>         As a matter of fact, I have to go out of my way to prevent
>>         possible harm
>>         from gcc's resource guesses from its argv[0].
>>
>>         Please do not make ack act in such fashion.
>>
>>         Rune
>>
>>         _______________________________________________
>>         Tack-devel mailing list
>>         Tac...@li...
>>         <mailto:Tac...@li...>
>>         https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>