tack-devel — Discussion for developers of the ACK.

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

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

On Thu, Jun 21, 2018 at 12:30:23AM +0200, David Given wrote:
> Yup. In fact, 5.5 had the same divide, it's just it put both types of thing
> in the same mach directory --- this is why there's a mach/minix (containing
> the OS-specific bit) and a mach/i386 (containing the CPU-specific bit). I
> split these into two directories because I found it confusing.

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:

 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)

Regards,
Rune

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

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

On Thu, Jun 21, 2018 at 12:30:23AM +0200, David Given wrote:
> > "a combinations of a CPU and an OS syscall API"?

> Yup. In fact, 5.5 had the same divide, it's just it put both types of thing
> in the same mach directory --- this is why there's a mach/minix (containing
> the OS-specific bit) and a mach/i386 (containing the CPU-specific bit). I
> split these into two directories because I found it confusing.

Sigh.

> The libc is currently in lang/cem/libcc.ansi, and it contains both the
> OS-generic things like strcmp() and malloc(), and also some OS-specific
> things like system() and stdio, which rely on Posix system calls. This is
> all mixed together and there's no (good) way for a plat to configure it.

> > The reusable parts do not logically "belong" to any "machine target"
> > so for clarity should have their own place.
> 
> What do you mean by reusable parts in this context?

I mean that the product, the useful "platform" implementations are being
constructed from pieces of varying generality (the libcs, the runtime
support like floating point routines, even the code generators can have
common parts).

For example a "malloc()" implementation can be usable with multiple
OS APIs and multiple CPUS, but probably not suit all of the ones or the
others.

It would be quite straightforward to have a copy of each needed piece to
be present at each "platform" but then we'd have lots of duplicated code.

The duplicated part would be what I call "reusable" (i.e. not "specific"
nor "common", the latter being an extreme special case of "reusable").

It is the irregularity of reusability of different parts of the code
which makes the picture cloudy.

To make it better, the first thing could be to write down
a document about the relations/reuse of the different parts of the code.

The next step would be to streamline the namespacing (the directory
tree allocation) so that all differently used parts would be separated
from each other.

OTOH the right thing is of course what works for you the developer.

Regards,
Rune

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

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

On Wed, 20 Jun 2018 at 22:47 <u-...@ae...> wrote:
[...]

> What is a "machine target"? Guessing:
> "a combinations of a CPU and an OS syscall API"?
> This is more or less what Ack-5.5 "mach" is, that's why I asked.
>

Yup. In fact, 5.5 had the same divide, it's just it put both types of thing
in the same mach directory --- this is why there's a mach/minix (containing
the OS-specific bit) and a mach/i386 (containing the CPU-specific bit). I
split these into two directories because I found it confusing.

The libc is currently in lang/cem/libcc.ansi, and it contains both the
OS-generic things like strcmp() and malloc(), and also some OS-specific
things like system() and stdio, which rely on Posix system calls. This is
all mixed together and there's no (good) way for a plat to configure it.


> The reusable parts do not logically "belong" to any "machine target"
> so for clarity should have their own place.
>

What do you mean by reusable parts in this context?

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

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

On Wed, Jun 20, 2018 at 07:59:00PM +0200, David Given wrote:
> Re build tools: unfortunately the ACK is a really complex thing to build
> with lots of code generation and dependencies between components. The old
> build system didn't even try to track any of this stuff and relied on a
> hard-coded build order and single-threaded builds; but it was impossibly
> slow and impossible to understand, and didn't really achieve correct builds
> anyway. It was completely unable to be modified to support parallel builds.
> Hence the succession of new build systems.

I see. Fortunately it is not exactly "impossibly slow" on a relatively modern
processor and a well-performing file system. It takes less than 3 minutes
to do a full build from scratch here.
OTOH it does not seem to be meant/capable to do partial rebuilds.

Parallel builds bring an additional degree of complexity,
that's why I feel fine without them.

> I'm actually on the verge of giving up on make completely; it's essentially
> unable to do correct builds no matter how hard you try (try to build
> something which produces multiple output files some time!).

I would say go ahead. Make has it own niche but is hardly the right
tool for complex projects.

Even Ack's "scripts which builds scripts" are easier to analyze than
a corresponding tree of Makefiles, because they do not [have to] implement
exhaustive dependency resolution.

I wouldn't mind fully lua-based build tools, because I have got ack-built
lua and hence it is in the same "maintenance complexity domain".

> Re mach vs plat: mach contains CPU architectures, plat contains machine
> targets. Each plat depends on a single mach, but each mach may be used by

What is a "machine target"? Guessing:
"a combinations of a CPU and an OS syscall API"?
This is more or less what Ack-5.5 "mach" is, that's why I asked.

Then a target implementation implies a CPU-specific code generator
(which in your setup falls under "mach"? good)
and a libc implementation, possibly consisting of three parts,
 OS-generic,CPU-specific        <= a candidate for reuse by reference
 OS-specific,CPU-generic        <= a candidate for reuse by reference
 OS-specific,CPU-specific
right?

The reusable parts do not logically "belong" to any "machine target"
so for clarity should have their own place.

It would help if the source would consistently reflect the above.

Afaics that's why the current structure is hard to manage,
it does not make these relations sufficiently explicit.

> any number of plats. (Although not all the platform-specific stuff has been
> moved out of mach yet.)
> 
> Re libc problems: I don't know whether this is present in 5.5, but I
> wouldn't be surprised if it did. The problem is that the libc depends on
> many, many symbols which don't have prototypes by just importing them with
> extern. It's particularly keen on calling leading-underscore versions of
> system calls, so the implementation of system() actually calls _execl() to
> do the work. If the syscall library doesn't implement _execl() and only
> implements execl() then everything will appear to work until you try to
> actually *use* system(). I think the only complete syscall libraries are
> minix and em. (If you look in
> https://github.com/davidgiven/ack/blob/release-5-6/mach/minix/libsys you'll
> see that each symbol is defined twice.) (Also, it took me ages to find the

Of course. I removed this extra redirection level while porting minix
libc for ackpack but this _stuff is intact in Ack-5.5 so it works as
expected by the authors.

> em syscall library because it only exists in K&R C; it's in
> https://github.com/davidgiven/ack/tree/release-5-6/lang/cem/libcc/mon and
> the last change was in 1993. I think the phrase 'creakingly old' applies
> here.)
> 
> This only became apparent with em because ass doesn't work like led and
> tries to resolve all symbols when it links, rather than just the used ones.

Yes happened to notice this while building something to emXX, had to
remove some unused declaration iirc.

Keep going David!

Regards,
Rune

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

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

Re build tools: unfortunately the ACK is a really complex thing to build
with lots of code generation and dependencies between components. The old
build system didn't even try to track any of this stuff and relied on a
hard-coded build order and single-threaded builds; but it was impossibly
slow and impossible to understand, and didn't really achieve correct builds
anyway. It was completely unable to be modified to support parallel builds.
Hence the succession of new build systems.

I'm actually on the verge of giving up on make completely; it's essentially
unable to do correct builds no matter how hard you try (try to build
something which produces multiple output files some time!).

Re mach vs plat: mach contains CPU architectures, plat contains machine
targets. Each plat depends on a single mach, but each mach may be used by
any number of plats. (Although not all the platform-specific stuff has been
moved out of mach yet.)

Re libc problems: I don't know whether this is present in 5.5, but I
wouldn't be surprised if it did. The problem is that the libc depends on
many, many symbols which don't have prototypes by just importing them with
extern. It's particularly keen on calling leading-underscore versions of
system calls, so the implementation of system() actually calls _execl() to
do the work. If the syscall library doesn't implement _execl() and only
implements execl() then everything will appear to work until you try to
actually *use* system(). I think the only complete syscall libraries are
minix and em. (If you look in
https://github.com/davidgiven/ack/blob/release-5-6/mach/minix/libsys you'll
see that each symbol is defined twice.) (Also, it took me ages to find the
em syscall library because it only exists in K&R C; it's in
https://github.com/davidgiven/ack/tree/release-5-6/lang/cem/libcc/mon and
the last change was in 1993. I think the phrase 'creakingly old' applies
here.)

This only became apparent with em because ass doesn't work like led and
tries to resolve all symbols when it links, rather than just the used ones.


On Wed, 20 Jun 2018 at 18:24 <u-...@ae...> wrote:

> Hello David,
>
> On Wed, Jun 20, 2018 at 04:53:26PM +0200, David Given wrote:
> > Very belatedly, I got em binaries working with the 6.0 stream, and
> there's
> > a basic em22 platform. It's all in head of git and it's built
> automatically
> > so you can just check out, build, install, and do:
> >
> > $ /usr/local/lib/ack/int /usr/local/share/ack/examples/mandelbrot_c.em22
>
> Congratulations!
>
> I appreciate your work on Ack and understand that the new build tools
> make your development easier or feasible at all.
>
> Unfortunately, the new Ack-6* build stuff did not really fit in my
> development model. I tried it earlier, before porting ackpack.
>
> One property is that the new build tools are more "complex" than the
> target, they can not be built/maintained without yet other tools, much
> more complicated than ack.
>
> Ack used to be dependent only on the V7-era stuff and I try to keep its
> maintenance in that complexity domain. (According to the commits, up to
> version 4 Ack was apparently small enough to be hosted even on pdp-11.)
>
> The other thing is the semantics of different directories.
> This is not exactly consistent in the original Ack (at least where the
> stuff is being installed, objects of different classes/namespaces are
> often mixed in common directories) but I find it even harder to follow
> in the new one. What is the semantics of "mach" vs "plat"?
>
> > ...and it should work. However, I discovered huge problems with the libc
> in
> > the process and it needs refactoring --- turns out that it largely only
> > works by accident at the moment, so I'm taking some time out to try and
> fix
> > that before adding em24 and em44.
>
> Is it because of some changes in libc or is the problem present in 5.5?
>
> I can confirm that the interpreter indeed needs some fixing.
>
> Tested a program which worked reliably both
>  natively, built with ackpack for linux on ia32, and
>  under apout, when built with ack-5.5 for v7unix on pdp.
>
> It worked on small data also under em22/int but crashed at some point
> given a larger dataset (not affecting the amount of the needed memory
> but among others the number of de/allocations).
>
> Regards,
> Rune
>
>

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

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

Hello David,

On Wed, Jun 20, 2018 at 04:53:26PM +0200, David Given wrote:
> Very belatedly, I got em binaries working with the 6.0 stream, and there's
> a basic em22 platform. It's all in head of git and it's built automatically
> so you can just check out, build, install, and do:
> 
> $ /usr/local/lib/ack/int /usr/local/share/ack/examples/mandelbrot_c.em22

Congratulations!

I appreciate your work on Ack and understand that the new build tools
make your development easier or feasible at all.

Unfortunately, the new Ack-6* build stuff did not really fit in my
development model. I tried it earlier, before porting ackpack.

One property is that the new build tools are more "complex" than the
target, they can not be built/maintained without yet other tools, much
more complicated than ack.

Ack used to be dependent only on the V7-era stuff and I try to keep its
maintenance in that complexity domain. (According to the commits, up to
version 4 Ack was apparently small enough to be hosted even on pdp-11.)

The other thing is the semantics of different directories.
This is not exactly consistent in the original Ack (at least where the
stuff is being installed, objects of different classes/namespaces are
often mixed in common directories) but I find it even harder to follow
in the new one. What is the semantics of "mach" vs "plat"?

> ...and it should work. However, I discovered huge problems with the libc in
> the process and it needs refactoring --- turns out that it largely only
> works by accident at the moment, so I'm taking some time out to try and fix
> that before adding em24 and em44.

Is it because of some changes in libc or is the problem present in 5.5?

I can confirm that the interpreter indeed needs some fixing.

Tested a program which worked reliably both
 natively, built with ackpack for linux on ia32, and
 under apout, when built with ack-5.5 for v7unix on pdp.

It worked on small data also under em22/int but crashed at some point
given a larger dataset (not affecting the amount of the needed memory
but among others the number of de/allocations).

Regards,
Rune

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

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

Very belatedly, I got em binaries working with the 6.0 stream, and there's
a basic em22 platform. It's all in head of git and it's built automatically
so you can just check out, build, install, and do:

$ /usr/local/lib/ack/int /usr/local/share/ack/examples/mandelbrot_c.em22

...and it should work. However, I discovered huge problems with the libc in
the process and it needs refactoring --- turns out that it largely only
works by accident at the moment, so I'm taking some time out to try and fix
that before adding em24 and em44.

On Wed, 20 Jun 2018 at 15:05 <u-...@ae...> wrote:

> Hello,
>
> For information:
>
> Thanks to the ackpack + libc port from Minix to Linux I was able to build
> under Linux-ia32 the historical tools expected by Ack-5.5 and then build
> Ack-5.5 for all of its supported targets.
>
> Smoke tested em22, em24, em44 and also pdp with apout, all seem to work.
>
> (the em interpreter needed a float to unsigned conversion fix, which
> Ceriel apparently also fixed 7 years ago but I found his version only
> after the fact)
>
> Regards,
> Rune
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

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

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

Hello,

For information:

Thanks to the ackpack + libc port from Minix to Linux I was able to build
under Linux-ia32 the historical tools expected by Ack-5.5 and then build
Ack-5.5 for all of its supported targets.

Smoke tested em22, em24, em44 and also pdp with apout, all seem to work.

(the em interpreter needed a float to unsigned conversion fix, which
Ceriel apparently also fixed 7 years ago but I found his version only
after the fact)

Regards,
Rune

Re: [Tack-devel] Questions on current state of ACK

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

On 2018-06-02 17:11, David Given wrote:
> Re ABI limitations:
>
> Yes, what you've said is true --- em can only handle the em ABI, which 
> passes all parameters on the stack. So it can't call procedures 
> compiled with other compilers, which pass them in registers. It'd be 
> quite possible to extend the spec, but actually /implementing/ the 
> change would be very hard as everything would need to be changed at 
> once: all the compilers would need to generate register-calls, all the 
> hand-written machine code libraries would need to use the new 
> specification, etc. I can't realistically see it happen.

Thanks for your quick answer, actually i was more wondering if it was 
possible to add more type information in the EM format, all the while 
adapting a bit the backend to simply ignore this type information, so 
that each backend is free to implement or not... Sorry, I did not dive 
in the code yet to see if this was feasible technically. The objective 
is that to permit this feature optionally for each backend by having the 
type information to make linking with ABI compliant object files simply 
easier...

> Re em tools:
>
> You not entirely sure what you mean here. The ACK contains an 
> assembler, archiver and linker which work on native object files; 
> ack.out. These work fine. But there are /also/ tools which operate on 
> em bytecode (e.out) files, which include the interpreter, em_encode 
> (the assembler) and em_decode (the disassembler). The linker for em 
> bytecode is em_ass, in util/ass, and until I went looking just now I 
> honestly didn't know there was one. The em /interpreter/ exists but is 
> not built and nobody's touched it for years.
>
> Essentially, for as long as I've been involved the focus has been on 
> native code generation, rather than the interpreter. There's no reason 
> why it couldn't be made to work and all the pieces are still there, 
> but it /hasn't/ been made to work. Interpreted em bytecode is 
> essentially a whole new target.
>
You understood correctly, i was more interested in the em_encode, 
em_decode, linker and the interpreter... Thanks for pointing me to the 
code, i will look into it, i am interested to make these work on my side 
:) I do think that EM, even though stack based, can be quite more 
powerful than LLVM IR, as it seems, at least from the documentation 
perspective more portable ...

> Re debugging information:
>
> ack.out files can contain a symbol table; the generated code can be 
> annotated with source line information; that's about as far is it 
> goes. There's a debugger, grind, which nobody's got working; it's 
> pretty antiquated, and works by running the process-under-test as a 
> child and communicates with it via pipes, so it needs client code 
> running in the process-under-test, and I don't believe any of the 
> current targets have this.
Do you know if the e.out files have debug information? I guess it must 
be at the same level, right?

> Re building on Windows:
>
> It doesn't build on Cygwin, but nobody's gone and looked why (it's 
> probably due to the case-sensitive filesystem). There's currently an 
> issue where the recent ed release broke the ACK build --- that's 
> probably going to be a tough fix because it seems all the ACK's ed 
> scripts are illegal, and they'll need to be replaced entirely. And 
> while it's /technically/ true that the ACK builds with GNU Make I 
> wouldn't recommend it; it's too complicated for GNU Make and the 
> builds sometimes don't work properly. I'd recommend ninja instead.
>
I understand this point, but i have sometimes crazy ideas, such as 
making some of the ACK tools work on weird platforms, and for that I 
need to restrict myself to POSIX tools as well as basic GNU tools :)

Thanks for all your help!
Carl Eric Codere

Re: [Tack-devel] Questions on current state of ACK

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

Re ABI limitations:

Yes, what you've said is true --- em can only handle the em ABI, which
passes all parameters on the stack. So it can't call procedures compiled
with other compilers, which pass them in registers. It'd be quite possible
to extend the spec, but actually *implementing* the change would be very
hard as everything would need to be changed at once: all the compilers
would need to generate register-calls, all the hand-written machine code
libraries would need to use the new specification, etc. I can't
realistically see it happen.

Re em tools:

You not entirely sure what you mean here. The ACK contains an assembler,
archiver and linker which work on native object files; ack.out. These work
fine. But there are *also* tools which operate on em bytecode (e.out)
files, which include the interpreter, em_encode (the assembler) and
em_decode (the disassembler). The linker for em bytecode is em_ass, in
util/ass, and until I went looking just now I honestly didn't know there
was one. The em *interpreter* exists but is not built and nobody's touched
it for years.

Essentially, for as long as I've been involved the focus has been on native
code generation, rather than the interpreter. There's no reason why it
couldn't be made to work and all the pieces are still there, but it
*hasn't* been
made to work. Interpreted em bytecode is essentially a whole new target.

Re debugging information:

ack.out files can contain a symbol table; the generated code can be
annotated with source line information; that's about as far is it goes.
There's a debugger, grind, which nobody's got working; it's pretty
antiquated, and works by running the process-under-test as a child and
communicates with it via pipes, so it needs client code running in the
process-under-test, and I don't believe any of the current targets have
this.

Re building on Windows:

It doesn't build on Cygwin, but nobody's gone and looked why (it's probably
due to the case-sensitive filesystem). There's currently an issue where the
recent ed release broke the ACK build --- that's probably going to be a
tough fix because it seems all the ACK's ed scripts are illegal, and
they'll need to be replaced entirely. And while it's *technically* true
that the ACK builds with GNU Make I wouldn't recommend it; it's too
complicated for GNU Make and the builds sometimes don't work properly. I'd
recommend ninja instead.



On Sat, 2 Jun 2018 at 14:54 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                   I have been looking at this project for a quite and i do
> feel its interesting... my dream as always been to make portable code for
> my software... and ack can i think permit this. i am also a person that
> likes bavkward compatibility :) i have mostly read the whitepapers of
> version 5.5.
>
> I do have technical questions first though, quite technical in nature
> though:
>
> * reading the documentation it seems there is an issue with the em format
> where it does not contain information on procedure parameters sizes and
> types thus it is not possible to be compatible with the different abi's? am
> i right? or had this fixed? even though n do you feel it would be possible
> to adapt the em format to have this information in a backward compatible
> format?
> * what is the current state of the em assembler?
> * what is the current state of the em interpreter?
> * what is the current state of the em ar and em linket tool?
> * does em support debug information in its native format?
>
> an important point though for me its important that the ack tool can be
> compiled on different systems with gnu make and a standard c compiler..
> including windows. i understand that this is currently not possible?
>
> i am currently working onanother big project but i would be intersted in
> helping out especially on the em part above... later tjis year.
>
> thanks
> Carl Eric Codere
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>

[Tack-devel] Questions on current state of ACK

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

Greetings,
                  I have been looking at this project for a quite and i do feel its interesting... my dream as always been to make portable code for my software... and ack can i think permit this. i am also a person that likes bavkward compatibility :) i have mostly read the whitepapers of version 5.5.

I do have technical questions first though, quite technical in nature though:

* reading the documentation it seems there is an issue with the em format where it does not contain information on procedure parameters sizes and types thus it is not possible to be compatible with the different abi's? am i right? or had this fixed? even though n do you feel it would be possible to adapt the em format to have this information in a backward compatible format?
* what is the current state of the em assembler?
* what is the current state of the em interpreter?
* what is the current state of the em ar and em linket tool?
* does em support debug information in its native format?

an important point though for me its important that the ack tool can be compiled on different systems with gnu make and a standard c compiler.. including windows. i understand that this is currently not possible?

i am currently working onanother big project but i would be intersted in helping out especially on the em part above... later tjis year.

thanks
Carl Eric Codere

[Tack-devel] Raw Intel 8080 and Motorola 6800 binaries from C?

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

Is it possible to use the ACK cross compiler to generate raw Intel 8080/8085 binaries from C? and raw Motorola 6800 binaries from C?

Just a binary starting at a chosen address with no lib support.


This would make it possible to provide some support for other 8080-based systems (such as the Olivetti M 10).


I have read that ACK can generate CP/M Intel 8080 .COM executable files. I hope it is possible to get just plain binaries.


I have read that there is some support for the Motorola 6800 but I cannot see any option for it.


   Fabrizio

[Tack-devel] It's Here! Today's Supply Leaders Academy Daily ...According to Industry Week: Blockchain: The 2018 Disruptor of the Year

[Randy - S. L. A. <ra...@cp...>]

Your email client cannot read this email.
To view it online, please go here:
http://jqsmail.com/display.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&S=171&L=27&N=150



Friend, It's Here! Today's Supply Leaders Academy Daily ...According to
Industry Week: Blockchain: The 2018 Disruptor of the Year

Click below to learn more...

Don't keep this a secret!

Forward to your team and vendors
tell them to Click here to see the today's news
at Supply Leaders Academy Daily


Learn the 7 secrets of RFP systems that transform buyers into profit
drivers and value focused advisors for strategic sourcing in your supply
chain.

•	How systems make RFPs easier for your entire organization to adopt
strategic sourcing
•	What to look for in RFP software so you're not overwhelmed with useless
features that cause confusion
•	Why cloud technologies are a must for completing more RFPs in less time

Click here to watch webinar


Develop Your Skills and Save More Money
The Cheat Sheets

Supply Leaders Academy Cheat Sheets gives you the strategies and tactics to
improve your skills, get the job done faster, and easily save more money.
Click to download.

Achieve Supply Chain Mastery in 12 Weeks

Move from the back-room to the
boardroom when you complete
our on-line training
click here to learn more...

Available 24/7 anywhere in the world



To stop receiving these
emails:http://jqsmail.com/unsubscribe.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&L=27&N=171
Supply Leaders Academy |  877-680-0494 |
http://jqsmail.com/link.php?M=470513&N=171&L=5&F=T | 444 Point Lobos Drive
| Satellite Beach FL 32937 | USA

[Tack-devel] , Let's show you a RFP system that works for...

[Randy - S. L. A. <ra...@cp...>]

Your email client cannot read this email.
To view it online, please go here:
http://jqsmail.com/display.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&S=170&L=27&N=149


, let's show you a RFP system that works for...

Hey ,

Let's show you a RFP system that
works for any size organization.

Click here to set up a 20 minute appointment where I
review your RFP process to show you how to
make more profits with less effort.

You got inside information about RFP systems
during the webinar where you learned how
RFPs can generate big profits from cost savings.

We had such a great response from people, we wanted to offer you a
free review of your RFP process and strategy to learn how we can help.

If you didn't watch the webinar, no worries,
click here to watch the replay of
Secrets To Getting Higher Profits and
More Value With RFP Systems:

See you there,
Randy

To stop receiving these
emails:http://jqsmail.com/unsubscribe.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&L=27&N=170
Supply Leaders Academy |  877-680-0494 |
http://jqsmail.com/link.php?M=470513&N=170&L=5&F=T | 444 Point Lobos Drive
| Satellite Beach FL 32937 | USA

[Tack-devel] , Did you miss it?

[Randy - S. L. A. <ra...@cp...>]

Your email client cannot read this email.
To view it online, please go here:
http://jqsmail.com/display.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&S=168&L=27&N=147


Did you miss it, ?

Hey ,

Did you miss the special training yesterday?

We had a great webinar where you got inside information about RFP systems
from my special guest, so if you didn't have time to make the webinar, no
worries.

Click below to watch the replay of Secrets To Getting Higher Profits and
More Value With RFP Systems:

http://jqsmail.com/link.php?M=470513&N=168&L=106&F=T

See you there,
Randy

To stop receiving these
emails:http://jqsmail.com/unsubscribe.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&L=27&N=168
Supply Leaders Academy |  877-680-0494 |
http://jqsmail.com/link.php?M=470513&N=168&L=5&F=T | 444 Point Lobos Drive
| Satellite Beach FL 32937 | USA

[Tack-devel] , we start at noon...

[Randy - S. L. A. <ra...@cp...>]

Your email client cannot read this email.
To view it online, please go here:
http://jqsmail.com/display.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&S=166&L=27&N=145


Special training on RFP systems that transform procurement

Hey ,

We start at noon EST for this special training where we share inside
information about RFP systems,

so reserve your complimentary seat here to get the

Secrets To Getting Higher Profits and More Value With RFP Systems:
http://jqsmail.com/link.php?M=470513&N=166&L=106&F=T

See you there,
Randy


To stop receiving these
emails:http://jqsmail.com/unsubscribe.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&L=27&N=166
Supply Leaders Academy |  877-680-0494 |
http://jqsmail.com/link.php?M=470513&N=166&L=5&F=T | 444 Point Lobos Drive
| Satellite Beach FL 32937 | USA

[Tack-devel] Don't miss my special training tomorrow,

[Randy - S. L. A. <ra...@cp...>]

Your email client cannot read this email.
To view it online, please go here:
http://jqsmail.com/display.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&S=162&L=27&N=141


Special training on RFP systems that transform procurement

Hey ,

I wanted to personally invite you to a special training I’m holding on my
simple system for RFPs. The training is Wednesday at noon EST.

During the training, you will meet a very special guest who has used RFPs
to save 100's of thousands of dollars. You don't want to miss this
opportunity to inside information about RFP systems, so reserve your
complimentary seat here:

http://jqsmail.com/link.php?M=470513&N=162&L=106&F=T

Here’s just a taste of what you’ll learn on this special online
training:
How systems make RFPs easier for your entire organization to adopt
strategic sourcing
What to look for in RFP software so you're not overwhelmed with useless
features that cause confusion
Who must be involved in the RFP process to make sure every RFP results in
best value for every dollar spent
Why cloud technologies are a must for completing more RFPs in less time

Plus tons more...

Here is the link to get registered now:
http://jqsmail.com/link.php?M=470513&N=162&L=106&F=T

See you there,

Randy



To stop receiving these
emails:http://jqsmail.com/unsubscribe.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&L=27&N=162

Supply Leaders Academy |  877-680-0494 |
http://jqsmail.com/link.php?M=470513&N=162&L=5&F=T | 444 Point Lobos Drive
| Satellite Beach FL 32937 | USA

[Tack-devel] It's Here! Today's Supply Leaders Academy Daily ...According to Industry Week: Blockchain: The 2018 Disruptor of the Year

[Randy - S. L. A. <ra...@cp...>]

Your email client cannot read this email.
To view it online, please go here:
http://jqsmail.com/display.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&S=157&L=27&N=135



Friend, It's Here! Today's Supply Leaders Academy Daily ...According to
Industry Week: Blockchain: The 2018 Disruptor of the Year

Click below to learn more...

Don't keep this a secret!

Forward to your team and vendors
tell them to Click here to see the today's news
at Supply Leaders Academy Daily


Learn the 7 secrets of RFP systems that transform buyers into profit
drivers and value focused advisors for strategic sourcing in your supply
chain.

•	How systems make RFPs easier for your entire organization to adopt
strategic sourcing
•	What to look for in RFP software so you're not overwhelmed with useless
features that cause confusion
•	Why cloud technologies are a must for completing more RFPs in less time

Click here to watch webinar


Develop Your Skills and Save More Money
The Cheat Sheets

Supply Leaders Academy Cheat Sheets gives you the strategies and tactics to
improve your skills, get the job done faster, and easily save more money.
Click to download.

Achieve Supply Chain Mastery in 12 Weeks

Move from the back-room to the
boardroom when you complete
our on-line training
click here to learn more...

Available 24/7 anywhere in the world



To stop receiving these
emails:http://jqsmail.com/unsubscribe.php?M=470513&C=8a024daafdb0bd8ea0779dc3a6a0b7c5&L=27&N=157

Supply Leaders Academy |  877-680-0494 |
http://jqsmail.com/link.php?M=470513&N=157&L=5&F=T | 444 Point Lobos Drive
| Satellite Beach FL 32937 | USA

[Tack-devel] random numbers and time zones

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

I write about random numbers in the Amsterdam Compiler Kit, then about
time zones.

ack comes with an example in several languages of the game, "See if
you can guess my number." The Basic version in examples/hilo.bas is
easy, because the computer's number is always zero, so I always guess
0 and win in 1 try.

The code to pick the number is
    1010 Number% = rnd(1) mod 100

ACK's EM-Basic ignores the 1 in rnd(1); Microsoft's QBasic would check
if the 1 is positive. Then, in both EM-Basic and QBasic, RND should
return the next random number as a float from 0.0 to 1.0. The MOD in
`rnd(1) mod 100` is an integer operation, so Basic rounds the float to
an integer 0 or 1. Then the result of 0 mod 100 or 1 mod 100 is 0 or
1. The game should pick 0 or 1.

EM-Basic calls C's rand(), but uses the wrong maximum for rand() on
platforms with 4-byte int. This causes RND to always pick numbers
close to 0. Then the game always rounds the numbers to 0.

There are two random number generators in ack.

C's rand() uses the linear congruential generator
    next = next * 1103515245 + 12345;
rand() discards the lowest 16 bits,
and returns the next 15 bits of that value.

Modula-2's random uses an additive generator
    x[k] = x[k - 55] + x[k - 24]
but x is a ring buffer of the last 55 values.

Both are from the 1980s. I might try to replace them with a more
recent generator.

Two recent algorithms are
xoroshiro128+ from http://xoroshiro.di.unimi.it/
PCG from http://www.pcg-random.org/

I didn't like xoroshiro128+ because it uses 64-bit integers, and ack
lacks 64-bit operations. It only uses bit operations (xor, shift,
rotate) and one can easily split them into 32-bit operations, but I
didn't want to try.

I didn't like PCG because it uses multiplication, which is slow in
processors without a multiply instruction, like the i80.

I am now looking at
sfc32 from http://pracrand.sourceforge.net/

sfc32 uses 32-bit integers with bit operations and addition. Modula-2
seems to have no bit operations on integers (both shifts and bitwise
logic), but I might write the code in EM. sfc32 has a rotate (barrel
shift) and EM code can rotate with ROL or ROR. C code would split the
rotate into shifts and bit-or, and ack can't optimize it to ROL or
ROR. Back end for PowerPC can't compile ROL or ROR, but I might teach
it.

QBasic by tradition uses
    randomize timer
to seed the generator.

EM-Basic has randomize but is missing timer, to return a float
counting seconds since midnight. One would need to know the time zone
to calculate midnight. That's a problem because ack's libc can't find
the time zone. It wants to call ftime() to get the time zone from the
kernel, but that technique is obsolete. If I try to call ctime(), the
compile fails as the linker can't find ftime().

The modern way is to open /etc/localtime and read tzfile(5) for time
zone, but ack's libc hasn't learned to do that. Also, libc has an
outdated default rule for summer time. It doesn't know that the
European Union changed the rule in 1996.

--George Koehler

Re: [Tack-devel] a testcase which does not pass in my ack

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

On 27/04/17 14:51, u-...@ae... wrote:
[...]
> push ebp
> mov ebp,esp
> push esi
> mov esi,1234
> push 1
> call _xx
> pop ecx
> pop ecx
> pop esi
> leave
> ret
[...]
> It is "... ! <var>, <var> ..." being passed as arguments which makes
> the compiler push an insufficient number of items and also generate
> an unsuitable constant there. A presence of an extra argument (not the
> same <var>) _between_ "! <var>" and "<var>" prevents the insanity.

Okay, so I've had a chance to look at this...

(a) it definitely looks like a bug. (I can duplicate it on my modern
ACK, for all architectures, not just i386.)
(b) it looks like a really, really old bug. (I can duplicate this on
Minix 1.7, released 2005.)

This appears to be an optimiser bug. If you compile with -t and compare
the .k file (before optimisation) with the .m file (after optimisation),
you get this:

Before:

loc 1234
stl -2
lol -2
lol -2
loc 0
cmi 2
tne
teq
cal $xx

After:

loc 1234
stl -2
loc 1
cal $xx

The last is definitely wrong.

My feeling is that what's happening here is something terrible is
happening in the constant propagation code. But it obviously can't be
happening very *often*, because otherwise someone would have noticed in
the past decade or so...

I've had a quick look through the optimiser patterns in
util/opt/patterns, but don't see anything immediately obvious. It'll
need more investigation.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true." --- Master Li Kao,
│ _The Bridge of Birds_

[Tack-devel] a testcase which does not pass in my ack

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

Hello,

I am running natively on i386 Linux ackpack ported from Minix-2,
which is more or less identical to the i386 part of the "original" ack.

Now I noticed a case of odd behaviour:

$ cat >test.c <<////
void xx(int, int);

void a(void) {
  int i = 1234;
  xx(! i, i);
}
////
$ cc -S test.c
$ cat test.s
.sect .text; .sect .rom; .sect .data; .sect .bss
.extern _a
.sect .text
_a:
push ebp
mov ebp,esp
push esi
mov esi,1234
push 1
call _xx
pop ecx
pop ecx
pop esi
leave
ret
$

It is "... ! <var>, <var> ..." being passed as arguments which makes
the compiler push an insufficient number of items and also generate
an unsuitable constant there. A presence of an extra argument (not the
same <var>) _between_ "! <var>" and "<var>" prevents the insanity.

David, I am curious what your ack does when presented with such input?
Do you possibly have a clue of how to fix the problem?

Regards,
Rune

[Tack-devel] You are one of the few who gets in on this!

[Swiss M. <in...@ch...>]

 

You are receiving this email from Swiss Millionaire because you signed
up to be on our list.
 If you wish not to receive further emails, please unsubscribe below. 

Read in browser
http://secure.luxusarctica.com/index.php/campaigns/tz330oqvyt1da/track-url/yv169l9bqnb36/18a32c14c574366e63d2e76c398c809d7192a9bf


YOU DON'T WANT TO MISS THIS OPPORTUNITY 

This new guaranteed money system is going to go fast, so I'll get
straight to the point. It’s BRAND NEW, just about the most simple
system created and brings in over $7,180 per day! Finally the payday
you and all of us deserve! 

So check this out: A video just released to youtube that you're going
to want to see. Here's the link: 

 		CHECK IT OUT
http://secure.luxusarctica.com/index.php/campaigns/tz330oqvyt1da/track-url/yv169l9bqnb36/7d97cac745295ac2019703749e851ffa75d09b0d

This method, called the "Swiss Millionaire System" doesn't require you
to start with: Money - Hard work - Business Experience - Any
particular skills. 

And what's so incredibly wonderful about Swiss Millionaire System is
that you only have to be active for 5 minutes a day; it can run pretty
much entirely on auto pilot with GUARANTEED profits. 

We must be insane - we'll be sharing with you exactly how you can make
over $230,000 per month using this exact method. Check out the video
now before we change our minds! 

This strategy proved to be an overnight success for us and we're sure
it will be for you too! Watch the video now before the server gets
bogged down with others wanting in! 

Don’t miss out there are only a few spots left. Do you really want
to miss out on profiting over $7,180 per day? If you leave now,
you’ll regret it when you come back to try this out and you see the
page cannot be found. 

It’s FREE today. 

 		GET YOUR FREE ACCESS TODAY!
http://secure.luxusarctica.com/index.php/campaigns/tz330oqvyt1da/track-url/yv169l9bqnb36/7d97cac745295ac2019703749e851ffa75d09b0d

Copyright © 2017 Swiss Millionaire, All rights reserved 
Unsubscribe
http://secure.luxusarctica.com/index.php/campaigns/tz330oqvyt1da/track-url/yv169l9bqnb36/ab97c18f540bb64fd84e7d66f824557691f7c778


 

[Tack-devel] incomplete changes to PowerPC ncg, ego

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

My branch https://github.com/kernigh/ack/tree/kernigh-linuxppc has
some incomplete changes to PowerPC ncg and ego. No pull request,
because my branch has at least one problem with 4-byte floats. I will
not be active for the next several days, so my branch will remain as
is.

We have two PowerPC back ends, ncg and mcg. The new code generator
(ncg) is really the old one. PowerPC ncg existed by 2007, got some
important fixes in September 2016, and can now compile some but not
all C and Modula-2 programs. David Given's modern code generator (mcg)
existed by October 2016, and can now compile most programs, but often
emits wrong code. When I last checked, printf() in C worked in ncg but
not in mcg.

In my branch, I tried to complete the old back end, PowerPC ncg. I
added the missing conversions between integers and 4-byte floats. I
implemented the EM instruction lxl, for nested procedures in Modula-2.
I also made some changes to register allocation.

Since 2007, PowerPC ncg had defined an individual register class for
each of the 32 general-purpose and 32 floating-point registers. These
64 classes had names like GPR3, FPR3, GPR4, FPR4, and so on. The table
used these classes to coerce values from the EM stack into specific
registers. For example, the rule for EM instruction aar coerced 3
values into GPR3, GPR4, GPR5.

But ncg's register allocator is too slow with so many classes. A rule
using 3 GPRs would take about 2 seconds to allocate them. So in
October 2016, I added REG_PAIR to speed up some rules. REG_PAIR meant
to allocate a pair of GPRs from a list of only 4 pairs.

In http://tack.sourceforge.net/olddocs.html, I found warnings against
too many register classes. Frank Doodeman's m68020 paper said,

> Since Hans van Staveren in his document [4] clearly states that *cg* execution time is negatively influenced by the number of properties, only four different properties have been defined.

van Staveren's ncg paper said,

> Every extra property means the register set is more unorthogonal and *cg* execution time is influenced by that, because it has to take into account a larger set of registers that are not equivalent. So try to keep the number of different register classes to a minimum. When faced with the choice between two possible code rules for a nonfrequent EM sequence, one being elegant but requiring an extra property, and the other less elegant, elegance should probably loose.

In my branch, I removed 63 of the 64 individual register classes. (I
left a singleton class for register r3.) I also removed REG_PAIR.
Register allocation becomes much faster, because each allocation picks
from only 1 or 2 classes. Compilation with ack -O1 is quick;
compilation with ack -O2 or higher uses most time to run ego, the EM
global optimizer.

To remove the register classes, I changed libem. When rules in ncg
call libem, they can no longer coerce stack values to registers
(except r3). So I changed libem to pass most values on the real stack,
not in registers. This is slower. (Regular calls to C functions or
Modula-2 procedures continue to use the real stack, and are as slow as
always.) Because of these libem changes, I needed to delete all my
PowerPC .o files.

My branch also made changes to register variables. These use a second
method of register allocation, where the registers get preserved
across function calls. The method, in ncg, simply maps EM local
variables into registers. There is an RA phase in ego that rearranges
the local variables so ncg can emit better code.

In the default branch, PowerPC ncg has regvars only for integers, not
for floats. We run the RA phase in ego. Platform osxppc runs ego with
the descr file, but platform linuxppc runs ego without a descr. (When
I wrote powerpc.descr, I enabled it for osxppc but forgot to enable it
for other platforms.)

I find that it harms code generation to run the RA phase without a
descr file. Each EM local variable has a register score. Before ego
runs, this score is about the number of times that the var appears in
the code. If the score is bigger than about 3, then ncg would try to
allocate a regvar. If ego runs the RA phase, it changes each score to
0 or 10000. The number of registers with score 10000 is never greater
than the number of registers in the descr file. But if there's no
descr, the phase changes all the scores to zero. When linuxppc runs
ego without a descr, if we run the RA phase, we disable regvars in
ncg. So we can emit better code for linuxppc by running ack -O1 or
-O2, because -O3 enables the RA phase.

In my branch, I tried to add floating-point regvars to PowerPC ncg.
But in ncg, all float regvars must have the same size. I added only
8-byte float regvars, because 8-byte floats seem more common then
4-byte floats. I added the float regvars to ego's descr. But the RA
phase assumed that all float regvars hold 4-byte floats. It changed
all the scores for 8-byte floats to zero, so ncg never allocated the
float regvars! I then changed ego to put both 4-byte floats and 8-byte
floats in registers.

My branch has a problem. When the RA phase puts a local in a register,
it also frees the stack space for the local. So the RA phase can put a
4-byte float in a register and free its stack space. Then PowerPC ncg
refuses to put the 4-byte float in a register (because it only has
8-byte float regvars), and ncg tries to use the stack space that ego
freed. This doesn't work, so I am observing corruption of 4-byte
floats in programs. I have not fixed this problem.

My branch https://github.com/kernigh/ack/tree/kernigh-linuxppc will
remain as is (with the 4-byte float problem) for at least the next
several days, while I am not active.

-George Koehler

Re: [Tack-devel] change in RELOPPC with hi16, ha16, lo16

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

After I sent the last mail about the RELOPPC change, I decided to
throw it away and do it differently.

I did rewind my branch
  https://github.com/kernigh/ack/tree/kernigh-linuxppc
to before the RELOPPC change. I then added a new relocation type
RELOLIS. I transplanted my ncg changes from the old branch to the new
branch.

The old branch is now
  https://github.com/kernigh/ack/tree/zzz-old-reloppc

RELOLIS handles a single instruction, a PowerPC lis using ha16 or hi16:

  lis RT, ha16[expr] == addis RT, r0, ha16[expr]
  lis RT, hi16[expr] == addis RT, r0, hi16[expr]

The relocated expr is a symbol plus a signed 26-bit offset. The trick
is how RELOLIS stores the offset in the program text. The lis
instruction takes 32 bits. There are 6 bits for the addis opcode, 5
bits for register RT, 5 bits for register r0, and 16 bits for the
immediate value. RELOLIS is only for lis instructions, so it doesn't
need to store the addis opcode or register r0. This frees 11 bits.

I need 5 bits to store register RT, but I have 27 other bits. I use 1
bit as a flag, set for ha16, clear for hi16. The other 26 bits are the
offset. RELOLIS stores the value with the flag in the high bit, the
register RT in the next 5 bits, and the offset in the low 26 bits.

During relocation, the linker does symbol plus offset. The high 16
bits of the sum become the immediate value of the lis. If the ha16
flag is set, the linker does the sign adjustment. Then the linker
assembles the lis instruction, filling in the addis opcode and the
register r0.

RELOLIS is simple because it handles a single ha16 or hi16
instruction. It doesn't need to find a second instruction with a
matching lo16.

-George Koehler

[Tack-devel] change in RELOPPC with hi16, ha16, lo16

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

This mail describes a change in my branch
https://github.com/kernigh/ack/tree/kernigh-linuxppc

It isn't ready for a pull request. In my branch, ncg can generate code like

    lis r12,ha16[__II0]
    lis r11,ha16[_f]
    lfs f1,lo16[_f](r11)
    lfs f2,lo16[__II0](r12)
    fadds f13,f2,f1
    stfs f13,lo16[_f](r11)

Here ncg has allocated r11 for ha16[_f] and used r11 in both lfs and
stfs. I changed the assembler and linker to accept this code.

Before my changes, each ha16[_f] needs a matching lo16[_f] in the next
instruction, and each lo16[_f] needs a previous ha16[_f]. After my
changes, each ha16[_f] needs a matching lo16[_f] in the next 1 to 63
instructions, and lo16[_f] doesn't need ha16[_f]. A lonely lo16 gets a
simple RELO2 relocation.

I change the format of a RELOPPC relocation. Before my change, RELOPPC
has a 32-bit offset. After my change, it has a signed 26-bit offset. I
use the high 6 bits to encode the distance from the ha16 (or hi16)
instruction to the matching lo16 instruction.

Each ack.out relocation has a symbol + offset, and stores the offset
inside the instructions. This is why RELOPPC must pair ha16 with lo16.
Each instruction has room for only 16 bits of an offset, so RELOPPC
pairs 2 instructions to get 32 bits.

The above code has a gap of distance 3 from ha16[__II0] to
lo16[__II0]. The gap exists because ncg emits the lis as soon as it
allocates the register.

When ncg loads a 4-byte value, I don't know whether to emit lwz (to a
general-purpose register) or lfs (to a floating-point register). So, I
yield a token. Later, ncg coerces the token to a register. This
coercion emits lwz or lfs. A coercion in ncg may not allocate more
than one register. The coercion that emits lfs f2,lo16[__II0](r12) may
allocate f2, but not r12. So I allocate r12 earlier, in pat lae. So
ncg emits lis r12,ha16[__II0] early.

I changed the format of RELOPPC to allow the gap between the lis from
the early allocation, and the lwz or lfs from the coercion.

There is a disadvantage. The assembler fails if the offset is too big
for signed 26-bit. This can happen if a module has more than 32 MB of
data in a section. The program would use ha16 and lo16 to reference
this data. The relocation would be offset from the beginning of the
section. An offset of at least 32 MB would fail.

Before my change, RELOPPC uses a signed 26-bit offset for branches. My
change is to also use a signed 26-bit offset for ha16 and hi16.

-George Koehler