Mad Pascal

[Shawn Jefferson]

With cc65, you need to remember that there are only 6 bytes of register variables (really zeropage locations that are saved and restored depending on which ones your functions use-and this adds overhead to your function too!), but since you are using static local variables, the others that don't get fit as register are in BSS (ie. given a static location, and not on the C stack), which usually makes the code faster and smaller. In Ilmenit's code anyway.

 

In any project that isn't trivial, you will optimize your function variables appropriately, using register where appropriate and also just allocating your own zeropage variables also.

 

Also, as you've pointed out, printf family of functions are quite large... for obvious reasons I think (compatibility, portability, flexibility, etc...) Also, file I/O is also quite large with cc65 and is sometimes better to roll your own unless you are looking for portability, IMO.

[funkheld]

cc65 is deprecated.

it is out.

since neither programmed with more.

greeting

Edited December 25, 2015 by funkheld

[Shawn Jefferson]

 

cc65 is deprecated.

it is out.

since neither programmed with more.

 

huh? It's very much NOT deprecated and actively maintained.

 

http://cc65.github.io/cc65/

[funkheld]

is nonsense.

none created more programs with the cc65 for atari800.

too much time spent on a working or still has other things on his mind.

cc65 is a waste of time from life.

greeting

[funkheld]

MadPascal...

 

wonderfull.

 

greeting

[ilmenit]

 

is nonsense.

none created more programs with the cc65 for atari800.

too much time spent on a working or still has other things on his mind.

cc65 is a waste of time from life.

greeting

 

I don't want to steal the thread but this is bullshit, software is being created in cc65: from this year at least: port of Moria and Turbo Snail. Previously The Hunt, Roxblox, His Dark Majesty etc.

 

Tebe, do you plan to create optimizer for Mad Pascal? I recently found a nice document about optimizations in VBCC compiler - a nice one for inspiration. Still a peephole optimizer would be probably the best. As more and more code is being created that outputs MADS asm (Effectus, Atalan) maybe it wouldn't be bad to create a peephole optimizer compatible for it :-) I think that 6502 CPU is simple enough even to create a superoptimizer for it. Would anyone like to participate in such project?

[tebe]

yes, optimizer for MP is almost finished

 

in attachment sieve example (with optimization)

sieve.zip

[ilmenit]

Nice! :-)

[danwinslow]

Mad Pascal sounds great. CC65 is great also, and still in heavy use.

[Gury]

I noticed some changes in Mad Pascal 1.2.9. Procedures with assembler code are now followed with assembler directive and pushing and pulling of X register is done by txa:pha / pla:tax pair of code.

 

Graphics programs are really fast now with the help od FastGraph unit library. Circle and line examples simply vrooomm!!!

[tebe]

yes, new directive for proc/func: assembler, forward, overload

 

http://wiki.freepascal.org/Forward_Referencing

 

http://www.freepascal.org/docs-html/ref/refsu80.html

[tebe]

news from future

 

recursion allowed, propably with new modificator like 'dynamic'

procedure name(a,b: integer); dynamic;

now all procedures/functions are dynamically allocated variables

 

with modificator 'dynamic' only selected, it's important for speed

recursion.zip

Edited January 1, 2016 by tebe

[JamesD]

Recursion should be supported by default to be compatible with the Pascal standard.
I would create an extension similar to C's static to alter the behavior rather than the other way around.
But that's just me.

[danwinslow]

What James said, but really I don't follow what you mean by 'dynamic'. Do you mean that will be required for recursion, or that recursion will be faster with it? Not understanding.

[JamesD]

What James said, but really I don't follow what you mean by 'dynamic'. Do you mean that will be required for recursion, or that recursion will be faster with it? Not understanding.

Normally, when you make a subroutine call in Pascal, local variables are supposed to go out of scope and the subroutine has it's own variable space on the stack.

They are preserved on the stack before the subroutine is executed and are restored when the subroutine returns.

That would be dynamic. The variables including parameters don't hold the same value from one call to the next.

Technically, I don't think it specifies you use a stack, that's just the typical approach.

 

I don't really know what Mad Pascal is doing but I assume something is static to make the program smaller and/or faster.

That would imply at present, some variable or parameter is stored in the same memory if you try a recursive call.

A recursive call of a subroutine could interfere with the previous call's variables.

But I'm just speculating since I haven't looked at what is going on.

Edited January 1, 2016 by JamesD

[danwinslow]

Ah. Yeah that'd be a pretty big departure from normal Pascal. I guess I was assuming that Mad Pascal had the normal stack mechanisms. On such a limited machine, it's understandable, but I think they'll wind up wanting to go the normal call parameter stack route, and then maybe mark things as you mentioned if they want the static semantics and speed.

[tebe]

add VBXE (Color Map, 40x30, cell 8x8)

 

tested only with Altirra

// VBXE Color Map Graphics
 
uses crt, graph;
 
const
charsets = $8000;
 
var f: file;
    p: ^byte;
    chrAdr, i: byte;
 
    
procedure vbl; interrupt; assembler;
asm
{ mva >charsets chrAdr
 
jmp xitvbv
};
end;
 
 
procedure dli; interrupt; assembler;
asm
{ pha
 
lda chrAdr
sta wsync
sta chbase
 
add #4
sta chrAdr
 
pla
};
end;
 
 
begin
 
 InitGraph(vbxe, 12, '');
 
 p:=pointer(dpeek(88));
 assign(f, 'D:DONTTURN.SCR'); reset(f, 1);
 blockread(f, p, 40*24);
 close(f);
 
 p:=pointer(charsets);
 assign(f, 'D:DONTTURN.FNT'); reset(f, 1);
 blockread(f, p, 1024*;
 close(f);
 
 SetVideoBank($80);
 
 p:=pointer($4100+3*160);
 assign(f, 'D:DONTTURN.CMP'); reset(f, 1);
 blockread(f, p, 160*24);
 close(f);
 
 SetVideoBank(0);
 
 intr(iVBL, @vbl);
 
 intr(iDLI, @dli);
 
 p:=pointer(dpeek($230)+2);
 
 p^:=$f0;
 
 inc(p, 5);
 
 for i:=0 to 6 do begin
  p^:=$84;
  inc(p, 3);
 end;
 
 poke($d40e, $c0);
 
 SetBkColor(6);
 
 repeat until keypressed;
 
 clrscr;
end.

vbxe_mp.zip

Edited February 15, 2016 by tebe

[tebe]

MadPascal 1.3.0

 

+ {$i filename}

+ -o Optimize code

+ CONST by Type

const

a: word = 5; // WORD

b = 5; // BYTE

+ INTERRUPT, FORWARD, REGISTER

+ ColorMap (40x30x8x8) VBXE (unitGRAPH, CRT), SetColorMap, SetColorCell, SetVideoBank

+ SYSUTILS: TSearchRec, FindFirst, FindNext, FindClose

+ GRAPH: FillRect

+ SYSTEM: LOW, HIGH, SIZEOF, INTR (INTERRUPT_NUMBER), binStr, octStr, hexStr

mp_130.zip

Edited February 22, 2016 by tebe

[Gury]

THAT's what I am talking about New and outstanding features.

 

Thank you, Tebe.

[ilmenit]

Does MADS Pascal allow to build code into specific addresses (like ORG in asm) or set addresses for code, data, bss, heap etc.? Maybe something similar to http://www.cc65.org/doc/ld65-5.html ?

[pps]

Cool, MP rises more and more into a mature programming tool

[ilmenit]

Tebe did a great job also internally with the optimizer :-)

[Gury]

Is it possible to use Write routine with channel #6 in text modes 1 and 2? Or do I have to poke to display memory to show a character in specific color?

GotoXY and Write routines do seem to work only in text mode 0 and in window area in graphics modes.

[pirx]

 

I think that 6502 CPU is simple enough even to create a superoptimizer for it. Would anyone like to participate in such project?

This is one bold idea! Superoptimized plot would rock

[tebe]

MadPascal 1.3.1 http://mads.atari8.info