Loading ...
Sorry, an error occurred while loading the content.
 

Re: [jallist] Re: Jal for old dos laptop ??

Expand Messages
  • Rob Hamerling
    Hi Kyle, ... I compiled the source with Open Watcom C/C++ with 16-bits DOS as target. ... Without even trying to understand the code this seems to me a case
    Message 1 of 20 , Jul 1, 2011
      Hi Kyle,

      On 06/30/11 07:52 pm, zz wrote:

      > Curious where you perceive 16-bit unsigned as a problem. I tried very
      > hard to avoid this.

      I compiled the source with Open Watcom C/C++ with 16-bits DOS as target.
      This gave me some warnings, like:

      > Compiling pic_inst
      > pic_inst.c(522): Warning! W135: Shift amount too large

      This applies to the last line of:

      > unsigned literal;
      >
      > ...... (some lines removed)
      >
      > switch (pic_code_ofs_get(code)) {
      > case 0: break;
      > case 1: literal >>= 8; break;
      > case 2: literal >>= 16; break;

      Without even trying to understand the code this seems to me a case where
      a 16-bits unsigned integer doesn't give the desired result.

      There were several similar warnings (cod_file 106,107,445,446).

      I assumed that there would be other situations where 16 bits integers
      will not work, even when they don't produce warnings.
      I apologize if I made the wrong assumption.

      BTW I got no other messages (apart from the trivial warning I always see
      and which I have reported to you long ago), apart from:

      > jal_main.c(466): Warning! W131: No prototype found for function 'cos'

      After the compilations the linker reported:

      > Error! E2020: size of group DGROUP exceeds 64k by 2912 bytes

      Maybe there is a solution for this, but because of the issue above I
      didn't care to analyse this problem.

      Regards, Rob.


      --
      R. Hamerling, Netherlands --- http://www.robh.nl
    • zz
      Greetings, ... Yep, good catch. I try to keep the code clean, and apparently fail sometimes :) ... These are invalid -- note in these cases the destination is
      Message 2 of 20 , Jul 1, 2011
        Greetings,

        --- In jallist@yahoogroups.com, Rob Hamerling <robhamerling@...> wrote:
        >
        >
        > Hi Kyle,
        >
        > On 06/30/11 07:52 pm, zz wrote:
        >
        > > Curious where you perceive 16-bit unsigned as a problem. I tried very
        > > hard to avoid this.
        >
        > I compiled the source with Open Watcom C/C++ with 16-bits DOS as target.
        > This gave me some warnings, like:
        >
        > > Compiling pic_inst
        > > pic_inst.c(522): Warning! W135: Shift amount too large
        >
        > This applies to the last line of:
        >
        > > unsigned literal;
        > >
        > > ...... (some lines removed)
        > >
        > > switch (pic_code_ofs_get(code)) {
        > > case 0: break;
        > > case 1: literal >>= 8; break;
        > > case 2: literal >>= 16; break;
        >
        > Without even trying to understand the code this seems to me a case where
        > a 16-bits unsigned integer doesn't give the desired result.

        Yep, good catch. I try to keep the code clean, and apparently fail sometimes :)

        > There were several similar warnings (cod_file 106,107,445,446).

        These are invalid -- note in these cases the destination is unsigned long, and the shift amount has `UL' appended which should promote the entire expression to unsigned long.

        > I assumed that there would be other situations where 16 bits integers
        > will not work, even when they don't produce warnings.
        > I apologize if I made the wrong assumption.

        No apologies necessary. Anything that improves the code is good.

        >
        > BTW I got no other messages (apart from the trivial warning I always see
        > and which I have reported to you long ago), apart from:
        >
        > > jal_main.c(466): Warning! W131: No prototype found for function 'cos'

        Oops. Looks like I don't include math.h when MSDOS is defined.

        > After the compilations the linker reported:
        >
        > > Error! E2020: size of group DGROUP exceeds 64k by 2912 bytes
        >
        > Maybe there is a solution for this, but because of the issue above I
        > didn't care to analyse this problem.

        TurboC defined different memory models depending on the amount of code & data expected. I suspect Watcom does the same. If I recall, the HUGE memory model allowed for both large code & data (over 64K each).

        --kyle
      • zz
        Greetings, I profiled this two ways on a long program (which normally requires 23 seconds). First profile without generating code, which shows only the front
        Message 3 of 20 , Jul 1, 2011
          Greetings,

          I profiled this two ways on a long program (which normally requires 23 seconds). First profile without generating code, which shows only the front end. Second with code generation. Results below.

          --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
          >
          > --- In jallist@yahoogroups.com, "zz" <kyle@> wrote:
          >
          > > Do you really think the legacy swapping code slows the compiler that much? I'll profile it sometime & see. I rarely have compiles that take more than a few seconds so I cannot say I've noticed a problem.
          >
          > I did not profile it either but I still feel that too many levels
          > of inderection are there - sometimes compilations are taking 10-15
          > secs but how much could be saved by "unswaping"?
          >
          > I saw following things I would eliminate (not always for speed):
          >
          > - this obiquitous pf pointer carried everywhere even if there is
          > only one instance exists

          While I see the utility in this, I cannot bring myself to create a global state variable. I'm also not convinced passing a parameter around is taking a substantial amount of time.

          > - swapping (simple define swapper lookup as macro that does nothing)

          You're ignoring the cache code serves another purpose -- it also validates the memory so I can trivially catch things like double free, or using the wrong free on a given element.

          Given that, cache_element_seek takes ~7.5% of the time which can probably be eliminated.

          > - each and every op is at least one level of access function or
          > even inderect call (it's so hard to follow all this).

          This is basic OO programming, and I've never had an issue with it in the past, whereas I've had many issues with direct structure access.

          > - tokenizer is clearly overcomplicated and slow - every time it
          > assembles the current token even if it has been assembled 10
          > times already. It slows down the parser - but I believe parser
          > is not the biggest time consumer.

          I'd say this is backward -- the tokenizer is too simple. It only assembles a given token once, but that token can be checked many times. You are correct however, this doesn't even register in the profiling. pf_token_is_eof() comes in at 0.5%, none of the other token code shows up.

          > But as you said - w/o profiling there is a little reason to
          > do anything and profiling probably would point to the optimizer.

          Top 50% without code generation:

          17% variable_name_get
          14% variable_element_seek
          10% varname_cb
          10% variable_list_find

          Top 50% with code generation:

          16% variable_name_get
          12% variable_element_seek
          10% tag_name_get
          10% variable_list_find
          8% cache_element_seek

          Which leaves the question -- are people finding the compiler to be too slow? Should I work on speeding things up other than the horrible variable allocator?

          --kyle
        • Rob Hamerling
          Hi Kyle, [RobH] ... I forgot to mention that pic_inst.c line 556 has the same issue. I suppose literal and val should be declared as ulong. ... I m not so
          Message 4 of 20 , Jul 1, 2011
            Hi Kyle,

            [RobH]
            >> pic_inst.c(522): Warning! W135: Shift amount too large

            >> Without even trying to understand the code this seems to me a case where
            >> a 16-bits unsigned integer doesn't give the desired result.

            > Yep, good catch. I try to keep the code clean, and apparently
            > fail sometimes :)

            I forgot to mention that pic_inst.c line 556 has the same issue.
            I suppose 'literal' and 'val' should be declared as ulong.


            >>> pic_inst.c(522): Warning! W135: Shift amount too large

            >> There were several similar warnings (cod_file 106,107,445,446).
            >
            > These are invalid -- note in these cases the destination is unsigned
            > long, and the shift amount has `UL' appended which should promote the
            > entire expression to unsigned long.

            I'm not so familiar with promotion rules. It could be an issue with
            Watcom. Personally I would have written these statements like this:

            n |= (ulong)uchar_parse(buf) << 16;
            n |= (ulong)uchar_parse(buf) << 24;

            And indeed, now Watcom doesn't produce warnings.

            >> After the compilations the linker reported:
            >>
            >>> Error! E2020: size of group DGROUP exceeds 64k by 2912 bytes

            >
            > TurboC defined different memory models depending on the amount of
            > code& data expected. I suspect Watcom does the same. If I recall, the
            > HUGE memory model allowed for both large code& data (over 64K each).

            I specified huge memory model. Nevertheless Watcom by default puts all
            data items in a single segment DGROUP, which is a 'near' segment and
            which provides faster access than 'far' segments. But I found a
            parameter to force data items of a certain (specifiable) size (typically
            larger items) to go to far segments, which causes DGROUP to shrink. Now
            the linker produces an executable. But I don't know if it works, I have
            no 286 environment on hand.

            Regards, Rob.


            --
            R. Hamerling, Netherlands --- http://www.robh.nl
          • Rob Hamerling
            Hi Kyle, ... With -no-variable-reuse the compiler is fast enough for me. Regards, Rob. -- R. Hamerling, Netherlands --- http://www.robh.nl
            Message 5 of 20 , Jul 1, 2011
              Hi Kyle,

              On 07/01/11 05:05 pm, zz wrote:

              > -- are people finding the compiler to be
              > too slow? Should I work on speeding things up other than the horrible
              > variable allocator?

              With -no-variable-reuse the compiler is fast enough for me.

              Regards, Rob.

              --
              R. Hamerling, Netherlands --- http://www.robh.nl
            • a_b_aldus
              ... I do not think that speeding up is REQUIRED now - but should look to the arrival of bigger and bigger processors so time would grow significantly (it s not
              Message 6 of 20 , Jul 1, 2011
                > Which leaves the question -- are people finding the compiler to be too slow? Should I work on speeding things up other than the horrible variable allocator?

                I do not think that speeding up is REQUIRED now - but should look
                to the arrival of bigger and bigger processors so time would grow
                significantly (it's not clear yet what would be the grows scale
                for various algorithm you used). May be some haavy time hoggers
                could be optimized or at least planned. There are clearly lot of
                JAL code optimizations that are needed more then compiler code
                optimizations.

                Thanks,
                Arcady
              • a_b_aldus
                BTW yes, when I tried with TurboC I also found all (?) those places and in the example given literal variable is declared unsigned long for me. As for the
                Message 7 of 20 , Jul 1, 2011
                  BTW yes, when I tried with TurboC I also found all (?) those
                  places and in the example given literal variable is declared
                  "unsigned long" for me.

                  As for the data segment overflow - it looks like compiler uses
                  LARGE code model (1mb of code, 1Mb of static data), but have to use HUGE model (1Mb code/data).

                  Arcady

                  --- In jallist@yahoogroups.com, Rob Hamerling <robhamerling@...> wrote:
                  >
                  >
                  > Hi Kyle,
                  >
                  > On 06/30/11 07:52 pm, zz wrote:
                  >
                  > > Curious where you perceive 16-bit unsigned as a problem. I tried very
                  > > hard to avoid this.
                  >
                  > I compiled the source with Open Watcom C/C++ with 16-bits DOS as target.
                  > This gave me some warnings, like:
                  >
                  > > Compiling pic_inst
                  > > pic_inst.c(522): Warning! W135: Shift amount too large
                  >
                  > This applies to the last line of:
                  >
                  > > unsigned literal;
                  > >
                  > > ...... (some lines removed)
                  > >
                  > > switch (pic_code_ofs_get(code)) {
                  > > case 0: break;
                  > > case 1: literal >>= 8; break;
                  > > case 2: literal >>= 16; break;
                  >
                  > Without even trying to understand the code this seems to me a case where
                  > a 16-bits unsigned integer doesn't give the desired result.
                  >
                  > There were several similar warnings (cod_file 106,107,445,446).
                  >
                  > I assumed that there would be other situations where 16 bits integers
                  > will not work, even when they don't produce warnings.
                  > I apologize if I made the wrong assumption.
                  >
                  > BTW I got no other messages (apart from the trivial warning I always see
                  > and which I have reported to you long ago), apart from:
                  >
                  > > jal_main.c(466): Warning! W131: No prototype found for function 'cos'
                  >
                  > After the compilations the linker reported:
                  >
                  > > Error! E2020: size of group DGROUP exceeds 64k by 2912 bytes
                  >
                  > Maybe there is a solution for this, but because of the issue above I
                  > didn't care to analyse this problem.
                  >
                  > Regards, Rob.
                  >
                  >
                  > --
                  > R. Hamerling, Netherlands --- http://www.robh.nl
                  >
                • a_b_aldus
                  ... It wouldn t - not in this case. For short n expression n
                  Message 8 of 20 , Jul 1, 2011
                    --- In jallist@yahoogroups.com, "zz" <kyle@...> wrote:
                    >
                    > > There were several similar warnings (cod_file 106,107,445,446).
                    >
                    > These are invalid -- note in these cases the destination is unsigned long, and the shift amount has `UL' appended which should promote the entire expression to unsigned long.

                    It wouldn't - not in this case. For "short n" expression "n << 2ul"
                    still have type "short". I also saw those strange (for me) uses
                    of shift counters but ignored them (converted back to int).

                    Arcady
                  • Rob Hamerling
                    I m afraid this discusion is not very relevant for Jal users.... ... We have different notions of 16 bits memory models! large is for multiple code and
                    Message 9 of 20 , Jul 2, 2011
                      I'm afraid this discusion is not very relevant for Jal users....

                      On 07/01/11 10:31 pm, a_b_aldus wrote:

                      > As for the data segment overflow - it looks like compiler uses
                      > LARGE code model (1mb of code, 1Mb of static data), but have to use HUGE model (1Mb code/data).

                      We have different notions of 16 bits memory models!
                      'large' is for multiple code and multiple data segments (no 1 MB
                      limits), 'huge' is only needed when a single data item exceeds the size
                      of a segment (64KB).

                      Anyway, even when you specify 'huge' or 'large' (or 'compact') Watcom
                      collects all data items in the DGROUP segment, which is a (the only)
                      'near' segment, unless you request to put data items larger than a
                      certain size into separate ('far') segments. Seems a fair optimisation
                      goal to me.

                      I'm sure I specified 'huge', but it better be 'large', since JalV2
                      doesn't use data times over 64KB. I checked using the 'large' memory
                      model and limiting data items for DGROUP to 128 bytes. I see in the
                      memory map that the DGROUP segment is slightly below 64KB (the segment
                      overflow messages is gone) and there are about 10 'far' data segments
                      varying in size from 176 to 1430 bytes.

                      Although it is possible to build a 16 bits DOS executable the question
                      remains if it will be workable. The executable alone is almost 400 KB!

                      Regards, Rob.

                      --
                      R. Hamerling, Netherlands --- http://www.robh.nl
                    • a_b_aldus
                      ... I believe there is only one authority on the names of the memory models - Borland with TurboC/TurboPascal - everybody else are late-comers, so have no
                      Message 10 of 20 , Jul 2, 2011
                        --- In jallist@yahoogroups.com, Rob Hamerling <robhamerling@...> wrote:
                        > We have different notions of 16 bits memory models!
                        > 'large' is for multiple code and multiple data segments (no 1 MB
                        > limits), 'huge' is only needed when a single data item exceeds the size
                        > of a segment (64KB).

                        I believe there is only one authority on the names of the
                        memory models - Borland with TurboC/TurboPascal - everybody
                        else are late-comers, so have no saying on it :( But it's
                        anyway trial-and-error process - fitting the program into
                        the memory model.

                        > Anyway, even when you specify 'huge' or 'large' (or 'compact') Watcom
                        > collects all data items in the DGROUP segment, which is a (the only)
                        > 'near' segment, unless you request to put data items larger than a
                        > certain size into separate ('far') segments. Seems a fair optimisation
                        > goal to me.

                        DGROUP is not a real segment - as you could see it's a group of
                        segments (DATA and BSS as the rule) used to be able to set ds
                        properly. By "definition" HUGE memory model does not have DGROUP
                        as every memory reference could go to different segment completely.
                        If Watcom invented new notion of HUGE - good for them but strange.

                        > I'm sure I specified 'huge', but it better be 'large', since JalV2
                        > doesn't use data times over 64KB. I checked using the 'large' memory
                        > model and limiting data items for DGROUP to 128 bytes. I see in the
                        > memory map that the DGROUP segment is slightly below 64KB (the segment
                        > overflow messages is gone) and there are about 10 'far' data segments
                        > varying in size from 176 to 1430 bytes.
                        >
                        > Although it is possible to build a 16 bits DOS executable the question
                        > remains if it will be workable. The executable alone is almost 400 KB!

                        JAL is memory hog and for sure nothing reasonable big would work
                        here - swapper should be re-inserted (may be using XMM or EMS or
                        plain disk/ramdisk) but there is no point to do it. This exercise
                        helped to find some suspicious data size places and lets be thankful
                        for this!

                        Thanks for you sharing those details,
                        Arcady
                      Your message has been successfully submitted and would be delivered to recipients shortly.