tack-devel — Discussion for developers of the ACK.

Re: [Tack-devel] Trying 8-byte integers

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

Worth doing, although it's going to be tough --- let us know how you get
on...

Remember that you'll also need to change the definition of arith to be a
int64_t; this is used (mostly) everywhere for intermediate value
representation. That change should be largely orthogonal to the code
generation side of things but is probably going to be really fiddly and
error prone, as I'm sure there's lots of code which turn ariths into ints
and back (quite possibly written by me; the old code is probably pretty
good about this due to needing to support 16-bit ints).


On Sun, 1 Sep 2019 at 07:03, George Koehler <ke...@gm...> wrote:

> The languages of the ACK don't have 64-bit integers, but I want them.
>
> https://github.com/kernigh/ack/tree/kernigh-data8 begins to add 8-byte
> integers for ack -mlinux386. As of now, it adds the .data8 pseudo to
> the assembler, some operations like `adi 8` (add 8-byte integers) to
> the i386 code generator, and the long long type to ACK C. Some
> operations are missing. C literals like 123LL are missing. If I add
> the missing operations and literals, then long long will still be
> missing in libc, so printf("%lld", value) won't work.
>
> I have a few ideas for 8-byte integers. The timezone code in ACK's
> libc is obsolete and broken. It should learn to read /etc/localtime,
> which is in tzfile(5) format and may contain 8-byte integers. ACK's
> software-floating point uses a pair of 4-byte integers for the 64-bit
> mantissa; switching to an 8-byte integer might simplify the code and
> use the add-with-carry in some processors.
>
> ack -mosx386 will become obsolete when Apple removes 32-bit mode from
> macOS. I would like to build 64-bit executables, but there are a few
> obstacles:
> - I would need to create an amd64 code generator.
> - The 64-bit system calls in macOS aren't stable. I would need to load
> Apple's libc and make foreign function calls from ACK's libsys to
> Apple's libc.
> - amd64 code uses a lot of 8-byte integers, so the ACK must be able to
> handle 8-byte integers.
>
> If it can handle 8-byte integers in linux386, this is one step toward
> eventually building amd64 code that runs in macOS.
>
> The ACK is old, and has ossified a maximum width of 4 bytes for
> integers. I try to add 8-byte integers by making exceptions to the
> 4-byte limit in parts of the ACK. For example, the assembler still
> uses 4-byte integers in expressions, but I widened integer literals
> from 4 bytes to 8, so .data8 can take a literal (but not an
> expression).
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Tack-devel] Trying 8-byte integers

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

The languages of the ACK don't have 64-bit integers, but I want them.

https://github.com/kernigh/ack/tree/kernigh-data8 begins to add 8-byte
integers for ack -mlinux386. As of now, it adds the .data8 pseudo to
the assembler, some operations like `adi 8` (add 8-byte integers) to
the i386 code generator, and the long long type to ACK C. Some
operations are missing. C literals like 123LL are missing. If I add
the missing operations and literals, then long long will still be
missing in libc, so printf("%lld", value) won't work.

I have a few ideas for 8-byte integers. The timezone code in ACK's
libc is obsolete and broken. It should learn to read /etc/localtime,
which is in tzfile(5) format and may contain 8-byte integers. ACK's
software-floating point uses a pair of 4-byte integers for the 64-bit
mantissa; switching to an 8-byte integer might simplify the code and
use the add-with-carry in some processors.

ack -mosx386 will become obsolete when Apple removes 32-bit mode from
macOS. I would like to build 64-bit executables, but there are a few
obstacles:
- I would need to create an amd64 code generator.
- The 64-bit system calls in macOS aren't stable. I would need to load
Apple's libc and make foreign function calls from ACK's libsys to
Apple's libc.
- amd64 code uses a lot of 8-byte integers, so the ACK must be able to
handle 8-byte integers.

If it can handle 8-byte integers in linux386, this is one step toward
eventually building amd64 code that runs in macOS.

The ACK is old, and has ossified a maximum width of 4 bytes for
integers. I try to add 8-byte integers by making exceptions to the
4-byte limit in parts of the ACK. For example, the assembler still
uses 4-byte integers in expressions, but I widened integer literals
from 4 bytes to 8, so .data8 can take a literal (but not an
expression).

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

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

Ceriel,

On 6/25/19 10:17 AM, Jacobs, C.J.H. wrote:
> I’m sorry, I did not find the source code. So far, I only found an old RCS repository with some scripts that
> - are not documented
> - are about 30 years old
> - no longer work because they use commands/scripts that I no longer have (Dick Grune’s original CVS)
> - apparently create a minix version of the compiler passes from an existing ACK tree.


Ok. At least something. Thanks for your efforts.


> Still looking ...


More thanks.


regards,
chris


>
> Ceriel
>
>> On 24 Jun 2019, at 21:15, Christian Groessler <ch...@gr...> wrote:
>>
>> 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.
>>
>> Kind reminder, did you find some time to check if you still have the source code?
>>
>> regards,
>> chris
>>
>>
>>
>> _______________________________________________
>> Tack-devel mailing list
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

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

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

I’m sorry, I did not find the source code. So far, I only found an old RCS repository with some scripts that 
- are not documented
- are about 30 years old
- no longer work because they use commands/scripts that I no longer have (Dick Grune’s original CVS)
- apparently create a minix version of the compiler passes from an existing ACK tree.

Still looking ...

Ceriel

> On 24 Jun 2019, at 21:15, Christian Groessler <ch...@gr...> wrote:
> 
> 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.
> 
> 
> Kind reminder, did you find some time to check if you still have the source code?
> 
> 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...>]

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.


Kind reminder, did you find some time to check if you still have the 
source code?

regards,
chris

Re: [Tack-devel] SBS instruction question

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

Greetings,
              Yes, what you write makes full sense, for example target em24 could potentially cause this issue, and thus cause an overflow trap if the difference was too big and did not fit in a 16-bit signed integer.

So actually nothing to change.
Thanks for the clarification,
Carl
 

    On Monday, June 24, 2019, 3:04:05 AM GMT+8, David Given <dg...@co...> wrote:  
 
 Is this for architectures where sizeof(ptr) != sizeof(int)? I believe the m68k has a mode where it can operate like that. In this situation, if two 32-bit pointers are too far apart then the result can't be represented in a 16-bit int.
The em spec does say that you can only do pointer comparisons between addresses in the same fragment.
On Sun, 23 Jun 2019 at 18:44, Carl Eric Codere via Tack-devel <tac...@li...> wrote:

Greetings, 
               Another interesting question on the SBS EM instruction.

It seems that both em.p and the EM interpreter do overflow checking on the SBS (subtract pointer from pointer) instruction only when the word size is 16-bits. Should this be documented, and i guess if technically possible this should be the same for 32-bit pointers, right?
Another simple question, is there a practical use-case where SBS is used where ptr1 - ptr2 where ptr2 is at higher address than ptr1? This gives a negative number and according to me should not be possible, right, but maybe i am missing something here... I am just curious to see if this is a valid use case.

Thanks in advance,
Carl



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



-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup  

Re: [Tack-devel] SBS instruction question

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

Is this for architectures where sizeof(ptr) != sizeof(int)? I believe the
m68k has a mode where it can operate like that. In this situation, if two
32-bit pointers are too far apart then the result can't be represented in a
16-bit int.

The em spec does say that you can only do pointer comparisons between
addresses in the same fragment.

On Sun, 23 Jun 2019 at 18:44, Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                Another interesting question on the SBS EM instruction.
>
> It seems that both em.p and the EM interpreter do overflow checking on the
> SBS (subtract pointer from pointer) instruction only when the word size is
> 16-bits. Should this be documented, and i guess if technically possible
> this should be the same for 32-bit pointers, right?
>
> Another simple question, is there a practical use-case where SBS is used
> where ptr1 - ptr2 where ptr2 is at higher address than ptr1? This gives a
> negative number and according to me should not be possible, right, but
> maybe i am missing something here... I am just curious to see if this is a
> valid use case.
>
> Thanks in advance,
> Carl
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Tack-devel] SBS instruction question

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

Greetings, 
               Another interesting question on the SBS EM instruction.

It seems that both em.p and the EM interpreter do overflow checking on the SBS (subtract pointer from pointer) instruction only when the word size is 16-bits. Should this be documented, and i guess if technically possible this should be the same for 32-bit pointers, right?
Another simple question, is there a practical use-case where SBS is used where ptr1 - ptr2 where ptr2 is at higher address than ptr1? This gives a negative number and according to me should not be possible, right, but maybe i am missing something here... I am just curious to see if this is a valid use case.

Thanks in advance,
Carl

Re: [Tack-devel] INN / SET EM instruction behavior on ignored trap

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

 Greetings,               Actually the current behavior seems already OK, if the bit number is outside the allowed range, ESET is thrown, the only problem where I had some doubts:
* If the trap is ignored completely (on platforms that do not support it, or through the SIM instruction)

In that case, what should be the value returned? But you just gave me the answer by looking at the old pascal interpreter code (which I forgot to look at), the value 0 is pushed back on the stack, which what i thought also to do, so its consistent.

p.s: I am writing a complete instruction reference manual that should describe each instruction with the possible traps that can be thrown, but it is far from finished.

Carl


    On Saturday, June 22, 2019, 7:34:29 a.m. GMT+8, David Given <dg...@co...> wrote:  
 
 
The EM spec PDF (see the white papers section on http://tack.sf.net) has a sample interpreter written in Pascal in one of the appendices, and INN is implemented as:
begin  k:=argw(k);
  t:=pop;
  i:= t mod 8;  t:= t div 8;
  if t>=k then
    begin trap(ESET); s:=0 end
  else
    begin s:=memb(sp+t) end;
  newsp(sp+k);  push(bit(i,s));
end;

So it does raise ESET if the bit's out of bounds. But that doesn't seem to be actually specified anywhere, and ESET itself is not referred to anywhere in the spec other than as 'set out of bounds error'.
I don't think specifying that it raises an error would be a good idea, as that cripples good code generation for, e.g., word-wide sets (where it can just turn into a shift left of 1). Your suggested behaviour is sensible but it doesn't allow for ESET to be raised on platforms which do support it --- I see that several libem libraries do it. So I'm wondering whether we should define it as (a) undefined, (b) either raising ESET or the behaviour you describe, (c) your behaviour and then remove the checks from the existing code (or just leave them in and declare them as non-comformant...).
On Fri, 21 Jun 2019 at 18:35, Carl Eric Codere via Tack-devel <tac...@li...> wrote:

Greetings,               The EM interpreter, which I am using as reference for the EM testsuite does not define the behavior of the INN and SET instructions when the bitno is outside of the allowed range and the ESET trap is ignored.
I propose the following for SET: Create the set but not set any bit, since the bit number is invalid.I propose the following for INN: Always push a value of zero indicating that the bit is not in the set, thus avoiding reading illegal memory.
Comments welcome...If ok, i will update the code accordingly...
Carl




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



-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup  

Re: [Tack-devel] INN / SET EM instruction behavior on ignored trap

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

The EM spec PDF (see the white papers section on http://tack.sf.net) has a
sample interpreter written in Pascal in one of the appendices, and INN is
implemented as:

begin
  k:=argw(k);
  t:=pop;
  i:= t mod 8;
  t:= t div 8;
  if t>=k then
    begin trap(ESET); s:=0 end
  else
    begin s:=memb(sp+t) end;
  newsp(sp+k);
  push(bit(i,s));
end;

So it does raise ESET if the bit's out of bounds. But that doesn't seem to
be actually specified anywhere, and ESET itself is not referred to anywhere
in the spec other than as 'set out of bounds error'.

I don't think specifying that it raises an error would be a good idea, as
that cripples good code generation for, e.g., word-wide sets (where it can
just turn into a shift left of 1). Your suggested behaviour is sensible but
it doesn't allow for ESET to be raised on platforms which do support it ---
I see that several libem libraries do it. So I'm wondering whether we
should define it as (a) undefined, (b) either raising ESET *or* the
behaviour you describe, (c) your behaviour and then remove the checks from
the existing code (or just leave them in and declare them as
non-comformant...).

On Fri, 21 Jun 2019 at 18:35, Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                The EM interpreter, which I am using as reference for the
> EM testsuite does not define the behavior of the INN and SET instructions
> when the bitno is outside of the allowed range and the ESET trap is ignored.
>
> I propose the following for SET: Create the set but not set any bit, since
> the bit number is invalid.
> I propose the following for INN: Always push a value of zero indicating
> that the bit is not in the set, thus avoiding reading illegal memory.
>
> Comments welcome...
> If ok, i will update the code accordingly...
>
> Carl
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Tack-devel] INN / SET EM instruction behavior on ignored trap

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

Greetings,               The EM interpreter, which I am using as reference for the EM testsuite does not define the behavior of the INN and SET instructions when the bitno is outside of the allowed range and the ESET trap is ignored.
I propose the following for SET: Create the set but not set any bit, since the bit number is invalid.I propose the following for INN: Always push a value of zero indicating that the bit is not in the set, thus avoiding reading illegal memory.
Comments welcome...If ok, i will update the code accordingly...
Carl

Re: [Tack-devel] Accessing to unaligned data in records/structures

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

EM requires word-aligned accesses (or short-aligned for shorts) (which just
recently came as a nasty shock when I set the i80 alignment to 1 and
everything started failing obscurely). Only architectures that don't
require it you *can* get away with code like the above but it's not
guaranteed to work, and the C compiler will insert padding in structures to
make alignment work.

To load unaligned fields you have to read bytes and then assemble a word
with arithmetic. For some reason there aren't any EM instructions to do
unaligned reads.

On Tue, 11 Jun 2019 at 17:35, Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>               I am slowly working on the em instruction testsuite, and I
> am a bit stuck, when trying to test LOI from the below code, I get a bad
> pointer error in the interpreter at LOI 2, because the address is not
> aligned. Hence my question, how do you access the second field of this
> structure? What happens in pascal if the record is declared as packed, or
> is this just a problem associated with the interpreter?
>
>
> /* Unaligned structure containing the data to read. */
> struct01
>     rom    255I1
>     rom -32767I2
>     rom 2147483647I4
> #if EM_WSIZE >= 4
>     rom 9223372036854775807I8
> #endif
>
>     exp $_m_a_i_n
>     pro $_m_a_i_n, 0
>
>     /* Unaligned structure access */
>
> 1
>     lae    struct01+1            /* stack address of structure */
>     loi    2                    /* stack data from structure    */
>     loc    -32767
>     cmi    EM_WSIZE            /* check if value is what is expected. */
>     zeq *2
>
>     ldc __LINE__
>     cal $fail
>     asp 4
>
> Thanks for all your help,
> Carl
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Tack-devel] Accessing to unaligned data in records/structures

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

Greetings,              I am slowly working on the em instruction testsuite, and I am a bit stuck, when trying to test LOI from the below code, I get a bad pointer error in the interpreter at LOI 2, because the address is not aligned. Hence my question, how do you access the second field of this structure? What happens in pascal if the record is declared as packed, or is this just a problem associated with the interpreter?


/* Unaligned structure containing the data to read. */ 
struct01
    rom    255I1
    rom -32767I2
    rom 2147483647I4
#if EM_WSIZE >= 4    
    rom 9223372036854775807I8
#endif
    
    exp $_m_a_i_n
    pro $_m_a_i_n, 0
    
    /* Unaligned structure access */
    
1    
    lae    struct01+1            /* stack address of structure */
    loi    2                    /* stack data from structure    */
    loc    -32767
    cmi    EM_WSIZE            /* check if value is what is expected. */
    zeq *2

    ldc __LINE__
    cal $fail
    asp 4    
    
Thanks for all your help,Carl

[Tack-devel] Confusion on system libraries.

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

Greetings,              I am completely confused on the usage and building of the non C system libraries.
When i try to build asprint.p in util/em_ass by targeting -mem22 using ack (and also using my own apc application), i get duplicate symbols, because it links with libc.a, libsys.a and libpc.a
Now the solution i found to resolve this is that only to link libpc (libpascal), and libsys. By doing this you then get three unresolved symbols:* free* malloc* _environ
So my next step is simply to build libpc.a using malloc.c and environ.c of the libc library.Therefore linking is only done using libsys.a and libpc.a. I feel it makes sense, but i want confirmation...

Is this the correct approach?Carl

Re: [Tack-devel] Is there a plan to support more targets in the long term?

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

There is actually a Z8000 code generator, but it's nowhere near useful ---
the assembler needs overhauling, then it needs a plat etc, and then
(eventually) we have to find out if it's working. It's also using the old *old
*code generator framework so I suspect the code quality's not good.

Regarding other architectures... sure! It just needs someone willing to do
the work. The ACK's pretty easy to retarget compared to other compilers,
but it's still a substantial amount of largely undocumented engineering.
Plus, the code generation architecture is restrictive. It was intended for
use on 16-bit CISC architectures with a fixed frame pointer register and a
very limited number of other registers --- the 8086, essentially. On
register-centric or 8-bit machines it struggles.

It can be made to work: George Koehler put in heroic work and produced an
actually decent PowerPC backend. I've been overhauling the 8080 backend and
it now generates smaller code than sdcc does (note: it is, however,
slower). There's also mcg, designed for register-centric architectures,
which produces... tolerable... code; there's a MIPS backend using that.

It'd probably work well on the 6809, should anyone want to try porting it.
(There's already an assembler, but it hasn't been made to work.)

On Thu, 9 May 2019 at 15:39, Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                 On my side definitely... i even started it a bit the
> emulators architecture for both 6502 and 6809 emulators... :)
>
> Carl
>
>
>
> -------- Original message --------
> From: Fabrizio Caruso <fab...@ho...>
> Date: 2019/05/09 20:45 (GMT+08:00)
> To: tac...@li...
> Subject: [Tack-devel] Is there a plan to support more targets in the long
> term?
>
> Hi everyone!
>
> I wonder whether there is a long-term plan to revive more targets in ACK
> (such as Zilog Z8000, MOS 6502, MOS 6809, etc.).
>
> I dream of 6800-support because no cross-compiler for this target exists
> but I guess it will never be in ACK because it never was and C may not be
> the best language to code on 6800-based systems, which have very little ram.
>
>    Fabrizio
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

Re: [Tack-devel] Is there a plan to support more targets in the long term?

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

Greetings,
                On my side definitely... i even started it a bit the emulators architecture for both 6502 and 6809 emulators... :)

Carl



-------- Original message --------
From: Fabrizio Caruso <fab...@ho...> 
Date: 2019/05/09  20:45  (GMT+08:00) 
To: tac...@li... 
Subject: [Tack-devel] Is there a plan to support more targets in the long term? 

Hi everyone!

I wonder whether there is a long-term plan to revive more targets in ACK (such as Zilog Z8000, MOS 6502, MOS 6809, etc.).

I dream of 6800-support because no cross-compiler for this target exists but I guess it will never be in ACK because it never was and C may not be the best language to code on 6800-based systems, which have very little ram.

   Fabrizio

[Tack-devel] Is there a plan to support more targets in the long term?

[Fabrizio C. <fab...@ho...>]

Hi everyone!

I wonder whether there is a long-term plan to revive more targets in ACK (such as Zilog Z8000, MOS 6502, MOS 6809, etc.).

I dream of 6800-support because no cross-compiler for this target exists but I guess it will never be in ACK because it never was and C may not be the best language to code on 6800-based systems, which have very little ram.

   Fabrizio

Re: [Tack-devel] Updates and issues

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

Ah, right, that one. That actually produces a tool called em_nopt as well
as a library which can be used elsewhere (although nothing does yet). It's
a generic tool which only needs to be built once. Add a "pkg" rule which
installs it into the right place, and then reference it from the top-level
build.lua file --- use util/misc/build.lua as a reference. There's actually
build system documentation here:
https://github.com/davidgiven/ack/blob/default/first/ackbuilder.md

Nothing actually uses em_nopt, though, and I strongly suspect it's
thoroughly obsolete. It looks like it was intended to massage the EM
bytecode files after compilation and before code generation, which is
required for correctness. However, from the man page, it seems to think the
front-end compilers now do this, but they don't: opt itself does it. So I
think it hasn't been used for at least two generations of code.



On Tue, 7 May 2019 at 04:04, Carl Eric Codere <cec...@ya...> wrote:

> Greetings,
>                 Ok understood... actually i never planned to drop ack at
> all, just try to find a quick alternative. Ok i can wait... the good news
> is that i think locally i should be very very close to build on mingw for
> windows now...
>
> Now locally most shell scripts have been replaced by awk/sed instead but
> with my build system... as you proposed a while back i finish the ansi part
> then i can adapt the build lua scripts to directly use sed and ack....
>
> Regarding em_opt... it was more about the one in modules ... which now
> builds... i did not test it yet though...
>
> Carl
>
>
> -------- Original message --------
> From: David Given <dg...@co...>
> Date: 2019/05/07 03:53 (GMT+08:00)
> To: Carl Eric Codere <cec...@ya...>
> Cc: Carl Eric Codere via Tack-devel <tac...@li...>
> Subject: Re: [Tack-devel] Updates and issues
>
> It's probably not worth chasing pure ANSI-compatibility too hard --- ANSI
> C is so limited that for many programs it just won't be feasible. The ack
> driver is a good candidate. getopt is more interesting; it's completely
> standard, defined by Posix. so having our own copy only really benefits
> non-Posix systems of which there are very few, and none are supported by
> the ACK right now. I'd be inclined to stick with the Posix one until we
> actually run into a non-Posix platform in real life.
>
> Re em_opt: is this util/opt? If so, there should already be a build.lua in
> there. Build files are only picked up automatically if they're referred to
> be another build rule. em_opt's depended on by the plat/*/build-tools.lua
> file, but all plats use the same copy, so it's only built once.
>
> On Mon, 6 May 2019 at 19:32, Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
>
>> Greetings,
>>                I am slowly moving forward on making the code more ANSI
>> compatible, I discovered a few points:
>>
>> * The current ANSI libc has a lot of non ANSI C functions - but i guess
>> this is known.
>> * em_ego cannot build using a pure ANSI C compiler because it uses getopt
>> - how could this be solved cleanly? Any ideas? Should i put getopt in
>> system or any ideas?
>> * em_opt library now builds using my build system, but how do i add it to
>> the LUA build system, just by adding build.lua in the directory, it will
>> automatically be picked up?
>> * the ack executable is fully unixish... by looking at it i am a bit
>> worried to move it to using only ANSI C without breaking a lot of stuff...
>> therefore I am using now acc to build on my side, /fast/driver/ do you
>> think it would also be useful to add it to the build system?
>>
>> Carl
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Tack-devel mailing list
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>
>
> --
> ┌─── http://www.cowlark.com ───
> │ "I have always wished for my computer to be as easy to use as my
> │ telephone; my wish has come true because I can no longer figure out
> │ how to use my telephone." --- Bjarne Stroustrup
>
> On Mon, 6 May 2019 at 19:32, Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
>
>> Greetings,
>>                I am slowly moving forward on making the code more ANSI
>> compatible, I discovered a few points:
>>
>> * The current ANSI libc has a lot of non ANSI C functions - but i guess
>> this is known.
>> * em_ego cannot build using a pure ANSI C compiler because it uses getopt
>> - how could this be solved cleanly? Any ideas? Should i put getopt in
>> system or any ideas?
>> * em_opt library now builds using my build system, but how do i add it to
>> the LUA build system, just by adding build.lua in the directory, it will
>> automatically be picked up?
>> * the ack executable is fully unixish... by looking at it i am a bit
>> worried to move it to using only ANSI C without breaking a lot of stuff...
>> therefore I am using now acc to build on my side, /fast/driver/ do you
>> think it would also be useful to add it to the build system?
>>
>> Carl
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Tack-devel mailing list
>> Tac...@li...
>> https://lists.sourceforge.net/lists/listinfo/tack-devel
>>
>
>
> --
> ┌─── http://www.cowlark.com ───
> │ "I have always wished for my computer to be as easy to use as my
> │ telephone; my wish has come true because I can no longer figure out
> │ how to use my telephone." --- Bjarne Stroustrup
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

Re: [Tack-devel] Updates and issues

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

Greetings, 
                Ok understood... actually i never planned to drop ack at all, just try to find a quick alternative. Ok i can wait... the good news is that i think locally i should be very very close to build on mingw for windows now...  

Now locally most shell scripts have been replaced by awk/sed instead but with my build system... as you proposed a while back i finish the ansi part then i can adapt the build lua scripts to directly use sed and ack....

Regarding em_opt... it was more about the one in modules ... which now builds... i did not test it yet though...

Carl


-------- Original message --------
From: David Given <dg...@co...> 
Date: 2019/05/07  03:53  (GMT+08:00) 
To: Carl Eric Codere <cec...@ya...> 
Cc: Carl Eric Codere via Tack-devel <tac...@li...> 
Subject: Re: [Tack-devel] Updates and issues 

It's probably not worth chasing pure ANSI-compatibility too hard --- ANSI C is so limited that for many programs it just won't be feasible. The ack driver is a good candidate. getopt is more interesting; it's completely standard, defined by Posix. so having our own copy only really benefits non-Posix systems of which there are very few, and none are supported by the ACK right now. I'd be inclined to stick with the Posix one until we actually run into a non-Posix platform in real life.

Re em_opt: is this util/opt? If so, there should already be a build.lua in there. Build files are only picked up automatically if they're referred to be another build rule. em_opt's depended on by the plat/*/build-tools.lua file, but all plats use the same copy, so it's only built once.

On Mon, 6 May 2019 at 19:32, Carl Eric Codere via Tack-devel <tac...@li...> wrote:
Greetings,
               I am slowly moving forward on making the code more ANSI compatible, I discovered a few points:

* The current ANSI libc has a lot of non ANSI C functions - but i guess this is known.
* em_ego cannot build using a pure ANSI C compiler because it uses getopt - how could this be solved cleanly? Any ideas? Should i put getopt in system or any ideas?
* em_opt library now builds using my build system, but how do i add it to the LUA build system, just by adding build.lua in the directory, it will automatically be picked up?
* the ack executable is fully unixish... by looking at it i am a bit worried to move it to using only ANSI C without breaking a lot of stuff... therefore I am using now acc to build on my side, /fast/driver/ do you think it would also be useful to add it to the build system?

Carl






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


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

On Mon, 6 May 2019 at 19:32, Carl Eric Codere via Tack-devel <tac...@li...> wrote:
Greetings,
               I am slowly moving forward on making the code more ANSI compatible, I discovered a few points:

* The current ANSI libc has a lot of non ANSI C functions - but i guess this is known.
* em_ego cannot build using a pure ANSI C compiler because it uses getopt - how could this be solved cleanly? Any ideas? Should i put getopt in system or any ideas?
* em_opt library now builds using my build system, but how do i add it to the LUA build system, just by adding build.lua in the directory, it will automatically be picked up?
* the ack executable is fully unixish... by looking at it i am a bit worried to move it to using only ANSI C without breaking a lot of stuff... therefore I am using now acc to build on my side, /fast/driver/ do you think it would also be useful to add it to the build system?

Carl






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


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

Re: [Tack-devel] Updates and issues

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

It's probably not worth chasing pure ANSI-compatibility too hard --- ANSI C
is so limited that for many programs it just won't be feasible. The ack
driver is a good candidate. getopt is more interesting; it's completely
standard, defined by Posix. so having our own copy only really benefits
non-Posix systems of which there are very few, and none are supported by
the ACK right now. I'd be inclined to stick with the Posix one until we
actually run into a non-Posix platform in real life.

Re em_opt: is this util/opt? If so, there should already be a build.lua in
there. Build files are only picked up automatically if they're referred to
be another build rule. em_opt's depended on by the plat/*/build-tools.lua
file, but all plats use the same copy, so it's only built once.

On Mon, 6 May 2019 at 19:32, Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                I am slowly moving forward on making the code more ANSI
> compatible, I discovered a few points:
>
> * The current ANSI libc has a lot of non ANSI C functions - but i guess
> this is known.
> * em_ego cannot build using a pure ANSI C compiler because it uses getopt
> - how could this be solved cleanly? Any ideas? Should i put getopt in
> system or any ideas?
> * em_opt library now builds using my build system, but how do i add it to
> the LUA build system, just by adding build.lua in the directory, it will
> automatically be picked up?
> * the ack executable is fully unixish... by looking at it i am a bit
> worried to move it to using only ANSI C without breaking a lot of stuff...
> therefore I am using now acc to build on my side, /fast/driver/ do you
> think it would also be useful to add it to the build system?
>
> Carl
>
>
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

On Mon, 6 May 2019 at 19:32, Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                I am slowly moving forward on making the code more ANSI
> compatible, I discovered a few points:
>
> * The current ANSI libc has a lot of non ANSI C functions - but i guess
> this is known.
> * em_ego cannot build using a pure ANSI C compiler because it uses getopt
> - how could this be solved cleanly? Any ideas? Should i put getopt in
> system or any ideas?
> * em_opt library now builds using my build system, but how do i add it to
> the LUA build system, just by adding build.lua in the directory, it will
> automatically be picked up?
> * the ack executable is fully unixish... by looking at it i am a bit
> worried to move it to using only ANSI C without breaking a lot of stuff...
> therefore I am using now acc to build on my side, /fast/driver/ do you
> think it would also be useful to add it to the build system?
>
> Carl
>
>
>
>
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>


-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup

[Tack-devel] Updates and issues

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

Greetings,               I am slowly moving forward on making the code more ANSI compatible, I discovered a few points:
* The current ANSI libc has a lot of non ANSI C functions - but i guess this is known.
* em_ego cannot build using a pure ANSI C compiler because it uses getopt - how could this be solved cleanly? Any ideas? Should i put getopt in system or any ideas?* em_opt library now builds using my build system, but how do i add it to the LUA build system, just by adding build.lua in the directory, it will automatically be picked up?* the ack executable is fully unixish... by looking at it i am a bit worried to move it to using only ANSI C without breaking a lot of stuff... therefore I am using now acc to build on my side, /fast/driver/ do you think it would also be useful to add it to the build system?
Carl

[Tack-devel] Start with a 100% Welcome Bonus up to $1000 and take it away!

[Attention W. <new...@mo...>]

Your email client cannot read this email.
To view it online, please go here:
http://modecyl.info/display.php?M=1391336&C=5d7a461592643f6b90f29f2803bf9ed9&S=24&L=23&N=3


To stop receiving these
emails:http://modecyl.info/unsubscribe.php?M=1391336&C=5d7a461592643f6b90f29f2803bf9ed9&L=23&N=24
<!-- #*#*# FLIPMODE! #*#*# -->

[Tack-devel] [SPAM] Malcolm from adguru.net classified ads

[Malcolm Adguru.n. <new...@mo...>]

Your email client cannot read this email.
To view it online, please go here:
http://modecyl.info/display.php?M=1391336&C=5d7a461592643f6b90f29f2803bf9ed9&S=22&L=23&N=1


To stop receiving these
emails:http://modecyl.info/unsubscribe.php?M=1391336&C=5d7a461592643f6b90f29f2803bf9ed9&L=23&N=22
<!-- #*#*# FLIPMODE! #*#*# -->

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

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

I know Minix 2 does have some networking support (with the usual Minix
architecture of having network drivers in the kernel but the TCP/IP
subsystem is a userspace server), but have never used it. See
https://minix1.woodhull.com/hints.html#nethints. There's a reference there
to someone running a HTTP server on a 286 with Minix 2.0.3, so 64kB
segments does obviously work... somehow.

On Mon, 1 Apr 2019 at 12:47 Christian Groessler <ch...@gr...> wrote:

> I've looked at your github page.
>
> I'm not hooked on exactly Minix version 1.5. Because I'd like to have
> TCP/IP as well. Is there a version (Minix 2.0?) which supports IP and still
> works on systems with 64K segments?
>
> And I'd like to have it self-hosting. So finding the ACKPACK sources would
> be good. I'm expecting work to be done there for Z8000.
>
> regards,
> chris
>
>
> On 3/31/19 1:44 PM, David Given wrote:
>
> 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...>]

I've looked at your github page.

I'm not hooked on exactly Minix version 1.5. Because I'd like to have 
TCP/IP as well. Is there a version (Minix 2.0?) which supports IP and 
still works on systems with 64K segments?

And I'd like to have it self-hosting. So finding the ACKPACK sources 
would be good. I'm expecting work to be done there for Z8000.

regards,
chris


On 3/31/19 1:44 PM, David Given wrote:
> 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... 
> <mailto: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... <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
>>>