Re: [Tack-devel] Update on porting effort

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

Being able to build the ACK on small systems is definitely valuable, and we
should keep it. That said, the current configuration can't do it and people
aren't currently building it for these platforms. (Apart from anything else
everything's built with the BigPars settings. See
https://github.com/davidgiven/ack/blob/default/lang/cem/cemcom.ansi/BigPars vs
SmallPars.) I'm quite sure that mcg won't work on these systems.

That said, I'm not sure that using a custom system library's the right way
to do this. These days C is much more standard than it was back then and
the need for custom wrappers to make sure that, e.g., realloc with NULL
works properly isn't necessary. A lot of the stuff in system is equivalent
to the standard Posix calls, or is unused completely (sys_lock --- in fact,
I see that function's not even built!).

What I'd propose as a compromise is:

- if a system function is a trivial reimplementation of Posix, replace it
with the Posix version.
- *do* replace File* with FILE*. If it turns out to be too expensive later,
we can replace the buffered stdio with an unbuffered implementation
equivalent to the one in system, but using the standard interfaces.
- *don't* start calling printf() where we don't need it. One of the things
on the to-do list is to make printf cheaper, somehow (I have a few ideas),
but let's not tempt fate.

This way we should end up with standard interfaces, which makes things
easier to work on and maintain, but still allow the small systems.

PS. I use cscope to search for symbols in the ACK tree. It's great. Do
'cscope -Rq' and then enter a function name in the box.

On Fri, 15 Feb 2019 at 07:49 Carl Eric Codere via Tack-devel <
tac...@li...> wrote:

> Greetings,
>                  Thank you for the clarifications, it makes me understand
> the initial objectives.
>
> I guess its a question for the current maintainers now:
>
> In that case, I propose to keep system, and maybe at least in the current
> version have system use stdio as it is already doing now, clean it up a
> bit, expand it as necessary, and then when we need to support compiling on
> low end machines we just need to adapt system and not everything?
>
> Is it also in the long term objectives of ACK development to run the
> compiler on older systems that are maybe within a minimal threshold? Not
> only as targets, but also as hosts? I would nice, no, not sure it its
> possible though?
>
> Thanks again,
> Carl
>
>
> On Thursday, February 14, 2019, 4:15:28 p.m. GMT+8, Jacobs, C.J.H. <
> c.j...@vu...> wrote:
>
>
> Hi,
>
> back when we developed ACK, we were worried about code size (in
> particular, the resulting size of binaries).
> We needed to have versions of the compiler running in 16-bit address space
> (OK, we had separate instruction and data spaces),
> but that meant that the compiler binary code had to fit in 64K, on systems
> that did not support shared libraries and such.
> Using stdio would make that virtually impossible, because even back then,
> that would add 8-16K to the binary size (I don’t
> remember exactly, but it was a lot). This is the reason that the ACK
> compiler front-ends don’t use printf, sprintf, FILE, etc.,
> or anything that internally uses those.
>
> Best wishes,
>
> Ceriel Jacobs
>
> > On 13 Feb 2019, at 16:25, Carl Eric Codere via Tack-devel <
> tac...@li...> wrote:
> >
> > Greetings,
> > ����������������� I am trying to be
> careful on the ansification process so i don't break anything, so I am
> carefully reviewing my changes before doing a commit in my branch, I have
> some questions, because i am probably missing some understanding.
> >
> > * Why is the alloc library relying on the system library in NoMem(void)
> ? Can we simply not call fprintf(stderr.. ) and exit(EXIT_FAILURE) instead?
> It would make it more portable and less interdependent of other libraries,
> no?
> > * Why is the print library relying on the system library for its I/O,
> same question as before, we could just replace File* by standard FILE* ?
> >
> > The only reasons i could foresee are
> > *� that this was done before ISO C90 and was not portable at the time?
> > *� when printing you may want to actually write somewhere else by
> implementing your own sys_xxx function.
> > *� any others?
> >
> > What is the objective of the system library?
> > I thought it would contain API calls that are not fully portable, for
> example POSIX API's that we should "emulate" for each platform, or ISO C
> routines that must be overriden because of broken implementations in some
> libraries (tmpfile() and tmpnam() in Visual C++ come to mind)? other
> examples:
> > * get file modification time.
> > * create temp file
> > But I see sys_write and sys_open ... I am ok to keep them, but it should
> not be a FILE* instead?
> > Should it also not also add some common API's gettmpdir() that could are
> used in different utilities, maybe instead it needs to be reimplemented?
> >
> > Sorry for all those questions, but it is very difficult for me to
> understand the spirit of the above...
> >
> > Thanks in advance,
> > Carl
> >
> >
> >
> >
> >
> >
> >
> >
> > On 2019-02-08 00:57, Carl Eric Codere via Tack-devel wrote:
> >> 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
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Tack-devel mailing list
> >>
> >> Tac...@li...
> >> https://lists.sourceforge.net/lists/listinfo/tack-devel
>
> >
> > _______________________________________________
> > Tack-devel mailing list
> > Tac...@li...
> > https://lists.sourceforge.net/lists/listinfo/tack-devel
>
> _______________________________________________
> Tack-devel mailing list
> Tac...@li...
> https://lists.sourceforge.net/lists/listinfo/tack-devel
>