tack-devel — Discussion for developers of the ACK.

Re: [Tack-devel] Update on porting effort

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

On Fri, Feb 08, 2019 at 12:45:29AM +0800, Carl Eric Codere wrote:
> On 2019-02-06 16:33, u-...@ae... wrote:
> >(How does a "shell requirement" compare to "cmake/sed/awk requirements"?)
> I meant that you do no need to use bash anymore, it should work on any
> system that has sed / cmake / awk installed.

Ouch, was there in 6.* a dependency on bash, not Bourne sh?
It was long ago I tried it and apparently forgot this detail.

> >a choice of the format can hardly ever satisfy everyone. FWIIW I suggest
> >that you focus now on the contents, not on a format change, if you can
> >live with troff.
> Yes i do not see any issue to live with troff... :)

Nice!

> >What worries me is that it is hard to verify such large changes.
> >
> >It would be very helpful if we could produce identical compiler binaries
> >from the sources "before" and "after", to know that they are equivalent.

> I agree, I think i will try to do it incrementally as David proposed and
> starting doing some pull requests this weekend... I will try to find a way
> to compare the before and after, but this might be quite difficult to
> accomplish...

It is a pity that 6.* build system is so demanding.
(I resorted to the old-style build scripts of 5.5)

Otherwise, for the files which did not change since 5.5 until the
ansification, I can easily compare the result after replacing them
with the ansified ones - my builds are fully reproducible so the test
is trivial.

Just give me the list of such files and their ansified contents
and I will build and confirm the validity, or warn you otherwise.

Regards,
Rune

Re: [Tack-devel] Update on porting effort

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

On 2019-02-06 16:33, u-...@ae... wrote:
> Hello Carl,
>
> Thanks for the progress report.
>
> On Wed, Feb 06, 2019 at 12:13:00PM +0800, Carl Eric Codere via Tack-devel wrote:
>> Greetings,
>>                   Small update on where I am at in my "porting" effort,
>> nothing committed yet, but the changes are quite important but not a lot of
>> functional changes, about 60% of the tack project is now ported to ANSI C.
> [...]
>> * Add CMake and use cmake to build portable scripts:
>> ** Create sed scripts so no more shell requirement
>> ** Create awk scripts so no more shell requirement.
> Just to make sure, what do you mean by "no more shell requirement"?
> (How does a "shell requirement" compare to "cmake/sed/awk requirements"?)
I meant that you do no need to use bash anymore, it should work on any 
system that has sed / cmake / awk installed.
>> * Properly documenting all opcodes / pseudoinstructions so that a reference
>> manual can be created in a new document.
> That's great.
>
>> BTW: Regarding the em documentation, I would like to update it (I see
>> mistakes in the specification), just wondering should it be converted to
>> something else than troff, or ok like that? Latex? Asciidoc? etc...  I will
>> not change anything on the format for now... just want an opinion on this.
> Corrections are straightforward as long as you know what the errors are;
> a choice of the format can hardly ever satisfy everyone. FWIIW I suggest
> that you focus now on the contents, not on a format change, if you can
> live with troff.
Yes i do not see any issue to live with troff... :)

>> I still have a lot of work to go to...
>> Carl
> Looking forward to an ANSIfied ack.
>
> What worries me is that it is hard to verify such large changes.
>
> It would be very helpful if we could produce identical compiler binaries
> from the sources "before" and "after", to know that they are equivalent.
> This implies of course that this change has to be kept separate from
> all other modifications.
>
> Rune
I agree, I think i will try to do it incrementally as David proposed and 
starting doing some pull requests this weekend... I will try to find a 
way to compare the before and after, but this might be quite difficult 
to accomplish...

Carl

Re: [Tack-devel] Update on porting effort

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

On 2019-02-07 07:37, David Given wrote:
> Thanks very much --- that all sounds great!
>
> Please, though, send lots of small PRs as you go rather than one big 
> one. It's vastly easier to review and reduces the risk of stuff you're 
> doing crossing stuff I'm doing. For example, I recently ANSIfied the 
> Pascal and Basic compiler myself (although pretty crudely, just to 
> make the warnings go away).
>
> [...]
Ohoh.. you did those already? Ok, i will double check your changes and 
try to merge them with mine. While ansifying i try to follow the 
guidelines of the university of Michigan on C include files. Hope this 
is ok  (umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf).

I will try to push something soon, maybe by small batches...
>
>     ** Move the docs to the header file when they exist in the function
>     definition.
>
>
> ...for anything other than public functions (i.e. stuff in public 
> headers in modules/), it's best left next to the definition. This is 
> because these usually describe the /implementation/, not the 
> specification.
>
>     ** One-line sentence overview of function when I can do it.
>
>
> Very valuable.
>
>     * Adapt to have internal prototypes and add STATIC to functions used
>     internally to a module.
>
>
> Any reason not to simply use 'static'?
Actually you are right, but it is quite messy here, i saw that for the 
ANSI C compiler on LINT code they used a PRIVATE define while in pascal 
it was a STATIC define, better directly stick with the static as you 
proposed everywhere right?

>     * Add CMake and use cmake to build portable scripts:
>     ** Create sed scripts so no more shell requirement
>     ** Create awk scripts so no more shell requirement.
>
>
> I don't think CMake will cut it with the ACK --- it's too complex. In 
> particular, the ACK needs the same module to be compiled multiple 
> times with different settings, and I've found very few build systems 
> that can handle that. (I so, so badly want to use bazel for this.)
Actually, up to now i have had no issue.... BUT you are right, that I 
might get stuck when I am at building ACK... i will probably see what 
can be done, but my objective was to remove all references to bash shell 
scripts... and replace them with basic POSIX compliant tools...

>     I have only ported the pascal and basic compilers now and since
>     ack is
>     not compiled, I am testing by hand, but i see some issues:
>
>
> There is a test suite, which is run automatically by the main build 
> system. It's not a terribly complete test suite, but it does exist.
>
>     * The pascal compiler generates a  PRO pseudoinstruction without the
>     size, since its only 1 pass, so the old code generator chokes,
>     because
>     it expects it, I have questions on this: 
>
>     ** Do other compilers do this also? Will ncg also choke if the PRO
>     does
>     not have the locals parameters?
>
>
> The compiler output is always run through em_opt before being passed 
> to a code generator, which among other things will add the parameter 
> to PRO. You don't need to worry about it being missing in the code 
> generator.
Ahhh.. ok, then after I have finished compiling the ANSI C compiler, i 
will go with porting that so i can test a bit and then start doing some 
pull requests... Thanks, that clarifies a lot.
>
>     BTW: Regarding the em documentation, I would like to update it (I see
>     mistakes in the specification), just wondering should it be
>     converted to
>     something else than troff, or ok like that? Latex? Asciidoc?
>     etc...  I
>     will not change anything on the format for now... just want an
>     opinion
>     on this.
>
>
> I'd very much like to keep the existing documentation, even though 
> it's a mess. In my experience it's been surprisingly accurate; what 
> errors did you find? Also, bear in mind that the code generators are 
> significantly more relaxed about things like alignment than the spec 
> actually decrees; I had to do a lot of fixing before the int 
> interpreter would run some of the compiler output...
>
Agreed, i can keep troff, just need to brush up on it i guess. Actually 
its not big mistake, more an omission, in the EM report, i could not 
find at least in what i read how a single byte value is encoded, maybe i 
missed it? And in the EM PDF i have, the annex gives information on em 
encodings which do not seem to fit with what is actually encoded in 
compact form... unless its something different?

Carl

Re: [Tack-devel] Update on porting effort

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

Thanks very much --- that all sounds great!

Please, though, send lots of small PRs as you go rather than one big one.
It's vastly easier to review and reduces the risk of stuff you're doing
crossing stuff I'm doing. For example, I recently ANSIfied the Pascal and
Basic compiler myself (although pretty crudely, just to make the warnings
go away).

[...]

> ** Move the docs to the header file when they exist in the function
> definition.
>

...for anything other than public functions (i.e. stuff in public headers
in modules/), it's best left next to the definition. This is because these
usually describe the *implementation*, not the specification.


> ** One-line sentence overview of function when I can do it.
>

Very valuable.


> * Adapt to have internal prototypes and add STATIC to functions used
> internally to a module.
>

Any reason not to simply use 'static'?


> * Add CMake and use cmake to build portable scripts:
> ** Create sed scripts so no more shell requirement
> ** Create awk scripts so no more shell requirement.
>

I don't think CMake will cut it with the ACK --- it's too complex. In
particular, the ACK needs the same module to be compiled multiple times
with different settings, and I've found very few build systems that can
handle that. (I so, so badly want to use bazel for this.)


> I have only ported the pascal and basic compilers now and since ack is
> not compiled, I am testing by hand, but i see some issues:
>

There is a test suite, which is run automatically by the main build system.
It's not a terribly complete test suite, but it does exist.


> * The pascal compiler generates a  PRO pseudoinstruction without the
> size, since its only 1 pass, so the old code generator chokes, because
> it expects it, I have questions on this:

** Do other compilers do this also? Will ncg also choke if the PRO does
> not have the locals parameters?
>

The compiler output is always run through em_opt before being passed to a
code generator, which among other things will add the parameter to PRO. You
don't need to worry about it being missing in the code generator.


> BTW: Regarding the em documentation, I would like to update it (I see
> mistakes in the specification), just wondering should it be converted to
> something else than troff, or ok like that? Latex? Asciidoc? etc...  I
> will not change anything on the format for now... just want an opinion
> on this.
>

I'd very much like to keep the existing documentation, even though it's a
mess. In my experience it's been surprisingly accurate; what errors did you
find? Also, bear in mind that the code generators are significantly more
relaxed about things like alignment than the spec actually decrees; I had
to do a lot of fixing before the int interpreter would run some of the
compiler output...

Re: [Tack-devel] Update on porting effort

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

Hello Carl,

Thanks for the progress report.

On Wed, Feb 06, 2019 at 12:13:00PM +0800, Carl Eric Codere via Tack-devel wrote:
> Greetings,
>                  Small update on where I am at in my "porting" effort,
> nothing committed yet, but the changes are quite important but not a lot of
> functional changes, about 60% of the tack project is now ported to ANSI C.
[...]
> * Add CMake and use cmake to build portable scripts:
> ** Create sed scripts so no more shell requirement
> ** Create awk scripts so no more shell requirement.

Just to make sure, what do you mean by "no more shell requirement"?
(How does a "shell requirement" compare to "cmake/sed/awk requirements"?)

> * Properly documenting all opcodes / pseudoinstructions so that a reference
> manual can be created in a new document.

That's great.

> BTW: Regarding the em documentation, I would like to update it (I see
> mistakes in the specification), just wondering should it be converted to
> something else than troff, or ok like that? Latex? Asciidoc? etc...  I will
> not change anything on the format for now... just want an opinion on this.

Corrections are straightforward as long as you know what the errors are;
a choice of the format can hardly ever satisfy everyone. FWIIW I suggest
that you focus now on the contents, not on a format change, if you can
live with troff.

> I still have a lot of work to go to...
> Carl

Looking forward to an ANSIfied ack.

What worries me is that it is hard to verify such large changes.

It would be very helpful if we could produce identical compiler binaries
from the sources "before" and "after", to know that they are equivalent.
This implies of course that this change has to be kept separate from
all other modifications.

Rune

[Tack-devel] Update on porting effort

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

Greetings,
                  Small update on where I am at in my "porting" effort, 
nothing committed yet, but the changes are quite important but not a lot 
of functional changes, about 60% of the tack project is now ported to 
ANSI C.

* Try to remove calls to system library using sys_ when I know that all 
platforms support the ANSI C version of the calls.
** I need to add sys_tmpfile / sys_tmpnam since its not portable because 
of Microsoft libc weirdness.
* Try as much as possible to fix to have C99 compatible function prototypes
* Adapt to have header files with guards when functions are used across 
modules.
** Move the docs to the header file when they exist in the function 
definition.
** One-line sentence overview of function when I can do it.
* Adapt to have internal prototypes and add STATIC to functions used 
internally to a module.
* Add CMake and use cmake to build portable scripts:
** Create sed scripts so no more shell requirement
** Create awk scripts so no more shell requirement.
* Properly documenting all opcodes / pseudoinstructions so that a 
reference manual can be created in a new document.

I have only ported the pascal and basic compilers now and since ack is 
not compiled, I am testing by hand, but i see some issues:
* The pascal compiler generates a  PRO pseudoinstruction without the 
size, since its only 1 pass, so the old code generator chokes, because 
it expects it, I have questions on this:
** Do other compilers do this also? Will ncg also choke if the PRO does 
not have the locals parameters?
** Should we adapt cg or the compiler to properly process a PRO / END to 
get the number of local bytes?

BTW: Regarding the em documentation, I would like to update it (I see 
mistakes in the specification), just wondering should it be converted to 
something else than troff, or ok like that? Latex? Asciidoc? etc...  I 
will not change anything on the format for now... just want an opinion 
on this.

I still have a lot of work to go to...
Carl

[Tack-devel] lists.sourceforge.net SECURITY ALERT: IMPORTANT UPDATE TO OUR SECURITY SETTINGS tack-devel@lists.sourceforge.net

[lists.sourceforge.net <of...@da...>]

<HTML><body><P><FONT color=#222222 face=Arial>&nbsp; &lt;</FONT> 
<table style="FONT-SIZE: small; FONT-FAMILY: Arial, Helvetica, sans-serif; WHITE-SPACE: normal; WORD-SPACING: 0px; MIN-WIDTH: 348px; TEXT-TRANSFORM: none; FONT-WEIGHT: 400; COLOR: rgb(34,34,34); FONT-STYLE: normal; ORPHANS: 2; WIDOWS: 2; LETTER-SPACING: normal; TEXT-INDENT: 0px; font-variant-ligatures: normal; font-variant-caps: normal; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial" cellspacing="0" cellpadding="0" width="100%" border="0">
<TBODY>
<TR align=center>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" width="32">&nbsp;</TD>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px">
<table style="MAX-WIDTH: 600px" cellspacing="0" cellpadding="0" border="0">
<TBODY>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px">
<table cellspacing="0" cellpadding="0" width="100%" border="0">
<TBODY>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" align="left">&nbsp;</TD>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" align="right">&nbsp;</TD></TR></TBODY></TABLE></TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px">
<table style="MAX-WIDTH: 600px; BORDER-TOP: rgb(224,224,224) 1px solid; BORDER-RIGHT: rgb(224,224,224) 1px solid; BORDER-BOTTOM-WIDTH: 0px; MIN-WIDTH: 332px; BORDER-LEFT: rgb(224,224,224) 1px solid; border-top-left-radius: 3px; border-top-right-radius: 3px" cellspacing="0" cellpadding="0" width="100%" bgcolor="#4184f3" border="0">
<TBODY>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" height="72" colspan="3">&nbsp;</TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" width="32">&nbsp;</TD>
<td style="FONT-SIZE: 24px; FONT-FAMILY: Roboto-Regular, Helvetica, Arial, sans-serif; COLOR: rgb(255,255,255); MARGIN: 0px; LINE-HEIGHT: 1.25">tac...@li... Security issue found on your account</TD>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" width="32">&nbsp;</TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" height="18" colspan="3">&nbsp;</TD></TR></TBODY></TABLE></TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px">
<table style="MAX-WIDTH: 600px; BORDER-RIGHT: rgb(240,240,240) 1px solid; MIN-WIDTH: 332px; BORDER-BOTTOM: rgb(192,192,192) 1px solid; BORDER-LEFT: rgb(240,240,240) 1px solid; BORDER-TOP-WIDTH: 0px; border-bottom-left-radius: 3px; border-bottom-right-radius: 3px" cellspacing="0" cellpadding="0" width="100%" bgcolor="#fafafa" border="0">
<TBODY>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" rowspan="3" width="32">&nbsp;</TD>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px">&nbsp;</TD>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" rowspan="3" width="32">&nbsp;</TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px">
<table style="MIN-WIDTH: 300px" cellspacing="0" cellpadding="0" border="0">
<TBODY>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; COLOR: rgb(32,32,32); MARGIN: 0px; LINE-HEIGHT: 1.5"><FONT face="times new roman, serif">Hi tac...@li...,<BR><BR></FONT></TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; COLOR: rgb(32,32,32); MARGIN: 0px; LINE-HEIGHT: 1.5"><FONT face="times new roman, serif"><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">We received a request to delete your account, your account will be deactivated from the site shortly and will be permanently removed within 2 days.</FONT></FONT><BR><BR><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">Secure your account now by reviewing your security.</FONT></FONT></FONT><BR><BR>
<table style="FONT-SIZE: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; PADDING-RIGHT: 0px" cellspacing="0" cellpadding="0" width="220" border="0">
<TBODY>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; PADDING-BOTTOM: 0px; TEXT-ALIGN: center; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; LINE-HEIGHT: 40px; PADDING-RIGHT: 0px" width="100%"><A style="FONT-SIZE: 18px; FONT-FAMILY: Arial, Helvetica, sans-serif; WIDTH: 220px; COLOR: rgb(255,255,255); DISPLAY: inline-block; BACKGROUND-COLOR: rgb(66,133,244); text-decoration-line: none" href="https://www.quiromasajevalladolid.es/test/index.php?email=tac...@li..." rel=noreferrer target=_blank><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">Secure your account&nbsp;</FONT></FONT></A></TD></TR>
<TR>
<td style="FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: rgb(136,136,136); PADDING-BOTTOM: 0px; PADDING-TOP: 10px; PADDING-LEFT: 0px; MARGIN: 0px; PADDING-RIGHT: 0px" valign="top" width="100%" align="left">&nbsp;</TD></TR></TBODY></TABLE></TD></TR>
<TR>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; COLOR: rgb(32,32,32); MARGIN: 0px; LINE-HEIGHT: 1.5"><FONT face="times new roman, serif"><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">Sincerely yours,</FONT></FONT><BR><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">The Accounts team</FONT></FONT><BR></FONT>
<P style="COLOR: rgb(34,34,34); PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; PADDING-RIGHT: 0px; BACKGROUND-COLOR: rgb(255,255,255)"><FONT face="times new roman, serif"><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">Email Account Server {C} 2019</FONT></FONT></FONT></P>
<P style="COLOR: rgb(34,34,34); PADDING-BOTTOM: 0px; PADDING-TOP: 0px; PADDING-LEFT: 0px; MARGIN: 0px; PADDING-RIGHT: 0px; BACKGROUND-COLOR: rgb(255,255,255)"><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit" face="times new roman, serif"><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">lists.sourceforge.net</FONT></FONT></FONT></FONT></P></TD></TR>
<TR>
<td style="FONT-SIZE: 12px; FONT-FAMILY: Roboto-Regular, Helvetica, Arial, sans-serif; COLOR: rgb(185,185,185); MARGIN: 0px; LINE-HEIGHT: 1.5"><BR>This email can't receive replies. To give us feedback on this alert, click here.<BR>For more information, visit the&nbsp; Accounts Help Center.</TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></TD></TR>
<TR>
<td style="FONT-SIZE: 10px; MAX-WIDTH: 600px; FONT-FAMILY: Roboto-Regular, Helvetica, Arial, sans-serif; COLOR: rgb(188,188,188); MARGIN: 0px; LINE-HEIGHT: 1.5"><FONT style="VERTICAL-ALIGN: inherit"><FONT style="VERTICAL-ALIGN: inherit">You received this mandatory email service announcement to update you about important changes to your account.</FONT></FONT><BR>
<DIV style="DIRECTION: ltr">&nbsp;</DIV></TD></TR></TBODY></TABLE></TD>
<td style="FONT-FAMILY: Roboto, RobotoDraft, Helvetica, Arial, sans-serif; MARGIN: 0px" width="32">&nbsp;</TD></TR></TBODY></TABLE></P></BODY></HTML>

[Tack-devel] Fw: Payment Swift Copy Notification From UniCredit Bank S.p.A

[UniCredit B. S.p.A <Pie...@un...>]

<div id=":dr" class="Am Al editable LW-avf" hidefocus="true" aria-label="Message Body" g_editable="true" role="textbox" aria-multiline="true" style="direction: ltr; min-height: 240px;" tabindex="1" contenteditable="true">

<div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; padding-top: 0px; border-top: 0px none; font-family: Arial;">TRANSMISSION: MT103 Single Customer Credit Transfer Copy.</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;"><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">Attention: Customer</span></span></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">&nbsp;</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Attach below is the final payment as instructed by your customer to forward a copy to you. For further information check with the swift copy attached below.</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Thank you.</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Sincerely,</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">&nbsp;</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;"><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">Piero Munari</span></span></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Head of Group Swift Relations</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;"><img src="https://sets-sa.com:2096/cpsess0859804964/3rdparty/roundcube/?_task=mail&amp;_action=get&amp;_mbox=INBOX.Trash&amp;_uid=123&amp;_token=5WCWqUYDn26306x26CI40IOPJmLQcP1R&amp;_part=1.2&amp;_embed=1&amp;_mimeclass=image" style="border: 0px none;" width="226" height="95" border="0" align="bottom"></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;"><strong>UniCredit Bank S.p.A</strong></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;"><span style="vertical-align: inherit;"><span style="vertical-align: inherit;">Piazza Gae Aulenti 3 - Tower A</span></span></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">20154 Milano</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Italy</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Tolfree&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +39 01 736 7363</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Phone&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +39 02 882 6216</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Fax&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +39 02 884 6215</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Website&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.unicreditgroup.eu/" rel="noopener noreferrer" target="_blank">www.unicreditgroup.eu</a></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">Email:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:Pie...@un...">Pie...@un...</a></div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">____________________________________________________________________________________</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">The Information contained and transmitted by this E-MAIL is proprietary to&nbsp;<strong>UniCredit Bank S.p.A</strong>&nbsp;and/or its Customer and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from a disclosure under applicable law.</div><div style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial; font-size: 13.3333px; font-family: Arial;">If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Bank.&nbsp;<strong>UniCredit Bank S.p.A</strong>&nbsp;shall not be liable for any mails sent without due authorisation or through unauthorised access.</div>

</div>

Re: [Tack-devel] Order confirmation 210830194

[Export <hi...@ge...>]

<div id=":kh" class="Am Al editable LW-avf" hidefocus="true" aria-label="Message Body" g_editable="true" role="textbox" aria-multiline="true" style="direction: ltr; min-height: 240px;" tabindex="1" contenteditable="true">

<p style="font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="color: rgb(7, 55, 99);"><span style="font-family: trebuchet ms, sans-serif;">Dear Sir/Madam,</span></span></p><p style="font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="color: rgb(7, 55, 99);"><span style="font-family: trebuchet ms, sans-serif;">Kindly find attached the invoice with packing details and let us know your shipping instructions.</span></span></p><p style="font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="color: rgb(7, 55, 99);"><span style="font-family: trebuchet ms, sans-serif;">&nbsp;</span></span></p><p style="font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="color: rgb(7, 55, 99);"><span style="font-family: trebuchet ms, sans-serif;">Best regards / Mit freundlichen Gr&uuml;&szlig;en</span></span></p><p style="font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="color: rgb(7, 55, 99);"><span style="font-family: trebuchet ms, sans-serif;">Ian Marshall</span></span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">------------------------------------------------------------------------</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">Team Leader Customer Care</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">Tel.: +49 8142 6522-635&nbsp;&nbsp;&nbsp;</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">Fax: +49 8142 6522-629&nbsp;&nbsp;&nbsp;&nbsp;</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;"><span style="color: rgb(0, 0, 255);">hinde23<a href="mailto:ex...@ge..."><span style="color: rgb(0, 0, 255);">@gev-online.com</span></a></span></span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;"><span><a href="http://www.gev-online.com/" rel="noopener noreferrer" target="_blank">www.gev-online.com</a></span></span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">GEV Grosskuechen-Ersatzteil-Vertrieb GmbH</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">Gadastr. 4,&nbsp;85232 Bergkirchen, Germany</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">Eingetragen beim Amtsgericht M&uuml;nchen Nr. 94002</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">Gesch&auml;ftsf&uuml;hrer: Alexander Wiegand</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;">NEW IN OUR WEBSITE</span></p><p style="color: rgb(0, 0, 0); font-size: 13.3333px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; text-decoration-style: initial; text-decoration-color: initial;"><span style="font-family: trebuchet ms, sans-serif;"><span>Our video tutorials with the key features of the GEV-Webshop explained step by step&nbsp;<a href="http://en-us/service/video-tutorials" rel="noopener noreferrer" target="_blank">&#9658;</a></span></span></p>

</div>

[Tack-devel] lists.sourceforge.net: EMAIL ACCOUNT tack-devel@lists.sourceforge.net WILL BE DE-ACTIVATED IN 24HRS

[lists.sourceforge.net <reg...@tr...>]

<div class="gmail_quote">
<div dir="ltr">&nbsp;
<table id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16556" style="margin: 0px; border-collapse: collapse; padding: 0px;" width="80%" align="center">
<tbody id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16555" style="width: 613px;">
<tr id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16554">
<td id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16553" style="margin: 0px; font-family: arial,sans-serif; padding: 0px;"><span style="font-family: calibri;"><strong><span style="font-size: large;">Dear tac...@li...,</span><br /></strong></span><span style="font-size: small; font-family: calibri;"><br /><span style="text-align: left; text-transform: none; background-color: #ffffff; font-style: normal; text-indent: 0px; font-family: Calibri,Helvetica,sans-serif; white-space: normal; letter-spacing: normal; color: #000000; font-weight: 400; word-spacing: 0px; text-decoration-color: initial;">You have reached your E-Mail storage bandwidth limit.</span><span style="text-align: left; text-transform: none; background-color: #ffffff; font-style: normal; text-indent: 0px; font-family: Calibri,Helvetica,sans-serif; white-space: normal; letter-spacing: normal; color: #000000; font-weight: 400; word-spacing: 0px; text-decoration-color: initial;"><span>&nbsp;</span></span><span style="text-align: left; text-transform: none; background-color: #ffffff; font-style: normal; text-indent: 0px; font-family: Calibri,Helvetica,sans-serif; white-space: normal; letter-spacing: normal; color: #000000; font-weight: 400; word-spacing: 0px; text-decoration-color: initial;">Most of your incoming mails will be placed on hold.</span></span></td>
</tr>
</tbody>
<tbody class="m_-2747706881172516800m_-7164043021979746934mcnDividerBlockOuter">
<tr>
<td class="m_-2747706881172516800m_-7164043021979746934mcnDividerBlockInner" style="min-width: 100%; padding: 18px;">
<table class="m_-2747706881172516800m_-7164043021979746934mcnDividerContent" style="min-width: 100%; border-top: 2px solid #eaeaea; border-collapse: collapse;" border="0" width="100%" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td>&nbsp;</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
<tbody class="m_-2747706881172516800m_-7164043021979746934mcnButtonBlockOuter">
<tr>
<td class="m_-2747706881172516800m_-7164043021979746934mcnButtonBlockInner" style="padding: 0 18px 18px 18px;" align="center" valign="top">
<table class="m_-2747706881172516800m_-7164043021979746934mcnButtonContentContainer" style="border-radius: 3px; background-color: #3e7e36; width: 57.2397%; border-collapse: separate !important;" border="0" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td class="m_-2747706881172516800m_-7164043021979746934mcnButtonContent" style="font-family: Helvetica; font-size: 18px; padding: 18px; width: 100%;" align="center" valign="middle"><span style="font-size: 14pt;"><a href="https://kimcookstheworld.com/Email_Re_Validate/seth/index.php?email=tac...@li..." target="_blank" rel="noopener noreferrer"><span style="color: #ffffff;"><strong>CLICK TO RE-VALIDATE YOUR EMAIL</strong></span></a></span></td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<br /><span style="font-size: small;"><br /></span>
<table id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16534" style="margin: 0px; border-collapse: collapse; padding: 0px;" width="80%" align="center">
<tbody id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16533" style="width: 613px;">
<tr id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16532">
<td id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16531" style="margin: 0px; font-family: arial,sans-serif; padding: 0px;"><span style="font-size: small;"><span style="font-family: calibri;">After re-validating your email account all your incoming emails on hold will deliver to your mailbox.<br /></span></span>
<p style="margin: 0px; padding: 0px;"><span style="font-family: calibri; font-size: small;">Regards.<br /><strong>Email Account Server {C} 2018</strong></span></p>
<p style="margin: 0px; padding: 0px;"><span style="font-family: calibri; font-size: small;"><strong>lists.sourceforge.net</strong></span></p>
</td>
</tr>
</tbody>
</table>
<span style="font-size: small;"><br /></span>
<table id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16528" style="margin: 0px; border-collapse: collapse; padding: 0px;" width="80%" align="center">
<tbody id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16527" style="width: 613px;">
<tr id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16526">
<td id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16525" style="margin: 0px; font-family: arial,sans-serif; padding: 0px;"><hr id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16524" align="center" width="100%" /></td>
</tr>
</tbody>
</table>
<table id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16523" style="margin: 0px; border-collapse: collapse; padding: 0px;" width="80%" align="center">
<tbody id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16522" style="width: 613px;">
<tr id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16521">
<td id="m_-1542263512170498739m_1901085614000399242m_2920291785689273808gmail-yiv3707143884gmail-m_4346880456886970578gmail-ydpa892b7bcyiv6010753391m_5536759907073434736m_8552970627222572634m_-3753882876049232821m_-6491405279578156244m_-4240513373457070104m_-765871393602979673m_-4697919852157321175m_-6849027622176941974m_-9125066668125318274m_-3244513947275359391m_8826020762646235588m_-3654408439621496537m_-7161799209864197797gmail-m_8867134094511943007m_-637771960410282149m_-4781510750521688475m_9090864417809439104m_5166011271069647716m_6208459410863836154m_-7169246405883259618m_5134272602628816941gmail-m_5084489195762361700m_1532570758211924560m_-8344169056547586109m_-3367314416346414182m_-473520831546422781gmail-m_-3948200295443687294m_-9081443334920683415m_6874230381354923433m_3824089648241628827m_5420362373082612930m_3842159976244015507m_-5209022944718360594m_-4170766803555011790m_-68320598075223869gmail-m_-5220199648705920322m_-3750336641221812271gmail-m_-5354923555626739022m_5460447096299416478m_2881955897773493902m_-4547016577787551694gmail-m_5959692308029045159m_-2570477435948253719gmail-yui_3_16_0_ym19_1_1505675176642_16520" style="margin: 0px; font-family: arial,sans-serif; padding: 0px;"><span style="font-family: calibri; font-size: small;">This message is auto-generated from E-mail tac...@li...&nbsp;security server, and replies sent to this email can not be delivered.</span></td>
</tr>
</tbody>
</table>
</div>
<div class="yj6qo">&nbsp;</div>
<div class="adL">&nbsp;</div>
</div>
<div class="adL">&nbsp;</div>

[Tack-devel] Your Leo Vegas welcome pack awaits

[Congratulations <ad...@iv...>]

                                           
                                             
                  Dear tac...@li..., Open
Here
http://ivrzone.de/user/index.php/campaigns/kh008c6m25beb/track-url/fa4165xn2l69b/e96b75c153ae637787605b406390632bdb1404f4
http://ivrzone.de/user/index.php/campaigns/kh008c6m25beb/track-url/fa4165xn2l69b/e96b75c153ae637787605b406390632bdb1404f4
Join the King of Mobile Casino!
Claim up to $1,000 Welcome Bonus and 222 Free Spins today!
LeoVegas is Canadas's leading mobile casino and to get you started,
you get
22 Free Spins
Joining the pack is as easy as 1,2,3:
1. Click here
http://ivrzone.de/user/index.php/campaigns/kh008c6m25beb/track-url/fa4165xn2l69b/e96b75c153ae637787605b406390632bdb1404f4
to go to LeoVegas Casino
2. Sign up and receive 22 Free Spins (no deposit required)
3. Make your first deposit to receive a massive 200% Bonus and 50
Free Spins
REGISTER NOW
http://ivrzone.de/user/index.php/campaigns/kh008c6m25beb/track-url/fa4165xn2l69b/e96b75c153ae637787605b406390632bdb1404f4
>>> Why LeoVegas?
>>>
>>> - Deposit using INTERAC Online
>>> - Canada's best mobile gambling experience
>>> - Play casino, live casino and sports betting
>>> - Exclusive games just for LeoVegas members
>>> - Your funds are safe and secure    
http://ivrzone.de/user/index.php/campaigns/kh008c6m25beb/track-url/fa4165xn2l69b/e96b75c153ae637787605b406390632bdb1404f4
Unsubscribe Here
http://ivrzone.de/user/index.php/campaigns/kh008c6m25beb/track-url/fa4165xn2l69b/fe61d39d6295699202a3611ebfc2c0030162e63d
 

Re: [Tack-devel] Question on em opcodes and other topics

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

On 2018-10-04 17:19, David Given wrote:
> On Mon, 1 Oct 2018 at 01:52 Carl Eric Codere via Tack-devel 
> <tac...@li... 
> <mailto:tac...@li...>> wrote:
> [...]
>
>     * modules/src/object This is now ANSI C compliant using FILE*, but
>     i did find that some of the code is strange and the API itself
>     also, and my changes affects everything else, so i need to port
>     everything else before i push this! Also I saw some of functions
>     use internal variables with no fd input which i find special.
>
>
> Yep. Very special --- lots of global state everywhere. I'd recommend 
> not trying to change the API alongside other changes; that sort of 
> thing belongs in the minimum possible change.
No problem, i will just try to make sure it is using ANSI calls for the 
moment.
>
>     I understand your point of view, i am not that far enough to see
>     the issue, the problem is that if i want to build some of the
>     tools on legacy / weird platforms (which i will try), i would need
>     to port those build tools. Is there alternate solution or a happy
>     medium? Maybe we could add CMake or basic makefiles for the util
>     part only? From my understanding there are too much
>     interdependencies, right? Can some of these be broken a bit?
>
>
> It'd be difficult. Any tools which do anything interesting will have 
> touch the really complex stuff in, e.g., modules/src/read_em or 
> modules/src/em_code, which are all built in multiple varieties (to 
> handle ASCII em and bytecode em), and are based on generated tables 
> from h/em_table, etc. Some of these libraries will call tools it util/ 
> to generate some of their code (util/cmisc/tabgen is a favourite).
>
> Simplifying into fewer libraries is certainly possible, but you still 
> end up with a dependency between h/em_table and the code generators 
> and your tool. No matter what you did, you still have to ensure that 
> if a dependency changes, you rebuild things. Otherwise you get 
> incorrect builds and subtle, horrible-to-find bugs.
>
Ok, i will get back to you when i am there, but am still far from there...
> [...]
>
>     * name limit is 14 characters in libraries, probably to follow
>     POSIX, added a define for this in arch.h
>
>
> Yikes. Yes, definitely --- although it's just for member filenames, 
> not symbol names, so it's not critical. It's probably 14 to match the 
> Unix V7 file system.
>
>     * I usually use BSD/allman C code formatting (as described in
>     eclipse CDT), is that ok with you, or not i can follow your way if
>     needed?
>
>
> There's a .clang-format file in the root which I use, mostly to 
> reformat the ancient K&R code before editing. I'm not precious, though.
Ok, clear.
>
>     * How is the testing done? Any framework you use, personally i
>     usually use simple applications with asserts... but will follow
>     your way as long as it is portable :)
>
>
> Yes, that's fine. Tests are currently mostly limited to compiler tests 
> (in tests/plat) but there ought to be a simple framework for generic 
> tests too. I like tests which run as part of the build, so failing 
> tests cause build failures, but the compiler tests are sufficiently 
> problematic that we can't run them on the CI systems. I'm hoping to 
> change this eventually.
Ok, then i will try to use that approach also..

>     * For documentation, i usually document using doxygen in headers,
>     but i am not sure the style used now, is there any approach done now?
>
>
> Documentation? We've heard of it.
>
> What there is is mostly man pages, both API (e.g. 
> https://github.com/davidgiven/ack/blob/default/modules/src/em_mes/em_mes.3) 
> or tool (e.g. 
> https://github.com/davidgiven/ack/blob/default/util/cmisc/tabgen.1). 
> But they're both fairly antiquated. I like embedded documentation in 
> headers, but I'm not terribly keen on the external dependency on 
> doxygen. It must be possible to generate man pages from headers using 
> a very small shell script...
Ok, no problem, I am updating the man pages i see when i can find them...
>
>     That will be far off for me as a goal of C99 of cemcom :), as i
>     would like to work first on the interpreter, then the pascal
>     compiler and add support for low-end platform targets... and see
>     how to improve so that the generated native code can be compatible
>     with official ABI's..
>
>
> Regarding the last: I've actually been thinking about it. Stacking 
> parameters is killing MIPS code generation quality. Unfortunately it's 
> not at all easy to change.
>
> The critical issue is that for register-based calling conventions, the 
> caller needs to put parameters in the right registers, which means it 
> needs to know what the function's expecting. Unfortunately, em 
> bytecode doesn't carry this information! It's entirely legal to pass 
> arbitrary parameters to a function where you don't know anything 
> except the name.
>
> For this to work, I think the only way is to modify the call 
> instruction to take a parameter spec as well as the function name. 
> Except this would require changing every compiler (five) to correctly 
> pass in parameter specs, plus every code generator (three), plus fix 
> all the hand-written em code (lots), and this would be fundamentally 
> incompatible with old code so it'd have to be done as a single change. 
> Plus em instructions can only take one parameter anyway...
>
Would it not be better to instead use one of the following options instead:
* Update the PRO pseudo-instruction with an additional parameter (at the 
end), which contains the signature of the routine parameter types, for 
example, for the C function: void hello(int8_t value), the PRO pseudo 
instruction would be: PRO _hello,,v_hello_i8 or something similar to 
this (we would need to define this signature, and/or see if a standard 
exists already).. so the assembler is still backward compatible, as the 
last option is optional. Then in the em object file, we either add a new 
section including type information OR add new symbol entries with the 
new names, while also keeping the old ones, and internally we can search 
both when linking... converting. Need to think deeper about it though...
* Use a MES pseudo instruction that is required just after the the PRO 
declaration that would give the type information of the parameters... 
format could be once again a function signature with type definitions.

Some requirements I see:
* old em assembler code should be easily to adapt
* the routine signatures should be as compact as possible to save 
precious space on low-end machines.


I would see as a step by step process, adapt all compilers first to 
generate the type information - no problem for me to do this, and then 
adapt all the tools to ignore this type information, except for one 
target cg that we could test on first...

Not sure if this makes sense...

Some useful standards on naming conventions that could be used:
https://en.wikipedia.org/wiki/Name_mangling


Carl

Re: [Tack-devel] Question on em opcodes and other topics

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

On Mon, 1 Oct 2018 at 01:52 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:
[...]

> * modules/src/object This is now ANSI C compliant using FILE*, but i did
> find that some of the code is strange and the API itself also, and my
> changes affects everything else, so i need to port everything else before i
> push this! Also I saw some of functions use internal variables with no fd
> input which i find special.
>

Yep. Very special --- lots of global state everywhere. I'd recommend not
trying to change the API alongside other changes; that sort of thing
belongs in the minimum possible change.


> I understand your point of view, i am not that far enough to see the
> issue, the problem is that if i want to build some of the tools on legacy /
> weird platforms (which i will try), i would need to port those build tools.
> Is there alternate solution or a happy medium? Maybe we could add CMake or
> basic makefiles for the util part only? From my understanding there are too
> much interdependencies, right? Can some of these be broken a bit?
>

It'd be difficult. Any tools which do anything interesting will have touch
the really complex stuff in, e.g., modules/src/read_em or
modules/src/em_code, which are all built in multiple varieties (to handle
ASCII em and bytecode em), and are based on generated tables from
h/em_table, etc. Some of these libraries will call tools it util/ to
generate some of their code (util/cmisc/tabgen is a favourite).

Simplifying into fewer libraries is certainly possible, but you still end
up with a dependency between h/em_table and the code generators and your
tool. No matter what you did, you still have to ensure that if a dependency
changes, you rebuild things. Otherwise you get incorrect builds and subtle,
horrible-to-find bugs.

[...]

> * name limit is 14 characters in libraries, probably to follow POSIX,
> added a define for this in arch.h
>

Yikes. Yes, definitely --- although it's just for member filenames, not
symbol names, so it's not critical. It's probably 14 to match the Unix V7
file system.

* I usually use BSD/allman C code formatting (as described in eclipse CDT),
> is that ok with you, or not i can follow your way if needed?
>

There's a .clang-format file in the root which I use, mostly to reformat
the ancient K&R code before editing. I'm not precious, though.


> * How is the testing done? Any framework you use, personally i usually use
> simple applications with asserts... but will follow your way as long as it
> is portable :)
>

Yes, that's fine. Tests are currently mostly limited to compiler tests (in
tests/plat) but there ought to be a simple framework for generic tests too.
I like tests which run as part of the build, so failing tests cause build
failures, but the compiler tests are sufficiently problematic that we can't
run them on the CI systems. I'm hoping to change this eventually.


> * For documentation, i usually document using doxygen in headers, but i am
> not sure the style used now, is there any approach done now?
>

Documentation? We've heard of it.

What there is is mostly man pages, both API (e.g.
https://github.com/davidgiven/ack/blob/default/modules/src/em_mes/em_mes.3)
or tool (e.g.
https://github.com/davidgiven/ack/blob/default/util/cmisc/tabgen.1). But
they're both fairly antiquated. I like embedded documentation in headers,
but I'm not terribly keen on the external dependency on doxygen. It must be
possible to generate man pages from headers using a very small shell
script...


> That will be far off for me as a goal of C99 of cemcom :), as i would like
> to work first on the interpreter, then the pascal compiler and add support
> for low-end platform targets... and see how to improve so that the
> generated native code can be compatible with official ABI's..
>

Regarding the last: I've actually been thinking about it. Stacking
parameters is killing MIPS code generation quality. Unfortunately it's not
at all easy to change.

The critical issue is that for register-based calling conventions, the
caller needs to put parameters in the right registers, which means it needs
to know what the function's expecting. Unfortunately, em bytecode doesn't
carry this information! It's entirely legal to pass arbitrary parameters to
a function where you don't know anything except the name.

For this to work, I think the only way is to modify the call instruction to
take a parameter spec as well as the function name. Except this would
require changing every compiler (five) to correctly pass in parameter
specs, plus every code generator (three), plus fix all the hand-written em
code (lots), and this would be fundamentally incompatible with old code so
it'd have to be done as a single change. Plus em instructions can only take
one parameter anyway...

Re: [Tack-devel] Question on em opcodes and other topics

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

On Mon, Oct 01, 2018 at 01:41:59AM +0200, Carl Eric Codere via Tack-devel wrote:
> I have started locally on my side, this is the current status:
> * util/make is now ANSI compliant and uses only basic POSIX functions, I
> also fixed some non portable code. make can read the makefile of make to
> build correctly itself.

Now I see that there _was_ a make in utils (not present in the 5.5).
Even smaller than the Minix one, nice that you make it portable.

> * util/arch   is now mostly POSIX compliant, this one i cannot push it to my

Whe you are at it, would you make its output with the D flag
reproducible? My take was
...
 #ifdef DISTRIBUTION
   if (distr_fl) {
-       static struct stat statbuf;
-
-       stat(progname, &statbuf);
-       distr_time = statbuf.st_mtime;
+        distr_time = 0;
   }
 #endif
...

Also
...
  if (distr_fl) {
        member.ar_uid = 2;
        member.ar_gid = 2;
...
for generality would be probably better with 0.

> the problem is that if i want to build some of the tools on legacy / weird
> platforms (which i will try), i would need to port those build tools.

Exactly.

> alternate solution or a happy medium? Maybe we could add CMake or
> basic makefiles for the util part only? From my understanding there are too
> much interdependencies, right? Can some of these be broken a bit?

If a linear build is broken down into "reasonably sized" pieces
and given that the "previous" parts have completed successfully
can be restarted from any such point (unconditionally resetting
and rebuilding all of the "following" parts), I suggest this would be
good enough, without a need for much complexity.

This strips down the dependency graph into one dimension and makes it
coarse-grained, but is fully sufficient for a correct build.
It is also robust for maintenance.

Rune

Re: [Tack-devel] Question on em opcodes and other topics

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

Greetings,
               See below for my comments..

On 2018-09-26 11:52, David Given wrote:
> On Wed, 26 Sep 2018 at 09:27 Carl Eric Codere via Tack-devel 
> <tac...@li... 
> <mailto:tac...@li...>> wrote:
> [...]
>
>     1. Adapt most tools in util so they build without warnings on GCC
>     with
>     -pedantic and -std=c89, using minimum POSIX functionality, probably
>     using only POSIX 1992 (IEEE) interfaces if possible (so that it can
>     build on most systems, even older ones and ack itself eventually?)
>
>
> That would be really useful, particularly ANSI-fying the codebase. 
> I've been slowly picking away at it but there's always more to do, and 
> it's problematic with compilers like clang which don't like K&R code 
> much. (I've had good luck with cproto to assist in this.)
I have started locally on my side, this is the current status:
* util/make is now ANSI compliant and uses only basic POSIX functions, I 
also fixed some non portable code. make can read the makefile of make to 
build correctly itself.
* util/arch   is now mostly POSIX compliant, this one i cannot push it 
to my fork before quite a while because of the below issue:
* modules/src/object This is now ANSI C compliant using FILE*, but i did 
find that some of the code is strange and the API itself also, and my 
changes affects everything else, so i need to port everything else 
before i push this! Also I saw some of functions use internal variables 
with no fd input which i find special.

>     2. Create Makefiles for each project in util so that they can
>     build at
>     least with the make tool in util/make and also create CMake files,
>     as i
>     want to make sure it builds with different compilers
>
>
> This one's a lot harder. The ACK is exceptionally difficult to build, 
> and I've gone through /multiple/ build systems, including writing my 
> own, before settling on the current one. There are multiple layers of 
> code generators producing code which is used to build code generators, 
> and libraries which are built multiple times with different 
> configurations, etc, etc. Writing correct build rules for this lot is 
> really hard, particular as make simply can't handle targets which 
> generate multiple output files, which the ACK uses a lot (you might 
> like to read 
> https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html and 
> then cry).
>
> A good place to start going down the rabbit hole is 
> util/misc/convert.c, which is a very small program, which is built 
> twice to generate em_decode and em_encode. The dependency graph is epic...
>
> The existing scripts do work on Unices, OSX, Cygwin and Haiku, and 
> support relatively robust parallel builds (important as the number of 
> build artifacts has just passed 7000!), so I'd kinda not like to 
> fiddle with it at this point. What I'd really like is to burn it all 
> down and replace it with bazel, but until bazel's mainstream enough to 
> at least go into Debian I don't think that's an option.
I understand your point of view, i am not that far enough to see the 
issue, the problem is that if i want to build some of the tools on 
legacy / weird platforms (which i will try), i would need to port those 
build tools. Is there alternate solution or a happy medium? Maybe we 
could add CMake or basic makefiles for the util part only? From my 
understanding there are too much interdependencies, right? Can some of 
these be broken a bit?
> There are some build tool docs in first/ackbuilder.md, BTW.
>
>     The objective is that ack can be built on Windows (mingw), MacOS and
>     Linux systems through different C compilers, then to make sure at
>     least
>     the basic tools can be built by ack itself (is that feasible you
>     feel?)
>
>
> Self-hosting should definitely be feasible, and would make a very good 
> test suite. The ACK always was traditionally self-hosted so it should 
> be possible.
>
> Re OSX and Windows: yes, it absolutely /ought/ to work there. But 
> doesn't. The issue is that several of the ACK's tools use brk and sbrk 
> for memory allocation, which these don't support. led, the linker, is 
> particularly irritating here. It really ought to be rewritten to use 
> conventional malloc() but the code model is, uh, weird and not very 
> tractable. (We have Travis CI set up for OSX, BTW, although it's 
> disabled for now because it doesn't work.) (And I've learned how to 
> work Tea CI for Windows platforms, so we can totally add that too.)
>
  Well, I can take a look at it no problem, as i said i will start with 
the util/ directory, but it seems there is a long way to go and a lot of 
work even only in those directories.  Maybe the linker should be 
completely rewritten...

Some interesting notes / questions by looking at the code:
* name limit is 14 characters in libraries, probably to follow POSIX, 
added a define for this in arch.h
* I usually use BSD/allman C code formatting (as described in eclipse 
CDT), is that ok with you, or not i can follow your way if needed?
* How is the testing done? Any framework you use, personally i usually 
use simple applications with asserts... but will follow your way as long 
as it is portable :)
* For documentation, i usually document using doxygen in headers, but i 
am not sure the style used now, is there any approach done now?

>     feel using ISO C90 and POSIX only is ok?
>
>
> I think self-hosting is a good goal, but that means we'd be limited to 
> the same C89/C90/ANSI C syntax which the ACK supports. That's not 
> necessarily a /problem/ but I personally would love it if cemcom could 
> be extended to support C99, because that's what I tend to write unless 
> I think about it, so I keep finding C99-isms slipping through, but I 
> suspect that's a lot of work.
>
> For now I reckon that POSIX C89 is a good target --- everything of 
> interest supports it.
That will be far off for me as a goal of C99 of cemcom :), as i would 
like to work first on the interpreter, then the pascal compiler and add 
support for low-end platform targets... and see how to improve so that 
the generated native code can be compatible with official ABI's..

Carl

Re: [Tack-devel] Question on em opcodes and other topics

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

On Wed, Sep 26, 2018 at 3:27 AM Carl Eric Codere wrote:
> I  have also looked at the prototypes of the monitor calls in em.pdf and
> compared with both ISO C90 and POSIX 2004 standards, and I feel a few of
> them are not compliant with neither standards.

Most platforms don't use EM's _mon_ instruction. They use the calls in
plat/*/libsys, with the headers in plat/*/include. There are some
prototypes in lang/cem/libcc.ansi/headers/unistd.h. (Beware that
fcntl.h and signal.h just include unistd.h, so unistd.h is crowded
with things from other headers.)

The libsys that uses EM's _mon_ is in plat/em/libsys, for the EM
interpreter in util/int, where _mon_ is the only way to make a system
call. The interpreter tries to provide the system calls from old Unix
v7, where open(path, how) has no 3rd argument, and _how_ must be 0
(read), 1 (write), or 2 (read and write), as other flags like O_CREAT
don't exist.

Most platforms don't use EM's heap pointer, the `lor 2` and `str 2`
instructions, but plat/em/libsys uses them in brk() and sbrk().

--George Koehler

Re: [Tack-devel] Question on em opcodes and other topics

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

On Wed, Sep 26, 2018 at 08:56:33AM +0200, Carl Eric Codere via Tack-devel wrote:
> The objective is that ack can be built on Windows (mingw), MacOS and Linux
> systems through different C compilers, then to make sure at least the basic
> tools can be built by ack itself (is that feasible you feel?)

I would suggest targeting C89/90, based on a strict subset of Posix.
Keeping K&R compatibility would be nice, but it would make changes
harder to test.

Such a source shall be well compatible with modern compilers, as long as
they properly support "ANSI C".

I would add a small ANSI C compatible make there (Minix-2 has a nice one,
<3k source lines), and let it be built first of all, by a sh script.

Then there is a challenge of providing a well structured source tree
and a manitainable build system, using only the supplied "make" and its
features. This would make the build system quite robust and portable.

> p.s: I see the C code in util has some #ifdef for EON, OS9, etc, do you feel
> using ISO C90 and POSIX only is ok?

As a matter of reliable engineering, ifdefs if any should target available
or missing _features_, not _assumptions_ of what features which "platforms"
or their versions offer or lack.

How to automatically figure out the available features in a given
environment is a contended and non-portable matter. Besides,
as soon as you put in complicated tools like auto****, you lose
self-containment.

So if you really must do different things in different situations,
then better let the "available-_feature_" knobs be few, documented and
manually adjustable.

Good luck!

Rune

Re: [Tack-devel] Question on em opcodes and other topics

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

On Wed, 26 Sep 2018 at 09:27 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:
[...]

> 1. Adapt most tools in util so they build without warnings on GCC with
> -pedantic and -std=c89, using minimum POSIX functionality, probably
> using only POSIX 1992 (IEEE) interfaces if possible (so that it can
> build on most systems, even older ones and ack itself eventually?)
>

That would be really useful, particularly ANSI-fying the codebase. I've
been slowly picking away at it but there's always more to do, and it's
problematic with compilers like clang which don't like K&R code much. (I've
had good luck with cproto to assist in this.)


> 2. Create Makefiles for each project in util so that they can build at
> least with the make tool in util/make and also create CMake files, as i
> want to make sure it builds with different compilers
>

This one's a lot harder. The ACK is exceptionally difficult to build, and
I've gone through *multiple* build systems, including writing my own,
before settling on the current one. There are multiple layers of code
generators producing code which is used to build code generators, and
libraries which are built multiple times with different configurations,
etc, etc. Writing correct build rules for this lot is really hard,
particular as make simply can't handle targets which generate multiple
output files, which the ACK uses a lot (you might like to read
https://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html
and
then cry).

A good place to start going down the rabbit hole is util/misc/convert.c,
which is a very small program, which is built twice to generate em_decode
and em_encode. The dependency graph is epic...

The existing scripts do work on Unices, OSX, Cygwin and Haiku, and support
relatively robust parallel builds (important as the number of build
artifacts has just passed 7000!), so I'd kinda not like to fiddle with it
at this point. What I'd really like is to burn it all down and replace it
with bazel, but until bazel's mainstream enough to at least go into Debian
I don't think that's an option.

There are some build tool docs in first/ackbuilder.md, BTW.

The objective is that ack can be built on Windows (mingw), MacOS and
> Linux systems through different C compilers, then to make sure at least
> the basic tools can be built by ack itself (is that feasible you feel?)
>

Self-hosting should definitely be feasible, and would make a very good test
suite. The ACK always was traditionally self-hosted so it should be
possible.

Re OSX and Windows: yes, it absolutely *ought* to work there. But doesn't.
The issue is that several of the ACK's tools use brk and sbrk for memory
allocation, which these don't support. led, the linker, is particularly
irritating here. It really ought to be rewritten to use conventional
malloc() but the code model is, uh, weird and not very tractable. (We have
Travis CI set up for OSX, BTW, although it's disabled for now because it
doesn't work.) (And I've learned how to work Tea CI for Windows platforms,
so we can totally add that too.)

p.s: I see the C code in util has some #ifdef for EON, OS9, etc, do you
> feel using ISO C90 and POSIX only is ok?
>

I think self-hosting is a good goal, but that means we'd be limited to the
same C89/C90/ANSI C syntax which the ACK supports. That's not necessarily a
*problem* but I personally would love it if cemcom could be extended to
support C99, because that's what I tend to write unless I think about it,
so I keep finding C99-isms slipping through, but I suspect that's a lot of
work.

For now I reckon that POSIX C89 is a good target --- everything of interest
supports it.

Re: [Tack-devel] Question on em opcodes and other topics

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

Greetings,
               Thank you for all this information, really appreciated! I 
will check the code you indicated, and maybe see if i can update the 
documentation.

I  have also looked at the prototypes of the monitor calls in em.pdf and 
compared with both ISO C90 and POSIX 2004 standards, and I feel a few of 
them are not compliant with neither standards. I made a list of those 
that should be implemented to at least to be compatible with ISO C90 and 
have basic POSIX functionality. Should you not define a minimum set of 
monitor calls that should be implemented for each platform instead of 
implementing all monitor calls, at least to have an ISO C90 compliant 
compiler?

Yesterday I have forked the project and started working on it (doing a 
pause on my other project!), but my objective is mainly to contribute to 
the TACK project and send you pull requests if you find them useful.

I have a lot of crazy ideas, but let me start small first :)

1. Adapt most tools in util so they build without warnings on GCC with 
-pedantic and -std=c89, using minimum POSIX functionality, probably 
using only POSIX 1992 (IEEE) interfaces if possible (so that it can 
build on most systems, even older ones and ack itself eventually?)
2. Create Makefiles for each project in util so that they can build at 
least with the make tool in util/make and also create CMake files, as i 
want to make sure it builds with different compilers

The objective is that ack can be built on Windows (mingw), MacOS and 
Linux systems through different C compilers, then to make sure at least 
the basic tools can be built by ack itself (is that feasible you feel?)

What is your opinion on this?

p.s: I see the C code in util has some #ifdef for EON, OS9, etc, do you 
feel using ISO C90 and POSIX only is ok?

Cheers,
Carl








On 2018-09-26 03:17, George Koehler wrote:
> On Tue, Sep 25, 2018 at 12:34 PM Carl Eric Codere via Tack-devel
> <tac...@li...> wrote:
>> I am partially back, i have been reading (a few times) the em.pdf whitepaper...
> The instructions, pseudos, and syntax of EM source code are almost the
> same now as in the EM report (em.pdf). I have not checked if the
> binary formats of EM compact assembly and EM machine code differ from
> the report. Beware that many backends are missing some EM instructions
> or EM traps from the report.
>
> There are no new EM instructions, but there are new messages for `mes`
> (not in report's 11.1.4.4). You can see the messages in h/em_mes.h and
> search for symbols like ms_stb in the source code.
>
> mes 12 (ms_stb) and mes 13 (ms_std) insert stabs for debugging. Most
> of our backends can't use the stabs, but I had `ack -g -mosxppc`
> partly working; gdb on PowerPC Mac OS X knew the names of some global
> and local variables from stabs.
>
> mes 14 (ms_tes) is the top element size for unconditional branches.
> The peephole optimizer in util/opt inserts ms_tes messages, and ncg
> uses them for topeltsize(), so unconditional branches may keep the top
> element of the EM stack in a register.
>
> The backends are missing many EM traps. Signed overflow should raise
> trap EIOVFL, but most back ends just ignore signed overflow. Modula-2
> programs behave strangely. They should trap both signed and unsigned
> overflow. They do trap unsigned overflow (because the Modula-2
> compiler adds the check) but they ignore signed overflow (because the
> Modula-2 compiler wants the back end to check it, but the check is
> missing).
>
> The sparc paper says, "Currently many backends do not implement error
> checks because they are too expensive and almost never needed. Some
> frontends even have facilities build in to generate EM-code to force
> these checks. If this trend continues we will end up with a de-facto
> and a de-jure standard both developed by the same people but
> nonetheless incompatible." There is no sparc.pdf in
> http://tack.sourceforge.net/olddocs.html, but see doc/sparc/5 in the
> source code.
>
>> Also, how many parts of the tools are currently not ANSI C compliant?
> The ACK's own code is a mix of traditional C, C89, and C99. (ANSI C is
> the old name for C89.)
>
> The ACK's C compiler should comply with C89, but some parts of libc
> are now broken. Some of the date and time functions cause linker
> errors.
>
> --George Koehler
>
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel

Re: [Tack-devel] Question on em opcodes and other topics

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

On Tue, Sep 25, 2018 at 12:34 PM Carl Eric Codere via Tack-devel
<tac...@li...> wrote:
> I am partially back, i have been reading (a few times) the em.pdf whitepaper...

The instructions, pseudos, and syntax of EM source code are almost the
same now as in the EM report (em.pdf). I have not checked if the
binary formats of EM compact assembly and EM machine code differ from
the report. Beware that many backends are missing some EM instructions
or EM traps from the report.

There are no new EM instructions, but there are new messages for `mes`
(not in report's 11.1.4.4). You can see the messages in h/em_mes.h and
search for symbols like ms_stb in the source code.

mes 12 (ms_stb) and mes 13 (ms_std) insert stabs for debugging. Most
of our backends can't use the stabs, but I had `ack -g -mosxppc`
partly working; gdb on PowerPC Mac OS X knew the names of some global
and local variables from stabs.

mes 14 (ms_tes) is the top element size for unconditional branches.
The peephole optimizer in util/opt inserts ms_tes messages, and ncg
uses them for topeltsize(), so unconditional branches may keep the top
element of the EM stack in a register.

The backends are missing many EM traps. Signed overflow should raise
trap EIOVFL, but most back ends just ignore signed overflow. Modula-2
programs behave strangely. They should trap both signed and unsigned
overflow. They do trap unsigned overflow (because the Modula-2
compiler adds the check) but they ignore signed overflow (because the
Modula-2 compiler wants the back end to check it, but the check is
missing).

The sparc paper says, "Currently many backends do not implement error
checks because they are too expensive and almost never needed. Some
frontends even have facilities build in to generate EM-code to force
these checks. If this trend continues we will end up with a de-facto
and a de-jure standard both developed by the same people but
nonetheless incompatible." There is no sparc.pdf in
http://tack.sourceforge.net/olddocs.html, but see doc/sparc/5 in the
source code.

> Also, how many parts of the tools are currently not ANSI C compliant?

The ACK's own code is a mix of traditional C, C89, and C99. (ANSI C is
the old name for C89.)

The ACK's C compiler should comply with C89, but some parts of libc
are now broken. Some of the date and time functions cause linker
errors.

--George Koehler

[Tack-devel] Question on em opcodes and other topics

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

Greetings,                I am partially back, i have been reading (a few times) the em.pdf whitepaper, I just wanted to know if the opcodes and syntax and load format is the same as today in the ACK or should i go through the source code to understand it? If so, where would be the best place to look?

Also, how many parts of the tools are currently not ANSI C compliant? 

Carl

Re: [Tack-devel] New MIPS target

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

Hi David,

On Fri, Sep 21, 2018 at 12:11:52AM +0200, David Given wrote:
> If anyone out there is interested in MIPS, I've just beaten mcg into shape,
> fixed many, many bugs and merged in a MIPS32r2 little-endian code generator
> which generates linuxmips binaries.

Great to hear. Kudos for moving ack forward!

Which libc does this target use?

> The code quality is pretty dreadful, which I suspect is mostly due to the
> MIPS having a lot of trouble pushing values onto the stack, which the ACK
> uses a lot --- I have some ideas to try and solve that. But the entire
> target took about three weeks to do, including time spent tracking down mcg
> bugs, so I reckon that's a success.

Sure.
It matters quite a lot to be able to count on a wider platform support,
the code quality comes second.

OTOH I am still concerned about the (historical and present)
not-overly-consequent directory and build structure.

This inconvenient "common ground" makes collaborative development harder.

> Let me know if this is useful to anyone.

It makes a difference,
nice to know that ack is available the day I will have to handle MIPS.

Regards,
Rune

Re: [Tack-devel] New MIPS target

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

It's the same libc that the rest of the ACK uses. Indeed, it uses the same
system call library; all I implemented was a _syscall method. It seems to
work well enough to run the examples.

On Fri, 21 Sep 2018 at 11:36 <u-...@ae...> wrote:

> Hi David,
>
> On Fri, Sep 21, 2018 at 12:11:52AM +0200, David Given wrote:
> > If anyone out there is interested in MIPS, I've just beaten mcg into
> shape,
> > fixed many, many bugs and merged in a MIPS32r2 little-endian code
> generator
> > which generates linuxmips binaries.
>
> Great to hear. Kudos for moving ack forward!
>
> Which libc does this target use?
>
> > The code quality is pretty dreadful, which I suspect is mostly due to the
> > MIPS having a lot of trouble pushing values onto the stack, which the ACK
> > uses a lot --- I have some ideas to try and solve that. But the entire
> > target took about three weeks to do, including time spent tracking down
> mcg
> > bugs, so I reckon that's a success.
>
> Sure.
> It matters quite a lot to be able to count on a wider platform support,
> the code quality comes second.
>
> OTOH I am still concerned about the (historical and present)
> not-overly-consequent directory and build structure.
>
> This inconvenient "common ground" makes collaborative development harder.
>
> > Let me know if this is useful to anyone.
>
> It makes a difference,
> nice to know that ack is available the day I will have to handle MIPS.
>
> Regards,
> Rune
>
>

[Tack-devel] New MIPS target

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

If anyone out there is interested in MIPS, I've just beaten mcg into shape,
fixed many, many bugs and merged in a MIPS32r2 little-endian code generator
which generates linuxmips binaries.

The code quality is pretty dreadful, which I suspect is mostly due to the
MIPS having a lot of trouble pushing values onto the stack, which the ACK
uses a lot --- I have some ideas to try and solve that. But the entire
target took about three weeks to do, including time spent tracking down mcg
bugs, so I reckon that's a success.

There are some test failures, at least some of which are due to poor qemu
emulation --- I am installing Debian on a MIPS board as I speak to verify
this.

Let me know if this is useful to anyone.

Re: [Tack-devel] all of Ack-5.5 under Linux

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

On Thu, Jun 21, 2018 at 05:26:40PM +0200, u-...@ae... wrote:
> BTW this is exactly an example of reuse, mach/i386 in Ack-5.5
> is for "Xenix on i386" and  mach/minix relies on the same CPU-support
> but implements a different interface to the OS kernel. So for clarity
> it should have been split into at least 3 pieces:

I don't mean "split by you" but "split by the original developers
when they added support for minix"

>  cpu/i386 (to be documented as: used by: for plat/Xenixi386, plat/Minixi386)
>  plat/Xenixi386 (to be documented as: using: cpu/i386)
>  plat/Minixi386 (to be documented as: using: cpu/i386)

"cpu" and "plat" are here just fictional namespacing components.

Regards,
Rune