SjASMPlus Z80 кросс ассемблер

[SAM style]

В общем, поскольку 99% людей пользуется сборщиками (make, bat), а если и запускают - ходят в папку с проектом перед запуском - то это действительно несколько странный запрос. Несложно ж сделать мейк и не думать через год, чего там как собирается, разве не так?

НАЙН! Я не про это. Посмотри вложение в прошлом посте - там в комментариях написано. Где должен лежать файл, который подключается из файла, который сам подключен из main.asm и лежит в поддиректории?

[introspec]

НАЙН! Я не про это. Посмотри вложение в прошлом посте - там в комментариях написано.

SAM style, я посмотрел и придерживаюсь старой точки зрения. Если все библиотеки лежат в "include\...", логично что ты все библиотеки так именно и включаешь. Си имеет систему дополнительных папок, типа lib, которые прибиты гвоздями, сорри, считаются по относительным путям от экзешника. По идее, такие доп. пути сделали бы то, что тебе хочется.

Чтобы чётче прозвучало: я очень люблю проекты со 100500 файлами разбросанными по папкам, т.е. я очень активно использую и include, и incbin. Но то, что тебе хочется сделать, кажется мне актуальным только если гонять файлы из папки в папку. Обычно мне не хочется это сделать. Ты уверен, что ты именно что хочешь это сделать?

[SAM style]

Чтобы чётче прозвучало: я очень люблю проекты со 100500 файлами разбросанными по папкам, т.е. я очень активно использую и include, и incbin. Но то, что тебе хочется сделать, кажется мне актуальным только если гонять файлы из папки в папку. Обычно мне не хочется это сделать. Ты уверен, что ты именно что хочешь это сделать?

Я не очень люблю кучу файлов, а ещё больше не люблю, когда в огромных файлах каша из тонн кода и данных. Но проект разбух до такой степени, что неизбежно появится либо одно, либо другое.
Если сравнивать с Си, то Сджасмовские инклюды куда ближе к #include "file", чем к #include <file>. В первом случае никаких дополнительных путей не надо - путь у файлу рассчитывается относительно директории файла, из которого он подключен. Внезапно подумалось, что и здесь действует такой же подход, а нет...

[Vitamin]

introspec, а ты можешь припомнить другие тулзы, обрабатывающие инклюды относительно не текущего файла, а относительно текущей директории?

[introspec]

introspec, а ты можешь припомнить другие тулзы, обрабатывающие инклюды относительно не текущего файла, а относительно текущей директории?

Так ведь текущая папка - понятие командного процессора, а не вызванной утилиты. Поэтому любые утилиты так работают. Сишный стандарт вот так из головы сейчас не вспомню, но нахожу удобство относительных файловых путей скорее спорным.



Sent from my HTC One using Tapatalk

[Vitamin]

Так ведь текущая папка - понятие командного процессора, а не вызванной утилиты.

Нет. Это свойство процесса.
http://linux.die.net/man/3/getcwd

Сишный стандарт вот так из головы сейчас не вспомню, но нахожу удобство относительных файловых путей скорее спорным.

В с/с++ правила несколько сложнее.

http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html

GCC looks for headers requested with #include "file" first in the directory containing the current file, then in the directories as specified by -iquote options, then in the same places it would have looked for a header requested with angle brackets. For example, if /usr/include/sys/stat.h contains #include "types.h", GCC looks for types.h first in /usr/include/sys, then in its usual search path.

http://msdn.microsoft.com/ru-ru/library/36k2cdd4.aspx

Препроцессор ищет включаемые файлы в следующем порядке:
В том же каталоге, где находится файл с оператором #include.
В каталогах открытых в данный момент включаемых файлов (в порядке, обратном тому, в котором они открывались). Поиск начинается в каталоге родительского включаемого файла, а затем выполняется в каталогах всех включаемых файлов-прародителей.
По путям, заданным всеми параметрами компилятора /I.
По путям, заданным в переменной среды INCLUDE.

Как видно, "текущий каталог процесса" тут никоим боком не присутствует, зато присутствует путь текущего файла.

[introspec]

Нет. Это свойство процесса.
http://linux.die.net/man/3/getcwd

Ну да, а как называется наш процесс при сборке из батника? "cmd"! Вот поэтому поведение компилятора си и кажется не до конца логичным: оно может работать только в рамках одной программы или пакета вместе написанных программ. При сборке лапшой из разного кода это не работает.

[Vitamin]

Ну да, а как называется наш процесс при сборке из батника? "cmd"!

sjasmplus.exe он называется в случае винды. Или cmd уже умеет инклюдить файлы и преобразовывать их в объектный код для зетника?

Вот поэтому поведение компилятора си и кажется не до конца логичным: оно может работать только в рамках одной программы или пакета вместе написанных программ. При сборке лапшой из разного кода это не работает.

Бл... ин! ЧТО ИМЕННО не работает? Ты хорошо выходные отпраздновал чтоли?

[esl]

Подскажите, можно ли создать новую метку в макросе ?
что-то типа такого (это перебежал в PASM)

        macro xx, nn,hh,value
        fn_ ## nn ## _h ## hh ## _i0:
            ld  a,value
            jp  do_fill
        fn_ ## nn ## _h ## hh ## _i1:
            ld  a,value XOR 0xff
            jp  do_fill
        endm

do_fill:

        xx '1','0',11110000b
        xx '2','0',01111000b
        xx '3','0',00111100b
        xx '4','0',00011110b
        xx '5','0',00001111b

получаем такое

do_fill		EQU 00000H
fn_1_h0_i0	EQU 00000H
fn_1_h0_i1	EQU 00005H
fn_2_h0_i0	EQU 0000AH
fn_2_h0_i1	EQU 0000FH
fn_3_h0_i0	EQU 00014H
fn_3_h0_i1	EQU 00019H
fn_4_h0_i0	EQU 0001EH
fn_4_h0_i1	EQU 00023H
fn_5_h0_i0	EQU 00028H
fn_5_h0_i1	EQU 0002DH

т.е конструируем имя теки из параметров.
такое еще m80 81года рождения умел.

---------- Post added at 16:37 ---------- Previous post was at 16:36 ----------

и заодно, можно ли в LUA скрипт параметр передать (типа как луа как макрос с параметром)

примеров в доке ЖУТКО не хватает.

[esl]

спасибо, а вызывать как ?
пример бы