Author Topic: Update 0.2  (Read 334 times)

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Update 0.2
« on: June 07, 2019, 01:24:52 PM »

 Hello Charles, thanks for the update. I haven't finished testing but test are going well so far.

 One thing i noticed though was that the benchmark times for string comparison and concatenation
went up...

 This engine catched a few errors i had in my code, for example, i had:

Code: [Select]
local g = 0
instead of:

Code: [Select]
long g = 0
 In a couple of the stock functions.

 That is nice. :)

 One comment, this still fails at compilation time:

Code: [Select]
print str(31 / 7 OR 3) chr(13, 10)







Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4097
    • Oxygen Basic
Re: Update 0.2
« Reply #1 on: June 07, 2019, 06:17:19 PM »
Thanks Brian.

O2 doesn't like doing bitwise operations on float expressions. So none of these work:

Code: [Select]
'print str(31 / 7 OR 3) chr(13, 10)
'print 7.0 or 3
'int a= 7.0 or 3
'float a=7.0 or 3

but performing an integer division '\' instead of '/' will make your example work:

Code: [Select]
print str(31 \ 7 OR 3) chr(13, 10)

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #2 on: June 07, 2019, 09:36:59 PM »
  I see. Okay, the error description is not very intuitive but it makes sense.
 I will then re-implement my aproach hoping the new update behaves better
with my code. :)

  I will break statements and pre-compute them manually part by part. This will
make statements mostly unreadable by humans but, this way i can implement my
new feature... custom operators. Hopefully this will not explode in my face. :)


Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #3 on: June 07, 2019, 10:26:33 PM »
 Maybe i found an issue... this outputs 7:

Code: [Select]
print 4 OR 3 CHR(13, 10)
This outputs 4:

Code: [Select]
print floor(31 / 7) CHR(13, 10)
 This complains about the same issue:

Code: [Select]
print str(floor(31 / 7) OR 3) CHR(13, 10)
 I am converting the division to integer prior to using th OR operator in it...
Im not sure where the issue is.

Added:
This works fine though....

Code: [Select]
FUNCTION flooor(double v) as int
    return floor(v)
end function

print (flooor(31 / 7) OR 3) CHR(13, 10)

« Last Edit: June 07, 2019, 10:59:25 PM by Brian Alvarez »

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #4 on: June 07, 2019, 10:44:26 PM »
 Maybe the issue that is sometimes preventing my routines from working properly is related to this?...

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4097
    • Oxygen Basic
Re: Update 0.2
« Reply #5 on: June 08, 2019, 02:40:00 AM »
Division is a processor-intensive successive approximation, so it's best avoided wherever possible. It's similar to doing school detention-time long division. Even CPUs find it hard :)

However, I'm testing a patch to down-convert from float to integer accumulator , before a bitwise operation is attemted. This would apply to NOT AND OR XOR

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #6 on: June 08, 2019, 04:12:56 AM »
Yes, it is Charles, but I have to test and get it to work for those cases where it is indispensable. :)

 I havent seen the code for Oxygen, do you mind if i take a look at the part that works with operators? I am no expert at assembly,
but i know it enough. Does Oxygen compile with Oxygen? If so, maybe i can give you a hand. I rather work on Oxygen than
in that same area of PluriBASIC. In fact, if i finish that part, nothing would stop me from generating executables directly.... except
time maybe.

 Anyway, i would like to add support for EQV, IMP, SHR and SHL, as well as adding a way to create custom operators and make them
work on 64 bit variables.

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4097
    • Oxygen Basic
Re: Update 0.2
« Reply #7 on: June 08, 2019, 06:52:22 AM »
Sure.

Take a look at OXSC\pars.inc  identop()

I'll add SHL SHR ROL ROR equivalent to << >> <<< >>>

Code: [Select]
      wr=tword(s,i) : i=swd+lenw
      if wr="and"
        n=33 : prl=3 : goto idop
      endif
      if wr="or"
        n=34 : prl=1 : goto idop
      endif
      if wr="xor"
        n=35 : prl=2 : goto idop
      endif
      if wr="shl"
        n=74 : prl=5 : goto idop
      endif
      if wr="shr"
        n=75 : prl=5 : goto idop
      endif
      if wr="rol"
        n=76 : prl=5 : goto idop
      endif
      if wr="ror"
        n=77 : prl=5 : goto idop
      endif
    endif
  endif


What are EQV and IMP? I dont think anyone uses them. Best avoided for code clarity.

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4097
    • Oxygen Basic
Re: Update 0.2
« Reply #8 on: June 08, 2019, 08:11:59 AM »
With a few adjustments we can also have pow and mod as operators, as well as functions, without conflicting syntax:

Code: [Select]
    a=asclc(a)
    select a
    case 0x61,0x6d,0x6f,0x70,0x72,0x73,0x78 'a m o p r s x
      i=k
      wr=tword(s,i) : i=swd+lenw
      if (lenw<2)or(lenw>3)
        goto idop 'NONE OF THE FOLLOWING
      elseif wr="and"
        n=33 : prl=3
      elseif wr="or"
        n=34 : prl=1
      elseif wr="xor"
        n=35 : prl=2
      elseif wr="shl"
        n=74 : prl=5
      elseif wr="shr"
        n=75 : prl=5
      elseif wr="rol"
        n=76 : prl=5
      elseif wr="ror"
        n=77 : prl=5
      elseif wr="pow"
        n=94 : prl=8
      elseif wr="mod"
        n=93 : prl=7
      endif
    end select
  endif



John

  • Hero Member
  • *****
  • Posts: 3600
Re: Update 0.2
« Reply #9 on: June 08, 2019, 08:53:59 AM »
First time I've seen CASE and ELSEIF in the same bed together. The best of both flow structures working together.

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #10 on: June 08, 2019, 12:46:56 PM »
EQV and IMP are bitwise operators, but I would like to use them as logical operators. If AND and OR are & and |, then EQV and IMP would be like && and ||... as far as i can remember it was like that. But i dont remember very well.

Charles Pegge

  • Admin Support Member
  • *****
  • Posts: 4097
    • Oxygen Basic
« Last Edit: June 08, 2019, 05:39:26 PM by Charles Pegge »

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #12 on: June 08, 2019, 01:44:07 PM »
Look at this:

Brian Alvarez

  • Sr. Member
  • ****
  • Posts: 375
    • PluriBASIC
Re: Update 0.2
« Reply #13 on: June 08, 2019, 02:11:48 PM »
The bitwise part, i dont care. I have never used them for that. Just plan logical or/and would do.